Bug#814030: Security flaw fixed in version 6.2.0
Hi, I just add maintainer and uploader to the loop. Hopefully, they should know something about the package/code/issue. Le 04/01/2017 à 21:42, Salvatore Bonaccorso a écrit : > On Sun, Mar 27, 2016 at 01:33:01PM +0200, Moritz Mühlenhoff wrote: >> On Sun, Feb 07, 2016 at 02:28:04PM -0400, David Prévot wrote: >>> Package: php-tcpdf >>> Version: 6.0.093+dfsg-1 >>> Severity: serious >>> Tags: security upstream >>> >>> According to their changelog [1], upstream fixed a security issue over a >>> year ago: >>> >>> 6.2.0 (2014-12-10) >>> - Bug #1005 "Security Report, LFI posting internal files externally >>> abusing default parameter" was fixed. >>> >>> 1: https://sourceforge.net/p/tcpdf/code/ci/master/tree/CHANGELOG.TXT >>> >>> The upstream bug report [2] is not public, so I don’t have much >>> information about the issue, the fix, nor it’s actual severity. >>> >>> 2: https://sourceforge.net/p/tcpdf/bugs/1005/ >> >> Can you contact upstream for information on this security bug? I have >> no idea what that could possibly mean. > > Did you got any information on that from upstream? The bug is stil > closed, so does not really help. > > Regards, > Salvatore signature.asc Description: OpenPGP digital signature
Bug#850226: no longer advertises route
Package: quagga-bgpd Version: 1.1.0-3 Severity: grave Hi, I lost all of my IPv6 connectivity this morning; a bit of searching shows that it is due to an automated upgrade of: 2017-01-05 07:36:26 upgrade quagga:amd64 1.0.20160315-2 1.1.0-3 None of the neighbors see my IPv6 route anymore; it is not in the table, and the peers (over various GRE tunnels, using link-local addresses) say: altersex# show bgp neighbors fe80::5ccc:2ed1 routes altersex# Similarly for another Quagga peer: pannekake.samfundet.no# show bgp neighbors fe80::5ccc:2ed1 routes pannekake.samfundet.no# My side claims it's advertising the network to one of them, though: morgental# show bgp neighbors fe80::c30b:9a61 advertised-routes BGP table version is 0, local router ID is 80.218.216.227 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Origin codes: i - IGP, e - EGP, ? - incomplete Network Next HopMetric LocPrf Weight Path *> 2001:67c:29f4::/48 fe80::5ccc:2ed1600 0 58302 i But somehow not to the other one: morgental# show bgp neighbors fe80::6bbf:a185 advertised-routes morgental# Restart of the daemon does not work, but downgrading Quagga back to the previous version (1.0.20160315-3) immediately fixes the issue: pannekake.samfundet.no# show bgp neighbors fe80::5ccc:2ed1 routes BGP table version is 0, local router ID is 129.241.93.35 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Origin codes: i - IGP, e - EGP, ? - incomplete Network Next HopMetric LocPrf Weight Path *> 2001:67c:a4::/48 :: 600 0 48908 i Total number of prefixes 1 pannekake.samfundet.no# Here's the entire Quagga config, for reference: morgental# show run Building configuration... Current configuration: ! hostname morgental log file /var/log/quagga/quagga.log log file /var/log/quagga/ospf6d.log hostname fugl log file /var/log/quagga/bgpd.log bgp multiple-instance ! service advanced-vty ! debug ospf6 lsa unknown debug bgp ! password enable password ! interface bablefisk no link-detect ! interface br0 no link-detect ! interface elfkin no link-detect ! interface eno1 no link-detect ! interface enp2s0 no link-detect ! interface enp2s0.2 no link-detect ! interface enp2s0.3 no link-detect ! interface enp2s0.10 no link-detect ! interface enp2s0.11 no link-detect ! interface eth0 no link-detect ! interface eth0.2 no link-detect ! interface eth0.3 no link-detect ! interface eth0.4 no link-detect ! interface eth0.5 no link-detect ! interface eth0.10 no link-detect ! interface eth0.11 no link-detect ! interface eth0.2000 no link-detect ! interface eth2 no link-detect ! interface fnismc no link-detect ! interface foo no link-detect ! interface gre0 no link-detect ! interface gretap0 no link-detect ! interface he-ipv6 no link-detect ! interface ifb0 no link-detect ! interface ifb1 no link-detect ! interface ip6gre0 no link-detect ! interface ip6tnl0 no link-detect ! interface k_adamcik no link-detect ! interface k_altersex no link-detect ipv6 ospf6 cost 1 ipv6 ospf6 network broadcast ! interface k_berge no link-detect ! interface k_jodal no link-detect ! interface k_klette no link-detect ! interface k_kletteoslo no link-detect ! interface k_magne no link-detect ipv6 ospf6 cost 1 ipv6 ospf6 network broadcast ! interface k_molven no link-detect ipv6 ospf6 cost 1 ipv6 ospf6 network broadcast ! interface k_molvenfinnoy no link-detect ! interface k_pannekake no link-detect ! interface k_sandsmark no link-detect ! interface k_sesse no link-detect ipv6 ospf6 cost 1 ipv6 ospf6 network broadcast ! interface k_torvaldl no link-detect ! interface k_trygve no link-detect ! interface k_underworld no link-detect ! interface k_wikene no link-detect ! interface k_xml no link-detect ! interface l2tpeth0 no link-detect ! interface lo no link-detect ! interface merete no link-detect ! interface nat64 no link-detect ! interface pan0 no link-detect ! interface pimreg no link-detect ! interface renater no link-detect ! interface sit0 no link-detect ! interface test no link-detect ! interface tungre no link-detect ! interface wlan0 no link-detect ! interface wlp3s0 no link-detect ! interface wmaster0 no link-detect ! router bgp 48908 bgp router-id 80.218.216.227 bgp always-compare-med bgp bestpath med missing-as-worst neighbor kvadratsky peer-group neighbor kvadratsky next-hop-self neighbor kvadratsky soft-reconfiguration inbound neighbor kvadratsky prefix-list kvadratsky in neighbor 2001:470:12:84::1 remote-as 6939 neighbor 2001:470:12:84::1 update-source 2001:470:12:84::2 neighbor 2001:470:12:84::1 next-hop-self neighbor 2001:470:12:84::1 soft-reconfigurati
Processed: severity of 850196 is normal
Processing commands for cont...@bugs.debian.org:
> severity 850196 normal
Bug #850196 {Done: Niels Thykier } [release.debian.org]
unblock: dgit/2.14
Severity set to 'normal' from 'grave'
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
850196: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850196
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#786566: this is affecting us
Peter Palfrader writes: > It's a serious bug that makes it break in many cases, requiring the > sysadmin to clean up and/or reboot the system. Whether or not it's RC > in the end is the decision of the release team, but this severity was > set after discussing this on #debian-release. Is anything being done to fix this? What is the hold up? Apparently there is a patch for this RC bug and the other RC bug #817236. It is kind of looking like stretch will get released without schroot support, or any packages that depend on it. Maybe time to forgot schroot and look for alternatives??? -- Brian May
Bug#850215: [pkg-php-pear] Bug#850215: zendframework: CVE-2016-10034
On 05.01.2017 07:01, Salvatore Bonaccorso wrote: > Source: zendframework > Version: 1.12.9+dfsg-1 > Severity: grave > Tags: upstream security > Justification: user security hole > > Hi, > > the following vulnerability was published for zendframework. > > CVE-2016-10034[0]: > | The setFrom function in the Sendmail adapter in the zend-mail > | component before 2.4.11, 2.5.x, 2.6.x, and 2.7.x before 2.7.2, and > | Zend Framework before 2.4.11 might allow remote attackers to pass > | extra parameters to the mail command and consequently execute > | arbitrary code via a \" (backslash double quote) in a crafted e-mail > | address. > > If you fix the vulnerability please also make sure to include the > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. > > For further information see: > > [0] https://security-tracker.debian.org/tracker/CVE-2016-10034 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10034 > > Please adjust the affected versions in the BTS as needed. Hi Salvatore, thanks for bringing that up. I actually don't think this CVE is valid for ZendFramework 1 (Version < 2). Not only there are big differences in class structure between ZF1 and ZF >= 2.0, but many features have been introduced first in ZF > 2. I see no specific handling for a From header in Zend_Mail_Transport_Sendmail. https://github.com/zendframework/zf1/blob/master/library/Zend/Mail/Transport/Sendmail.php#L128 A user of the library would be able to insert additional parameters, and pass whatever argument to sendmail. But the user would have to care about securing / escaping then. As we currently don't have a package for Zend-Mail, and zendframework is < 2, this bug wouldn't affect Debian. Would love if someone could approve or object my analysis. Cheers Markus Frosch -- mar...@lazyfrosch.de / lazyfro...@debian.org http://www.lazyfrosch.de signature.asc Description: OpenPGP digital signature
Bug#850215: [pkg-php-pear] Bug#850215: zendframework: CVE-2016-10034
Hi On Thu, Jan 05, 2017 at 10:34:29AM +0100, Markus Frosch wrote: > On 05.01.2017 07:01, Salvatore Bonaccorso wrote: > > Source: zendframework > > Version: 1.12.9+dfsg-1 > > Severity: grave > > Tags: upstream security > > Justification: user security hole > > > > Hi, > > > > the following vulnerability was published for zendframework. > > > > CVE-2016-10034[0]: > > | The setFrom function in the Sendmail adapter in the zend-mail > > | component before 2.4.11, 2.5.x, 2.6.x, and 2.7.x before 2.7.2, and > > | Zend Framework before 2.4.11 might allow remote attackers to pass > > | extra parameters to the mail command and consequently execute > > | arbitrary code via a \" (backslash double quote) in a crafted e-mail > > | address. > > > > If you fix the vulnerability please also make sure to include the > > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. > > > > For further information see: > > > > [0] https://security-tracker.debian.org/tracker/CVE-2016-10034 > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10034 > > > > Please adjust the affected versions in the BTS as needed. > > Hi Salvatore, > thanks for bringing that up. > > I actually don't think this CVE is valid for ZendFramework 1 (Version < 2). > > Not only there are big differences in class structure between ZF1 and ZF >= > 2.0, > but many features have been introduced first in ZF > 2. > > I see no specific handling for a From header in Zend_Mail_Transport_Sendmail. > > https://github.com/zendframework/zf1/blob/master/library/Zend/Mail/Transport/Sendmail.php#L128 > > A user of the library would be able to insert additional parameters, and pass > whatever > argument to sendmail. But the user would have to care about securing / > escaping then. > > As we currently don't have a package for Zend-Mail, and zendframework is < 2, > this bug > wouldn't affect Debian. > > Would love if someone could approve or object my analysis. Adding Thijs to the loop, who did some additional research, which triggered us to change the status from to in the security-tracker. Regards, Salvatore
Bug#838704: gnustep-dl2-postgresql-adaptor: fails to upgrade on a long grown system
Hello, in d/gnustep-dl2-postgresql-adaptor.maintscript the first link uses "Current" which is already a symlink. When one replaces this with "0" the upgrade works fine. (I tested this with -9+nmu build on sid upgrading to the patched -15 which also failed here for the unpatched version. I would prepare an NMU but: The packaging git does not contain the latest version (i.e. -15) but only -14, so I don't know whether you have already any updates privately queued up. The package has two lintian errors that should either be suppressed or corrected: E: gnustep-dl2-sqlite-adaptor: arch-dependent-file-in-usr-share usr/share/GNUstep/Frameworks/SQLite3EOAdaptor/Versions/0/LoginPanel.bun dle/LoginPanel E: gnustep-dl2-postgresql-adaptor: arch-dependent-file-in-usr-share usr/share/GNUstep/Frameworks/PostgreSQLEOAdaptor/Versions/0/LoginPanel. bundle/LoginPanel I guess the *plist file is considered to be arch-dependent, although I don't see why given its content. I've attached the according patch to fix this bug. Best, Gert --- gnustep-dl2-0.12.0/debian/gnustep-dl2-postgresql-adaptor.maintscript 2016-07-13 09:56:56.0 + +++ gnustep-dl2-0.12.0.new/debian/gnustep-dl2-postgresql-adaptor.maintscript 2017-01-05 09:28:36.346876308 + @@ -1,4 +1,4 @@ -symlink_to_dir /usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Resources /usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Versions/Current/Resources 0.12.0-15~ +symlink_to_dir /usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Resources /usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Versions/0/Resources 0.12.0-15~ dir_to_symlink /usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Versions/0/Headers /usr/include/GNUstep/PostgreSQLEOAdaptor 0.12.0-14~ dir_to_symlink /usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Resources/LoginPanel.bundle/Resources /usr/share/GNUstep/Frameworks/PostgreSQLEOAdaptor/LoginPanel.bundle 0.12.0-14~ dir_to_symlink /usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Versions/0/Resources /usr/share/GNUstep/Frameworks/PostgreSQLEOAdaptor/Versions/0 0.12.0-14~
Bug#814030: Security flaw fixed in version 6.2.0
Hi, CCing upstream author for confirmation. Nicola we are trying to understand what security fix went into tcpdf 6.2.0. The bug is private on sourceforge, could you make it public now? For more details see: https://bugs.debian.org/814030 On Wed, 04 Jan 2017, David Prévot wrote: > >> Can you contact upstream for information on this security bug? I have > >> no idea what that could possibly mean. > > > > Did you got any information on that from upstream? The bug is stil > > closed, so does not really help. I did not contact upstream but looking at the changes in that version: https://sourceforge.net/p/tcpdf/code/ci/40662daa766bd3a6b5eafa44dfde680ee6661716/tree/tcpdf.php?diff=3d5921442e7adde1ce225104118bc246a1933c65 https://sourceforge.net/p/tcpdf/code/ci/40662daa766bd3a6b5eafa44dfde680ee6661716/tree/include/tcpdf_fonts.php?diff=3d5921442e7adde1ce225104118bc246a1933c65 https://sourceforge.net/p/tcpdf/code/ci/40662daa766bd3a6b5eafa44dfde680ee6661716/tree/include/tcpdf_static.php?diff=3d5921442e7adde1ce225104118bc246a1933c65 I see calls to fopen() being replaced by TCPDF_STATIC::fopenLocal() which does ensure that we pass only "file://" URL or which add this prefix if there's no "://" in the string. So I guess that this issue is related to this. All the fopen() calls are for files to which we write so I guess that we can possibly inject "ftp://"; URL in some parameters and get some local files sent to a remote location. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Bug#850229: dune-grid: FTBFS (not enough slots available)
Package: src:dune-grid Version: 2.5.0-1 Severity: serious Dear maintainer: I tried to build this package in stretch with "dpkg-buildpackage -A" (which is what the "Arch: all" autobuilder would do to build it) but it failed: [...] debian/rules build-indep dh build-indep --parallel --builddirectory=build dh_testdir -i -O--parallel -O--builddirectory=build dh_update_autotools_config -i -O--parallel -O--builddirectory=build debian/rules override_dh_auto_configure make[1]: Entering directory '/<>' dh_auto_configure -- -DBUILD_SHARED_LIBS=1 cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DBUILD_SHARED_LIBS=1 -- The C compiler identification is GNU 6.2.1 -- The CXX compiler identification is GNU 6.2.1 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info [... snipped ...] Status:FAILED Output: -- There are not enough slots available in the system to satisfy the 2 slots that were requested by the application: test-yaspgrid-yaspfactory-1d Either request fewer slots for your application, or make more slots available for use. -- == Name: test-yaspgrid-yaspfactory-2d-mpi-2 FullName: ./dune/grid/test/yasp/test-yaspgrid-yaspfactory-2d-mpi-2 Status:FAILED Output: -- There are not enough slots available in the system to satisfy the 2 slots that were requested by the application: test-yaspgrid-yaspfactory-2d Either request fewer slots for your application, or make more slots available for use. -- == Name: test-yaspgrid-yaspfactory-3d-mpi-2 FullName: ./dune/grid/test/yasp/test-yaspgrid-yaspfactory-3d-mpi-2 Status:FAILED Output: -- There are not enough slots available in the system to satisfy the 2 slots that were requested by the application: test-yaspgrid-yaspfactory-3d Either request fewer slots for your application, or make more slots available for use. -- /usr/share/dune/dune-debian.mk:16: recipe for target 'override_dh_auto_test' failed make[1]: *** [override_dh_auto_test] Error 1 make[1]: Leaving directory '/<>' debian/rules:6: recipe for target 'build-indep' failed make: *** [build-indep] Error 2 dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2 This is just how the build ends, not necessarily the relevant part. I've put several build logs here: https://people.debian.org/~sanvila/build-logs/dune-grid/ If this is really a bug in one of the build-depends, please use reassign and affects, so that this is still visible in the page for this package. The bug should be reproducible with sbuild on a single CPU virtual machine. It always fail for me (I tried 10 times in different autobuilders). Thanks.
Bug#850236: python-django: FTBFS (AssertionError)
Package: src:python-django
Version: 1:1.10.3-2
Severity: serious
Dear maintainer:
I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:
[...]
debian/rules build-indep
dh build-indep --with sphinxdoc,python2,python3 --buildsystem=pybuild
dh_testdir -i -O--buildsystem=pybuild
dh_update_autotools_config -i -O--buildsystem=pybuild
dh_auto_configure -i -O--buildsystem=pybuild
I: pybuild base:184: python2.7 setup.py config
running config
I: pybuild base:184: python3.5 setup.py config
running config
debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
dh_auto_build
I: pybuild base:184: /usr/bin/python setup.py build
[... snipped ...]
test_options (generic_views.test_base.ViewTest) ... ok
test_options_for_get_and_post_view (generic_views.test_base.ViewTest) ... ok
test_options_for_get_view (generic_views.test_base.ViewTest) ... ok
test_options_for_post_view (generic_views.test_base.ViewTest) ... ok
test_pathological_http_method (generic_views.test_base.ViewTest) ... ok
test_response_without_messages (messages_tests.test_middleware.MiddlewareTest)
... ok
test_script_prefix_set_in_commands (user_commands.tests.CommandRunTests) ... ok
==
FAIL: test_timesince07
(template_tests.filter_tests.test_timesince.TimesinceTests)
--
Traceback (most recent call last):
File "/<>/django/test/utils.py", line 205, in inner
return func(*args, **kwargs)
File "/<>/tests/template_tests/utils.py", line 61, in inner
func(self)
File "/<>/tests/template_tests/filter_tests/test_timesince.py",
line 67, in test_timesince07
self.assertEqual(output, '1\xa0week')
AssertionError: u'6\xa0days' != u'1\xa0week'
==
FAIL: test_timesince08
(template_tests.filter_tests.test_timesince.TimesinceTests)
--
Traceback (most recent call last):
File "/<>/django/test/utils.py", line 205, in inner
return func(*args, **kwargs)
File "/<>/tests/template_tests/utils.py", line 61, in inner
func(self)
File "/<>/tests/template_tests/filter_tests/test_timesince.py",
line 74, in test_timesince08
self.assertEqual(output, '1\xa0week')
AssertionError: u'6\xa0days' != u'1\xa0week'
--
Ran 11263 tests in 245.226s
FAILED (failures=2, skipped=1064, expected failures=5)
OK
Destroying test database for alias 'default' (':memory:')...
Destroying test database for alias 'other' (':memory:')...
debian/rules:24: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>'
debian/rules:12: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2
This is just how the build ends, not necessarily the relevant part.
I've put several build logs here:
https://people.debian.org/~sanvila/build-logs/python-django/
If this is really a bug in one of the build-depends, please use reassign and
affects,
so that this is still visible in the page for this package.
The bug should be reproducible with sbuild on a single CPU virtual machine.
It always fail for me (I tried 10 times in different autobuilders), and it
also fails here:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-django.html
Thanks.
Bug#850230: fabric: FTBFS (sbuild hangs)
Package: src:fabric
Version: 1.13.1-1
Severity: serious
Dear maintainer:
I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:
[...]
debian/rules build-indep
dh build-indep --with python2,sphinxdoc --buildsystem=pybuild
dh_testdir -i -O--buildsystem=pybuild
dh_update_autotools_config -i -O--buildsystem=pybuild
dh_autoreconf -i -O--buildsystem=pybuild
dh_auto_configure -i -O--buildsystem=pybuild
I: pybuild base:184: python2.7 setup.py config
running config
dh_auto_build -i -O--buildsystem=pybuild
I: pybuild base:184: /usr/bin/python setup.py build
running build
running build_py
creating /<>/.pybuild/pythonX.Y_2.7/build/fabric
[... snipped ...]
copying fabric/exceptions.py ->
/<>/.pybuild/pythonX.Y_2.7/build/fabric
copying fabric/colors.py -> /<>/.pybuild/pythonX.Y_2.7/build/fabric
copying fabric/job_queue.py ->
/<>/.pybuild/pythonX.Y_2.7/build/fabric
creating /<>/.pybuild/pythonX.Y_2.7/build/fabric/contrib
copying fabric/contrib/django.py ->
/<>/.pybuild/pythonX.Y_2.7/build/fabric/contrib
copying fabric/contrib/console.py ->
/<>/.pybuild/pythonX.Y_2.7/build/fabric/contrib
copying fabric/contrib/__init__.py ->
/<>/.pybuild/pythonX.Y_2.7/build/fabric/contrib
copying fabric/contrib/files.py ->
/<>/.pybuild/pythonX.Y_2.7/build/fabric/contrib
copying fabric/contrib/project.py ->
/<>/.pybuild/pythonX.Y_2.7/build/fabric/contrib
dh_auto_test -i -O--buildsystem=pybuild
I: pybuild base:184: cd /<>/.pybuild/pythonX.Y_2.7/build;
python2.7 -m nose tests
.Traceback
(most recent call last):
File
"/<>/.pybuild/pythonX.Y_2.7/build/tests/Python26SocketServer.py",
line 561, in process_request_thread
self.finish_request(request, client_address)
File
"/<>/.pybuild/pythonX.Y_2.7/build/tests/Python26SocketServer.py",
line 320, in finish_request
self.RequestHandlerClass(request, client_address, self)
File
"/<>/.pybuild/pythonX.Y_2.7/build/tests/Python26SocketServer.py",
line 631, in __init__
self.handle()
File "/<>/.pybuild/pythonX.Y_2.7/build/tests/server.py", line
361, in handle
if self.sudo_prompt and not self.sudo_password():
File "/<>/.pybuild/pythonX.Y_2.7/build/tests/server.py", line
426, in sudo_password
self.channel.send(env.sudo_prompt)
File "/usr/lib/python2.7/dist-packages/paramiko/channel.py", line 715, in send
return self._send(s, m)
File "/usr/lib/python2.7/dist-packages/paramiko/channel.py", line 1075, in
_send
raise socket.error('Socket is closed')
error: Socket is closed
..Traceback (most recent call last):
File
"/<>/.pybuild/pythonX.Y_2.7/build/tests/Python26SocketServer.py",
line 561, in process_request_thread
self.finish_request(request, client_address)
File
"/<>/.pybuild/pythonX.Y_2.7/build/tests/Python26SocketServer.py",
line 320, in finish_request
self.RequestHandlerClass(request, client_address, self)
File
"/<>/.pybuild/pythonX.Y_2.7/build/tests/Python26SocketServer.py",
line 631, in __init__
self.handle()
File "/<>/.pybuild/pythonX.Y_2.7/build/tests/server.py", line
361, in handle
if self.sudo_prompt and not self.sudo_password():
File "/<>/.pybuild/pythonX.Y_2.7/build/tests/server.py", line
426, in sudo_password
self.channel.send(env.sudo_prompt)
File "/usr/lib/python2.7/dist-packages/paramiko/channel.py", line 715, in send
return self._send(s, m)
File "/usr/lib/python2.7/dist-packages/paramiko/channel.py", line 1075, in
_send
raise socket.error('Socket is closed')
error: Socket is closed
.
E: Build killed with signal TERM after 60 minutes of inactivity
This is just how the build ends, not necessarily the relevant part.
I've put several build logs here:
https://people.debian.org/~sanvila/build-logs/fabric/
If this is really a bug in one of the build-depends, please use reassign and
affects,
so that this is still visible in the page for this package.
The bug should be reproducible with sbuild on a single CPU virtual machine.
It always fail for me (I tried 10 times in different autobuilders), and
it also fails here:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/fabric.html
Thanks.
Bug#849718: Can not reproduce from fresh git checkout
Hi, I tried this from a fresh git build and can not reproduce it. Could you please double check that "Settings/Preferences/Marking Changes/Ask to confirm changes that also affect other packages" is set? Cheers, Michael
Bug#786566: this is affecting us
On 05/01/17 09:23, Brian May wrote: Peter Palfrader writes: It's a serious bug that makes it break in many cases, requiring the sysadmin to clean up and/or reboot the system. Whether or not it's RC in the end is the decision of the release team, but this severity was set after discussing this on #debian-release. Is anything being done to fix this? What is the hold up? Apparently there is a patch for this RC bug and the other RC bug #817236. I'm not personally working on any fix in schroot, since it's not an schroot bug. It is kind of looking like stretch will get released without schroot support, or any packages that depend on it. Maybe time to forgot schroot and look for alternatives??? schroot is not responsible for setting up device nodes in a debootstrapped chroot. We expect them to be set up correctly. This isn't a Debian-specific constraint; we expect all chroots of any sort to be in a sane and directly usable state. schroot's requirements are not any different here from that of the basic chroot(8). Is chroot(8) equally broken here? The mounts and other features schroot offers on top of that are entirely optional, and implementation wise is nothing more than a wrapper around chroot(2) to perform exactly the same job as chroot(8) with some sudo-like PAM authentication and authorisation. While we could add additional mounts to the schroot fstab templates, it's important to understand that this is optional functionality, and has always been optional. It's not a mechanism for working around external breakage. Looking for alternatives to schroot is entirely your choice, but breaking basic system-level functionality which has been working for over two decades, and used for over 11 years by schroot, is I think something which needs careful consideration. I'm prepared to do some work to ensure that schroot interoperates with contemporary systems, but working around breakage like this is perhaps a step too far. Regards, Roger
Bug#850235: nuitka: FTBFS (SyntaxError: duplicate argument 'a' in function definition)
Package: src:nuitka Version: 0.5.24.4+ds-1 Severity: serious Dear maintainer: I tried to build this package in stretch with "dpkg-buildpackage -A" (which is what the "Arch: all" autobuilder would do to build it) but it failed: [...] debian/rules build-indep dh build-indep --with python2 dh_testdir -i dh_update_autotools_config -i dh_auto_configure -i debian/rules override_dh_auto_build make[1]: Entering directory '/<>/nuitka-0.5.24.4+ds' rst2pdf README.rst rst2pdf Developer_Manual.rst cp Changelog.rst changelog cp Developer_Manual.rst Developer_Manual.txt make[1]: Leaving directory '/<>/nuitka-0.5.24.4+ds' debian/rules override_dh_auto_test [... snipped ...] Comparing output of 'PrintFuture.py' using 'python3.5' with flags silent, expect_success, remove_output, recurse_all, original_file ... Comparing output of 'Recursion.py' using 'python3.5' with flags silent, expect_success, remove_output, recurse_all, original_file ... Comparing output of 'Referencing.py' using 'python3.5-dbg' with flags silent, expect_success, remove_output, recurse_all, original_file, python_debug, recurse_not:test_common ... Comparing output of 'Referencing32.py' using 'python3.5-dbg' with flags silent, expect_success, remove_output, recurse_all, original_file, python_debug, recurse_not:test_common ... Comparing output of 'Referencing33.py' using 'python3.5-dbg' with flags silent, expect_success, remove_output, recurse_all, original_file, python_debug, recurse_not:test_common ... Comparing output of 'Referencing35.py' using 'python3.5-dbg' with flags silent, expect_success, remove_output, recurse_all, original_file, python_debug, recurse_not:test_common ... Comparing output of 'Slots.py' using 'python3.5' with flags silent, expect_success, remove_output, recurse_all, original_file ... Comparing output of 'ThreadedGenerators.py' using 'python3.5' with flags silent, expect_success, remove_output, recurse_all, original_file ... Comparing output of 'TrickAssignments32.py' using 'python3.5' with flags silent, expect_success, remove_output, recurse_all, original_file ... Comparing output of 'TryContinueFinally.py' using 'python3.5' with flags silent, expect_success, remove_output, recurse_all, original_file ... Comparing output of 'TryExceptContinue.py' using 'python3.5' with flags silent, expect_success, remove_output, recurse_all, original_file ... Comparing output of 'TryExceptFinally.py' using 'python3.5' with flags silent, expect_success, remove_output, recurse_all, original_file ... Comparing output of 'TryExceptFrames.py' using 'python3.5' with flags silent, expect_success, remove_output, recurse_all, original_file ... Comparing output of 'TryReturnFinally.py' using 'python3.5' with flags silent, expect_success, remove_output, recurse_all, original_file ... Comparing output of 'TryYieldFinally.py' using 'python3.5' with flags silent, expect_success, remove_output, recurse_all, original_file ... Comparing output of 'Unicode.py' using 'python3.5' with flags silent, expect_success, remove_output, recurse_all, original_file ... Comparing output of 'Unpacking35.py' using 'python3.5' with flags silent, expect_success, remove_output, recurse_all, original_file ... Comparing output of 'Varargs.py' using 'python3.5' with flags silent, expect_success, remove_output, recurse_all, original_file ... Comparing output of 'WithStatements.py' using 'python3.5' with flags silent, expect_success, remove_output, recurse_all, original_file ... Comparing output of 'YieldFrom33.py' using 'python3.5' with flags silent, expect_success, remove_output, recurse_all, original_file, ignore_stderr ... Running the syntax tests with options '' with python3.5: Run './tests/syntax/run_all.py search' in '/<>/nuitka-0.5.24.4+ds'. Using concrete python 3.5.2 on x86_64 Comparing output of 'BreakWithoutLoop.py' using 'python3.5' with flags silent, expect_failure, remove_output ... Comparing output of 'ClassReturn.py' using 'python3.5' with flags silent, expect_failure, remove_output ... Comparing output of 'ContinueWithoutLoop.py' using 'python3.5' with flags silent, expect_failure, remove_output ... Comparing output of 'DuplicateArgument.py' using 'python3.5' with flags silent, expect_failure, remove_output ... --- python3.5 (stderr) +++ nuitka (stderr) @@ -1,5 +1,4 @@ File "/<>/nuitka-0.5.24.4+ds/tests/syntax/DuplicateArgument.py", line 18 def f(a, a): -^ SyntaxError: duplicate argument 'a' in function definition Error, outputs differed. Error exit! 1 debian/rules:16: recipe for target 'override_dh_auto_test' failed make[1]: *** [override_dh_auto_test] Error 1 make[1]: Leaving directory '/<>/nuitka-0.5.24.4+ds' debian/rules:4: recipe for target 'build-indep' failed make: *** [build-indep] Error 2 dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2 -
Bug#850231: heat: FTBFS (TypeError: unsupported operand type(s) for +=: 'int' and 'str')
Package: src:heat Version: 1:7.0.0-1 Severity: serious Dear maintainer: I tried to build this package in stretch with "dpkg-buildpackage -A" (which is what the "Arch: all" autobuilder would do to build it) but it failed: [...] debian/rules build-indep pyversions: missing X(S)-Python-Version in control file, fall back to debian/pyversions pyversions: missing debian/pyversions file, fall back to supported versions pyversions: missing X(S)-Python-Version in control file, fall back to debian/pyversions pyversions: missing debian/pyversions file, fall back to supported versions py3versions: no X-Python3-Version in control file, using supported versions dh build-indep --buildsystem=python_distutils --with python2,sphinxdoc,systemd dh_testdir -i -O--buildsystem=python_distutils dh_update_autotools_config -i -O--buildsystem=python_distutils dh_auto_configure -i -O--buildsystem=python_distutils debian/rules override_dh_auto_build make[1]: Entering directory '/<>' pyversions: missing X(S)-Python-Version in control file, fall back to debian/pyversions [... snipped ...] File "/usr/lib/python2.7/dist-packages/sphinx/application.py", line 291, in build self.builder.build_all() File "/usr/lib/python2.7/dist-packages/sphinx/builders/__init__.py", line 211, in build_all self.build(None, summary='all source files', method='all') File "/usr/lib/python2.7/dist-packages/sphinx/builders/__init__.py", line 322, in build self.write(docnames, list(updated_docnames), method) File "/usr/lib/python2.7/dist-packages/sphinx/builders/__init__.py", line 360, in write self._write_serial(sorted(docnames), warnings) File "/usr/lib/python2.7/dist-packages/sphinx/builders/__init__.py", line 368, in _write_serial self.write_doc(docname, doctree) File "/usr/lib/python2.7/dist-packages/sphinx/builders/html.py", line 448, in write_doc self.docwriter.write(doctree, destination) File "/usr/lib/python2.7/dist-packages/docutils/writers/__init__.py", line 80, in write self.translate() File "/usr/lib/python2.7/dist-packages/sphinx/writers/html.py", line 48, in translate self.document.walkabout(visitor) File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 174, in walkabout if child.walkabout(visitor): File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 174, in walkabout if child.walkabout(visitor): File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 174, in walkabout if child.walkabout(visitor): File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 174, in walkabout if child.walkabout(visitor): File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 174, in walkabout if child.walkabout(visitor): File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 174, in walkabout if child.walkabout(visitor): File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 174, in walkabout if child.walkabout(visitor): File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 166, in walkabout visitor.dispatch_visit(self) File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 1882, in dispatch_visit return method(node) File "/usr/lib/python2.7/dist-packages/docutils/writers/html4css1/__init__.py", line 778, in visit_thead self.write_colspecs() File "/usr/lib/python2.7/dist-packages/docutils/writers/html4css1/__init__.py", line 289, in write_colspecs width += node['colwidth'] TypeError: unsupported operand type(s) for +=: 'int' and 'str' debian/rules:76: recipe for target 'override_dh_sphinxdoc' failed make[1]: *** [override_dh_sphinxdoc] Error 1 make[1]: Leaving directory '/<>' debian/rules:10: recipe for target 'binary-indep' failed make: *** [binary-indep] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary-indep gave error exit status 2 This is just how the build ends, not necessarily the relevant part. I've put several build logs here: https://people.debian.org/~sanvila/build-logs/heat/ Seems like a problem with sphinx. Thanks.
Processed: your mail
Processing commands for cont...@bugs.debian.org: > severity 849718 normal Bug #849718 [synaptic] [synaptic] Synaptic does not ask about changes anymore Severity set to 'normal' from 'grave' > tags 849718 + unreproducible Bug #849718 [synaptic] [synaptic] Synaptic does not ask about changes anymore Added tag(s) unreproducible. > End of message, stopping processing here. Please contact me if you need assistance. -- 849718: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849718 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Incomplete fix (was: Re: Bug#850160 closed by Reiner Herrmann (Bug#850160: fixed in firejail 0.9.44.2-2))
Processing control commands:
> reopen -1
Bug #850160 {Done: Reiner Herrmann } [firejail] firejail:
CVE-2017-5180: local root exploit
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions firejail/0.9.44.2-2.
--
850160: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850160
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#850160: Incomplete fix (was: Re: Bug#850160 closed by Reiner Herrmann (Bug#850160: fixed in firejail 0.9.44.2-2))
Control: reopen -1 Hi Salvatore, On Thu, Jan 05, 2017 at 07:54:24AM +0100, Salvatore Bonaccorso wrote: > On Wed, Jan 04, 2017 at 11:21:05PM +, Debian Bug Tracking System wrote: > >* Add upstream fix for CVE-2017-5180 (Closes: #850160). > > Thanks. The fix had a followup which does not seem to be applied, cf. > https://github.com/netblue30/firejail/issues/1020#issuecomment-270514760 Thanks for the information. I will later upload this followup fix. Regards, Reiner signature.asc Description: Digital signature
Processed (with 1 error): update info 844781
Processing commands for cont...@bugs.debian.org: > reassign 844781 dietlibc 0.34~cvs20160606-3 Bug #844781 [src:libowfat] libowfat FTBFS on s390x: undefined reference to `__libc_waitpid' Bug reassigned from package 'src:libowfat' to 'dietlibc'. No longer marked as found in versions libowfat/0.30-2. Ignoring request to alter fixed versions of bug #844781 to the same values previously set Bug #844781 [dietlibc] libowfat FTBFS on s390x: undefined reference to `__libc_waitpid' There is no source info for the package 'dietlibc' at version '0.34~cvs20160606-3' with architecture '' Unable to make a source version for version '0.34~cvs20160606-3' Marked as found in versions 0.34~cvs20160606-3. > retitle 844781 libowfat FTBFS on s390x and mips64: undefined reference Bug #844781 [dietlibc] libowfat FTBFS on s390x: undefined reference to `__libc_waitpid' Changed Bug title to 'libowfat FTBFS on s390x and mips64: undefined reference' from 'libowfat FTBFS on s390x: undefined reference to `__libc_waitpid''. > to `__libc_waitpid' Unknown command or malformed arguments to command. > thanks Stopping processing here. Please contact me if you need assistance. -- 844781: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844781 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#850243: forge: FTBFS on multiple architectures
Source: forge Version: 0.9.2-2 Severity: serious Justification: fails to build from source (but built successfully in the past) Dear Maintainer, Since the latest update of the packaging, src:forge fails to build due to configuration error whilst looking for glm. Multiple architectures are affected, including major ones such as i386 or armhf / armel [1]. [1] https://buildd.debian.org/status/logs.php?pkg=forge&ver=0.9.2-2 Ghis -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
debian-bugs-rc@lists.debian.org
Package: reconserver Version: 0.13.0-1 Severity: serious Your package failed to build on ppc64el (twice), blocking the resiprocate transition. reConServer.cxx: In member function 'virtual int recon::ReConServerProcess::main(int, char**)': reConServer.cxx:941:164: error: no matching function for call to 'resip::HEPSipMessageLoggingHandler::HEPSipMessageLoggingHandler(resip::Data&, int&, int&)' profile->setTransportSipMessageLoggingHandler(SharedPtr(new HEPSipMessageLoggingHandler(captureHost, capturePort, captureAgentID))); Full logs at: https://buildd.debian.org/status/package.php?p=reconserver&suite=unstable Emilio -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (800, 'unstable'), (700, 'experimental'), (650, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.8.0-2-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 Init: systemd (via /run/systemd/system)
Processed: Re: python-crypto: regression: 2.6-4+deb7u4 breaks python-paramiko
Processing commands for cont...@bugs.debian.org: > tags 850025 + pending Bug #850025 [python-crypto] python-crypto: regression: 2.6-4+deb7u4 breaks python-paramiko Ignoring request to alter tags of bug #850025 to the same tags previously set > tags 850077 + pending Bug #850077 [python-paramiko] python-paramiko doesn't work with python-crypto 2.6-4 Ignoring request to alter tags of bug #850077 to the same tags previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 850025: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850025 850077: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850077 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#850246: missing dependencies, does not work
Package: python-social-auth Version: 0.3.0-1 Severity: grave Hi The library is now completely unusable as it requires at least social_core, which is not yet packaged. All files are currently stub which should map old social auth API to new modularized code and without the dependencies this is just completely unusable. I think best approach would be to revert to 0.2.x for now as there is no chance new packages 0.3.x requires will get in (due to soft freeze starting today). -- Michal Čihař | https://cihar.com/ | https://weblate.org/ -- System Information: Debian Release: stretch/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python-social-auth depends on: pn python:any python-social-auth recommends no packages. Versions of packages python-social-auth suggests: pn python-social-auth-doc -- no debconf information signature.asc Description: This is a digitally signed message part
Bug#850243: forge: FTBFS on multiple architectures
CC'd to the src:glm maintainer, On Thu, 05 Jan 2017 10:37:06 + Ghislain Antony Vaillant wrote: Source: forge Version: 0.9.2-2 Severity: serious Justification: fails to build from source (but built successfully in the past) Dear Maintainer, Since the latest update of the packaging, src:forge fails to build due to configuration error whilst looking for glm. Multiple architectures are affected, including major ones such as i386 or armhf / armel [1]. [1] https://buildd.debian.org/status/logs.php?pkg=forge&ver=0.9.2-2 Ghis -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Hi Guus, could you have a look at this please? It looks like it is due to a regression in glm introduced in 0.9.8.3 compared to 0.9.8.1. The CMake detection works correctly for amd64 but not i386. The bug only shows up now because src:forge used to silently download a copy of glm if a system version were not found. I have corrected this behaviour and pushed a new version of the packaging, which now triggers the CMake detection problem. Ghis
Bug#844781: #844781: libowfat FTBFS on s390x and mips64el: undefined reference to `__libc_waitpid'
Control: tag -1 + patch The same issue is noticed on mips64el: https://buildd.debian.org/status/fetch.php?pkg=libowfat&arch=mips64el&ver=0.30-2&stamp=1483522524 Both archs (s390x and mips64el) do not supportwaitpid, wait4 is used instead. (https://github.com/ensc/dietlibc/blob/master/s390x/__waitpid.c) As there is no waitpid system call for these archs,undefined reference to `__libc_waitpid' appears. In order to fix this it is needed to use wait4 syscall instead in syscalls.s/waitpid.S. The patch that solves this is attached. diff -uNr dietlibc-0.34~cvs20160606.orig/syscalls.s/waitpid.S dietlibc-0.34~cvs20160606/syscalls.s/waitpid.S --- dietlibc-0.34~cvs20160606.orig/syscalls.s/waitpid.S 2016-06-06 15:30:00.0 + +++ dietlibc-0.34~cvs20160606/syscalls.s/waitpid.S 2017-01-04 15:16:09.0 + @@ -2,4 +2,6 @@ #ifdef __NR_waitpid syscall_weak(waitpid,waitpid,__libc_waitpid) +#else +syscall_weak(wait4,waitpid,__libc_waitpid) #endif
Processed: RE: #844781: libowfat FTBFS on s390x and mips64el: undefined reference to `__libc_waitpid'
Processing control commands: > tag -1 + patch Bug #844781 [dietlibc] libowfat FTBFS on s390x and mips64: undefined reference Added tag(s) patch. -- 844781: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844781 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#850229: dune-grid: FTBFS (not enough slots available)
Hi On 05/01/2017 12:05, Santiago Vila wrote: Status:FAILED Output: -- There are not enough slots available in the system to satisfy the 2 slots that were requested by the application: test-yaspgrid-yaspfactory-1d Either request fewer slots for your application, or make more slots available for use. -- I started seeing similar errors in other MPI applications since the upload of openmpi 2.0.2~ to unstable. The solution was to add --oversubscribe to the mpirun command line, e.g. [1]. The bug should be reproducible with sbuild on a single CPU virtual machine. It always fail for me (I tried 10 times in different autobuilders). If I understand correctly, --oversubscribe should be needed in your case where you have fewer CPUs than the number of processes requested, but I was seeing the errors even when there were more than enough CPUs available. Regards Graham [1] https://anonscm.debian.org/cgit/debian-science/packages/lammps.git/commit/?id=64c465da9036114cec9220ebe58bd264b974b694
Processed (with 1 error): update info 844781
Processing commands for cont...@bugs.debian.org: > retitle 844781 libowfat FTBFS on s390x and mips64: undefined reference Bug #844781 [dietlibc] libowfat FTBFS on s390x and mips64: undefined reference Ignoring request to change the title of bug#844781 to the same title > to __libc_waitpid Unknown command or malformed arguments to command. > thanks Stopping processing here. Please contact me if you need assistance. -- 844781: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844781 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed (with 1 error): Fwd: update info 844781
Processing commands for cont...@bugs.debian.org: > retitle 844781 libowfat FTBFS on s390x and mips64el: undefined reference Bug #844781 [dietlibc] libowfat FTBFS on s390x and mips64: undefined reference Changed Bug title to 'libowfat FTBFS on s390x and mips64el: undefined reference' from 'libowfat FTBFS on s390x and mips64: undefined reference'. > to __libc_waitpid Unknown command or malformed arguments to command. > thanks Stopping processing here. Please contact me if you need assistance. -- 844781: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844781 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#844781: #844781: libowfat FTBFS on s390x and mips64el: undefined reference to `__libc_waitpid'
latinovic dixit: > The patch that solves this is attached. I think the patch is broken, wait4() requires an additional argument which must be zero for waitpid() emulation, not some random stack (or register, depending on the architecture) garbage. bye, //mirabilos -- Stéphane, I actually don’t block Googlemail, they’re just too utterly stupid to successfully deliver to me (or anyone else using Greylisting and not whitelisting their ranges). Same for a few other providers such as Hotmail. Some spammers (Yahoo) I do block.
Processed: Re: Bug#844781: #844781: libowfat FTBFS on s390x and mips64el: undefined reference to `__libc_waitpid'
Processing control commands: > retitle -1 dietlibc: waitpid broken w/ -lpthread on s390, s390x, mips64, ia64 Bug #844781 [dietlibc] libowfat FTBFS on s390x and mips64el: undefined reference Changed Bug title to 'dietlibc: waitpid broken w/ -lpthread on s390, s390x, mips64, ia64' from 'libowfat FTBFS on s390x and mips64el: undefined reference'. > tags -1 + confirmed Bug #844781 [dietlibc] dietlibc: waitpid broken w/ -lpthread on s390, s390x, mips64, ia64 Added tag(s) confirmed. > tags -1 - patch Bug #844781 [dietlibc] dietlibc: waitpid broken w/ -lpthread on s390, s390x, mips64, ia64 Removed tag(s) patch. -- 844781: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844781 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#844781: #844781: libowfat FTBFS on s390x and mips64el: undefined reference to `__libc_waitpid'
Control: retitle -1 dietlibc: waitpid broken w/ -lpthread on s390, s390x, mips64, ia64 Control: tags -1 + confirmed Control: tags -1 - patch Thanks for reassigning this. On 01/05/2017 11:48 AM, latinovic wrote: > Both archs (s390x and mips64el) do not support waitpid, wait4 is used instead. > (https://github.com/ensc/dietlibc/blob/master/s390x/__waitpid.c) > As there is no waitpid system call for these archs, undefined reference to > `__libc_waitpid' appears. > > In order to fix this it is needed to use wait4 syscall instead in > syscalls.s/waitpid.S. Unfortunately, this is wrong, because then the flags parameter for wait4 would be undefined and depend on the previous state of program execution. Also, dietlibc would then contain two copies of waitpid() on these platforms, because that doesn't remove __waitpid.c from there. Furthermore, ia64 is also affected because that contains a carbon copy of s390's __waitpid.c. (Don't know which one was first.) The correct solution is to change the name of the function to __libc_waitpid in __waitpid.c and to define a weak alias for waitpid there. I'm already working on this (saw your initial email where you reassigned this), and will do an upload soon together with regression tests for this. (The unit tests for dietlibc do already do check for a working waitpid(), but unfortunately they don't link against -lpthread.) Regards, Christian
Processed: Re: Processed (with 1 error): update info 844781
Processing commands for cont...@bugs.debian.org: > # let me help you... > retitle 844781 libowfat FTBFS on s390x and mips64: undefined reference to > __libc_waitpid Bug #844781 [dietlibc] dietlibc: waitpid broken w/ -lpthread on s390, s390x, mips64, ia64 Changed Bug title to 'libowfat FTBFS on s390x and mips64: undefined reference to __libc_waitpid' from 'dietlibc: waitpid broken w/ -lpthread on s390, s390x, mips64, ia64'. > thanks Stopping processing here. Please contact me if you need assistance. -- 844781: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844781 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: congress: still FTBFS randomly
Processing commands for cont...@bugs.debian.org:
> found 842244 4.0.0+dfsg1-3
Bug #842244 {Done: Thomas Goirand } [src:congress] congress:
FTBFS randomly (failing tests)
Marked as found in versions congress/4.0.0+dfsg1-3; no longer marked as fixed
in versions congress/4.0.0+dfsg1-3 and reopened.
> severity 842244 important
Bug #842244 [src:congress] congress: FTBFS randomly (failing tests)
Severity set to 'important' from 'serious'
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
842244: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842244
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Processed: undo
Processing commands for cont...@bugs.debian.org: > # sorry Christian, got your mail later than mine was sent > retitle 844781 dietlibc: waitpid broken with -lpthread on s390, s390x, > mips64, ia64 Bug #844781 [dietlibc] libowfat FTBFS on s390x and mips64: undefined reference to __libc_waitpid Changed Bug title to 'dietlibc: waitpid broken with -lpthread on s390, s390x, mips64, ia64' from 'libowfat FTBFS on s390x and mips64: undefined reference to __libc_waitpid'. > thanks Stopping processing here. Please contact me if you need assistance. -- 844781: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844781 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#842244: congress: still FTBFS randomly
found 842244 4.0.0+dfsg1-3 severity 842244 important thanks Hi. Sorry for the reopening, but this is still failing for me. Quite often indeed. I built this 100 times yesterday and it failed 86 times. Downgrading to "important" only to be on par with every other FTBFS-randomly bug I've detected (as RM are planning to consider RC-ness based on failure probability), but with a failure rate of 86% this one is certainly to worry about. Build logs available here: https://people.debian.org/~sanvila/build-logs/congress/ Thanks.
Bug#850253: retty doesn't work anymore
Package: retty Version: 1.0-2 Severity: grave Hi, while looking at fixing #817652 I tried to use retty but couldn't get it to work. In the second terminal, nothing happens: $ retty 3733 codesize: 138 codeaddr: ff99840c stack: ff9983fc eip: ff998414 sub:48 ^C ^\Verlassen ^C doesn't quit retty; on hitting ^\ the to-be-attached-to process segfaults. Kernel: amd64 4.7.6-1, in a i386 chroot (with linux32 personality). Maybe it's time to RM retty? (The packaging repo is now at ssh://git.debian.org/git/collab-maint/pkg-retty.git if someone manages to fix it.) Christoph signature.asc Description: PGP signature
Bug#850229: dune-grid: FTBFS (not enough slots available)
On Thu, 2017-01-05 at 12:59 +0200, Graham Inggs wrote: > On 05/01/2017 12:05, Santiago Vila wrote: > > Status:FAILED > > Output: > > -- > > > > There are not enough slots available in the system to > > satisfy the 2 slots > > that were requested by the application: > > test-yaspgrid-yaspfactory-1d > > > > Either request fewer slots for your application, or make > > more slots available > > for use. > > -- > > > > I started seeing similar errors in other MPI applications since the > upload of openmpi 2.0.2~ to unstable. > > The solution was to add --oversubscribe to the mpirun command line, Yes, it looks like OpenMPI changed the default :-/ > The bug should be reproducible with sbuild on a single CPU virtual > > machine. > > It always fail for me (I tried 10 times in different autobuilders). > > If I understand correctly, --oversubscribe should be needed in your > case where you have fewer CPUs than the number of processes > requested, but I was seeing the errors even when there were more than > enough CPUs available. On my laptop with 4 cores + HT (so 8 threads), I see `mpirun` complain once I start more than 4 processes, i.e. more processes than real cores. Did you count threads or cores when you tried? Ansgar
Bug#817461: marked as done (freepwing: Removal of debhelper compat 4)
Your message dated Thu, 05 Jan 2017 12:03:31 + with message-id and subject line Bug#817461: fixed in freepwing 1.5-2 has caused the Debian Bug report #817461, regarding freepwing: Removal of debhelper compat 4 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 817461: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817461 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: freepwing Severity: important Usertags: compat-4-removal Hi, The package freepwing uses debhelper with a compat level of 4, which is deprecated and scheduled for removal. * Please bump the debhelper compat at your earliest convenience. on the 15th of June. - Compat 9 is recommended - Compat 5 is the bare minimum - If the package has been relying on dh_install being lenient about missing files, please see "MIGRATING TO COMPAT 5 OR LATER" in [1]. * Compat level 4 will be removed on the first debhelper upload after the 15th of June. Thanks, ~Niels [1] https://lists.debian.org/debian-devel/2015/09/msg00257.html --- End Message --- --- Begin Message --- Source: freepwing Source-Version: 1.5-2 We believe that the bug you reported is fixed in the latest version of freepwing, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 817...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Andreas Beckmann (supplier of updated freepwing package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 05 Jan 2017 12:35:02 +0100 Source: freepwing Binary: freepwing Architecture: source Version: 1.5-2 Distribution: unstable Urgency: medium Maintainer: Debian QA Group Changed-By: Andreas Beckmann Description: freepwing - EB to JIS X 4081 converter Closes: 817461 Changes: freepwing (1.5-2) unstable; urgency=medium . * QA upload. * Set Maintainer to Debian QA Group. (See: #840887) * Switch to debhelper compat level 10, thanks to Logan Rosen. (Closes: #817461) * Switch to minimal dh rules. * Switch to source format 3.0 (quilt). Checksums-Sha1: 9ad21b76285258aa0971dd830007d038e2f28a46 1657 freepwing_1.5-2.dsc c9cf63107c79f79b1220ccb667e14efbaa579825 2656 freepwing_1.5-2.debian.tar.xz Checksums-Sha256: 86a38f2164f1f2ba237c8dbfb1a8dc4b1edd952a211e51e5d515bf34f3253fa1 1657 freepwing_1.5-2.dsc bb6c5fe7ee8696f630f993d171591c82b17e2335e5fedace909a528c6e6e9d4c 2656 freepwing_1.5-2.debian.tar.xz Files: ea666c4e4e5031a93ec489ee13a67cc1 1657 utils optional freepwing_1.5-2.dsc e6d386f553c7b23ae447f7b27db070b9 2656 utils optional freepwing_1.5-2.debian.tar.xz -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJYbjDUAAoJEF+zP5NZ6e0IiWEP/00oFjgH6SZm0jHO2+u/aFIN uPUbrC7KxNE+AH+aqFhinOzULxM1PklteCjskrQUKwRcTbHkBCuPOCYIaVDqtH8j EslT05pt79KWJ2KJDJCEGH0fvWzca/WKgPhFWQ1ezHYpIpli4WTq/nO85mPsf1/4 mTb30wsd7SuD1K+P6gGM80ixlwswc9YeKEKbz7+QR8CjRQlpCm5QFG7Z+jq1ST9t eDr3jwM0TfJ3R/l0l2V+SfRIOdSrqfZ7B8c08gCSi/vQaicVHjIrTUShlD0ZYFrA 852T1zLS0qYyJPRikYxoRyjjeICDUgC5VpYFqXlN+NdfrXaO+Td0sa/suBdfIPV/ 5yaFZ6SJoOwVMwypktvZfmO3ffy6UM8vBMv0gVtBj80mgXzC8IKMRiOJDyT64ZQK G6CUoHkYzjpntpSDrbyyUXckbJdsGjfjd33onDM1p2vZPFQoSQlydMJuPGdD2zPl G1gYeaJkpTDsnySl9MAHG9xfruz63xWbJ6Dgl0U5GTVzPouBtNZFysXUWi5/X5CL WwsaK3xnZ/XR7KPu4EGZ+6jsHxKqP1G94iPzYekqu6aOxoRPSvZC4cjUzpuJhr+/ RmU6NtPhuYhVkbFa9evzr2SOmaZahV8y5GXNRTklIw9GAkIp0t+crUKUGFqCh9Oa 9KvnGxDeyA9jiI0WPC/O =2VIx -END PGP SIGNATURE End Message ---
Processed: Re: mariadb_config garbage output
Processing control commands: > severity -1 serious Bug #850142 [libmariadb-dev] libmariadb-dev: mariadb_config emits trailing binary bullshit on mips64el Severity set to 'serious' from 'important' -- 850142: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850142 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#850243: forge: FTBFS on multiple architectures
CC'd the Debian CMake Team, who might be able to help.
On 05/01/17 10:48, Ghislain Vaillant wrote:
CC'd to the src:glm maintainer,
On Thu, 05 Jan 2017 10:37:06 + Ghislain Antony Vaillant
wrote:
Source: forge
Version: 0.9.2-2
Severity: serious
Justification: fails to build from source (but built successfully in
the past)
Dear Maintainer,
Since the latest update of the packaging, src:forge fails to build due
to configuration error whilst looking for glm. Multiple architectures
are affected, including major ones such as i386 or armhf / armel [1].
[1] https://buildd.debian.org/status/logs.php?pkg=forge&ver=0.9.2-2
Ghis
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Hi Guus, could you have a look at this please?
It looks like it is due to a regression in glm introduced in 0.9.8.3
compared to 0.9.8.1. The CMake detection works correctly for amd64 but
not i386.
The bug only shows up now because src:forge used to silently download a
copy of glm if a system version were not found. I have corrected this
behaviour and pushed a new version of the packaging, which now triggers
the CMake detection problem.
Ghis
Alright, this one is a bit tricky. Looking at the diff between 0.9.8.1
and 0.9.8.3:
```
diff --git a/CMakeLists.txt b/CMakeLists.txt
index b7df09f..253eee5 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -164,7 +164,7 @@ set(GLM_INSTALL_CONFIGDIR
"${CMAKE_INSTALL_LIBDIR}/cmake/glm")
install(DIRECTORY glm DESTINATION ${CMAKE_INSTALL_INCLUDEDIR})
write_basic_package_version_file(
-"${CMAKE_CURRENT_BINARY_DIR}/glmVersion.cmake"
+"${CMAKE_CURRENT_BINARY_DIR}/glmConfigVersion.cmake"
VERSION ${GLM_VERSION}
COMPATIBILITY AnyNewerVersion
)
@@ -188,7 +188,7 @@ configure_package_config_file(
install(
FILES
"${CMAKE_CURRENT_BINARY_DIR}/${GLM_INSTALL_CONFIGDIR}/glmConfig.cmake"
-"${CMAKE_CURRENT_BINARY_DIR}/glmVersion.cmake"
+"${CMAKE_CURRENT_BINARY_DIR}/glmConfigVersion.cmake"
DESTINATION ${GLM_INSTALL_CONFIGDIR}
)
```
It looks like the glm version lookup did not work before (because the
version file was wrongly named) and has been fixed in the most recent
release.
Now if we inspect the content of glmConfigVersion.cmake, we find the
following code, which I believe to be our culprit:
```
# check that the installed version has the same 32/64bit-ness as the one
which is currently searching:
if(NOT CMAKE_SIZEOF_VOID_P STREQUAL "8")
math(EXPR installedBits "8 * 8")
set(PACKAGE_VERSION "${PACKAGE_VERSION} (${installedBits}bit)")
set(PACKAGE_VERSION_UNSUITABLE TRUE)
endif()
```
Hence the following outcome during the build in src:forge for any 32-bit
architecture:
```
CMake Error at src/backend/opengl/CMakeLists.txt:17 (FIND_PACKAGE):
Could not find a configuration file for package "glm" that is compatible
with requested version "".
The following configuration files were considered but not accepted:
/usr/lib/cmake/glm/glmConfig.cmake, version: 0.9.8 (64bit)
```
So the question is how to instruct CMake to produce a ConfigVersion file
without the above bit-ness check?
Ghis
Bug#850243: forge: FTBFS on multiple architectures
Now CC'd to the Debian CMake Team
On 05/01/17 12:26, Ghislain Vaillant wrote:
CC'd the Debian CMake Team, who might be able to help.
On 05/01/17 10:48, Ghislain Vaillant wrote:
CC'd to the src:glm maintainer,
On Thu, 05 Jan 2017 10:37:06 + Ghislain Antony Vaillant
wrote:
Source: forge
Version: 0.9.2-2
Severity: serious
Justification: fails to build from source (but built successfully in
the past)
Dear Maintainer,
Since the latest update of the packaging, src:forge fails to build due
to configuration error whilst looking for glm. Multiple architectures
are affected, including major ones such as i386 or armhf / armel [1].
[1] https://buildd.debian.org/status/logs.php?pkg=forge&ver=0.9.2-2
Ghis
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Hi Guus, could you have a look at this please?
It looks like it is due to a regression in glm introduced in 0.9.8.3
compared to 0.9.8.1. The CMake detection works correctly for amd64 but
not i386.
The bug only shows up now because src:forge used to silently download a
copy of glm if a system version were not found. I have corrected this
behaviour and pushed a new version of the packaging, which now triggers
the CMake detection problem.
Ghis
Alright, this one is a bit tricky. Looking at the diff between 0.9.8.1
and 0.9.8.3:
```
diff --git a/CMakeLists.txt b/CMakeLists.txt
index b7df09f..253eee5 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -164,7 +164,7 @@ set(GLM_INSTALL_CONFIGDIR
"${CMAKE_INSTALL_LIBDIR}/cmake/glm")
install(DIRECTORY glm DESTINATION ${CMAKE_INSTALL_INCLUDEDIR})
write_basic_package_version_file(
-"${CMAKE_CURRENT_BINARY_DIR}/glmVersion.cmake"
+"${CMAKE_CURRENT_BINARY_DIR}/glmConfigVersion.cmake"
VERSION ${GLM_VERSION}
COMPATIBILITY AnyNewerVersion
)
@@ -188,7 +188,7 @@ configure_package_config_file(
install(
FILES
"${CMAKE_CURRENT_BINARY_DIR}/${GLM_INSTALL_CONFIGDIR}/glmConfig.cmake"
-"${CMAKE_CURRENT_BINARY_DIR}/glmVersion.cmake"
+"${CMAKE_CURRENT_BINARY_DIR}/glmConfigVersion.cmake"
DESTINATION ${GLM_INSTALL_CONFIGDIR}
)
```
It looks like the glm version lookup did not work before (because the
version file was wrongly named) and has been fixed in the most recent
release.
Now if we inspect the content of glmConfigVersion.cmake, we find the
following code, which I believe to be our culprit:
```
# check that the installed version has the same 32/64bit-ness as the one
which is currently searching:
if(NOT CMAKE_SIZEOF_VOID_P STREQUAL "8")
math(EXPR installedBits "8 * 8")
set(PACKAGE_VERSION "${PACKAGE_VERSION} (${installedBits}bit)")
set(PACKAGE_VERSION_UNSUITABLE TRUE)
endif()
```
Hence the following outcome during the build in src:forge for any 32-bit
architecture:
```
CMake Error at src/backend/opengl/CMakeLists.txt:17 (FIND_PACKAGE):
Could not find a configuration file for package "glm" that is compatible
with requested version "".
The following configuration files were considered but not accepted:
/usr/lib/cmake/glm/glmConfig.cmake, version: 0.9.8 (64bit)
```
So the question is how to instruct CMake to produce a ConfigVersion file
without the above bit-ness check?
Ghis
Processed: systemfixtures: still FTBFS randomly
Processing commands for cont...@bugs.debian.org:
> found 848414 0.6.1-1
Bug #848414 {Done: Free Ekanayaka } [src:systemfixtures]
systemfixtures: FTBFS randomly (failing tests)
Marked as found in versions systemfixtures/0.6.1-1; no longer marked as fixed
in versions systemfixtures/0.6.1-1 and reopened.
> severity 848414 important
Bug #848414 [src:systemfixtures] systemfixtures: FTBFS randomly (failing tests)
Severity set to 'important' from 'serious'
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
848414: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848414
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#848414: systemfixtures: still FTBFS randomly
found 848414 0.6.1-1 severity 848414 important thanks Hi. Sorry for the reopening but this is still (randomly) failing for me. The following test failed for me: ERROR: test_listen (systemfixtures.tests.test_executable.FakeExecutableTest) at least three times. Build logs available here: https://people.debian.org/~sanvila/build-logs/systemfixtures/ Thanks.
Processed: Re: zfs-zed.service can't start
Processing commands for cont...@bugs.debian.org: > found 849813 0.6.5.8-2 Bug #849813 [zfs-zed] [openmediavault.local] zfs-zed.service can't start Marked as found in versions zfs-linux/0.6.5.8-2. > severity 849813 grave Bug #849813 [zfs-zed] [openmediavault.local] zfs-zed.service can't start Severity set to 'grave' from 'minor' > thanks Stopping processing here. Please contact me if you need assistance. -- 849813: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849813 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#848137: problem with the upgrade of tango-db
On 2017-01-04 21:55, Paul Gevers wrote: > Hi Frederic-Emmanuel, Andreas, > > @Andreas, am I correct in the assumption that jessie to stretch with > tango-db was fine until MariaDB became the default? Or was this > migration with tango-db just never tested before? Have you seen other > dbconfig-common dependent packages fail since MariaDB became default (or > maybe since dbconfig-common 2.0.5 (26-08-2016)? I can't remember the details right now, but it is possible that this started to fail after the mariadb switch (which is a non-trivial thing to test with piuparts). I could try to find some older logs ... And I don't remember any other package having a similar issue. I needed, I could do further checks (or log lookup) next week. Andreas
Bug#849657: [Ceph-maintainers] Bug#849657: ceph: FTBFS on mips(el): g++: virtual memory exhausted: Cannot allocate memory
Hi Aurelien Jarno writes: > On 2016-12-30 10:06, Emilio Pozuelo Monfort wrote: >> On 29/12/16 20:56, Gaudenz Steinlin wrote: > > The problem is indeed a memory issue, not that the buildd doesn't have > enough memory, but just that you can allocate only 2GB per process on a > 32-bit MIPS machine. As Emilio said, the above GCC flag should help to > reduce the memory usage by running the garbage collector more often. > > However gcc 6.3 seems to have improved the situation a bit, so I given > back the packages, I hope they will build now. Otherwise I have a patch > ready to change the GCC defaults. That said GCC upstream consider it's a > bug in the garbage collector [1], so that should be fixed instead and the > patch should be considered as a temporary workaround. > Aurelien thanks for taking care and resheduling the build. Unfortunately this did not solve the problem. But setting the following variables solves the virtual memory issue for me on the mipsel porterbox (eller): export DEB_CFLAGS_MAINT_APPEND= --param ggc-min-expand=10 -O1 export DEB_CXXFLAGS_MAINT_APPEND= --param ggc-min-expand=10 -O1 export DEB_CFLAGS_MAINT_STRIP= -O2 export DEB_CXXFLAGS_MAINT_STRIP= -O2 But unfortunately the build fails at another point. See the log below. I'm not sure how to fix this. If I understand it right these atomic operations are just not supported on mipsel[1]. Or is there a way to make them work? Gaudenz [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56296 libtool: link: g++ -I/usr/include/nss -I/usr/include/nspr -Wall -Wtype-limits -Wignored-qualifiers -Winit-self -Wpointer-arith -Werror=format-security -fno-strict-aliasing -fsigned-char -rdynamic -ftemplate-depth-1024 -Wnon-virtual-dtor -Wno-invalid-offsetof -O2 -g -pipe -Wall -Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -fPIE -fstack-protector-strong -Wstrict-null-sentinel -I../src/gmock/include -I../src/gmock/include -I../src/gmock/gtest/include -I../src/gmock/gtest/include -g -fdebug-prefix-map=/home/gaudenz/ceph=. -fstack-protector-strong -Wformat -Werror=format-security --param ggc-min-expand=10 -O1 -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-z -Wl,relro -Wl,-z -Wl,now -o .libs/ceph_test_cls_rgw test/cls_rgw/ceph_test_cls_rgw-test_cls_rgw.o /usr/lib/mipsel-linux-gnu/libatomic_ops.a -Wl,--as-needed ./.libs/librados.so ./.libs/libcls_rgw_client.a ../src/gmock/lib/.libs/libgmock_main.a ../src/gmock/lib/.libs/libgmock.a ../src/gmock/gtest/lib/.libs/libgtest.a ./.libs/libglobal.a -lpthread -lm ./.libs/libradostest.a ./.libs/libcommon.a -ldl -lboost_thread -lboost_random -lrt -lblkid -luuid -lnss3 -lnssutil3 -lsmime3 -lssl3 -lplds4 -lplc4 -lnspr4 -lboost_iostreams -lboost_system -pthread rocksdb/librocksdb.a(memtable.o): In function `std::__atomic_base::load(std::memory_order) const': /usr/include/c++/6/bits/atomic_base.h:396: undefined reference to `__atomic_load_8' /usr/include/c++/6/bits/atomic_base.h:396: undefined reference to `__atomic_load_8' /usr/include/c++/6/bits/atomic_base.h:396: undefined reference to `__atomic_load_8' /usr/include/c++/6/bits/atomic_base.h:396: undefined reference to `__atomic_load_8' /usr/include/c++/6/bits/atomic_base.h:396: undefined reference to `__atomic_load_8' rocksdb/librocksdb.a(memtable.o):/usr/include/c++/6/bits/atomic_base.h:396: more undefined references to `__atomic_load_8' follow rocksdb/librocksdb.a(memtable.o): In function `std::__atomic_base::store(unsigned long long, std::memory_order)': /usr/include/c++/6/bits/atomic_base.h:374: undefined reference to `__atomic_store_8' /usr/include/c++/6/bits/atomic_base.h:374: undefined reference to `__atomic_store_8' rocksdb/librocksdb.a(memtable.o): In function `std::__atomic_base::load(std::memory_order) const': /usr/include/c++/6/bits/atomic_base.h:396: undefined reference to `__atomic_load_8' /usr/include/c++/6/bits/atomic_base.h:396: undefined reference to `__atomic_load_8' rocksdb/librocksdb.a(memtable.o): In function `std::__atomic_base::store(unsigned long long, std::memory_order)': /usr/include/c++/6/bits/atomic_base.h:374: undefined reference to `__atomic_store_8' /usr/include/c++/6/bits/atomic_base.h:374: undefined reference to `__atomic_store_8' rocksdb/librocksdb.a(env_posix.o): In function `std::__atomic_base::store(unsigned long long, std::memory_order)': /usr/include/c++/6/bits/atomic_base.h:374: undefined reference to `__atomic_store_8' /usr/include/c++/6/bits/atomic_base.h:374: undefined reference to `__atomic_store_8' rocksdb/librocksdb.a(env_posix.o): In function `std::__atomic_base::load(std::memory_order) const': /usr/include/c++/6/bits/atomic_base.h:396: undefined reference to `__atomic_load_8' /usr/include/c++/6/bits/atomic_base.h:396: undefined reference to `__atomic_load_8' rocksdb/librocksdb.a(env_posix.o): In function `std::__atomic_base::store(unsigned long long, std::memory_order)': /usr/include/c++/6/bits/atomic_base.h:374: undefined reference to `__atomic_store_8'
Processed: unarchive
Processing commands for cont...@bugs.debian.org:
> unarchive 802706
Bug #802706 {Done: Drew Parsons } [src:slepc] slepc:
FTBFS: Unable to link with PETSc
Unarchived Bug 802706
>
End of message, stopping processing here.
Please contact me if you need assistance.
--
802706: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802706
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#800182: marked as done (esix: Please migrate a supported debhelper compat level)
Your message dated Thu, 05 Jan 2017 13:07:39 + with message-id and subject line Bug#800182: fixed in esix 1-3 has caused the Debian Bug report #800182, regarding esix: Please migrate a supported debhelper compat level to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 800182: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800182 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: esix Severity: important Usertags: deprecated-debhelper-compat-leq-3 Hi, The package esix is using a debhelper compat level of 3 or less according to lintian. These compat levels have been deprecated for the past ~10 years and debhelper will remove support for them in the near future (as declared in [1]). * Please migrate the package to a supported debhelper compat level. - Compat 9 is recommended - Compat 5 is the bare minimum (compat 4 will be removed soon as well) * If your package uses any of the following tools, please remove them from the rules files. Neither of them does anything except warn about their deprecation. - dh_desktop - dh_scrollkeeper (deadline: January 1st 2016) - dh_suidregister - dh_undocumented * Please note that your package might have been flagged for using e.g. "DH_COMPAT=2 dh_foo ...". - This will still cause issues when the compat level is removed. * If the package has been relying on dh_install being lenient about missing files, please see "MIGRATING TO COMPAT 5 OR LATER" in [1]. * Deadline: - compat 1+2: November 1st 2015 - compat 3: January 1st 2016 If you are using other deprecated debhelper features (such as omitting the debian/compat file), please consider fixing those while you are at it. Thanks, ~Niels [1] https://lists.debian.org/debian-devel/2015/09/msg00257.html --- End Message --- --- Begin Message --- Source: esix Source-Version: 1-3 We believe that the bug you reported is fixed in the latest version of esix, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 800...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Andreas Beckmann (supplier of updated esix package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 05 Jan 2017 13:34:27 +0100 Source: esix Binary: esix Architecture: source Version: 1-3 Distribution: unstable Urgency: medium Maintainer: Debian QA Group Changed-By: Andreas Beckmann Description: esix - PDP-8 Engineering and Scientific Interpreter eXtended Closes: 800182 Changes: esix (1-3) unstable; urgency=medium . * QA upload. * Set maintainer to Debian QA Group. (See: #848572) * Switch to debhelper compat level 9, thanks to Logan Rosen. (Closes: #800182) * Switch to minimal dh rules. * Switch to source format 3.0 (quilt). Checksums-Sha1: 983aa3e7a40eb3a08ee07be739b03036b0825648 1602 esix_1-3.dsc f0bddfb6cd52db44f6f56aa2b9afe45f26100cd6 3244 esix_1-3.debian.tar.xz Checksums-Sha256: 69c6b03015ff50d6caf37cbfa7570e349cad216d7dfd1bb741f4efb6f2e5b08a 1602 esix_1-3.dsc dc84c14d2f3063d67dbfe606372fb3b9d65305d15fad9f0b6ef26d5599cbeaaa 3244 esix_1-3.debian.tar.xz Files: aa3d9bf49207c34fb3c7a2e5ba906b5d 1602 contrib/otherosfs optional esix_1-3.dsc a55914697bc00ab977b66e89df7190c3 3244 contrib/otherosfs optional esix_1-3.debian.tar.xz -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJYbj2DAAoJEF+zP5NZ6e0IJgkP/igB8cVaekM7W6z9j4R/LvBM ckDzXjgzSye9Q3vjoEeinHCQugdibglbUf6nBotkEWB/teo6hNhvspHtS6vnWlvH 5IK5MIAM/jqmbJgC9x7H4CTxK9ZpIUOuf4lyiAetAS0OiR+RcltzPU0PPEu6VZKb QAR666hng/nDRRbb+Oa1LXrTWYsla9zQPZ/yW/RUwZKNlDUDEbMs0JUxJdgSbZ2q rkzeIpgPM7rH9Gb+aETjRJZzMQpB8W0H9EudcEixLfbFAJFDAU7pUNRfcflBAJPb nahCtVMjQe/K0TouIEp8x14yjs3wkxK8q1Lf1tn2RIScMspW0gjfV0J8+SpBSH0k bJUPYeP1T+WnJJZFipAzG0073GuZlmnVQ4gYQo9jEz5IZsvBnBBiID1YYAySetBX l1J0YdG+Un3dB0ed1hQ0M/Bn4fPSjK47+EBMwvaYDnpsPz1PhlkIWERLDGRiPfyY kciNSsYUXf/YLaIRMQ2tmq5THWsMu4IInZerWhMSZE33LnHLH7cH/nqsPUL0u+mB 5BOY/Bgu04AvP0divk6Jam+lxIpbk29XVqFMb18O3mme38J25KJ75C3KyO639qZI kcZuXTFvJCVKNSDyb7J1D9ypNpb3hbBYMWGw7Sj0Cq0Uzesza4W97W5Kce9vc3BG 2ZjIo+agFeGIVXfTCY2m =qzyz -END PGP SIGNATURE End Message ---
Bug#849660: marked as done (ceph: FTBFS on armel: error: field 'result' has incomplete type 'std::promise')
Your message dated Thu, 05 Jan 2017 13:07:04 + with message-id and subject line Bug#849660: fixed in ceph 10.2.5-3 has caused the Debian Bug report #849660, regarding ceph: FTBFS on armel: error: field 'result' has incomplete type 'std::promise' to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 849660: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849660 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: ceph Version: 10.2.5-2 Severity: serious Your package failed to build on armel: utilities/backupable/backupable_db.cc:297:30: error: field 'result' has incomplete type 'std::promise' std::promise result; Logs at https://buildd.debian.org/status/package.php?p=ceph -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (800, 'unstable'), (700, 'experimental'), (650, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.8.0-2-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 Init: systemd (via /run/systemd/system) --- End Message --- --- Begin Message --- Source: ceph Source-Version: 10.2.5-3 We believe that the bug you reported is fixed in the latest version of ceph, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 849...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Gaudenz Steinlin (supplier of updated ceph package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 05 Jan 2017 09:18:41 +0100 Source: ceph Binary: ceph ceph-base rbd-mirror rbd-nbd ceph-common ceph-mds ceph-mon ceph-osd ceph-fuse rbd-fuse ceph-fs-common ceph-resource-agents librados2 librados-dev libradosstriper1 libradosstriper-dev librbd1 librbd-dev libcephfs1 libcephfs-dev librgw2 librgw-dev radosgw ceph-test python-ceph python-rados python-rbd python-cephfs libcephfs-java libcephfs-jni Architecture: source amd64 all Version: 10.2.5-3 Distribution: unstable Urgency: medium Maintainer: Ceph Maintainers Changed-By: Gaudenz Steinlin Description: ceph - distributed storage and file system ceph-base - common ceph daemon libraries and management tools ceph-common - common utilities to mount and interact with a ceph storage cluste ceph-fs-common - common utilities to mount and interact with a ceph file system ceph-fuse - FUSE-based client for the Ceph distributed file system ceph-mds - metadata server for the ceph distributed file system ceph-mon - monitor server for the ceph storage system ceph-osd - OSD server for the ceph storage system ceph-resource-agents - OCF-compliant resource agents for Ceph ceph-test - Ceph test and benchmarking tools libcephfs-dev - Ceph distributed file system client library (development files) libcephfs-java - Java library for the Ceph File System libcephfs-jni - Java Native Interface library for CephFS Java bindings libcephfs1 - Ceph distributed file system client library librados-dev - RADOS distributed object store client library (development files) librados2 - RADOS distributed object store client library libradosstriper-dev - RADOS striping interface (development files) libradosstriper1 - RADOS striping interface librbd-dev - RADOS block device client library (development files) librbd1- RADOS block device client library librgw-dev - RADOS client library (development files) librgw2- RADOS Gateway client library python-ceph - Meta-package for python libraries for the Ceph libraries python-cephfs - Python libraries for the Ceph libcephfs library python-rados - Python libraries for the Ceph librados library python-rbd - Python libraries for the Ceph librbd library radosgw- REST gateway for RADOS distributed object store rbd-fuse - FUSE-based rbd client for the Ceph distributed file system rbd-mirror - Ceph daemon for mirroring RBD images rbd-nbd- NBD-based rbd client for the Ceph distributed file system Closes: 849660 Changes: ceph (10.2.5-3) unstable; urgency=medium . * [eeff8d] Use -mfloat-abi=softfp on armel for NEO
Processed: slepc: FTBFS: Unable to link with PETSc
Processing commands for cont...@bugs.debian.org:
> found 802706 3.7.3+dfsg1-3
Bug #802706 {Done: Drew Parsons } [src:slepc] slepc:
FTBFS: Unable to link with PETSc
Marked as found in versions slepc/3.7.3+dfsg1-3 and reopened.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
802706: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802706
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#802706: slepc: FTBFS: Unable to link with PETSc
found 802706 3.7.3+dfsg1-3 thanks Hi. Sorry for the reopening but this is happening again in stretch. (I built this package 200 times, and it failed 200 times). Build logs available here: https://people.debian.org/~sanvila/build-logs/slepc/ Thanks.
Processed: Bug#849660 tagged as pending
Processing commands for cont...@bugs.debian.org:
> tag 849660 pending
Bug #849660 {Done: Gaudenz Steinlin } [src:ceph] ceph:
FTBFS on armel: error: field 'result' has incomplete type
'std::promise'
Added tag(s) pending.
> --
Stopping processing here.
Please contact me if you need assistance.
--
849660: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849660
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#849660: tagged as pending
tag 849660 pending -- We believe that the bug #849660 you reported has been fixed in the Git repository. You can see the commit message below and/or inspect the commit contents at: http://anonscm.debian.org/cgit/pkg-ceph/ceph.git/diff/?id=eeff8d6 (This message was generated automatically by 'git-post-receive-tag-pending-commitmsg' hook). --- commit eeff8d65bad5c8e2bdf966bfe725b75d63aa9bc5 Author: Gaudenz Steinlin Date: Tue Dec 27 21:35:47 2016 +0100 Use -mfloat-abi=softfp on armel for NEON plugin Closes: #849660
Bug#849845: [pkg-gnupg-maint] Bug#849845: dirmngr: Can't resolve keyserver hostname anymore
Hi, Daniel Kahn Gillmor: > The remaining problem for me ws that when i use tor, if i get back > records, the connections fail, but the IPv6 records are not marked as > dead, so they fail repeatedly. Same here, with a package built from commit 32bae0c609cb0c6180e9405a3d6a8fb3c0dec20e in the Vcs-Git (which by the way fixes the other problem I've reported here :) Cheers, -- intrigeri
Bug#831195: marked as done (xmacro: FTBFS with GCC 6: stl_algobase.h:243:56: error: macro "min" passed 3 arguments, but takes just 2)
Your message dated Thu, 05 Jan 2017 13:19:00 + with message-id and subject line Bug#831195: fixed in xmacro 0.3pre-2911-7 has caused the Debian Bug report #831195, regarding xmacro: FTBFS with GCC 6: stl_algobase.h:243:56: error: macro "min" passed 3 arguments, but takes just 2 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 831195: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831195 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: xmacro Version: 0.3pre-2911-6 Severity: serious Tags: stretch sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20160713 qa-ftbfs Justification: FTBFS with GCC 6 on amd64 Hi, During a rebuild of all packages in sid using the gcc-defaults package available in experimental to make GCC default to version 6, your package failed to build on amd64. For more information about GCC 6 and Stretch, see: - https://wiki.debian.org/GCC6 - https://lists.debian.org/debian-devel-announce/2016/06/msg7.html Relevant part (hopefully): > g++ -g -O2 -I/usr/X11R6/include -Wall -pedantic -DHAVE_IOSTREAM=1 > -DVERSION=0.3 xmacroplay.cpp -o xmacroplay -L/usr/X11R6/lib -lXtst -lX11 > In file included from /usr/include/c++/6/bits/char_traits.h:39:0, > from /usr/include/c++/6/ios:40, > from /usr/include/c++/6/ostream:38, > from /usr/include/c++/6/iostream:39, > from xmacroplay.cpp:54: > /usr/include/c++/6/bits/stl_algobase.h:243:56: error: macro "min" passed 3 > arguments, but takes just 2 > min(const _Tp& __a, const _Tp& __b, _Compare __comp) > ^ > /usr/include/c++/6/bits/stl_algobase.h:265:56: error: macro "max" passed 3 > arguments, but takes just 2 > max(const _Tp& __a, const _Tp& __b, _Compare __comp) > ^ > In file included from xmacroplay.cpp:41:0: > /usr/include/c++/6/bits/stl_algobase.h:195:5: error: expected unqualified-id > before 'const' > min(const _Tp& __a, const _Tp& __b) > ^ > /usr/include/c++/6/bits/stl_algobase.h:195:5: error: expected ')' before > 'const' > /usr/include/c++/6/bits/stl_algobase.h:195:5: error: expected ')' before > 'const' > /usr/include/c++/6/bits/stl_algobase.h:195:5: error: expected ')' before > 'const' > /usr/include/c++/6/bits/stl_algobase.h:195:5: error: expected initializer > before 'const' > /usr/include/c++/6/bits/stl_algobase.h:219:5: error: expected unqualified-id > before 'const' > max(const _Tp& __a, const _Tp& __b) > ^ > /usr/include/c++/6/bits/stl_algobase.h:219:5: error: expected ')' before > 'const' > /usr/include/c++/6/bits/stl_algobase.h:219:5: error: expected ')' before > 'const' > /usr/include/c++/6/bits/stl_algobase.h:219:5: error: expected ')' before > 'const' > /usr/include/c++/6/bits/stl_algobase.h:219:5: error: expected initializer > before 'const' > In file included from /usr/include/c++/6/bits/char_traits.h:39:0, > from /usr/include/c++/6/ios:40, > from /usr/include/c++/6/ostream:38, > from /usr/include/c++/6/iostream:39, > from xmacroplay.cpp:54: > /usr/include/c++/6/bits/stl_algobase.h:243:5: error: 'std::min' declared as > an 'inline' variable > min(const _Tp& __a, const _Tp& __b, _Compare __comp) > ^~~ > /usr/include/c++/6/bits/stl_algobase.h:246:7: error: expected > primary-expression before 'if' >if (__comp(__b, __a)) >^~ > /usr/include/c++/6/bits/stl_algobase.h:246:7: error: expected '}' before 'if' > /usr/include/c++/6/bits/stl_algobase.h:246:7: error: expected ';' before 'if' > /usr/include/c++/6/bits/stl_algobase.h:248:7: error: expected unqualified-id > before 'return' >return __a; >^~ > /usr/include/c++/6/bits/stl_algobase.h:265:5: error: 'max' declared as an > 'inline' variable > max(const _Tp& __a, const _Tp& __b, _Compare __comp) > ^~~ > /usr/include/c++/6/bits/stl_algobase.h:268:7: error: expected > primary-expression before 'if' >if (__comp(__a, __b)) >^~ > /usr/include/c++/6/bits/stl_algobase.h:268:7: error: expected '}' before 'if' > /usr/include/c++/6/bits/stl_algobase.h:268:7: error: expected ';' before 'if' > /usr/include/c++/6/bits/stl_algobase.h:270:7: error: expected unqualified-id > before 'return' >return __a; >^~ > /usr/include/c++/6/bits/stl_algobase.h:271:5: error: expected declaration > before '}' token > } > ^ > make[1]: *** [xmacroplay] Error 1 The full build log
Processed: unarchive
Processing commands for cont...@bugs.debian.org:
> unarchive 834959
Bug #834959 {Done: Martín Ferrari } [src:golang-goleveldb]
golang-goleveldb: FTBFS too much often (failing tests)
Unarchived Bug 834959
>
End of message, stopping processing here.
Please contact me if you need assistance.
--
834959: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834959
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#849657: [Ceph-maintainers] Bug#849657: ceph: FTBFS on mips(el): g++: virtual memory exhausted: Cannot allocate memory
On 05/01/17 14:00, Gaudenz Steinlin wrote: > > Hi > > Aurelien Jarno writes: > >> On 2016-12-30 10:06, Emilio Pozuelo Monfort wrote: >>> On 29/12/16 20:56, Gaudenz Steinlin wrote: >> >> The problem is indeed a memory issue, not that the buildd doesn't have >> enough memory, but just that you can allocate only 2GB per process on a >> 32-bit MIPS machine. As Emilio said, the above GCC flag should help to >> reduce the memory usage by running the garbage collector more often. >> >> However gcc 6.3 seems to have improved the situation a bit, so I given >> back the packages, I hope they will build now. Otherwise I have a patch >> ready to change the GCC defaults. That said GCC upstream consider it's a >> bug in the garbage collector [1], so that should be fixed instead and the >> patch should be considered as a temporary workaround. >> > > Aurelien thanks for taking care and resheduling the build. Unfortunately > this did not solve the problem. But setting the following variables > solves the virtual memory issue for me on the mipsel porterbox (eller): > > export DEB_CFLAGS_MAINT_APPEND= --param ggc-min-expand=10 -O1 > export DEB_CXXFLAGS_MAINT_APPEND= --param ggc-min-expand=10 -O1 > export DEB_CFLAGS_MAINT_STRIP= -O2 > export DEB_CXXFLAGS_MAINT_STRIP= -O2 > > But unfortunately the build fails at another point. See the log below. > I'm not sure how to fix this. If I understand it right these atomic > operations are just not supported on mipsel[1]. Or is there a way to make > them work? They are supported. You are probably missing -latomic. Cheers, Emilio
Processed: golang-goleveldb: still FTBFS randomly
Processing commands for cont...@bugs.debian.org:
> found 834959 0+git20160825.6ae1797-2
Bug #834959 {Done: Martín Ferrari } [src:golang-goleveldb]
golang-goleveldb: FTBFS too much often (failing tests)
Marked as found in versions golang-goleveldb/0+git20160825.6ae1797-2 and
reopened.
> retitle 834959 golang-goleveldb: FTBFS randomly (failing tests)
Bug #834959 [src:golang-goleveldb] golang-goleveldb: FTBFS too much often
(failing tests)
Changed Bug title to 'golang-goleveldb: FTBFS randomly (failing tests)' from
'golang-goleveldb: FTBFS too much often (failing tests)'.
> severity 834959 important
Bug #834959 [src:golang-goleveldb] golang-goleveldb: FTBFS randomly (failing
tests)
Severity set to 'important' from 'serious'
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
834959: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834959
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#850266: Missing headers in -dev package
Package: libsrtp2-dev Severity: serious Version: 2.0.0-1 Hi, it seems like the headers in the crypto subdirectory should also be included, at least partially. Without this, constants like SRTP_AES_128_ICM SRTP_NULL_CIPHER and others are missing and they seem to be needed for usage of the API. Also various functions from the srtp_priv.h header that was available in < 2.0 seem to be needed, at least the software I'm looking at is using them. For example srtp_get_stream(), for which there seems to be no alternative. Best regards, Sebastian signature.asc Description: This is a digitally signed message part
Bug#834959: golang-goleveldb: still FTBFS randomly
found 834959 0+git20160825.6ae1797-2 retitle 834959 golang-goleveldb: FTBFS randomly (failing tests) severity 834959 important thanks Hi. Sorry for the reopening but this is still failing (randomly) for me. Build logs available here: https://people.debian.org/~sanvila/build-logs/golang-goleveldb/ As a summary, a "grep ^FAIL" on the build logs yields this result: FAILgithub.com/syndtr/goleveldb/leveldb 203.394s FAILgithub.com/syndtr/goleveldb/leveldb 252.690s FAILgithub.com/syndtr/goleveldb/leveldb 254.444s FAILgithub.com/syndtr/goleveldb/leveldb 300.281s FAILgithub.com/syndtr/goleveldb/leveldb 321.150s FAILgithub.com/syndtr/goleveldb/leveldb 321.874s FAILgithub.com/syndtr/goleveldb/leveldb 339.488s FAILgithub.com/syndtr/goleveldb/leveldb 362.185s This is after 100 builds, so the failure rate is around 8%. Not too bad compared with other packages, but still I expect this to be much lower. Thanks.
Bug#850142: mariadb_config garbage output
Hi
The problem is that the mariadb-connector-c package adds symbol
versioning to
the mariadb_config binary. By doing so it fails to correctly export the
_IO_stdin_used symbol added by the GNU libc.
The attached patch fixes the problem on mips64el.
This solution was used to fix lua5.2 package with similar bug.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816059
Daniel
--- mariadb-connector-c-2.3.1.orig/libmariadb/CMakeLists.txt
+++ mariadb-connector-c-2.3.1/libmariadb/CMakeLists.txt
@@ -218,7 +218,8 @@ SET(EXPORT_SYMBOLS
mysql_thread_init
mysql_thread_safe
mysql_use_result
- mysql_warning_count)
+ mysql_warning_count
+ _IO_stdin_used)
IF(WITH_OPENSSL)
SET(EXPORT_SYMBOLS ${EXPORT_SYMBOLS} mariadb_deinitialize_ssl)
Bug#849657: [Ceph-maintainers] Bug#849657: ceph: FTBFS on mips(el): g++: virtual memory exhausted: Cannot allocate memory
Hi, It seems that maxparallel=1, which is used for arm64, helps. Using only 1 job I have got libatomic issue as well. Errors with atomic functions occurs because mips32 arches does not support use of 8-byte atomics functions. Linking with "latomic" library resolves this problem. export DEB_LDFLAGS_MAINT_APPEND= -latomic As building of ceph takes a lot of time I am still waiting to see if the build will finish successfully. Regards, Radovan
Processed: Re: [debian-mysql] Bug#850216: mysql-server-5.6: Listens on * by default after installation (related to use of alternatives)
Processing commands for cont...@bugs.debian.org: > reassign 850216 libmariadbclient18 Bug #850216 [src:mysql-5.6] mysql-server-5.6: Listens on * by default after installation (related to use of alternatives) Bug reassigned from package 'src:mysql-5.6' to 'libmariadbclient18'. No longer marked as found in versions mysql-5.6/5.6.30-1. Ignoring request to alter fixed versions of bug #850216 to the same values previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 850216: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850216 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#850216: [debian-mysql] Bug#850216: mysql-server-5.6: Listens on * by default after installation (related to use of alternatives)
reassign 850216 libmariadbclient18
thanks
Hi Salvatore,
Thank you for the report. I can reproduce this on stretch.
Otto: please could you take a look at this?
It seems that the problem is that libmariadbclient18 depends on
mariadb-common directly. mariadb-common's postinst adds
/etc/mysql/mariadb.conf to the configuration. And various things depend
on libmariadbclient18 now, such as libdbd-mysql-perl, which is pulling
it in.
I think this is wrong for two reasons:
1) libmariadbclient18 shouldn't add mariadb.cnf as an alternative at
all. Nor does libmysqlclient{18,20} add mysql.cnf currently, for
example. We both use and share my.cnf.fallback from the mysql-common
package for client library use. libmariadbclient18's use of
/usr/share/mysql-common/configure-symlinks should move to
mariadb-server-... packaging.
2) libmariadbclient18 should depend only on mysql-common, not
mariadb-common, since it doesn't (shouldn't) need anything from
mariadb-common.
I think the above issue is quite serious in itself, as it causes MariaDB
packaging to cause disruption and unexpected behaviour to users of MySQL
by taking over my.cnf when it shouldn't.
Another way of looking at this is that mariadb.cnf and mysql.cnf should
never end up both activated in update-alternatives on the same system at
once. In the original design, it is only mysql-server-* and
mariadb-server-* that provide the symlinks, and these packages conflict
with each other, uninstalling the symlink in postrm remove, so did
ensure this would never happen. By putting the configure-symlinks call
in mariadb-common, this mechanism stops working correctly.
It looks like mariadb-common has been like this ever since the symlink
handling was introduced. I'm sorry I didn't notice this problem at the
time. I guess the problem has only come up now because non-MariaDB
packaging is pulling in mariadb-common now, which didn't happen before.
For the security issue you reported, I can confirm it is fixed by
running "update-alternatives --remove my.cnf /etc/mysql/mariadb.cnf" and
restarting, so I'm confident that fixing the above issue will fix this
problem for MySQL. mariadb-server seems unaffected.
Robie
signature.asc
Description: PGP signature
Bug#828556: sslscan: FTBFS with openssl 1.1.0
Re: Adrian Bunk 2016-12-21 <20161221212734.64mvgghokxot7...@bunk.spdns.de>
> On Wed, Nov 30, 2016 at 04:53:58PM +0100, Marvin Stark wrote:
> > Am 2016-11-10 23:33, schrieb Sebastian Andrzej Siewior:
> >...
> > > Marvin: unless Adrian pulls out a patch I suggest you prepare a package
> > > to build against libssl1.0-dev. I have currently no better suggestion. I
> > > can sponsor the upload if you want me to.
> >
> > Yes please. I'll prepare a new package these days.
>
> ping
NMU diff:
Control files: lines which differ (wdiff format)
Build-Depends: debhelper (>= 9), {+libssl1.0-dev |+} libssl-dev {+(<< 1.1.0~)+}
diff -Nru sslscan-1.11.5-rbsec/debian/changelog
sslscan-1.11.5-rbsec/debian/changelog
--- sslscan-1.11.5-rbsec/debian/changelog 2016-04-01 10:33:03.0
+0200
+++ sslscan-1.11.5-rbsec/debian/changelog 2017-01-05 15:02:51.0
+0100
@@ -1,3 +1,10 @@
+sslscan (1.11.5-rbsec-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Build against openssl 1.0. (Closes: #828556)
+
+ -- Christoph Berg Thu, 05 Jan 2017 15:02:51 +0100
+
sslscan (1.11.5-rbsec-1) unstable; urgency=medium
* New Upstream release (Closes: #804616)
diff -Nru sslscan-1.11.5-rbsec/debian/control
sslscan-1.11.5-rbsec/debian/control
--- sslscan-1.11.5-rbsec/debian/control 2016-04-01 10:33:03.0 +0200
+++ sslscan-1.11.5-rbsec/debian/control 2017-01-05 15:02:51.0 +0100
@@ -3,7 +3,7 @@
Priority: extra
Maintainer: Marvin Stark
Homepage: https://github.com/rbsec/sslscan
-Build-Depends: debhelper (>= 9), libssl-dev
+Build-Depends: debhelper (>= 9), libssl1.0-dev | libssl-dev (<< 1.1.0~)
Standards-Version: 3.9.7.0
Package: sslscan
Christoph
signature.asc
Description: PGP signature
Bug#850236: marked as done (python-django: FTBFS (AssertionError))
Your message dated Thu, 5 Jan 2017 15:25:50 +0100
with message-id <20170105142550.dkycj4qlbaagp...@home.ouaza.com>
and subject line Re: Bug#850236: python-django: FTBFS (AssertionError)
has caused the Debian Bug report #850236,
regarding python-django: FTBFS (AssertionError)
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
850236: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850236
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:python-django
Version: 1:1.10.3-2
Severity: serious
Dear maintainer:
I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:
[...]
debian/rules build-indep
dh build-indep --with sphinxdoc,python2,python3 --buildsystem=pybuild
dh_testdir -i -O--buildsystem=pybuild
dh_update_autotools_config -i -O--buildsystem=pybuild
dh_auto_configure -i -O--buildsystem=pybuild
I: pybuild base:184: python2.7 setup.py config
running config
I: pybuild base:184: python3.5 setup.py config
running config
debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
dh_auto_build
I: pybuild base:184: /usr/bin/python setup.py build
[... snipped ...]
test_options (generic_views.test_base.ViewTest) ... ok
test_options_for_get_and_post_view (generic_views.test_base.ViewTest) ... ok
test_options_for_get_view (generic_views.test_base.ViewTest) ... ok
test_options_for_post_view (generic_views.test_base.ViewTest) ... ok
test_pathological_http_method (generic_views.test_base.ViewTest) ... ok
test_response_without_messages (messages_tests.test_middleware.MiddlewareTest)
... ok
test_script_prefix_set_in_commands (user_commands.tests.CommandRunTests) ... ok
==
FAIL: test_timesince07
(template_tests.filter_tests.test_timesince.TimesinceTests)
--
Traceback (most recent call last):
File "/<>/django/test/utils.py", line 205, in inner
return func(*args, **kwargs)
File "/<>/tests/template_tests/utils.py", line 61, in inner
func(self)
File "/<>/tests/template_tests/filter_tests/test_timesince.py",
line 67, in test_timesince07
self.assertEqual(output, '1\xa0week')
AssertionError: u'6\xa0days' != u'1\xa0week'
==
FAIL: test_timesince08
(template_tests.filter_tests.test_timesince.TimesinceTests)
--
Traceback (most recent call last):
File "/<>/django/test/utils.py", line 205, in inner
return func(*args, **kwargs)
File "/<>/tests/template_tests/utils.py", line 61, in inner
func(self)
File "/<>/tests/template_tests/filter_tests/test_timesince.py",
line 74, in test_timesince08
self.assertEqual(output, '1\xa0week')
AssertionError: u'6\xa0days' != u'1\xa0week'
--
Ran 11263 tests in 245.226s
FAILED (failures=2, skipped=1064, expected failures=5)
OK
Destroying test database for alias 'default' (':memory:')...
Destroying test database for alias 'other' (':memory:')...
debian/rules:24: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>'
debian/rules:12: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2
This is just how the build ends, not necessarily the relevant part.
I've put several build logs here:
https://people.debian.org/~sanvila/build-logs/python-django/
If this is really a bug in one of the build-depends, please use reassign and
affects,
so that this is still visible in the page for this package.
The bug should be reproducible with sbuild on a single CPU virtual machine.
It always fail for me (I tried 10 times in different autobuilders), and it
also fails here:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-django.html
Thanks.
--- End Message ---
--- Begin Message ---
Version: 1:1.10.5-1
This is https://code.djangoproject.com/ticket/27637 and has been fixed
in version 1.10.5 that just got uploaded. The failure only happens during
one week every 4 years. So it's not really release critical but we
still want the new version to migrat
Bug#850236: python-django: FTBFS (AssertionError)
On Thu, Jan 05, 2017 at 03:25:50PM +0100, Raphael Hertzog wrote: > This is https://code.djangoproject.com/ticket/27637 and has been fixed > in version 1.10.5 that just got uploaded. The failure only happens during > one week every 4 years. A whole week? I am not sure the security team would be happy with being unable to fix critical a bug in a whole week, if such thing ever happens. > So it's not really release critical but we still want the new > version to migrate in testing so it doesn't change much. It depends. My goal is to build 25000 source packages in a row and have 0.5 failures on average in total (i.e. closer to 0 than to 1). If we have 50 packages which FTBFS randomly, they should fail less than 1% on average. One week every 4 years is more than 7% of the time. Too much for my taste. Thanks.
Bug#850236: python-django: FTBFS (AssertionError)
On Thu, 05 Jan 2017, Santiago Vila wrote: > It depends. My goal is to build 25000 source packages in a row and have > 0.5 failures on average in total (i.e. closer to 0 than to 1). > > If we have 50 packages which FTBFS randomly, they should fail less > than 1% on average. > > One week every 4 years is more than 7% of the time. Too much for my taste. Your mathematics are broken :-) 52 weeks per year, 1 week out of 4 years = 1 / (4*52) = 0.0048 < 0.5% Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Bug#828556: marked as done (sslscan: FTBFS with openssl 1.1.0)
Your message dated Thu, 05 Jan 2017 15:10:13 + with message-id and subject line Bug#828556: fixed in sslscan 1.11.5-rbsec-1.1 has caused the Debian Bug report #828556, regarding sslscan: FTBFS with openssl 1.1.0 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 828556: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828556 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: sslscan Version: 1.11.5-rbsec-1 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/sslscan_1.11.5-rbsec-1_amd64-20160529-1539 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt --- End Message --- --- Begin Message --- Source: sslscan Source-Version: 1.11.5-rbsec-1.1 We believe that the bug you reported is fixed in the latest version of sslscan, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 828...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Christoph Berg (supplier of updated sslscan package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 05 Jan 2017 15:02:51 +0100 Source: sslscan Binary: sslscan Architecture: source Version: 1.11.5-rbsec-1.1 Distribution: unstable Urgency: medium Maintainer: Marvin Stark Changed-By: Christoph Berg Description: sslscan- Fast SSL scanner Closes: 828556 Changes: sslscan (1.11.5-rbsec-1.1) unstable; urgency=medium . * Non-maintainer upload. * Build against openssl 1.0. (Closes: #828556) Checksums-Sha1: 12acab561e1fb1b7900ea64142a12b7f515d1b6e 1787 sslscan_1.11.5-rbsec-1.1.dsc f393d192d9d84ed5d0e04e2f8f12d4054e1fb8be 2992 sslscan_1.11.5-rbsec-1.1.debian.tar.xz Checksums-Sha256: fcbe332f534182e8bff1ca056d6ad97960f18402907fd6de221a0d0281905abb 1787 sslscan_1.11.5-rbsec-1.1.dsc c8db5f1815cf5dda7386d69bd75006f1eae93b0826ec8e9056b95762c7552d67 2992 sslscan_1.11.5-rbsec-1.1.debian.tar.xz Files: 4c714e602a2e1735fbd90fe2d27dde58 1787 utils extra sslscan_1.11.5-rbsec-1.1.dsc 5e099ecd031c62514b478100ef1bcb62 2992 utils extra sslscan_1.11.5-rbsec-1.1.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEXEj+YVf0kXlZcIfGTFprqxLSp64FAlhuUvAACgkQTFprqxLS p6765g/+LhnFA1AthrIjaOISj8YCTRBnt2xfsCKbu4mFxenq9wqZtBsT9kMS8mPj NfJ8JQplI3xkPw74fqfBEMroCg1qlDJT+ZCg3Y4SvcDdWvii1D6+3wdRDFKOYw/K qKTkOmr8rEq7V7BbnTdxxJA1TW77J6XFPkhoYy92nEmSqd4qjlrpZc6Jpc58ML89 hdZqtJv7KrpdHvikHLuK/xLXTcg3I/3qM8MYjQAgVn8FQI6iF5i3fjgmyKz7CsXA tHnDTXyn6bE3l10UOQpj62QM2eMhktiX34gzwoCKPsLQpcdosteCwUfQKFNAKR0L F+53kwgi3/zlVNZB2hgjnf2C4F81cjpfBkLXqDT00MdE+kETHsQnXygfLH1rByw1 k1ewR6eDzu7+4PYcjhR9YrXAfp06ensFq/D1G0ySIjHxuTIWlYr8w+fbwBBBfsrF +UidPA6nlErgrqFUsucOsUavQwvMyiP4rz/Ud4yD/63n/KCGVFMeNDsOzMqf3Ljz UMHhsh/6DxuHrOVCmLGmJDcY7Qvw1SKAoGfi2ODQOcm6r7LvwxkJUBjJu02lxSlv MgcPraCpJjrvcfV5bp4O3ItHP2US96eXG6bO1FdmF00fR/DcUgjaBundVB9B/dJ9 eiUAmdECJroxUV8T1cIQBN3eQ/sRukQGFKeDDFVHk1GeLNLJ/ZA= =g7s0 -END PGP SIGNATURE End Message ---
Bug#850246: missing dependencies, does not work
Quoting Michal Čihař : The library is now completely unusable as it requires at least social_core, which is not yet packaged. All files are currently stub which should map old social auth API to new modularized code and without the dependencies this is just completely unusable. Oh, sh*t, big fail. I was aware of the deprecation and mentioned it in d/ch, but must have confused the versions :~( I think best approach would be to revert to 0.2.x for now as there is no chance new packages 0.3.x requires will get in (due to soft freeze starting today). Yes, reverting the code would be the best measure. The new code base would not be a good idea for stretch anyway so late, even if we had some weeks left. I'll use an epoch (1:) to be able to go back to 0.2.19+dfsg-2. Otherwise it would be confusing which version Debian actually ships.
Bug#850236: python-django: FTBFS (AssertionError)
On Thu, Jan 05, 2017 at 04:07:58PM +0100, Raphael Hertzog wrote: > On Thu, 05 Jan 2017, Santiago Vila wrote: > > It depends. My goal is to build 25000 source packages in a row and have > > 0.5 failures on average in total (i.e. closer to 0 than to 1). > > > > If we have 50 packages which FTBFS randomly, they should fail less > > than 1% on average. > > > > One week every 4 years is more than 7% of the time. Too much for my taste. > > Your mathematics are broken :-) > > 52 weeks per year, 1 week out of 4 years = 1 / (4*52) = 0.0048 < 0.5% Ooops! You are right. I did 7/365.25*4 by mistake, not 7/(365.25*4)... Thanks a lot.
Bug#844781: dietlibc: waitpid broken w/ -lpthread on s390, s390x, mips64, ia64
Control: clone -1 -2 Control: retitle -2 Various regressions in unit tests when linking against -lpthread On 01/05/2017 12:17 PM, Christian Seiler wrote: > The correct solution is to change the name of the function to > __libc_waitpid in __waitpid.c and to define a weak alias for > waitpid there. I'm already working on this (saw your initial email > where you reassigned this), and will do an upload soon together > with regression tests for this. So I now started to run the test suite by also linking against -lpthread and found two test suite failures already on amd64 (haven't tried the other platforms yet) if just -lpthread is added. Since none of the test suite run uses pthreads directly, this is because weak symbol overrides in the pthreads library cause unrelated functions to fail. Yikes. I'm cloning this bug report to track that problem separately. Regards, Christian
Processed: Re: Bug#844781: dietlibc: waitpid broken w/ -lpthread on s390, s390x, mips64, ia64
Processing control commands: > clone -1 -2 Bug #844781 [dietlibc] dietlibc: waitpid broken with -lpthread on s390, s390x, mips64, ia64 Bug 844781 cloned as bug 850276 > retitle -2 Various regressions in unit tests when linking against -lpthread Bug #850276 [dietlibc] dietlibc: waitpid broken with -lpthread on s390, s390x, mips64, ia64 Changed Bug title to 'Various regressions in unit tests when linking against -lpthread' from 'dietlibc: waitpid broken with -lpthread on s390, s390x, mips64, ia64'. -- 844781: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844781 850276: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850276 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#848851: marked as done (linux: FTBFS on ppc64el)
Your message dated Thu, 05 Jan 2017 16:00:10 + with message-id and subject line Bug#848851: fixed in linux 4.8.15-2 has caused the Debian Bug report #848851, regarding linux: FTBFS on ppc64el to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 848851: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848851 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: linux Version: 4.8.15-1 Severity: serious Justification: FTBFS Hi src:linux 4.8.15-1 FTBFS on ppc64el. Log: https://buildd.debian.org/status/fetch.php?pkg=linux&arch=ppc64el&ver=4.8.15-1&stamp=1482184049 [...] CC crypto/af_alg.mod.o CC crypto/algif_aead.mod.o ld: arch/powerpc/boot/zImage.pseries: Not enough room for program headers, try linking with -N ld: final link failed: Bad value /«PKGBUILDDIR»/arch/powerpc/boot/Makefile:323: recipe for target 'arch/powerpc/boot/zImage.pseries' failed make[6]: *** [arch/powerpc/boot/zImage.pseries] Error 1 make[6]: *** Waiting for unfinished jobs CC crypto/algif_hash.mod.o arch/powerpc/Makefile:285: recipe for target 'zImage' failed make[5]: *** [zImage] Error 2 make[5]: *** Waiting for unfinished jobs CC crypto/algif_skcipher.mod.o [...] Regards, Salvatore --- End Message --- --- Begin Message --- Source: linux Source-Version: 4.8.15-2 We believe that the bug you reported is fixed in the latest version of linux, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 848...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Ben Hutchings (supplier of updated linux package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 04 Jan 2017 19:39:36 + Source: linux Binary: linux-source-4.8 linux-support-4.8.0-2 linux-doc-4.8 linux-manual-4.8 linux-kbuild-4.8 linux-cpupower libcpupower1 libcpupower-dev linux-perf-4.8 libusbip-dev usbip hyperv-daemons linux-libc-dev linux-headers-4.8.0-2-all linux-headers-4.8.0-2-all-alpha kernel-image-4.8.0-2-alpha-generic-di nic-modules-4.8.0-2-alpha-generic-di nic-wireless-modules-4.8.0-2-alpha-generic-di nic-shared-modules-4.8.0-2-alpha-generic-di serial-modules-4.8.0-2-alpha-generic-di usb-serial-modules-4.8.0-2-alpha-generic-di ppp-modules-4.8.0-2-alpha-generic-di pata-modules-4.8.0-2-alpha-generic-di cdrom-core-modules-4.8.0-2-alpha-generic-di scsi-core-modules-4.8.0-2-alpha-generic-di scsi-modules-4.8.0-2-alpha-generic-di loop-modules-4.8.0-2-alpha-generic-di btrfs-modules-4.8.0-2-alpha-generic-di ext4-modules-4.8.0-2-alpha-generic-di isofs-modules-4.8.0-2-alpha-generic-di jfs-modules-4.8.0-2-alpha-generic-di xfs-modules-4.8.0-2-alpha-generic-di fat-modules-4.8.0-2-alpha-generic-di md-modules-4.8.0-2-alpha-generic-di multipath-modules-4.8.0-2-alpha-generic-di usb-modules-4.8.0-2-alpha-generic-di usb-storage-modules-4.8.0-2-alpha-generic-di fb-modules-4.8.0-2-alpha-generic-di input-modules-4.8.0-2-alpha-generic-di event-modules-4.8.0-2-alpha-generic-di mouse-modules-4.8.0-2-alpha-generic-di nic-pcmcia-modules-4.8.0-2-alpha-generic-di pcmcia-modules-4.8.0-2-alpha-generic-di nic-usb-modules-4.8.0-2-alpha-generic-di sata-modules-4.8.0-2-alpha-generic-di crc-modules-4.8.0-2-alpha-generic-di crypto-modules-4.8.0-2-alpha-generic-di crypto-dm-modules-4.8.0-2-alpha-generic-di ata-modules-4.8.0-2-alpha-generic-di nbd-modules-4.8.0-2-alpha-generic-di squashfs-modules-4.8.0-2-alpha-generic-di virtio-modules-4.8.0-2-alpha-generic-di zlib-modules-4.8.0-2-alpha-generic-di fuse-modules-4.8.0-2-alpha-generic-di srm-modules-4.8.0-2-alpha-generic-di linux-headers-4.8.0-2-common linux-image-4.8.0-2-alpha-generic linux-headers-4.8.0-2-alpha-generic linux-image-4.8.0-2-alpha-generic-dbgsym linux-image-4.8.0-2-alpha-smp linux-headers-4.8.0-2-alpha-smp linux-image-4.8.0-2-alpha-smp-dbgsym linux-headers-4.8.0-2-all-amd64 linux-image-4.8.0-2-amd64-unsigned linux-headers-4.8.0-2-amd64 linux-image-4.8.0-2-amd64-dbgsym xen-linux-system-4.8.0-2-amd64 linux-headers-4.8.0-2-common-rt linux-image-4.8.0-2-rt-amd64-unsigned linux-headers-4.8.0-2-rt-amd64 linux-image-4.8.0-2-rt-amd64-dbgsym linux-headers-4.8.0-2-all-arm64 linux-
Processed: tagging 849813
Processing commands for cont...@bugs.debian.org: > tags 849813 + pending Bug #849813 [zfs-zed] [openmediavault.local] zfs-zed.service can't start Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 849813: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849813 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#850243: forge: FTBFS on multiple architectures
control: block -1 by 850277
Processed: Re: forge: FTBFS on multiple architectures
Processing control commands: > block -1 by 850277 Bug #850243 [src:forge] forge: FTBFS on multiple architectures 850243 was not blocked by any bugs. 850243 was not blocking any bugs. Added blocking bug(s) of 850243: 850277 -- 850243: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850243 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#850276: dietlibc: libpthread overrides __errno_location even with TLS enabled
Processing control commands: > retitle -1 dietlibc: libpthread overrides __errno_location even with TLS > enabled Bug #850276 [dietlibc] Various regressions in unit tests when linking against -lpthread Changed Bug title to 'dietlibc: libpthread overrides __errno_location even with TLS enabled' from 'Various regressions in unit tests when linking against -lpthread'. -- 850276: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850276 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#849813: marked as done ([openmediavault.local] zfs-zed.service can't start)
Your message dated Thu, 05 Jan 2017 16:20:14 + with message-id and subject line Bug#849813: fixed in zfs-linux 0.6.5.8-3 has caused the Debian Bug report #849813, regarding [openmediavault.local] zfs-zed.service can't start to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 849813: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849813 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: zfs-zed Version: 0.6.5.8-2~bpo8+1 Severity: minor Dear Maintainer, zfs-zed.service can't start since there is no /sbin/zed here is `systemctl status -l zfs-zed` log ● zfs-zed.service - ZFS Event Daemon (zed) Loaded: loaded (/lib/systemd/system/zfs-zed.service; enabled) Active: failed (Result: exit-code) since 토 2016-12-31 21:20:36 KST; 16s ago Docs: man:zed(8) Process: 28615 ExecStart=/sbin/zed -F (code=exited, status=203/EXEC) -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-0.bpo.2-amd64 (SMP w/4 CPU cores) Locale: LANG=ko_KR.UTF-8, LC_CTYPE=ko_KR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages zfs-zed depends on: ii init-system-helpers 1.22 ii libc6 2.19-18+deb8u6 ii libnvpair1linux 0.6.5.8-2~bpo8+1 ii libuuid12.25.2-6 ii libzfs2linux0.6.5.8-2~bpo8+1 ii libzpool2linux 0.6.5.8-2~bpo8+1 ii zfs-dkms [zfs-modules] 0.6.5.8-2~bpo8+1 ii zfsutils-linux 0.6.5.8-2~bpo8+1 ii zlib1g 1:1.2.8.dfsg-2+b1 zfs-zed recommends no packages. zfs-zed suggests no packages. -- Configuration Files: /etc/zfs/zed.d/zed.rc changed [not included] -- no debconf information --- End Message --- --- Begin Message --- Source: zfs-linux Source-Version: 0.6.5.8-3 We believe that the bug you reported is fixed in the latest version of zfs-linux, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 849...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Carlos Alberto Lopez Perez (supplier of updated zfs-linux package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 05 Jan 2017 16:23:16 +0100 Source: zfs-linux Binary: libnvpair1linux libuutil1linux libzfslinux-dev libzfs2linux libzpool2linux zfs-dkms zfs-initramfs zfs-dracut zfsutils-linux zfs-zed zfs-dbg Architecture: source Version: 0.6.5.8-3 Distribution: unstable Urgency: medium Maintainer: Debian ZFS on Linux maintainers Changed-By: Carlos Alberto Lopez Perez Description: libnvpair1linux - Solaris name-value library for Linux libuutil1linux - Solaris userland utility library for Linux libzfs2linux - OpenZFS filesystem library for Linux libzfslinux-dev - OpenZFS filesystem development files for Linux libzpool2linux - OpenZFS pool library for Linux zfs-dbg- Debugging symbols for OpenZFS userland libraries and tools zfs-dkms - OpenZFS filesystem kernel modules for Linux zfs-dracut - OpenZFS root filesystem capabilities for Linux - dracut zfs-initramfs - OpenZFS root filesystem capabilities for Linux - initramfs zfs-zed- OpenZFS Event Daemon zfsutils-linux - command-line tools to manage OpenZFS filesystems Closes: 849813 Changes: zfs-linux (0.6.5.8-3) unstable; urgency=medium . * Fix the path on the zfs-zed unit file (Closes: #849813) Checksums-Sha1: ac8be42be6ce2d4dff95cae5345758ab46625120 2924 zfs-linux_0.6.5.8-3.dsc 8a819e83ed5800e9650c7e44ed001c40050545ca 38884 zfs-linux_0.6.5.8-3.debian.tar.xz Checksums-Sha256: d02325452e529cc15bb271f8c2b96b0dde91ed117b03a068743559e20e6318ad 2924 zfs-linux_0.6.5.8-3.dsc 22f8cb98771f4134c383320a53bdbd4e2b8357ef940da856b73b3a68113ee08b 38884 zfs-linux_0.6.5.8-3.debian.tar.xz Files: 5d7c391fb417b5be4d6730375b01d3b3 2924 contrib/kernel optional zfs-linux_0.6.5.8-3.dsc 2c859ffec5b2bf323ff4c7253e0b37d2 38884 contrib/kernel optional zfs-linux_0.6.5.8-3.debian.tar.xz -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJYbm5sAAoJEJZQic5rlfiCh8cQAJdJfoKb1v/l4lvGjaOMwve0 js3ShkABYcwuRosdaB+3v6+IoQw
Bug#850276: dietlibc: libpthread overrides __errno_location even with TLS enabled
Control: retitle -1 dietlibc: libpthread overrides __errno_location even with TLS enabled I've now tracked this down: libpthread apparently overrode __errno_location to point it to td->errno, where td is POSIX thread descriptor. This is just plain wrong, because errno is now a (TLS) variable, while in ancient dietlibc versions it used to be defined as the dereference of said function. However, syscalls still use that function to set the errno, so any code checking errno would fail in that case. Once I've made sure #844781 is fixed (and no other problems have arisen in the mean time), this will be part of the next upload. Regards, Christian
Bug#850281: python-gitdb: FTBFS on mips
Source: python-gitdb Version: 2.0.0-2 Severity: serious X-debbugs-Cc: on...@debian.org python-gitdb FTBFS on mips on the buildd: https://buildd.debian.org/status/fetch.php?pkg=python-gitdb&arch=mips&ver=2.0.0-2&stamp=148361 -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Processed: Proper version tracking
Processing commands for cont...@bugs.debian.org:
> fixed 85 2.0.21-18
Bug #85 {Done: Takatsugu Nokubi }
[namazu2,namazu2-index-tools] namazu2-index-tools and namazu2: error when
trying to install together
Marked as fixed in versions namazu2/2.0.21-18.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
85: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=85
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#786566: this is affecting us
On 05/01/17 10:08, Roger Leigh wrote: On 05/01/17 09:23, Brian May wrote: Peter Palfrader writes: It's a serious bug that makes it break in many cases, requiring the sysadmin to clean up and/or reboot the system. Whether or not it's RC in the end is the decision of the release team, but this severity was set after discussing this on #debian-release. Is anything being done to fix this? What is the hold up? Apparently there is a patch for this RC bug and the other RC bug #817236. I'm not personally working on any fix in schroot, since it's not an schroot bug. It is kind of looking like stretch will get released without schroot support, or any packages that depend on it. Maybe time to forgot schroot and look for alternatives??? schroot is not responsible for setting up device nodes in a debootstrapped chroot. We expect them to be set up correctly. This isn't a Debian-specific constraint; we expect all chroots of any sort to be in a sane and directly usable state. schroot's requirements are not any different here from that of the basic chroot(8). Is chroot(8) equally broken here? The mounts and other features schroot offers on top of that are entirely optional, and implementation wise is nothing more than a wrapper around chroot(2) to perform exactly the same job as chroot(8) with some sudo-like PAM authentication and authorisation. While we could add additional mounts to the schroot fstab templates, it's important to understand that this is optional functionality, and has always been optional. It's not a mechanism for working around external breakage. Looking for alternatives to schroot is entirely your choice, but breaking basic system-level functionality which has been working for over two decades, and used for over 11 years by schroot, is I think something which needs careful consideration. I'm prepared to do some work to ensure that schroot interoperates with contemporary systems, but working around breakage like this is perhaps a step too far. Very sorry, replying to the wrong ticket here. Got confused with #817236. For this specific issue with mount options, I've been following along but so far the discussion and proposed patches in this bug haven't reached a definitive conclusion with a consensus, so I'm waiting on an informed decision before I apply anything upstream. I don't myself have the expertise to judge what the right action is here, so I'll defer to others for what's best. Speaking frankly, I'm appalled that such gratuitous breakage through incompatible changes to the functioning of the base system was and is considered at all acceptable. There's over 20 years of software development and admin experience on Debian, 11 for schroot, and there's a lot of code, and a lot of sysadmin-related scripting and expectations which makes assumptions about how mount(2) and mount(8) will behave. schroot is just one tool amongst many which expects them to work in the traditional, documented and most of all portable way. Changing fundamental default system-wide behaviour on a whim is not what I would expect for a mature and established system. I'd expect rather more considered and measured incremental change, which is something I've tried to pay proper attention to in my own work. As an opt-in option for certain mounts, it would be fine, but enforcing it system wide is somewhat cavalier and inconsiderate of the multi-decade established semantics which we expect. This significant change in attitude is one of the factors behind my no longer actively using or developing on Debian. Like it or not, it's become a mature system, and that brings with it some responsibility toward backward compatibility even when we might want to rip it all out and start over with something new and exciting. Too late to fix that now, so I'll consider applying upstream whatever makes most sense. However, I must stress that schroot must remain portable to non-systemd-Linux, GNU/Hurd, GNU/kFreeBSD and FreeBSD, and any patches must not break this support. Roger
Bug#850286: lambdabot FTBFS in stretch
Package: lambdabot Version: 5.0.3-4 Severity: serious Tags: stretch sid # apt-get build-dep lambdabot Reading package lists... Done Reading package lists... Done Building dependency tree... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: builddeps:lambdabot : Depends: libghc-lambdabot-core-dev (< 5.1) but 5.1-2+b3 is to be installed Depends: libghc-lambdabot-haskell-plugins-dev (>= 5.0.3) but it is not installable Depends: libghc-lambdabot-haskell-plugins-dev (< 5.1) but it is not installable Depends: libghc-lambdabot-irc-plugins-dev (< 5.1) but 5.1-2+b3 is to be installed Depends: libghc-lambdabot-misc-plugins-dev (< 5.1) but 5.1-2+b3 is to be installed Depends: libghc-lambdabot-novelty-plugins-dev (< 5.1) but 5.1-2+b3 is to be installed Depends: libghc-lambdabot-reference-plugins-dev (< 5.1) but 5.1-2+b3 is to be installed Depends: libghc-lambdabot-social-plugins-dev (< 5.1) but 5.1-2+b3 is to be installed E: Unable to correct problems, you have held broken packages. #
Bug#848137: [Dbconfig-common-devel] Bug#848137: problem with the upgrade of tango-db
Hello, I discuss with the tango-db upstream and he found that this one line fixed the problem, befrore doing the tango-db upgrade UPDATE mysql.proc SET Definer='tango@localhost' where Db='tango'; Ideally it should be something like UPDATE mysql.proc SET Definer='xxx' where Db='yyy'; where xxx is the dbuser and yyy the database name.à It is true that for now my package works only if the database name is tango. this is a limitation but I do not want to mix this into this bug report. so can you help me write the right snipser at the right place in the debian scripts. Or maybe I should just put the upgrade script og tango-db 9.2.5 intot eh dbadmin part with this fix at the end in order to have something consistant forthe next upgrade (tango 10) Thanks for your help Cheers Frederic
Bug#849593: Re: Bug#849593: libfftw3-single3: dependencies in shlibs file not tight enough
Hi,
Please CC me, I only just saw this email when I checked on the bugreport.
On 30/12/16 17:17, Ghislain Vaillant wrote:
> CC'd to d-science,
>
> On Fri, 30 Dec 2016 01:24:07 + James Cowgill wrote:
>> On 30/12/16 00:50, Ghislain Vaillant wrote:
>> > On Thu, 29 Dec 2016 00:30:58 + James Cowgill
>> > wrote:
>> >> On 29/12/16 00:02, Oleksandr Gavenko wrote:
>> >>> Package: ardour
>> >>> Version: 1:5.5.0~dfsg-1
>> >>> Severity: important
>> >>>
>> >>> Application is being crashing constantly with:
>> >>>
>> >>> bash# ardour5
>> >>> /usr/lib/ardour5/ardour-5.5.0: symbol lookup error:
>> /usr/lib/ardour5/ardour-5.5.0: undefined symbol:
>> fftwf_make_planner_thread_safe
>> >> [...]
>> >>> Versions of packages ardour depends on:
>> >> [...]
>> >>> ii libfftw3-single3 3.3.4-2
>> >
>> > How come? Both testing and unstable have 3.3.5-1.
>>
>> I don't think that matters. Partial upgrades should work (and
>> derivatives may rely on it).
>
> Next time, it would be nice to explain upfront that the new version of
> ardour you are trying to build may *conditionally* use new features
> introduced by FFTW 3.5:
>
> https://github.com/Ardour/ardour/search?utf8=%E2%9C%93&q=fftwf_make_planner_thread_safe&type=Code
OK, but I don't think the conditionally part is relevant here. Any
package which uses the new function from FFTW 3.3.5 - conditionally or
not - has the potential to be broken by this bug. Since the condition is
evaluated at compile time, it will always be true in the ardour Debian
package in stretch/sid.
>> >> This package is the problem. The fftwf_make_planner_thread_safe
>> >> function is only present in fftw3 3.3.5 (so upgrading your package
>> >> would fix this). fftw3 should generate a stricter dependency so that
>> >> this doesn't happen.
>> >
>> > libfftw3-dev depends on libfftw3_single3 (=${binary:Version}).
>> >
>> > How is that not strict enough?
>>
>> I'm talking about the dependency from ardour to libfftw3_single3. The
>> dependency from libfftw3-dev doesn't matter here.
>
> Maybe this could be *temporarily* fixed on ardour's end by requiring
> libfftw3-dev (>= 3.3.5) as a b-dep no?
No, changing the build-dependencies has no effect on the runtime
dependencies (well for the majority of packages at least).
The temporary fix would be to add a "Depends: libfftw3-single3 (>=
3.3.5)" to ardour, but that won't fix anyone else who wants to use
features from 3.3.5.
>> >> fftw3 maintainers: to fix this you either need to provide a symbols
>> >> file, or pass a suitable -V option to dh_makeshlibs so the shlibs file
>> >> contains a stricter dependency.
>> >
>> > Please be more explicit about the expected outcome (i.e. the stricter
>> > dependency you keep mentioning).
>>
>> Please read policy 8.6 which describes most of this more fully.
>>
>> The goal is for dpkg-shlibdeps to generate a dependency like
>> "libfftw3-single3 (>= 3.3.5)" for any package which uses
>> fftwf_make_planner_thread_safe. This is needed otherwise you may get a
>> linker error like ardour does, and it's is done by using the symbols or
>> shlibs systems as described in policy 8.6.
>
> I am personally not familiar with the symbols stuff, so it would be up
> to somewhat from the team or yourself to provide a patch for this issue.
This is my attempt at fixing it the shlibs way (completely untested
however). A symbols file would be a lot more work but with more accurate
dependencies.
diff -ur a/debian/rules b/debian/rules
--- a/debian/rules 2016-10-03 17:12:31.0 +0100
+++ b/debian/rules 2017-01-05 17:35:18.123168915 +
@@ -168,7 +168,11 @@
dh_strip --dbg-package=libfftw3-dbg -a
dh_compress -a
dh_fixperms -a
- dh_makeshlibs -a
+ dh_makeshlibs -plibfftw3-single3 -V'libfftw3-single3 (>= 3.3.5)'
+ dh_makeshlibs -plibfftw3-double3 -V'libfftw3-double3 (>= 3.3.5)'
+ dh_makeshlibs -plibfftw3-long3 -V'libfftw3-long3 (>= 3.3.5)'
+ dh_makeshlibs -plibfftw3-quad3 -V'libfftw3-quad3 (>= 3.3.5)'
+ dh_makeshlibs -a --remaining-packages
dh_installdeb -a
dh_shlibdeps -a
dh_gencontrol -a
Thanks,
James
signature.asc
Description: OpenPGP digital signature
Bug#817649: marked as done (redet: Removal of debhelper compat 4)
Your message dated Thu, 5 Jan 2017 16:30:53 -0200 with message-id and subject line Re: redet: Removal of debhelper compat 4 has caused the Debian Bug report #817649, regarding redet: Removal of debhelper compat 4 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 817649: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817649 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: redet Severity: important Usertags: compat-4-removal Hi, The package redet uses debhelper with a compat level of 4, which is deprecated and scheduled for removal. * Please bump the debhelper compat at your earliest convenience. on the 15th of June. - Compat 9 is recommended - Compat 5 is the bare minimum - If the package has been relying on dh_install being lenient about missing files, please see "MIGRATING TO COMPAT 5 OR LATER" in [1]. * Compat level 4 will be removed on the first debhelper upload after the 15th of June. Thanks, ~Niels [1] https://lists.debian.org/debian-devel/2015/09/msg00257.html --- End Message --- --- Begin Message --- The problem was solved in last upload (8.26-1.2). However, I closed the wrong bug in debian/changelog. Regards, Eriberto--- End Message ---
Bug#810349: linux-patch-grsecurity2: removal of linux-patch-grsecurity2?
Control: severity -1 important On Thu, Mar 17, 2016 at 5:14 PM, Yves-Alexis Perez wrote: > On jeu., 2016-03-17 at 14:22 +0100, László Böszörményi (GCS) wrote: >> But as mentioned above, I think six months >> updates may be enough for advanced users. You get new features while >> not compile a new kernel every second day. This seems to be a good >> balance. > > I sure hope people update kernel more often than every six months. Of course, it depends on the machine and the environment. A machine with direct connection on the internet should be updated frequently. A machine with a small number of trusted users on an internal LAN may not be updated daily. >> Hope this is more clear now. > > Not really, but at least for the initial intent of this bug, yes: you want to > keep the package in the archive :) I do. Lowering the severity for now. Regards, Laszlo/GCS
Processed: Re: Bug#810349: linux-patch-grsecurity2: removal of linux-patch-grsecurity2?
Processing control commands: > severity -1 important Bug #810349 [src:linux-patch-grsecurity2] linux-patch-grsecurity2: removal of linux-patch-grsecurity2? Severity set to 'important' from 'serious' -- 810349: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810349 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#850298: Provides: policykit-1-gnome breaks other desktop environments like Cinnamon
Source: mate-polkit Version: 1.16.0-1 Severity: serious mate-polkit has Provides: policykit-1-gnome but the xdg autostart contains OnlyShowIn=Mate; As a result, desktop environments like Cinnamon, which have a dependency on policykit-1-gnome will be broken, unless the real policykit-1-gnome package is installed. -- System Information: Debian Release: stretch/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#828616: workaround for FTBFS
It may be too late for this, but here goes: In the source package's control file, if you replace the Build-Depends on libssl-dev with: libssl1.0-dev | libssl-dev (<< 1.1.0~) the package builds and appears to work normally. This is what OpenSSH (and maybe others) used to get past this FTBFS for this transition. I use this package regularly and hope it makes it into stable Stretch, especially since it seems that Debian can't become OpenSSL 1.1-only in this release cycle.
Bug#849657: [Ceph-maintainers] Bug#849657: ceph: FTBFS on mips(el): g++: virtual memory exhausted: Cannot allocate memory
On 2017-01-05 14:00, Gaudenz Steinlin wrote: > > Hi > > Aurelien Jarno writes: > > > On 2016-12-30 10:06, Emilio Pozuelo Monfort wrote: > >> On 29/12/16 20:56, Gaudenz Steinlin wrote: > > > > The problem is indeed a memory issue, not that the buildd doesn't have > > enough memory, but just that you can allocate only 2GB per process on a > > 32-bit MIPS machine. As Emilio said, the above GCC flag should help to > > reduce the memory usage by running the garbage collector more often. > > > > However gcc 6.3 seems to have improved the situation a bit, so I given > > back the packages, I hope they will build now. Otherwise I have a patch > > ready to change the GCC defaults. That said GCC upstream consider it's a > > bug in the garbage collector [1], so that should be fixed instead and the > > patch should be considered as a temporary workaround. > > > > Aurelien thanks for taking care and resheduling the build. Unfortunately > this did not solve the problem. But setting the following variables > solves the virtual memory issue for me on the mipsel porterbox (eller): > > export DEB_CFLAGS_MAINT_APPEND= --param ggc-min-expand=10 -O1 > export DEB_CXXFLAGS_MAINT_APPEND= --param ggc-min-expand=10 -O1 > export DEB_CFLAGS_MAINT_STRIP= -O2 > export DEB_CXXFLAGS_MAINT_STRIP= -O2 Thanks for testing that. I have found that the issue is also workarounded by keeping -O2 and --param ggc-min-expand=5, which is a quite aggressive value. The patch I have for GCC reduced the value to 30 (which corresponds to disabling the heuristics). Also note that the build failure actually only concern the testsuite, the code itself builds without any change. I'll report the bug to upstream with the preprocessed source as I have been advised. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Processed: Re: Bug#848178: gimagereader fails to start
Processing control commands: > severity -1 normal Bug #848178 [libtesseract3] libtesseract3: generated shlibs dependencies are not strict enough Severity set to 'normal' from 'grave' -- 848178: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848178 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#848178: gimagereader fails to start
Control: severity -1 normal On Fri, 16 Dec 2016 12:23:03 +0100 Philip Rinn wrote: > Hi Adrian, > > On 15.12.2016 at 20:50, Adrian Bunk wrote: > > Please do not close bugs that are actual bug - the generated > > dependencies must ensure that problems like the issue in this > > bug won't happen. > > > > Reopened and moved to the package where the root cause of this bug is. > > well, so true. > > The root cause of this bug was a silent ABI break in tesseract 3.04.00 -> > 3.04.01 > which is reverted upstream > (https://github.com/tesseract-ocr/tesseract/issues/254). This was reverted in release 3.04.01-3 of the package as well. Downgrading the severity because everything seems to be usable again. Thanks, _g. signature.asc Description: OpenPGP digital signature
Bug#828556: sslscan: FTBFS with openssl 1.1.0
On 2017-01-05 15:08:00 [+0100], Christoph Berg wrote:
> NMU diff:
>
>
> Control files: lines which differ (wdiff format)
>
> Build-Depends: debhelper (>= 9), {+libssl1.0-dev |+} libssl-dev {+(<<
> 1.1.0~)+}
why on libssl-dev (<< 1.1.0~)?
Otherwise I'm fine with it. I asked the release team & security if they
object adding openssl's source to sslscan and the release was not too
happy about it. With latest libssl1.0 upload sslscan won't be able to
detect 3des ciphers…
> Christoph
Sebastian
Bug#850317: reportbug: crashes when attaching a .tar.gz
Package: reportbug Version: 7.1.2 Severity: grave Justification: causes non-serious data loss -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 When attaching a gzip'ed tarball to a bug report, reportbug crashes without writing the drafted bug report anywhere: application/gzip; charset=binary Traceback (most recent call last): File "/usr/bin/reportbug", line 2233, in main() File "/usr/bin/reportbug", line 1107, in main return iface.user_interface() File "/usr/bin/reportbug", line 2224, in user_interface self.options.envelopefrom) File "/usr/lib/python3/dist-packages/reportbug/submit.py", line 209, in send_report (message, failed) = mime_attach(body, attachments, charset, body_charset) File "/usr/lib/python3/dist-packages/reportbug/submit.py", line 177, in mime_attach email.Encoders.encode_base64(part) AttributeError: module 'email' has no attribute 'Encoders' - -- Package-specific info: ** Environment settings: EDITOR="jupp" PAGER="less" DEBEMAIL="n...@naturalnet.de" DEBFULLNAME="Dominik George" INTERFACE="text" ** /home/nik/.reportbugrc: reportbug_version "6.4.3" mode advanced ui text realname "Dominik George" email "n...@naturalnet.de" smtphost "shore.naturalnet.de:587" smtpuser "nik" smtptls - -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/lksh Init: systemd (via /run/systemd/system) Versions of packages reportbug depends on: ii apt1.4~beta2 ii python3-reportbug 7.1.2 pn python3:any reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail ii debconf-utils 1.5.59 pn debsums pn dlocate ii emacs24-bin-common 24.5+1-7.1 ii file1:5.29-2 ii gir1.2-gtk-3.0 3.22.5-1 ii gir1.2-vte-2.91 0.46.1-1 ii gnupg 2.1.17-2 ii postfix [mail-transport-agent] 3.1.3-6 ii python3-gi 3.22.0-2 pn python3-gtkspellcheck pn python3-urwid ii xdg-utils 1.1.1-1 Versions of packages python3-reportbug depends on: ii apt1.4~beta2 ii file 1:5.29-2 ii python3-debian 0.1.29 ii python3-debianbts 2.6.1 ii python3-requests 2.12.4-1 pn python3:any python3-reportbug suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iQJ4BAEBCABiFiEEPJ1UpHV1wCb7F/0mt5o8FqDE8pYFAlhususxGmh0dHBzOi8v d3d3LmRvbWluaWstZ2VvcmdlLmRlL2dwZy1wb2xpY3kudHh0LmFzYxIcbmlrQG5h dHVyYWxuZXQuZGUACgkQt5o8FqDE8pbruhAAhPRFobJ3P2swV99KSKB1Fwhk/NhW 0z1Jk3tFJEj7IqMkuemNzurWBfMOiOgyGqblPBzkaoAavrkMlI38isbpP/cBoI/4 4/q6T4Ou7DogHkXCeENm3C7JKfuLX7I0PLrZV4sWnasQxK5IFKLI5amc8vnipSmF k1ls1MQrEe5nGA480Qqa19BXWxfkbVFIGndxKFFdMf+NtbuWk5FWdR7gbsB/Pz66 3hbinSuVUH166x3qAlSXheUPV3zWhhVNZ+CM++7ixqR7UA7khjn9peYDr8VWQQ6J 574tKH5Kw3467mw9HANFBoPuEqWA/xlnYFbmxVS3OVD1dKmUK1GFXlx1teZOcjK6 FAzCEIBWk6qUGsOXeglfhS2D6IHa9E6nQbT9GYeMRy/ApL71Xf8mu1eLNPPOFFem m9B4yp4RXu4K1Xuhfn/zuIahRY85e+rZ0trtLjV8+/IQlzjPtbYvlR8von9ngYZ/ mG5QkpOWznHHmowvScPUoJMoGuNgDRanRO8HJFhf018VoEadfAaUWd7zMw49JdYj IphpH/bedoCMqc6b+0kySLoD/npKivku50LQyg6bGMHuPX2c4Lb746/1+kU8RiI8 Ry6yTjtyAKVSVdKMKQhBxB08nPJ+OE9t7MIWDTfuw64wkhDl2X5AJKcIDyUsr01B Gm6doB3yOAIZXC8= =3Abt -END PGP SIGNATURE-
Bug#850320: mock: CVE-2016-6299: privilige escalation via mock-scm
Source: mock Version: 1.3.2-1 Severity: grave Tags: patch security upstream Justification: user security hole Hi, the following vulnerability was published for mock. I'm not too familiar with it, but following the code and the applied upstream commit 1.3.2-1 should be vulnerable. CVE-2016-6299[0]: privilige escalation via mock-scm If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2016-6299 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6299 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1375490 [2] https://github.com/rpm-software-management/mock/commit/8b02f43beadacf6911200b48d94e39e891a41da9 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#848234: txwinrm,winrm: error when trying to install together
Dear Dan, Thanks for getting in touch - sorry for not replying sooner. "winrm" is the name of a Microsoft Windows command, so users might expect a Linux command with the same name to perform a similar function. I'm not familiar with what the command in your package does, and it's a while since I did the original txwinrm packaging so I'm not sure off hand which of our commands is closer to the Windows winrm. I'll try to find some time in the next week or so to refresh my memory of the details, and consider what an appropriate name for the command in my package would be. Hope that's soon enough? Thanks. Christopher On 22 December 2016 at 10:08, Daniel Stender wrote: > Hi Christopher, > > we have a binaries-have-conflict between our packages and we have to > negotiate how to handle > this. > > I standpoint is, masterzen-winrm was in first (2016-04-14), so I would like > to ask if > you could change your package to solve this. I would change mine if this > would be the > other way around. Is that alright with you? > > Dan > > -- > 4096R/DF5182C8 > Debian Developer (sten...@debian.org) > LPIC-1 (LPI000329859 64mz6f7kt4) > http://www.danielstender.com/
Bug#834007: marked as done (bookletimposer: Should not be part of Stretch)
Your message dated Thu, 05 Jan 2017 22:53:38 +0100 with message-id <85k2a9i36l@boum.org> and subject line Re: Bug#834007: bookletimposer: Should not be part of Stretch has caused the Debian Bug report #834007, regarding bookletimposer: Should not be part of Stretch to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 834007: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834007 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: bookletimposer Version: 0.2-5 Severity: serious X-Debbugs-Cc: k...@a4nancy.net.eu.org bookletimposer has de facto been abandoned upstream: last upstream commits I can see are 4+ years old, I'm not aware of any _working_ upstream Git repo, no reply from the author on some forwarded bugs and patches since 2-3 years, and we're now carrying a patch for #763974 since upstream never addressed it on their side. In the current state of things I'm not comfortable with the perspective of maintaining bookletimposer for 3-5 years in the next Debian stable release: this would simply put too much responsibility on my shoulders, and I don't want to slowly become upstream for one more project. Hence this RC bug to get it auto-removed from testing, and block the migration of future uploads to testing, until the situation changes. I'm happy to keep it in sid for a few more years though, and I'd love to change my mind regarding suitability for a stable release, whenever the situation evolves :) Cheers! --- End Message --- --- Begin Message --- Hi, I've got good news! intrig...@debian.org: > bookletimposer has de facto been abandoned upstream: This appears to not be the case anymore. > I'm not aware of any _working_ upstream Git repo, https://git.codecoop.org/kjo/bookletimposer.git is the new location. The upstream homepage was updated to reflect that. > no reply from the author on some forwarded bugs and > patches since 2-3 years, and we're now carrying a patch for > #763974 since upstream never addressed it on their side. The patches we are shipping have now been integrated upstream. I'm not holding my breath for a new release, but that's a very good start :) > […] and I'd love to change my mind regarding suitability for > a stable release, whenever the situation evolves :) I'm willing to give it a try for Stretch, so I'm closing this bug. Cheers! -- intrigeri--- End Message ---
