Bug#593700: The package has a generic C version of this function

[Bálint Réczey]

tag 593700 patch
thanks

Hi,

I think this small patch should fix the ia64 build problem.
I haven't tried it myself because I lack the necessary hardware.

Cheers,
Balint
--- source/snd_qf/snd_mix.c.orig	2010-12-18 00:19:32.0 +0100
+++ source/snd_qf/snd_mix.c	2010-12-18 00:20:47.0 +0100
@@ -27,7 +27,7 @@
 int *snd_p, snd_linear_count, snd_vol, music_vol;
 short *snd_out;
 
-#if !defined ( id386 ) || defined ( __MACOSX__ )
+#if !defined ( id386 ) || defined ( __MACOSX__ ) || defined ( __ia64__ )
 #ifdef _WIN32
 #pragma warning( push )
 #pragma warning( disable : 4310 )   // cast truncates constant value

Bug#603986: qgis crashes on startup on PowerPC

[Bálint Réczey]

Hi Hideki,

On Thu, 9 Dec 2010, Hideki Yamane wrote:

> On Sat, 4 Dec 2010 12:47:20 -0500
> Steve  wrote:
>> If I build the qgis .deb files from source on my machine I don't get the
>> crash but the debs from the repository always crash.
>>
>> Is it possible to force a rebuild of the .debs in testing?
>
> Interesting, I cannot reproduce it, always crash with
>  - packages from repository
>  - packages built with pbuilder (sid)
>  - packages built with pbuilder (squeeze)
>  - source from git, built with pbuilder (sid)
>  - source from git, built with pbuilder (squeeze)
>
> Steve, how do you build your deb files?
>

Could you please try to reproduce the crash with the attached patch applied?
It generates a -dbg pkg while stripping so the the crash will probably
happen and we will still be able to debug it. :-)

Cheers,
Balint
diff -Naur qgis-1.4.0+12730.orig//debian/changelog qgis-1.4.0+12730/debian/changelog
--- qgis-1.4.0+12730.orig//debian/changelog	2010-12-30 14:28:08.0 +0100
+++ qgis-1.4.0+12730/debian/changelog	2010-12-30 14:28:30.0 +0100
@@ -1,3 +1,9 @@
+qgis (1.4.0+12730-3~rbalint.dbg0) unstable; urgency=low
+
+  * Ship debug symbols in libqgis1.4.0-dbg package
+
+ -- Balint Reczey   Thu, 30 Dec 2010 13:19:27 +0100
+
 qgis (1.4.0+12730-3) unstable; urgency=low
 
   * Updated debian/control for current Grass snapshot.
diff -Naur qgis-1.4.0+12730.orig//debian/control qgis-1.4.0+12730/debian/control
--- qgis-1.4.0+12730.orig//debian/control	2010-12-30 14:28:08.0 +0100
+++ qgis-1.4.0+12730/debian/control	2010-12-30 14:28:30.0 +0100
@@ -71,9 +71,22 @@
  This package contains the headers and libraries needed to develop plugins for
  Quantum GIS.
 
+Package: libqgis-dbg
+Architecture: any
+Section: debug
+Priority: extra
+Depends: ${misc:Depends}, libqgis1.4.0 (= ${binary:Version})
+Provides: qgis-dev
+Replaces: qgis-dev, libqgis1-dev, libqgis1.4.0-dev
+Description: Quantum GIS - debug symbols
+ Quantum GIS is a Geographic Information System (GIS) which manages, analyzes
+ and display databases of geographic information.
+ .
+ This package contains stripped debugging symbols for Quantum GIS.
+
 Package: qgis-plugin-grass
 Architecture: any
-Depends: qgis (= ${binary:Version}), qgis-plugin-grass-common (= ${source:Version}), ${shlibs:Depends}, ${misc:Depends}, libgdal1-1.6.0-grass, grass640-6
+Depends: qgis (= ${binary:Version}), qgis-plugin-grass-common (= ${source:Version}), ${shlibs:Depends}, ${misc:Depends}, libgdal1-1.6.0-grass, grass640+42329
 Description: GRASS plugin for Quantum GIS
  Quantum GIS is a Geographic Information System (GIS) which manages, analyzes
  and display databases of geographic information.
diff -Naur qgis-1.4.0+12730.orig//debian/control.in qgis-1.4.0+12730/debian/control.in
--- qgis-1.4.0+12730.orig//debian/control.in	2010-12-30 14:28:08.0 +0100
+++ qgis-1.4.0+12730/debian/control.in	2010-12-30 14:28:30.0 +0100
@@ -71,6 +71,19 @@
  This package contains the headers and libraries needed to develop plugins for
  Quantum GIS.
 
+Package: libqgis-dbg
+Architecture: any
+Section: debug
+Priority: extra
+Depends: ${misc:Depends}, libqgis{QGIS_ABI} (= ${binary:Version})
+Provides: qgis-dev
+Replaces: qgis-dev, libqgis1-dev, libqgis1.4.0-dev
+Description: Quantum GIS - debug symbols
+ Quantum GIS is a Geographic Information System (GIS) which manages, analyzes
+ and display databases of geographic information.
+ .
+ This package contains stripped debugging symbols for Quantum GIS.
+
 Package: qgis-plugin-grass
 Architecture: any
 Depends: qgis (= ${binary:Version}), qgis-plugin-grass-common (= ${source:Version}), ${shlibs:Depends}, ${misc:Depends}, libgdal1-1.6.0-grass, grass{GRASS_ABI}
diff -Naur qgis-1.4.0+12730.orig//debian/rules qgis-1.4.0+12730/debian/rules
--- qgis-1.4.0+12730.orig//debian/rules	2010-12-30 14:28:08.0 +0100
+++ qgis-1.4.0+12730/debian/rules	2010-12-30 14:28:30.0 +0100
@@ -136,7 +136,7 @@
 	dh_installmime -pqgis
 	dh_link
 	dh_lintian
-	dh_strip
+	dh_strip --dbg-package=libqgis-dbg
 	dh_compress --exclude=pdf
 	dh_fixperms
 	dh_makeshlibs

Bug#673038: Re: [Pkg-openldap-devel] Bug#673038: Bug#673038: slapd: slapcat output truncated every now and then

[Bálint Réczey]

tags 673038 patch upstream - moreinfo
thanks

Hi,

Upstream seems to know about the problem and I provided a fix for them
with a documentation update.
Slapcat's exit code is 1 in case of missing entries thus an
unsuccessful backup attempt can be detected.
Since there is also a helper script for retrying mentioned in me
earlier email I suggest decreasing the severity of this bug removing
it from the RC list.

Cheers,
Balint

PS: Discussion with upstream starts here:
http://www.openldap.org/lists/openldap-technical/201301/msg00195.html

2013/1/19 Balint Reczey 
>
> forwarded 673038 techni...@openldap.org
> thanks
>
> Hi,
>
> I have forwarded the problem to techni...@openldap.org but it has not
> yet appeared in the list archive.
>
> It worth noting that there exists a script [1] in ldap-git-backup which
> can be used for backing up LDAP databases more reliably.
>
> Cheers,
> Balint
>
> [1]
> https://github.com/elmar/ldap-git-backup/blob/master/README.mdown#safe-ldif
>
> On 06/19/2012 06:27 PM, Quanah Gibson-Mount wrote:
> > --On Tuesday, June 19, 2012 2:25 PM +0200 Axel Beckert
> >  wrote:
> >
> >> Hi Steve,
> >>
> >> Steve Langasek wrote:
> >>> > According to the slapcat man page it should be "always safe to run
> >>> > slapcat with the slapd-bdb(5) ... backends" even if slapd runs. We do
> >>> > use a BDB backend.
> >>>
> >>> Note that the HDB backend is the one recommended upstream and the
> >>> Debian
> >>> default.
> >>
> >> Well, yeah, that system has been dist-upgraded from at least Etch.
> >> IIRC it started at some time when BDB was still the default.
> >>
> >> I wrote that -- according to our backups -- this happened already with
> >> Lenny's slapd. But with Lenny it seemed to have happened less often
> >> (which is why we noticed it only recently).
> >
> > Personally, I would advise you to ask a question about this on
> > openldap-techni...@openldap.org.  I asked Howard about it, and he had
> > a ready answer as to why you were seeing this, but I forget what it
> > is.  In any case, this is not a debian specific openldap bug.
> >
>
>


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

Bug#673038: Re: [Pkg-openldap-devel] Bug#673038: Bug#673038: slapd: slapcat output truncated every now and then

[Bálint Réczey]

Hi Ben,

2013/1/26 Ben Hutchings :
> On Sat, 2013-01-26 at 00:08 +0100, Bálint Réczey wrote:
>> tags 673038 patch upstream - moreinfo
>> thanks
>>
>> Hi,
>>
>> Upstream seems to know about the problem and I provided a fix for them
>> with a documentation update.
>> Slapcat's exit code is 1 in case of missing entries thus an
>> unsuccessful backup attempt can be detected.
> [...]
>
> Really, that's not what it says here:
> https://github.com/elmar/ldap-git-backup/blob/master/README.mdown#safe-ldif
>
> Is there an upstream bug fix that makes the exit code non-zero?
Looking at slapcat.c the intention is returning 1 on errors while not
all error cases seem to be covered:
http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=servers/slapd/slapcat.c;h=6bd9293fe4e980dcd1d7d4a1ccd1a644062fb346;hb=HEAD

IMO the documentation should reflect the intention and the code should
be fixed if it does not do what the documentation says.

Cheers,
Balint


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

Bug#673038: Re: [Pkg-openldap-devel] Bug#673038: Bug#673038: slapd: slapcat output truncated every now and then

[Bálint Réczey]

tags 673038 - patch
thanks


2013/1/27 Ben Hutchings :
> On Sat, 2013-01-26 at 23:45 +0100, Bálint Réczey wrote:
>> Hi Ben,
>>
>> 2013/1/26 Ben Hutchings :
>> > On Sat, 2013-01-26 at 00:08 +0100, Bálint Réczey wrote:
>> >> tags 673038 patch upstream - moreinfo
>> >> thanks
>> >>
>> >> Hi,
>> >>
>> >> Upstream seems to know about the problem and I provided a fix for them
>> >> with a documentation update.
>> >> Slapcat's exit code is 1 in case of missing entries thus an
>> >> unsuccessful backup attempt can be detected.
>> > [...]
>> >
>> > Really, that's not what it says here:
>> > https://github.com/elmar/ldap-git-backup/blob/master/README.mdown#safe-ldif
>> >
>> > Is there an upstream bug fix that makes the exit code non-zero?
>> Looking at slapcat.c the intention is returning 1 on errors while not
>> all error cases seem to be covered:
>> http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=servers/slapd/slapcat.c;h=6bd9293fe4e980dcd1d7d4a1ccd1a644062fb346;hb=HEAD
>>
>> IMO the documentation should reflect the intention and the code should
>> be fixed if it does not do what the documentation says.
>
> I think we're all in agreement that the code should be fixed.  Please
> help to do that, if you can.
Upstream has rejected the proposed fix.
Since it seems I'm not familiar enough with upstream's plans and
coding practices I'm not the best person to provide a fix.

Upstream BTW don't see this issue as an important one and recommends
using the mdb back-end which is expected to be much faster in most
cases and also does not exhibit this problem.

Regarding the Debian Project IMO the best option would be living with
the bug, relying on the workaround for backups and releasing Wheezy
with this bug present.

Cheers,
Balint


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

Bug#1029254: wireshark: FTBFS: AttributeError: '_Outcome' object has no attribute 'errors'

[Bálint Réczey]

Control: fixed -1 4.0.3-1

Lucas Nussbaum  ezt írta (időpont: 2023. jan. 20., P, 12:02):
>
> Source: wireshark
> Version: 4.0.2-1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20230120 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
...
> > ERROR: test_text2pcap_sip_pcapng 
> > (suite_text2pcap.case_text2pcap_pcapng.test_text2pcap_sip_pcapng)
> > Test text2pcap with sip.pcapng.
> > --
> > Traceback (most recent call last):
> >   File "/<>/test/fixtures.py", line 321, in tearDown
> > self._orig_tearDown()
> >   File "/<>/test/subprocesstest.py", line 181, in tearDown
> > if self._last_test_failed():
> >
> >   File "/<>/test/subprocesstest.py", line 168, in 
> > _last_test_failed
> > for test_case, exc_info in self._outcome.errors:
> >
> > AttributeError: '_Outcome' object has no attribute 'errors'

Bug#931097: unattended-upgrades: InvalidURL(f"URL can't contain control characters. {url!r} "

[Bálint Réczey]

Control: tags -1 moreinfo unreproducible

Hi,

duncanwebb  ezt írta (időpont: 2019. jún.
26., Sze, 10:05):
>
> Package: unattended-upgrades
> Version: 0.83.3.2+deb8u1
> Severity: serious
> Justification: normal
>
> Dear Maintainer,
>
> Jessie uses python 3.4 and python 3.4 does not support f"" strings
>
> So now unattended upgrades no longer performs security upgrades.
>
> /etc/cron.daily/apt:
> Traceback (most recent call last):
>   File "/usr/bin/unattended-upgrade", line 55, in 
> import apt
>   File "/usr/lib/python3/dist-packages/apt/__init__.py", line 26, in 
> from apt.package import Package
>   File "/usr/lib/python3/dist-packages/apt/package.py", line 32, in 
> from http.client import BadStatusLine
>   File "/usr/lib/python3.4/http/client.py", line 1014
> raise InvalidURL(f"URL can't contain control characters. {url!r} "
>  ^
> SyntaxError: invalid syntax
>
> The problem is in the file /usr/lib/python3.4/http/client.py, changing (f"URL 
> to ("URL will
> will allow unattended-upgrades to work again but doesn't do what is intended.

Seems to be working for me:

root@j:~# unattended-upgrade --dry-run --verbose
Initial blacklisted packages:
Initial whitelisted packages:
Starting unattended upgrades script
Allowed origins are: ['origin=Debian,codename=jessie,label=Debian-Security']
No packages found that can be upgraded unattended
root@j:~# dpkg -l unattended-upgrades
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version
  ArchitectureDescription
+++--===-===-=
ii  unattended-upgrades
0.83.3.2+deb8u1 all
automatic installation of security upgrades

>
> -- System Information:
> Debian Release: 8.10
>   APT prefers oldstable
>   APT policy: (500, 'oldstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.9.0-0.bpo.5-amd64 (SMP w/32 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages unattended-upgrades depends on:
> ii  apt1.0.9.8.5
> ii  apt-utils  1.0.9.8.5
> ii  debconf [debconf-2.0]  1.5.56+deb8u1
> ii  init-system-helpers1.22
> ii  lsb-base   4.1+Debian13+nmu1
> ii  lsb-release4.1+Debian13+nmu1
> ii  python33.4.2-2

root@j:~# dpkg -l python3.4
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version
  ArchitectureDescription
+++--===-===-=
ii  python3.4
3.4.2-1+deb8u4  amd64
Interactive high-level object-oriented language (version 3.4)

Your python3.4 version seem to be newer than mine. Probably it
introduced a regression.
Please seek for help at the source of this package.

Cheers,
Balint

> ii  python3-apt0.9.3.12
> ii  ucf3.0030
> ii  xz-utils   5.1.1alpha+20120614-2+b3
>
> unattended-upgrades recommends no packages.
>
> Versions of packages unattended-upgrades suggests:
> ii  bsd-mailx  8.1.2-0.20141216cvs-2
> ii  exim4-daemon-light [mail-transport-agent]  4.84.2-2+deb8u5
>
> -- debconf-show failed
>

Bug#914957: [Pkg-shadow-devel] Bug#914957: login: removal of pts/* from /etc/securetty wasn't applied in stretch

[Bálint Réczey]

Hi Michael,

Michael Biebl  ezt írta (időpont: 2018. dec. 9., V, 0:37):
>
> On Sat, 8 Dec 2018 21:57:11 +0100 =?UTF-8?B?QsOhbGludCBSw6ljemV5?=
>  wrote:
> > While I believe securetty should be disabled by default
>
> Fwiw, I agree that securetty is a bad idea and should be removed from
> the default pam configuration.
> There is a login-standing bug report, documenting that securetty breaks
> "machinectl login" [1] fwiw.
>
> Can we please revisit this and drop securetty from /etc/pam.d/login for
> buster?

Unfortunately this missed Buster, but it is at least done for Bullseye
and later.

Cheers,
Balint

>
> Regards,
> Michael
>
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771675#20
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>

Bug#948876: kodi: FTBFS: something segfaults

[Bálint Réczey]

Control: reassign -1 fontforge 1:20190801~dfsg-2
Control: affects -1 kodi

Hi Mattia,

Mattia Rizzolo  ezt írta (időpont: 2020. jan. 14., K, 12:29):
>
> Source: kodi
> Version: 2:17.6+dfsg1-4
> Severity: serious
> Tags: ftbfs
>
> Dear maintainer,
> your package failed to rebuild in a standard sid chroot.
> If this is caused by a dependency, please reassign and sent an
> approriate "affects".
>
>debian/rules override_dh_auto_configure
> make[1]: Entering directory '/build/1st/kodi-17.6+dfsg1'
> cp -r /build/1st/kodi-17.6+dfsg1/webinterface-default 
> /build/1st/kodi-17.6+dfsg1/addons/webinterface.default
> sed -i 's/DEB_VERSION/"'2:17.6+dfsg1-4'"/' xbmc/Application.cpp 
> xbmc/utils/SystemInfo.cpp
> fontforge -script /build/1st/kodi-17.6+dfsg1/debian/mergefonts.ff \
> /usr/share/fonts/truetype/droid/DroidSansFallbackFull.ttf \
> /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf \
> /build/1st/kodi-17.6+dfsg1/media/Fonts/arial.ttf
> Copyright (c) 2000-2019. See AUTHORS for Contributors.
>  License GPLv3+: GNU GPL version 3 or later 
>  with many parts BSD . Please read LICENSE.
>  Version: 20190801
>  Based on sources from 12:20 UTC 13-Nov-2019-ML-D-GDK3.
> Cannot find your hotkey definition file!
> This font contains both a 'kern' table and a 'GPOS' table.
>   The 'kern' table will only be read if there is no 'kern' feature in 'GPOS'.
> Use-my-metrics flag set on at least two components in glyph 685
> The glyph named Omega is mapped to U+03A9.
>   But its name indicates it should be mapped to U+2126.
> Attempt to output 233084170 into a 16-bit field. It will be truncated and the 
> file may not be useful.make[1]: *** [debian/rules:112: 
> override_dh_auto_configure] Segmentation fault
> make[1]: Leaving directory '/build/1st/kodi-17.6+dfsg1'
> make: *** [debian/rules:87: build] Error 2
> dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Thanks, this is a bug in fontforge.

Cheers,
Balint

Bug#918746: pam-ssh-agent-auth alternative

[Bálint Réczey]

Hi,

Benda Xu  ezt írta (időpont: 2019. jan. 26., Szo, 4:45):
>
> Hi Moritz,
>
> That needs to be seriously considered.  I am using this package
> extensively.  Do you any alternatives to it?

I picked the patch used in Gentoo and FreeBSD to make the package
build again, but it does not resurrect upstream.

I'd say with this change there is no immediate need for removal, but I
removed myself from uploaders since I did not have enough time to take
care of the package properly and let the final word on removal for the
Security Team.

Cheers,
Balint

>
> Yours,
> Benda
>

Bug#905877: regression in 1.4: upgrades random packages from testing to experimental (doesn't respect pinning?)

[Bálint Réczey]

Control: tags -1 confirmed

Hi Paul,

Paul Wise  ezt írta (időpont: 2019. febr. 1., P, 18:39):
>
> Control: found -1 unattended-upgrades/1.10
>
> On Sat, 05 Jan 2019 11:24:42 +0800 Paul Wise wrote:
>
> > I thought this had been fixed but recently I got git upgraded to
> > experimental for some reason. I've included the full debug log below.
>
> This happened again with 1.10. I can add the log if needed. I've no
> idea what is special about git that it keeps getting upgraded.

Full support for pinning needs apt adding support for the "never" pinning:
https://salsa.debian.org/apt-team/apt/merge_requests/40

I'm also working on u-u's side that can land after APT's:
https://github.com/rbalint/unattended-upgrades/tree/apply-pinning

For the meantime I suggest excluding experimental from the allowed
origins overriding the default configuration in a separate file.

Cheers,
Balint

>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>

Bug#906083: nosexcover: Python2 removal in sid/bullseye, python3-nosexcover shouldn't depend on python-nose and python-coverage

[Bálint Réczey]

Control: tags -1 pending

Hi,

I have uploaded the attached fix to DELAYED/5.

Cheers,
Balint
diff -Nru nosexcover-1.0.11/debian/changelog nosexcover-1.0.11/debian/changelog
--- nosexcover-1.0.11/debian/changelog	2018-05-02 09:21:57.0 +0200
+++ nosexcover-1.0.11/debian/changelog	2019-11-10 18:07:13.0 +0100
@@ -1,3 +1,11 @@
+nosexcover (1.0.11-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop Python 2 dependencies, build-dependencies and binary package
+(Closes: #937159, #906083)
+
+ -- Balint Reczey   Sun, 10 Nov 2019 18:07:13 +0100
+
 nosexcover (1.0.11-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru nosexcover-1.0.11/debian/control nosexcover-1.0.11/debian/control
--- nosexcover-1.0.11/debian/control	2018-05-02 09:21:57.0 +0200
+++ nosexcover-1.0.11/debian/control	2019-11-10 18:07:13.0 +0100
@@ -4,32 +4,16 @@
 Maintainer: Guido Günther 
 Build-Depends: debhelper (>= 10.0.0~),
  dh-python,
- python-all,
- python3,
- python-nose,
+ python3-all,
  python3-nose,
- python-setuptools,
  python3-setuptools,
 Standards-Version: 4.1.1
 Homepage: http://pypi.python.org/pypi/nosexcover
 
-Package: python-nosexcover
-Architecture: all
-Depends: ${misc:Depends},
- ${python:Depends}, python-nose, python-coverage (>= 3.4)
-Description: Add Cobertura-style XML coverage report to nose (Python2 version)
- A companion to the built-in nose.plugins.cover, this plugin will write
- out an XML coverage report to a file named coverage.xml.
- .
- It will honor all the options you pass to the Nose coverage plugin,
- especially --cover-package.
- .
- This package contains the Python 2 version of the module.
-
 Package: python3-nosexcover
 Architecture: all
 Depends: ${misc:Depends},
- ${python3:Depends}, python-nose, python-coverage (>= 3.4)
+ ${python3:Depends}, python3-nose, python3-coverage (>= 3.4)
 Description: Add Cobertura-style XML coverage report to nose (Python3 version)
  A companion to the built-in nose.plugins.cover, this plugin will write
  out an XML coverage report to a file named coverage.xml.
diff -Nru nosexcover-1.0.11/debian/python3-nosexcover.install nosexcover-1.0.11/debian/python3-nosexcover.install
--- nosexcover-1.0.11/debian/python3-nosexcover.install	2015-02-19 13:02:36.0 +0100
+++ nosexcover-1.0.11/debian/python3-nosexcover.install	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-usr/lib/python3.?
diff -Nru nosexcover-1.0.11/debian/python-nosexcover.install nosexcover-1.0.11/debian/python-nosexcover.install
--- nosexcover-1.0.11/debian/python-nosexcover.install	2015-02-19 13:02:32.0 +0100
+++ nosexcover-1.0.11/debian/python-nosexcover.install	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-usr/lib/python2.?
diff -Nru nosexcover-1.0.11/debian/rules nosexcover-1.0.11/debian/rules
--- nosexcover-1.0.11/debian/rules	2015-02-19 13:37:49.0 +0100
+++ nosexcover-1.0.11/debian/rules	2019-11-10 18:07:13.0 +0100
@@ -1,4 +1,4 @@
 #!/usr/bin/make -f
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild

Bug#905877: regression in 1.4: upgrades random packages from testing to experimental (doesn't respect pinning?)

[Bálint Réczey]

Control: tags -1 confirmed

Hi Paul,

Paul Wise  ezt írta (időpont: 2018. aug. 11., Szo, 4:45):
>
> Package: unattended-upgrades
> Version: 1.4
> Severity: serious
>
> Recently I have had unattended-upgrades upgrade random packages from
> testing to experimental. If I downgrade the packages upgraded, I won't
> get the same packages upgraded the next day. I run apt-show-versions
> daily and save the output to my mail store. Using my mail store I found
> that the first instance of this happening was on 2018-07-06, there were
> earlier instances but they were from me manually installing packages
> from experimental and u-u doing subsequent upgrades. I noticed that I
> upgraded unattended-upgrades on that date from 1.3 to 1.4. I'm not
> sure, but the changelog indicates some package candidate changes,
> perhaps this caused the issue? I think this bug should be fixed before>
> Debian releases buster, this could break some setups.

Unattended-upgrades respect pinning to a very little extent and when I
started adding support it turned out that python-apt had less than
sufficient support for pinning to fix u-u.
Julian kindly fixed [1] python-apt quickly in git , and u-u needs this fix
in the archive before it can grow pinning support
(and make the current support work).

I proposed [2] a candidate adjustment fix which includes picking only
lower versions of packages originally offered by apt's resolver which
I believe would help in not upgrading packages to experimental.

Since pinning support in u-u never worked IMO the proper severity
would be 'important' rather than serious but I'd like to get this
fixed for Buster, too.

Cheers,
Balint

[1] 
https://salsa.debian.org/apt-team/python-apt/commit/75272eeffc04d4a7345e0c1095157e9d552ada1d
[2] 
https://github.com/mvo5/unattended-upgrades/pull/137/commits/cf074c0cca1e6e9a01c7a881d362c3def85542d8

Bug#904775: [Pkg-shadow-devel] Bug#904775: Broken dependencies

[Bálint Réczey]

Hi Sven,

2018-07-28 12:36 GMT+08:00 Sven Joachim :
> On 2018-07-27 21:36 +0200, Alf Gaida wrote:
>
>> Package: login
>> Version: 1:4.5-1
>> Severity: grave
>>
>> Dear Maintainer,
>> please don't break util-linux that is not even released. At least _one_ 
>> valid util-linux
>> should be available.
>
> Why was util-linux 2.32-0.2 not uploaded along shadow 1:4.5-1.1 to avoid
> this breakage?

There were issues with the util-linux upload but now it is building on
the buildds and should fix the breakage soon. I keep the RC bug open
till we are confident that everything went fine.

Sorry for the temporary inconvenience.

Cheers,
Balint

Bug#888383: kodi: FTBFS with FFmpeg 3.5

[Bálint Réczey]

Control: tags -1 confirmed

Hi James,

2018-01-25 6:26 GMT+08:00  :
> Source: kodi
> Version: 2:17.6+dfsg1-1
> Severity: important
> User: debian-multime...@lists.debian.org
> Usertags: ffmpeg-3.5-transition
>
> Hi,
>
> Your package FTBFS with the upcoming version 3.5 of FFmpeg. In FFmpeg 3.5,
> there are a number of API changes which will cause many packages to FTBFS.
> For this reason I have uploaded an early development snapshot to experimental
> before the 3.5 release in an attempt to fix some of these a bit quicker.
> While 3.5 has not been finalized and the ABI is not stable yet, there should
> not be any significant API breakages before the release.
>
> Incomplete list of changes (based on looking at common build failures):
> - Some fields in AVCodecContext have been removed and replaced with private
>   options which can be set using the av_opt_set* APIs
> - Most CODEC_* constants have been renamed to AV_CODEC_*
> - The buffer constants FF_INPUT_BUFFER_PADDING_SIZE and FF_MIN_BUFFER_SIZE
>   have been renamed to AV_INPUT_BUFFER_PADDING_SIZE and
>   AV_INPUT_BUFFER_MIN_SIZE.
> - The old resampling API provided by libavcodec has been removed. Use
>   libswresample instead.
> - The libavfilter/avfiltergraph.h header has been removed, include
>   libavfilter/avfilter.h instead.
> - The AVFrac structure (representing mixed rational numbers) has been
>   removed.

Thank you for the bug report. I'm fixing it by switching to new uptream.

Cheers,
Balint

Bug#853485: closed by Balint Reczey (Bug#853485: fixed in libcec 4.0.2+dfsg1-1)

[Bálint Réczey]

Hi Mattia,

2017-11-13 18:42 GMT+01:00 Mattia Rizzolo :
> On Tue, Sep 05, 2017 at 10:09:03PM +, Debian Bug Tracking System wrote:
>> This is an automatic notification regarding your Bug report
>> which was filed against the src:libcec package:
>>
>> #853485: libcec: ftbfs with GCC-7
>>
>> It has been closed by Balint Reczey .
>
> Hi,
>
> is there any reason to keep this in experimental, or can it be moved to
> unstable as well?

I kept it in experimental while kodi (reverse dependency) was FTBFS,
but now it can be uploaded to unstable.
I already prepared the update and I'm also in the process of updating kodi.

Cheers,
Balint

Bug#1020168: ecb: FTBFS: make[2]: *** [Makefile:86: ecb] Error 255

[Bálint Réczey]

Bálint Réczey  ezt írta (időpont: 2022. okt.
24., H, 23:21):
>
> Control: tags -1 confirmed help
>
> Lucas Nussbaum  ezt írta (időpont: 2022. szept. 18., V, 
> 9:00):
> >
> > Source: ecb
> > Version: 2.50+git20170628-1
> > Severity: serious
> > Justification: FTBFS
> > Tags: bookworm sid ftbfs
> > User: lu...@debian.org
> > Usertags: ftbfs-20220917 ftbfs-bookworm
> >
> > Hi,
> >
> > During a rebuild of all packages in sid, your package failed to build
> > on amd64.
> >
> >
> > Relevant part (hopefully):
> > > make[2]: Entering directory '/<>'
> > > Makefile:44: Makefile.conf not found. Using defaults for Linux!
> > > Makefile:45: Create Makefile.conf from Makefile.conf.template to override 
> > > the defaults.
> > > Byte-compiling ECB with LOADPATH= ...
> > > emacs -batch -no-site-file -l ecb-compile-script --eval 
> > > '(ecb-byte-compile t)'
> > > Package cl is deprecated
> > > ecb-util.el: Warning: ‘typecase’ is an obsolete alias (as of 27.1); use 
> > > ‘cl-typecase’ instead.
> > > Compiler-macro error for cl-typep: (error "Unknown type 
> > > button-release-event")
> > > Compiler-macro error for cl-typep: (error "Unknown type 
> > > button-press-event")
> ...
> > > ecb-compilation.el: Warning: ‘return’ is an obsolete alias (as of 27.1); 
> > > use ‘cl-return’ instead.
> > > Debugger entered--Lisp error: (error "Cannot find suitable directory for 
> > > output in ‘nati...")
> > >   error("Cannot find suitable directory for output in `nati...")
>
> I think this is an result of native compilation behaviour change in
> emacs 28 as discussed in this thread for example:
> https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-01/msg00838.html
>
> There are other similar FTBFS bugs and emacs-buttercup has been fixed
> for example:
> https://salsa.debian.org/emacsen-team/emacs-buttercup/-/commit/a42603de8c739681d9ae2e660af637ffb583a67d
>
> I think the best course of action would be switching ecb to use
> dh_elpa, but I don't know when I can work on that, thus help is
> appreciated.

There are also changes needed to make ecb compatible with Emacs 29.x,
which haven't been accepted upstream, but can probably be
cherry-picked:
https://github.com/ecb-home/ecb/pull/43

Bug#949329: flatbuffers: Needs rebuild to migrate to testing

[Bálint Réczey]

Source: flatbuffers
Version: 1.11.0+dfsg1-1
Severity: serious

Hi,

The package needs a source-only upload to let it be rebuilt and only
then can it migrate to testing.
I've already added the fixes needed [1] for the rebuild to the
packaging repository on Salsa.

Cheers,
Balint

[1] https://salsa.debian.org/debian/flatbuffers/commits/debian/master

Bug#888383: kodi: FTBFS with FFmpeg 3.5

[Bálint Réczey]

Rémi DUCCESCHI  ezt írta (időpont: 2018.
nov. 14., Sze, 11:30):
>
> Hello,
>
> I recently did the following bug report on kodi-bin because of broken 
> dependencies: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912994
>
> I just saw that in Ubuntu, they are depending on libavcodec58 for their last 
> version of kodi-bin (see https://packages.ubuntu.com/fr/cosmic/kodi-bin). I 
> wonder how hard it would be to take the work they did?

Thanks, I'm taking a look because packaging next upstream release
takes more time then expected.

Cheers,
Balint

Bug#910874: unattended-upgrades removes packages even if

[Bálint Réczey]

forwarded -1 https://github.com/mvo5/unattended-upgrades/pull/156
tags -1 confirmed pending

Hi Jan,

Jan Kowalsky  ezt írta (időpont: 2018. okt.
12., P, 17:57):
>
> Package: unattended-upgrades
> Version: 0.93.1+nmu1
> Severity: serious
>
> Even if I have configured 'Remove-Unused-Dependencies "false";' in
> apt.conf.d/50unattended-upgrades:
>
>
> // Do automatic removal of new unused dependencies after the upgrade
> // (equivalent to apt-get autoremove)
> Unattended-Upgrade::Remove-Unused-Dependencies "false";
>
> it DOES remove packages (see below) as long as apt is configured as:

There are several issues relevant to this bug. First, this option is
misleading and this is fixed here:
https://github.com/mvo5/unattended-upgrades/commit/7f84b1b029e127595fdf3d6928ac2382b640f0ee#diff-4e9bf0f40e9f1a04bed3d01667f4d2f6

The one to be set to false is this one:
Unattended-Upgrade::Remove-New-Unused-Dependencies

Also u-u can incorrectly remove previously unused packages, too which
is being fixed here:
https://github.com/mvo5/unattended-upgrades/pull/156

I'm closing this bug with the PR because the log you attached seem to
contain removal of  packages unrelated to the ones upgraded.

>
> APT::AutoRemove::RecommendsImportant "false";
>
> In my understanding this shouldn't be the case.

Yes, with setting Unattended-Upgrade::Remove-New-Unused-Dependencies
u-u should not remove packages even with the above APT setting.

Thank you for reporting the bug.

Cheers,
Balint

>
> Here is the output of unattended-upgrade:
>
> unattended-upgrade -d -v --dry-run
> Initial blacklisted packages:
> Initial whitelisted packages:
> Starting unattended upgrades script
> Allowed origins are: ['o=Debian,n=stretch,l=Debian-Security',
> 'o=Debian,n=stretch,l=Debian-Security']
> Checking: icedove ([ origin:'Debian' label:'Debian-Security' site:'security.debian.org'
> isTrusted:True>,  origin:'Debian' label:'Debian-Security' site:'security.debian.org'
> isTrusted:True>])
> pkg 'enigmail' now marked delete
> sanity check failed
> Checking: icedove-l10n-de ([ origin:'Debian' label:'Debian-Security' site:'security.debian.org'
> isTrusted:True>,  origin:'Debian' label:'Debian-Security' site:'security.debian.org'
> isTrusted:True>])
> pkg 'enigmail' now marked delete
> sanity check failed
> Checking: iceowl-extension ([ origin:'Debian' label:'Debian-Security' site:'security.debian.org'
> isTrusted:True>,  origin:'Debian' label:'Debian-Security' site:'security.debian.org'
> isTrusted:True>])
> pkg 'enigmail' now marked delete
> sanity check failed
> Checking: libsnmp-base ([ origin:'Debian' label:'Debian-Security' site:'security.debian.org'
> isTrusted:True>,  origin:'Debian' label:'Debian-Security' site:'security.debian.org'
> isTrusted:True>])
> Checking: libsnmp30 ([ origin:'Debian' label:'Debian-Security' site:'security.debian.org'
> isTrusted:True>])
> Checking: lightning ([ origin:'Debian' label:'Debian-Security' site:'security.debian.org'
> isTrusted:True>,  origin:'Debian' label:'Debian-Security' site:'security.debian.org'
> isTrusted:True>])
> pkg 'enigmail' now marked delete
> sanity check failed
> Checking: thunderbird ([ origin:'Debian' label:'Debian-Security' site:'security.debian.org'
> isTrusted:True>])
> pkg 'enigmail' now marked delete
> sanity check failed
> Checking: thunderbird-l10n-de ([ archive:'stable' origin:'Debian' label:'Debian-Security'
> site:'security.debian.org' isTrusted:True>,  archive:'stable' origin:'Debian' label:'Debian-Security'
> site:'security.debian.org' isTrusted:True>])
> pkg 'enigmail' now marked delete
> sanity check failed
> pkgs that look like they should be upgraded: libsnmp-base
> libsnmp30
> Fetched 0 B in 0s (0 B/s)
>
>
> fetch.run() result: 0
>  FileSize: 1594854
> DestFile:'/var/cache/apt/archives/libsnmp-base_5.7.3+dfsg-1.7+deb9u1_all.deb'
> DescURI:
> 'http://security.debian.org/pool/updates/main/n/net-snmp/libsnmp-base_5.7.3+dfsg-1.7+deb9u1_all.deb'
> ID:0 ErrorText: ''>
> check_conffile_prompt('/var/cache/apt/archives/libsnmp-base_5.7.3+dfsg-1.7+deb9u1_all.deb')
> found pkg: libsnmp-base
> No conffiles in deb
> '/var/cache/apt/archives/libsnmp-base_5.7.3+dfsg-1.7+deb9u1_all.deb'
> (There is no member named 'conffiles')
>  FileSize: 2331604
> DestFile:'/var/cache/apt/archives/libsnmp30_5.7.3+dfsg-1.7+deb9u1_amd64.deb'
> DescURI:
> 'http://security.debian.org/pool/updates/main/n/net-snmp/libsnmp30_5.7.3+dfsg-1.7+deb9u1_amd64.deb'
> ID:0 ErrorText: ''>
> check_conffile_prompt('/var/cache/apt/archives/libsnmp30_5.7.3+dfsg-1.7+deb9u1_amd64.deb')
> found pkg: libsnmp30
> No conffiles in deb
> '/var/cache/apt/archives/libsnmp30_5.7.3+dfsg-1.7+deb9u1_amd64.deb'
> (There is no member named 'conffiles')
> blacklist: []
> whitelist: []
> Option --dry-run given, *not* performing real actions
> Packages that will be upgraded: libsnmp-base libsnmp30
> Writing dpkg log to
> '/var/log/unattended-upgrades/unattended-upgrades-dpkg.log'
> found partition of size 2 (['libsnmp-base', 'libsnmp30'])
> found lea

Bug#877146: [pkg-go] Bug#877146: update to runc (1.0.0~rc4) breaks docker

[Bálint Réczey]

Control: affects -1 docker.io

Hi,

2017-09-29 10:23 GMT-04:00 Chris Lamb :
> Hi,
>
>> update to runc (1.0.0~rc4) breaks docker
>
> I can confirm that downgrading to 1.0.0~rc2+git20170201.133.9df8b30-3
> "fixed" this for me.

Before uploading I asked around on IRC if anyone had problems with
uploading with 1.0.0~r4
but got no objection.

I agree with blocking migration to testing and I'm wondering if
docker.io packages could be updated quickly to either work with this
runc version or provide docker-runc since it needs a fork based on
older runc.
Which is the first docker.io version that works with runc 1.0.0 rc4? I
would like to add the proper Breaks:.

Opengcs requires runc 1.0.0~rc4 thus IMO following runc upstream in
the runc package would be better than freezing it in unstable much
longer.

I should have targeted experimental with runc 1.0.0~rc4 and I'm ready
to add epoch and revert to previous version in unstable if upgrading
docker.io takes too much time.

Cheers,
Balint

>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

Bug#877146: [pkg-go] Bug#877146: update to runc (1.0.0~rc4) breaks docker

[Bálint Réczey]

Hi Chris,

2017-09-29 10:52 GMT-04:00 Chris Lamb :
> Hi Bálint,
>
>> Which is the first docker.io version that works with runc 1.0.0 rc4? I
>> would like to add the proper Breaks:.
>
> With rc4? None that are in Debian AFAICT. Perhaps I'm misunderstanding.

Yes, there is none AFAIK.
I see activity in docker.io's packaging repository in the v17.05.0-ce.new
which may work with rc4 but according to the control file it does not.

How about I upload docker-runc with previous runc version shipping
docker-runc binary and make docker.io use it by removing this patch hunk?:

https://anonscm.debian.org/cgit/docker/docker.io.git/tree/debian/patches/remove-docker-prefix.patch#n9

This would bring us closer to upstream.

Cheers,
Balint

>
> (As in, I was seeing this bug with docker.io 1.13.1~ds1-2, currently in
> sid).
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-

Bug#877146: [pkg-go] Bug#877146: update to runc (1.0.0~rc4) breaks docker

[Bálint Réczey]

Control: block -1 by 877284

Hi,

2017-09-29 11:25 GMT-04:00 Bálint Réczey :
> Hi Chris,
>
> 2017-09-29 10:52 GMT-04:00 Chris Lamb :
>> Hi Bálint,
>>
>>> Which is the first docker.io version that works with runc 1.0.0 rc4? I
>>> would like to add the proper Breaks:.
>>
>> With rc4? None that are in Debian AFAICT. Perhaps I'm misunderstanding.
>
> Yes, there is none AFAIK.
> I see activity in docker.io's packaging repository in the v17.05.0-ce.new
> which may work with rc4 but according to the control file it does not.
>
> How about I upload docker-runc with previous runc version shipping
> docker-runc binary and make docker.io use it by removing this patch hunk?:

I have uploaded docker-runc to unstable (in NEW) for docker.io
containing previous runc version
with fixes to make it build.

Thanks,
Balint

>
> https://anonscm.debian.org/cgit/docker/docker.io.git/tree/debian/patches/remove-docker-prefix.patch#n9
>
> This would bring us closer to upstream.
>
> Cheers,
> Balint
>
>>
>> (As in, I was seeing this bug with docker.io 1.13.1~ds1-2, currently in
>> sid).
>>
>>
>> Regards,
>>
>> --
>>   ,''`.
>>  : :'  : Chris Lamb
>>  `. `'`  la...@debian.org / chris-lamb.co.uk
>>`-

Bug#877146: update to runc (1.0.0~rc4) breaks docker

[Bálint Réczey]

Hi Shengjing,

2017-09-30 2:34 GMT-04:00 Shengjing Zhu :
>>> I see activity in docker.io's packaging repository in the v17.05.0-ce.new
>>> which may work with rc4 but according to the control file it does not.
>>>
>>> How about I upload docker-runc with previous runc version shipping
>>> docker-runc binary and make docker.io use it by removing this patch hunk?:
>>
>> I have uploaded docker-runc to unstable (in NEW) for docker.io
>> containing previous runc version
>> with fixes to make it build.
>
> I really think uploading this is not a good approach.
> At least I find docker master branch is using a runc version newer
> than 1.0.0-rc4.
> Packaging the lasted docker release is hard, but eventually we will
> do. And the runc/docker-runc in Debian will become duplicated.
>
> CCing docker.io maintainers, so they will be aware of this.

I agree that this is not an ideal approach due to duplication of code but
I think this is still the best approach since it allows following runc upstream
in runc and freeze the version for docker the same way docker upstream does.

When docker.io starts supporting latest runc in a timely manner it can
switch back from docker-runc and docker-runc can be removed from
the archive.

Before uploading the package I discussed it with Tianon from the docker.io
maintainers and he agreed that this would be the way to go in Debian.

Tianon, could you please switch to docker-runc in docker.io?

I have the packaging commits in git for docker-runc but I did not want to
push it to the go packages' area so when I get approved to the Docker
Packaging Team I'll push the repo to their area and happily hand over
the package.

Cheers,
Balint

>
> --
> Best regards,
> Shengjing Zhu

Bug#877146: update to runc (1.0.0~rc4) breaks docker

[Bálint Réczey]

Control: clone -1 -2
Control: reassign -2 docker.io 1.13.1~ds1-2
Control: retitle -2 docker.io: Please switch to using docker-runc

Hi,

I'm fixing the original bug by adding Breaks: with current docker.io version
to runc, please switch to using docker-runc in docker.io.

Thanks,
Balint

2017-09-30 11:37 GMT-04:00 Bálint Réczey :
> Hi Shengjing,
>
> 2017-09-30 2:34 GMT-04:00 Shengjing Zhu :
>>>> I see activity in docker.io's packaging repository in the v17.05.0-ce.new
>>>> which may work with rc4 but according to the control file it does not.
>>>>
>>>> How about I upload docker-runc with previous runc version shipping
>>>> docker-runc binary and make docker.io use it by removing this patch hunk?:
>>>
>>> I have uploaded docker-runc to unstable (in NEW) for docker.io
>>> containing previous runc version
>>> with fixes to make it build.
>>
>> I really think uploading this is not a good approach.
>> At least I find docker master branch is using a runc version newer
>> than 1.0.0-rc4.
>> Packaging the lasted docker release is hard, but eventually we will
>> do. And the runc/docker-runc in Debian will become duplicated.
>>
>> CCing docker.io maintainers, so they will be aware of this.
>
> I agree that this is not an ideal approach due to duplication of code but
> I think this is still the best approach since it allows following runc 
> upstream
> in runc and freeze the version for docker the same way docker upstream does.
>
> When docker.io starts supporting latest runc in a timely manner it can
> switch back from docker-runc and docker-runc can be removed from
> the archive.
>
> Before uploading the package I discussed it with Tianon from the docker.io
> maintainers and he agreed that this would be the way to go in Debian.
>
> Tianon, could you please switch to docker-runc in docker.io?
>
> I have the packaging commits in git for docker-runc but I did not want to
> push it to the go packages' area so when I get approved to the Docker
> Packaging Team I'll push the repo to their area and happily hand over
> the package.
>
> Cheers,
> Balint
>
>>
>> --
>> Best regards,
>> Shengjing Zhu

Bug#877661: runc: Block migration to testing until docker.io moves to docker-runc

[Bálint Réczey]

Package: runc
Version: 1.0.0~rc4+dfsg1-1
Severity: critical
Control: block -1 by 877329


Hi,

Runc 1.0.0~rc4 breaks current docker.io (#877146) until docker.io
moves to docker-runc (#877329),
hence letting runc 1.0.0~rc4 to migrate to testing would be a bad idea.

After fixing #877329 this bug can be closed.

Cheers,
Balint

Bug#877146: update to runc (1.0.0~rc4) breaks docker

[Bálint Réczey]

Hi Tianon,

2017-10-02 20:19 GMT+02:00 Tianon Gravi :
> On 30 September 2017 at 08:37, Bálint Réczey  wrote:
>> Tianon, could you please switch to docker-runc in docker.io?
>>
>> I have the packaging commits in git for docker-runc but I did not want to
>> push it to the go packages' area so when I get approved to the Docker
>> Packaging Team I'll push the repo to their area and happily hand over
>> the package.
>
> Your team application should be approved for creating that
> "docker-runc" repo and pushing your sources.

I pushed the repo here: https://anonscm.debian.org/cgit/docker/docker-runc.git

>
> I went to go try to update "src:docker.io", but I'm having trouble
> pulling in the "golang-github-opencontainers-docker-runc-dev"
> dependency (which is oddly named, but past the FTP team so I guess not
> a big deal).  I believe it needs to both "Provides:" and "Conflicts:"
> of "golang-github-opencontainers-runc-dev" for the sake of
> "golang-github-docker-containerd-dev" (which is very much
> intertwined).
>
> We might end up needing to _also_ create a "docker-containerd" package
> to get out of this, which would indirectly unblock
> https://github.com/containerd/containerd/issues/1508 (updating
> "containerd" to 1.x, which Docker doesn't support yet).

I think it would be cleaner to go without the Provides: and adding
docker-containerd build-depending on
golang-github-opencontainers-docker-runc-dev, but feel free to go either way.

I think the most efficient way forward would be if you could adopt the
docker-runc
package for the Docker Team and updating it as you please without
waiting for me -
and I'm perfectly OK with that.

Cheers,
Balint


>
> I'll push up my WIP changes now.
>
>
> ♥,
> - Tianon
>   4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#1072821: wireshark: binNMUs revert t64 transition

[Bálint Réczey]

Hi Jeremy,

I've just added sid and oracular. I can't recall any upload targeting
devel in Ubuntu, but it may work, thus I can add that as well.
I expect the next upstream SO version bump to take place this
summer/autumn, thus the code is expected to be short-lived.
Is there any better example of generating a t64 transitioned control
file for one set of releases and a not transitioned one for backports?

Thanks,
Balint

Jeremy Bícha  ezt írta (időpont: 2024.
jún. 9., V, 14:54):
>
> That debian/rules code seems fragile. Beyond sid, it also doesn't
> recognize several other valid upload targets: experimental, oracular
> (for Ubuntu), devel (for Ubuntu), forky (not valid yet but it will be
> the release after trixie).
>
> Thank you,
> Jeremy Bícha

Bug#955135: TypeError: '<' not supported between instances of 'NotImplementedType' and 'int'

[Bálint Réczey]

Control: tags -1 moreinfo

Hi Gian Piero,

Could you please check the output of:

sudo unattended-upgrade --download-only --verbose -d
apt list --upgradable

And tell which package (version) triggers the error?

I tried reproducing it locally and I don't see it with the package set
installed on my sid system.

Cheers,
Balint

Gian Piero Carrubba  ezt írta (időpont: 2020. márc.
29., V, 10:45):
>
> Package: unattended-upgrades
> Version: 2.0
> Followup-For: Bug #955135
> Control: severity -1 grave
>
> Raising the severity as this bug prevents the installation of any
> upgraded package.
>

Bug#955726: kodi: fails to connect to DLNA server

[Bálint Réczey]

Control: severity -1 important
Control: forwarded -1 https://github.com/xbmc/xbmc/issues/16335

Hi Peter,

Peter  ezt írta (időpont: 2020. ápr. 4., Szo, 10:57):
>
> Package: kodi
> Version: 2:18.6+dfsg1-1
> Severity: grave
> Tags: upstream
> Justification: renders package unusable
>
> Dear Maintainer,
>
>* What led up to the situation?
> Updating Kodi to 18.6
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> Removing set up DLNA server and trying to connect again
>* What was the outcome of this action?
> DLNA server is not available
>* What outcome did you expect instead?
> Succesfull connection to DLNA server and playing video \ audio
>
> Note: this bug is reported upstream long time ago:
> https://github.com/xbmc/xbmc/issues/16335

Thanks for reporting the bug. I agree that this is an important use
case, but there are many other ways kodi can still be used thus I'm
downgrading the severity [1].

Thanks for finding the upstream bug report. I hope upstream finds a
solution that may be backportable to 18.x as well.

Cheers,
Balint

[1] https://www.debian.org/Bugs/Developer#severities

Bug#956339: unattended-upgrades: regression: packages with conffile prompts are no longer skipped, leading to upgrade failures

[Bálint Réczey]

Control: tags -1 moreinfo

Hi Paul,

Paul Wise  ezt írta (időpont: 2020. ápr. 10., P, 7:39):
>
> Package: unattended-upgrades
> Version: 2.1
> Severity: serious
>
> Today I noticed that packages with conffile prompts are no longer
> skipped, which can lead to upgrade failures because dpkg stdin is not
> connected to any terminal. I think this is a regression since the work
> to enable pinning to work with unattended-upgrades.
>
> Package installation log:
> Log started: 2020-04-10  13:09:11
> apt-listchanges: Reading changelogs...
> apt-listchanges: Mailing root: apt-listchanges: changelogs for chianamo
> apt-listchanges: Reading changelogs...
> Preparing to unpack .../sgml-base_1.30_all.deb ...
> Unpacking sgml-base (1.30) over (1.29.1) ...
> Setting up popularity-contest (1.70) ...
>
> Configuration file '/etc/cron.daily/popularity-contest'
>  ==> Modified (by you or by a script) since installation.
>  ==> Package distributor has shipped an updated version.
>What would you like to do about it ?  Your options are:
> Y or I  : install the package maintainer's version
> N or O  : keep your currently-installed version
>   D : show the differences between the versions
>   Z : start a shell to examine the situation
>  The default action is to keep your current version.
> *** popularity-contest (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing 
> package popularity-contest (--configure):
>  end of file on stdin at conffile prompt
> Errors were encountered while processing:
>  popularity-contest

Thanks for the bug report!
I may have already fixed the the issue with the fix for LP: #1871639.
Could you please monitor if the problem shows up with 2.2, too?

Thanks,
Balint

Bug#887690: unattended-upgrades: FTBFS and Debci failure after testpackage was removed from Ubuntu server

[Bálint Réczey]

Hi Simon,

2018-02-07 23:25 GMT+07:00 Simon McVittie :
> Control: tags -1 + patch fixed-upstream
>
> On Fri, 19 Jan 2018 at 06:36:43 +0200, Adrian Bunk wrote:
>> The URI 'http://archive.ubuntu.com/ubuntu/test-package_2.0_all.deb' failed 
>> to download, aborting
>> The URI 'http://archive.ubuntu.com/ubuntu/test-package_2.0_all.deb' failed 
>> to download, aborting
>
> I think this is caused by a behaviour change in apt (see #886803).
> unattended-upgrades' test suite doesn't intend to *actually* download
> a test package from Ubuntu, it just pretends to do so by pre-populating
> an apt cache; but the filenames used in the apt cache (when the Version
> is not consistent with the Filename) have changed, so the pre-prepared
> file in the cache isn't used and the test fails.
>
> The attached patch (from the unattended-upgrades git repository) seems
> to resolve this for me. It just makes the Filename and the Version
> consistent with each other so that the problem situation doesn't arise.
>
> unattended-upgrades maintainers: is there an ETA for a 0.99 or 0.98.1
> release with this patch, or does someone need to NMU it? This is
> considered release-critical due to the FTBFS.

I'm trying the fix #875383 and release all the queued fixes this week.

Cheers,
Balint

Bug#914957: [Pkg-shadow-devel] Bug#914957: login: removal of pts/* from /etc/securetty wasn't applied in stretch

[Bálint Réczey]

Control: block -1 by 877374

Hi,

Salvatore Bonaccorso  ezt írta (időpont: 2018. nov.
29., Cs, 6:11):
>
> Control: fixed -1 1:4.5-1
>
> Hi,
>
> [disclaimer: not the maintainer here]
>
> On Thu, Nov 29, 2018 at 02:15:18PM +1100, russm wrote:
> > Package: login
> > Version: 1:4.4-4.1
> > Severity: grave
> > Tags: security
> > Justification: user security hole
> >
> > The addition of pts/* to /etc/securetty was reverted in 1:4.5-1 but
> > *not* in packages installed to stretch. Please backport this fix to
> > 1:4.4-*
>
> The stretch update part of this is requested here:
> https://bugs.debian.org/877374

While I believe securetty should be disabled by default and nullok is
a bad practice I offered the backport in #877374 and this is the most
I can do as the maintainer.

Cheers,
Balint

Bug#936805: kodi: Python2 removal in sid/bullseye

[Bálint Réczey]

Control: tags -1 confirmed upstream

Hi,

Vasyl Gello  ezt írta (időpont: 2020. júl. 5., V, 18:42):
>
> Hi Nicholas!
>
> I joined Debian to package Kodi 19.0 and full archive of binary addons and I 
> already made a
> significant progress on the way:
>
> 1. The build dependencies for kodi not present in Debian at the moment of my 
> join included:
>
> - dav1d (accepted to unstable 2 days ago, maintained by Dylan Aissi),
> - libudfread (awaiting approval from FTP team, maintained by me),
> - shairplay (awaiting approval from FTP team, maintained by me)
>
> So far, after libudfread & shairplay are accepted into unstable, we'll have 
> all dependencies
> within Debian.
>
> 2. The build dependencies requiring additional work were fixed:
>
> - flatbuffers (1.11.0 fixed, waiting for upstream to tag 1.12.1 closing 
> GCC-10 build failures)
> - libcdio (libcdio++ / libiso9660++ added, waiting for Gabriel T. Gomez to 
> upload the package to unstable),
> - libsrt (patches proposed for review)
>
> 3. The unofficial binary repository targeting buster-backports/amd64 has been 
> published on
> https://basilgello.github.io/kodi-nightly-debian-repo containing no-change 
> rebuilds of kodi build
> dependencies, kodi itself and binary addons gradually added as prepared. The 
> accompanying
> source code is hosted on Salsa: https://salsa.debian.org/basilgello-guest
>
> 4. After Kodi upstream declares the EOL of 18.x "Leia" branch, the 
> repositories will be pushed to
> multimedia team's space and on release, the whole set will be uploaded to 
> unstable. Uploading to
> experimental was considered excessive by Balint Reczey as every build 
> occupies 4GB of Debian
> snapshot server space forever on.

Experimental will be used for staging the uploads when needed, just
not for frequent upstream git snapshots.

Cheers,
Balint

>
> On Sun, 5 Jul 2020 11:48:39 -0400 Nicholas D Steeves  
> wrote:
> > Hi,
> >
> > On Fri, Aug 30, 2019 at 07:22:18AM +, Matthias Klose wrote:
> > > Package: src:kodi
> > > Version: 2:17.6+dfsg1-4
> > > Severity: normal
> > > Tags: sid bullseye
> > > User: debian-pyt...@lists.debian.org
> > > Usertags: py2removal
> > >
> > > Python2 becomes end-of-live upstream, and Debian aims to remove
> > > Python2 from the distribution, as discussed in
> > > https://lists.debian.org/debian-python/2019/07/msg00080.html
> > >
> > > Your package either build-depends, depends on Python2, or uses Python2
> > > in the autopkg tests. Please stop using Python2, and fix this issue
> > > by one of the following actions.
> > >
> >
> > [snip]
> >
> > This bug will be solved when updating to Kodi ≥ 19, which prominently
> > declares it migrated to Python 3. Of course some plugins might not be
> > py3 ready, so it's probably time to stage the kodi-without-py2
> > packages in experimental and report bugs upstream.
> >
> > The Python Team is moving ahead with making at py2 dep RC for low
> > popcon leaf packages this week, and while there isn't a roadmap
> > (afaik), I suspect this bug will become serious this fall (2020).
> >
> > Thanks,
> > Nicholas
>
> --
> Vasyl Gello
> 
> Certified SolidWorks Expert
>
> Mob.:+380 (98) 465 66 77
>
> E-Mail: vasek.ge...@gmail.com
>
> Skype: vasek.gello
> 
> 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#1020168: ecb: FTBFS: make[2]: *** [Makefile:86: ecb] Error 255

[Bálint Réczey]

Control: tags -1 confirmed help

Lucas Nussbaum  ezt írta (időpont: 2022. szept. 18., V, 9:00):
>
> Source: ecb
> Version: 2.50+git20170628-1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220917 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
> > make[2]: Entering directory '/<>'
> > Makefile:44: Makefile.conf not found. Using defaults for Linux!
> > Makefile:45: Create Makefile.conf from Makefile.conf.template to override 
> > the defaults.
> > Byte-compiling ECB with LOADPATH= ...
> > emacs -batch -no-site-file -l ecb-compile-script --eval '(ecb-byte-compile 
> > t)'
> > Package cl is deprecated
> > ecb-util.el: Warning: ‘typecase’ is an obsolete alias (as of 27.1); use 
> > ‘cl-typecase’ instead.
> > Compiler-macro error for cl-typep: (error "Unknown type 
> > button-release-event")
> > Compiler-macro error for cl-typep: (error "Unknown type button-press-event")
...
> > ecb-compilation.el: Warning: ‘return’ is an obsolete alias (as of 27.1); 
> > use ‘cl-return’ instead.
> > Debugger entered--Lisp error: (error "Cannot find suitable directory for 
> > output in ‘nati...")
> >   error("Cannot find suitable directory for output in `nati...")

I think this is an result of native compilation behaviour change in
emacs 28 as discussed in this thread for example:
https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-01/msg00838.html

There are other similar FTBFS bugs and emacs-buttercup has been fixed
for example:
https://salsa.debian.org/emacsen-team/emacs-buttercup/-/commit/a42603de8c739681d9ae2e660af637ffb583a67d

I think the best course of action would be switching ecb to use
dh_elpa, but I don't know when I can work on that, thus help is
appreciated.

Thanks,
Balint

Bug#839686: forked-daapd: does not recreate stuff in /var/cache after deletion

[Bálint Réczey]

Hi Dominik,

2016-10-06 23:15 GMT+02:00 Dominik George :
> Hi,
>
>> IMO it is unreasonable to think that removing the whole
>> /var/cache/forked-daapd directory can be deleted and is expected to be
>> recreated because many services drop root privileges thus can't create
>> dirs in /var/cache:
>
>> In my interpretation of the FHS the _files_ can be removed and are
>> expected to be recreated, while _directory structures_ need to be kept
>> for applications to operate.
>
> I do not quite agree.
>
> The same would be true for /var/run, but there, the application or the
> init system is expected to create the relevant directories before
> dropping privileges.

/var/run is different, see very different wording in FHS.

http://www.pathname.com/fhs/2.2/fhs-5.13.html#FN37

5.13 /var/run : Run-time variable data

5.13.1 Purpose

This directory contains system information data describing the system
since it was booted. Files under this directory must be cleared
(removed or truncated as appropriate) at the beginning of the boot
process. Programs may have a subdirectory of /var/run; this is
encouraged for programs that use more than one run-time file.[footnote
37]

...

[37] /var/run should be unwritable for unprivileged users (root or
users running daemons); it is a major security problem if any user can
write in this directory. Process identifier (PID) files, which were
originally placed in /etc, must be placed in /var/run. The naming
convention for PID files is .pid. For example, the crond
PID file is named /var/run/crond.pid.

Cheers,
Balint

Bug#840573: unicon: DFSG-incompatible license

[Bálint Réczey]

Hi,

2016-10-13 11:58 GMT+02:00 Santiago Vila :
> On Wed, 12 Oct 2016, Joao Eriberto Mota Filho wrote:
>
>> Source: unicon
>> Severity: serious
>> Tags: upstream
>> Justification: Policy 2.2.1
>>
>> Dear Maintainer,
>>
>> The file unicon/ImmModules/cxterm/utils/HZtable.h has the following license:
>>
>> Copyright 1994,1995 by Yongguang Zhang.  All Rights Reserved
>>
>> Permission to retain, use, modify, copy, and distribute CXTERM 5.0
>> in source or binary and its documentation (hereafter, the Software)
>> for non-commercial purpose is hereby granted to you without a fee,
>> provided that this entire copyright and permission notice appear in
>> all such copies, that no charge be associated with such copies,
>> that distribution of derivative works (including value-added
>> distributions such as with additional input dictionaries or fonts)
>> include clarification that such added or derived parts are not from
>> the original Software, and that the names of the author(s) not be
>> used to endorse or promote such works.
>>
>> THE AUTHOR(S) DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING
>> ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL
>> THE AUTHOR(S) BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR
>> ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS,
>> WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
>> ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
>>
>> There is a restriction for commercial use.
>
> Probably not the intent (as this is an old license), but certainly
> it's the letter.
>
> BTW: There is a similar wording in the Perl license: "You may not
> charge a fee for this Package itself."
>
> This is an orphaned package (maintained by "Debian QA"). In case you
> use this package yourself, would you like to forward this bug upstream
> (just to see if author would be willing to change the license), or
> should we just move this to non-free?
>
> I'm Cc:ing Balint, who made the last QA upload (maybe he uses the
> package himself, I don't).

I don't use the package either.

I don't think moving it to non-free is a reasonable solution because this
license is incompatible with GPL thus unicon as a whole can't be licensed
under GPL thus it looks like it does not have a valid license.

One could argue that .h files can't be licensed, but HZutil.c also share the
same license.

One option would be asking the cxterm upstream to relicense the files under
GPL if it fails and the unicon package is not usable without those files then
it should probably be removed from the archive. :-(

Cheers,
Balint

Bug#841420: --enable-default-pie breaks kernel builds

[Bálint Réczey]

Control: tags -1 - patch

2016-10-20 18:48 GMT+02:00 Sven Joachim :
> On 2016-10-20 17:54 +0200, Bálint Réczey wrote:
>
>> Control: reassign -1 linux 4.7.8-1
>> Control: severity -1 serious
>> Control: tags -1 patch
>>
>> Hi David,
>>
>> 2016-10-20 14:02 GMT+02:00 David Weinehall :
>>> Package: gcc-6
>>> Severity: important
>>> Version: 6.2.0-7
>>>
>>> --enable-default-pie (first enabled in gcc-6 6.2.0-7) causes kernel
>>> builds to fail.  If the kernel is configured with the stack protector
>>> enabled it'll fail with a rather unhelpful error message claiming
>>> that the compiler doesn't support -fstack-protector,
>>> but the problem is in fact caused by:
>>>
>>> kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
>>>
>>> (The kernel is built with -mcmodel=kernel)
>>>
>>> I think it's fair to say that the kernel is kind of an important piece
>>> of software and that it's imperative that we don't break kernel builds...
>>
>> The kernel is very important indeed and it did break in our build test.
>> I'm sorry, somehow I missed filing bug for the linux package, just for
>> user-mode-linux.
>> The following patch fixes the FTBFS:
>>
>> --- linux-4.7.8/debian/rules.d/Makefile.inc
>> +++ linux-4.7.8/debian/rules.d/Makefile.inc
>> @@ -5,7 +5,8 @@
>>
>>  SHELL = /bin/sh -e
>>
>> -CC = $(CROSS_COMPILE)gcc
>> +CC = $(CROSS_COMPILE)gcc -no-pie
>> +LD = $(CROSS_COMPILE)ld -no-pie
>>  CXX = $(CROSS_COMPILE)g++
>>  CFLAGS := $(shell dpkg-buildflags --get CFLAGS) -Wall
>>  CPPFLAGS := $(shell dpkg-buildflags --get CPPFLAGS) \
>>
>> Maybe the ld part is obsolete, I have not checked that.
>
> That patch might work for the Debian package, but has anybody contacted
> the upstream kernel developers about that?  At least the 4.8.3 vanilla
> kernel fails in the same way, I haven't tested 4.9-rc1 yet.

Fixing it upstream would certainly be better. I also haven't booted
the built image,
thus please use this patch only as inspiration. :-)

Cheers,
Balint

>
> FWIW, this issue has been discussed in Ubuntu for six months(!), see
> https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/1574982.
>
> Cheers,
>Sven

Bug#574086: Backtrace

[Bálint Réczey]

Thanks,
The fix will be in the next upload.
Cheers,
Balint

2010/3/17 Hilko Bengen :
> After finally figuring out how to provide gdb with binaries that it can
> use (#574284), here's a backtrace.
>
...
> Going back:
>
> smi.c:289 is an access to a SmiHandle which is defined in smi.c:60:
>
> ,
> | Handle *SmiHandle = NULL;
> `
>
> This variable is still set to NULL when the function is called, so
> there's a likely cause for the segfault.
>
> So, that SmiHandle pointer must have been initialized before one may use
> the function.
>
> So, let's look for smiInit()... It should have been called in
> epan/oids.c:register_mibs() which is called by epan/oids.c:oids_init().
> oids_init() is called by epan/prefs.c:read_prefs() but only if
> prefs.load_smi_modules is set. In my case, oids_init() is not called.
>
> HTH,
> -Hilko
>
>
>



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

Bug#594178: clisp: SIGSEGV during install - probably fixed

[Bálint Réczey]

Hi,

Could the problem be that in the buggy cases the fas files had not
been rebuilt for the new clisp version?
It seems that clisp segfaults when loading
/var/cache/common-lisp-controller/0/clisp/common-lisp-controller/common-lisp-controller.fas

macg4:/home/rbalint# apt-get install clisp
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  cl-asdf common-lisp-controller libffcall1 libsigsegv0 realpath
Suggested packages:
  gdb clisp-doc clisp-dev slime
Recommended packages:
  sbcl lisp-compiler
The following NEW packages will be installed:
  cl-asdf clisp common-lisp-controller libffcall1 libsigsegv0 realpath
0 upgraded, 6 newly installed, 0 to remove and 0 not upgraded.
Need to get 5,371kB of archives.
After this operation, 14.0MB of additional disk space will be used.
Do you want to continue [Y/n]?
Get:1 http://ftp.hu.debian.org/debian/ squeeze/main libffcall1 powerpc
1.10+cvs20100619-2 [13.3kB]
Get:2 http://ftp.hu.debian.org/debian/ squeeze/main libsigsegv0
powerpc 2.5-3 [23.2kB]
Get:3 http://ftp.hu.debian.org/debian/ squeeze/main cl-asdf all
2:2.004-1 [503kB]
Get:4 http://ftp.hu.debian.org/debian/ squeeze/main realpath powerpc
1.15 [16.5kB]
Get:5 http://ftp.hu.debian.org/debian/ squeeze/main
common-lisp-controller all 7.4 [34.5kB]
Get:6 http://ftp.hu.debian.org/debian/ squeeze/main clisp powerpc
1:2.48-3 [4,781kB]
Fetched 5,371kB in 1min 25s (63.1kB/s)
Preconfiguring packages ...
Selecting previously deselected package libffcall1.
(Reading database ... 143130 files and directories currently installed.)
Unpacking libffcall1 (from .../libffcall1_1.10+cvs20100619-2_powerpc.deb) ...
Selecting previously deselected package libsigsegv0.
Unpacking libsigsegv0 (from .../libsigsegv0_2.5-3_powerpc.deb) ...
Selecting previously deselected package cl-asdf.
Unpacking cl-asdf (from .../cl-asdf_2%3a2.004-1_all.deb) ...
Selecting previously deselected package realpath.
Unpacking realpath (from .../realpath_1.15_powerpc.deb) ...
Selecting previously deselected package common-lisp-controller.
Unpacking common-lisp-controller (from
.../common-lisp-controller_7.4_all.deb) ...
Adding system user `cl-builder' (UID 111) ...
Adding new group `cl-builder' (GID 120) ...
Adding new user `cl-builder' (UID 111) with group `cl-builder' ...
Not creating home directory `/usr/share/common-lisp/'.
Selecting previously deselected package clisp.
Unpacking clisp (from .../clisp_1%3a2.48-3_powerpc.deb) ...
Processing triggers for install-info ...
Processing triggers for man-db ...
Setting up libffcall1 (1.10+cvs20100619-2) ...
Setting up libsigsegv0 (2.5-3) ...
Setting up realpath (1.15) ...
Setting up common-lisp-controller (7.4) ...
Reinstalling for clisp
Recompiling Common Lisp Controller for clisp
Installing clc...
;; Loading file /usr/lib/clisp-2.48/install-clc.lisp ...
;;  Loading file
/usr/share/common-lisp/source/common-lisp-controller/common-lisp-controller.lisp
...
;;  Loaded file
/usr/share/common-lisp/source/common-lisp-controller/common-lisp-controller.lisp
;;  Loading file
/var/cache/common-lisp-controller/0/clisp/common-lisp-controller/common-lisp-controller.fas
...
;;  Loaded file
/var/cache/common-lisp-controller/0/clisp/common-lisp-controller/common-lisp-controller.fas
;;  Loading file /var/cache/common-lisp-controller/0/clisp/cl-asdf/asdf.fas ...
WARNING: DEFGENERIC: redefining function SYSTEM-SOURCE-FILE in
 /var/cache/common-lisp-controller/0/clisp/cl-asdf/asdf.fas,
was defined in top-level
;;  Loaded file /var/cache/common-lisp-controller/0/clisp/cl-asdf/asdf.fas
;;  Loading file
/var/cache/common-lisp-controller/0/clisp/cl-asdf/wild-modules.fas ...
;;  Loaded file
/var/cache/common-lisp-controller/0/clisp/cl-asdf/wild-modules.fas
;;  Loading file
/var/cache/common-lisp-controller/0/clisp/common-lisp-controller/post-sysdef-install.fas
...
;;  Loaded file
/var/cache/common-lisp-controller/0/clisp/common-lisp-controller/post-sysdef-install.fas
;; Loaded file /usr/lib/clisp-2.48/install-clc.lisp
;; Wrote the memory image into /usr/lib/clisp-2.48/full/lispinit.mem
(3,375,308 bytes)
Bytes permanently allocated:108,736
Bytes currently in use:   3,259,760
Bytes available until next GC:  812,225
created /usr/lib/clisp-2.48/full/lispinit.mem as expected.
-rw-r--r-- 1 root root 3375308 Sep 13 22:47
/usr/lib/clisp-2.48/full/lispinit.mem

Done rebuilding
Setting up cl-asdf (2:2.004-1) ...
Reinstalling for clisp
Recompiling Common Lisp Controller for clisp
Installing clc...
;; Loading file /usr/lib/clisp-2.48/install-clc.lisp ...
;;  Loading file
/usr/share/common-lisp/source/common-lisp-controller/common-lisp-controller.lisp
...
;;  Loaded file
/usr/share/common-lisp/source/common-lisp-controller/common-lisp-controller.lisp
;;  Loading file
/var/cache/common-lisp-controller/0/clisp/common-lisp-controller/common-lisp-controller.fas
...
;;  Loaded file
/var/cache/common-lisp-controller/0/clisp/common-lisp-

Bug#592768: clisp: SIGSEGV during install

[Bálint Réczey]

Hi,

Could the problem be that in the buggy cases the fas files had not
been rebuilt for the new clisp version?
It seems that clisp segfaults when loading
/var/cache/common-lisp-controller/0/clisp/common-lisp-controller/common-lisp-controller.fas

macg4:/home/rbalint# apt-get install clisp
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
 cl-asdf common-lisp-controller libffcall1 libsigsegv0 realpath
Suggested packages:
 gdb clisp-doc clisp-dev slime
Recommended packages:
 sbcl lisp-compiler
The following NEW packages will be installed:
 cl-asdf clisp common-lisp-controller libffcall1 libsigsegv0 realpath
0 upgraded, 6 newly installed, 0 to remove and 0 not upgraded.
Need to get 5,371kB of archives.
After this operation, 14.0MB of additional disk space will be used.
Do you want to continue [Y/n]?
Get:1 http://ftp.hu.debian.org/debian/ squeeze/main libffcall1 powerpc
1.10+cvs20100619-2 [13.3kB]
Get:2 http://ftp.hu.debian.org/debian/ squeeze/main libsigsegv0
powerpc 2.5-3 [23.2kB]
Get:3 http://ftp.hu.debian.org/debian/ squeeze/main cl-asdf all
2:2.004-1 [503kB]
Get:4 http://ftp.hu.debian.org/debian/ squeeze/main realpath powerpc
1.15 [16.5kB]
Get:5 http://ftp.hu.debian.org/debian/ squeeze/main
common-lisp-controller all 7.4 [34.5kB]
Get:6 http://ftp.hu.debian.org/debian/ squeeze/main clisp powerpc
1:2.48-3 [4,781kB]
Fetched 5,371kB in 1min 25s (63.1kB/s)
Preconfiguring packages ...
Selecting previously deselected package libffcall1.
(Reading database ... 143130 files and directories currently installed.)
Unpacking libffcall1 (from .../libffcall1_1.10+cvs20100619-2_powerpc.deb) ...
Selecting previously deselected package libsigsegv0.
Unpacking libsigsegv0 (from .../libsigsegv0_2.5-3_powerpc.deb) ...
Selecting previously deselected package cl-asdf.
Unpacking cl-asdf (from .../cl-asdf_2%3a2.004-1_all.deb) ...
Selecting previously deselected package realpath.
Unpacking realpath (from .../realpath_1.15_powerpc.deb) ...
Selecting previously deselected package common-lisp-controller.
Unpacking common-lisp-controller (from
.../common-lisp-controller_7.4_all.deb) ...
Adding system user `cl-builder' (UID 111) ...
Adding new group `cl-builder' (GID 120) ...
Adding new user `cl-builder' (UID 111) with group `cl-builder' ...
Not creating home directory `/usr/share/common-lisp/'.
Selecting previously deselected package clisp.
Unpacking clisp (from .../clisp_1%3a2.48-3_powerpc.deb) ...
Processing triggers for install-info ...
Processing triggers for man-db ...
Setting up libffcall1 (1.10+cvs20100619-2) ...
Setting up libsigsegv0 (2.5-3) ...
Setting up realpath (1.15) ...
Setting up common-lisp-controller (7.4) ...
Reinstalling for clisp
Recompiling Common Lisp Controller for clisp
Installing clc...
;; Loading file /usr/lib/clisp-2.48/install-clc.lisp ...
;;  Loading file
/usr/share/common-lisp/source/common-lisp-controller/common-lisp-controller.lisp
...
;;  Loaded file
/usr/share/common-lisp/source/common-lisp-controller/common-lisp-controller.lisp
;;  Loading file
/var/cache/common-lisp-controller/0/clisp/common-lisp-controller/common-lisp-controller.fas
...
;;  Loaded file
/var/cache/common-lisp-controller/0/clisp/common-lisp-controller/common-lisp-controller.fas
;;  Loading file /var/cache/common-lisp-controller/0/clisp/cl-asdf/asdf.fas ...
WARNING: DEFGENERIC: redefining function SYSTEM-SOURCE-FILE in
/var/cache/common-lisp-controller/0/clisp/cl-asdf/asdf.fas,
was defined in top-level
;;  Loaded file /var/cache/common-lisp-controller/0/clisp/cl-asdf/asdf.fas
;;  Loading file
/var/cache/common-lisp-controller/0/clisp/cl-asdf/wild-modules.fas ...
;;  Loaded file
/var/cache/common-lisp-controller/0/clisp/cl-asdf/wild-modules.fas
;;  Loading file
/var/cache/common-lisp-controller/0/clisp/common-lisp-controller/post-sysdef-install.fas
...
;;  Loaded file
/var/cache/common-lisp-controller/0/clisp/common-lisp-controller/post-sysdef-install.fas
;; Loaded file /usr/lib/clisp-2.48/install-clc.lisp
;; Wrote the memory image into /usr/lib/clisp-2.48/full/lispinit.mem
(3,375,308 bytes)
Bytes permanently allocated:108,736
Bytes currently in use:   3,259,760
Bytes available until next GC:  812,225
created /usr/lib/clisp-2.48/full/lispinit.mem as expected.
-rw-r--r-- 1 root root 3375308 Sep 13 22:47
/usr/lib/clisp-2.48/full/lispinit.mem

Done rebuilding
Setting up cl-asdf (2:2.004-1) ...
Reinstalling for clisp
Recompiling Common Lisp Controller for clisp
Installing clc...
;; Loading file /usr/lib/clisp-2.48/install-clc.lisp ...
;;  Loading file
/usr/share/common-lisp/source/common-lisp-controller/common-lisp-controller.lisp
...
;;  Loaded file
/usr/share/common-lisp/source/common-lisp-controller/common-lisp-controller.lisp
;;  Loading file
/var/cache/common-lisp-controller/0/clisp/common-lisp-controller/common-lisp-controller.fas
...
;;  Loaded file
/var/cache/common-lisp-controller/0/clisp/common-lisp-contr

Bug#592768: Re: Bug#592768: complementary information

[Bálint Réczey]

Hi,

I tried to reproduce the problem on my G4 box with 32 bit powerpc
kernel, but clisp installed fine.
As I saw the segfault happened with 64 kernels only.
Did the install work with older (/newer) 64 bit kernels?
Does the install work with a 32 bit kernel on your machine?

Cheers,
Balint



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

Bug#763148: Prevent migration to jessie

[Bálint Réczey]

2015-04-29 9:44 GMT+02:00 Emilio Pozuelo Monfort :
> On 27/04/15 00:30, Andreas Cadhalpun wrote:
>> On 27.04.2015 00:01, Emilio Pozuelo Monfort wrote:
>>> On 26/04/15 19:06, Andreas Cadhalpun wrote:
 Dear release team,

 as you undoubtedly know: jessie has been released! \o/

 Thus this bug is now obsolete and I'm closing it.

 Please remove the testing migration block of ffmpeg.
>>>
>>> I don't think you understand the problem.
>>>
>>> Having both ffmpeg and libav in the same release is the problem.
>>
>> But having mysql-5.5 and mariadb-10.0 in jessie is apparently no
>> problem, despite previous claims. What's the difference?
>>
>>> So at this moment, that "block" hint is not going to be removed.
>>
>> When will it be removed, if not now?
>>
>> Previously Moritz Mühlenhoff wrote [1]:
>> "After the jessie release a decision between libav and ffmpeg will need
>> to be made. It certainly possible to have them co-exist for a year or
>> so, but the decision needs to be made before the jessie+1 freeze."
>>
>> How do you think this should go forward?
>
> You could ask the TC to decide between the two. As it happened with #717076 
> for
> example.
There is no need to ask TC (yet), it is blocked by Julien:
https://release.debian.org/britney/hints/jcristau

Dear Julien,

Could you please lift the unblock now since Jessie has been released
and we generally don't ban packages from entering testing based on
duplicate functionality?

Thanks,
Balint


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

Bug#763148: Prevent migration to jessie

[Bálint Réczey]

Dear Emilio,

2015-04-29 12:28 GMT+02:00 Emilio Pozuelo Monfort :
> On 29/04/15 10:41, Bálint Réczey wrote:
>> 2015-04-29 9:44 GMT+02:00 Emilio Pozuelo Monfort :
>>> On 27/04/15 00:30, Andreas Cadhalpun wrote:
>>>> On 27.04.2015 00:01, Emilio Pozuelo Monfort wrote:
>>>>> On 26/04/15 19:06, Andreas Cadhalpun wrote:
>>>>>> Dear release team,
>>>>>>
>>>>>> as you undoubtedly know: jessie has been released! \o/
>>>>>>
>>>>>> Thus this bug is now obsolete and I'm closing it.
>>>>>>
>>>>>> Please remove the testing migration block of ffmpeg.
>>>>>
>>>>> I don't think you understand the problem.
>>>>>
>>>>> Having both ffmpeg and libav in the same release is the problem.
>>>>
>>>> But having mysql-5.5 and mariadb-10.0 in jessie is apparently no
>>>> problem, despite previous claims. What's the difference?
>>>>
>>>>> So at this moment, that "block" hint is not going to be removed.
>>>>
>>>> When will it be removed, if not now?
>>>>
>>>> Previously Moritz Mühlenhoff wrote [1]:
>>>> "After the jessie release a decision between libav and ffmpeg will need
>>>> to be made. It certainly possible to have them co-exist for a year or
>>>> so, but the decision needs to be made before the jessie+1 freeze."
>>>>
>>>> How do you think this should go forward?
>>>
>>> You could ask the TC to decide between the two. As it happened with #717076 
>>> for
>>> example.
>> There is no need to ask TC (yet), it is blocked by Julien:
>> https://release.debian.org/britney/hints/jcristau
>>
>> Dear Julien,
>>
>> Could you please lift the unblock now since Jessie has been released
>> and we generally don't ban packages from entering testing based on
>> duplicate functionality?
>
> Sigh. This has been said multiple times, but I'll explain it again.
>
> We do block stuff based on security concerns.
I have just checked and you are not a member of the Security Team:
https://www.debian.org/intro/organization

The last word from the Security Team was Moritz's email which gave
ffmpeg green light after Jessie's release.

Please clarify if the opinion you shared here is your own private
opinion (as a DD) or the Release Team's official position.
Note that as a DD you can engage in discussions about ffmpeg but can't
keep the block alive.

>
> Since there are concerns on shipping both libav and ffmpeg, we won't allow
> ffmpeg unless it is chosen to be the default and there is a clear transition
> plan, so that we can switch from one to the other. Only then will the block 
> hint
> be removed.
There are no technical reasons for not having both in testing an I see
this the only fair solution. There are no name- nor symbol collision
between the packages. They co-exist perfectly on my systems, too.

>
> Hope that is clear.
Your opinion is clear but I think you having this opinion should not
be enough to prevent the migration to testing and it would save a lot
of unnecessary debate if you could just let it go and see what
happens.

Cheers,
Balint


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

Bug#763148: Prevent migration to jessie

[Bálint Réczey]

Hi Alessandro,

2015-04-29 14:58 GMT+02:00 Alessandro Ghedini :
> On mer, apr 29, 2015 at 02:29:43 +0200, Bálint Réczey wrote:
>> > Since there are concerns on shipping both libav and ffmpeg, we won't allow
>> > ffmpeg unless it is chosen to be the default and there is a clear 
>> > transition
>> > plan, so that we can switch from one to the other. Only then will the 
>> > block hint
>> > be removed.
>> There are no technical reasons for not having both in testing an I see
>> this the only fair solution. There are no name- nor symbol collision
>> between the packages. They co-exist perfectly on my systems, too.
>
> There is at least one reason that I can think of. Assuming the decision to 
> keep
> either libav or ffmpeg (not both) stands, if ffmpeg is allowed to migrate and
> other packages start depending on it, and if before the stretch release ffmpeg
> is deemed not release ready (e.g. if libav is chosen), then more work will be
> required to untangle the dependencies and have ffmpeg removed from testing.
We can start the migration one year before the freeze date if only one
of libav/ffmpeg is to be kept in Stretch.
IMO we can keep both. I watched FFmpeg closely and the are very fast
in fixing security issues and in general handling of bugs. OTOH I also
think Libav deserves to be in testing/stable if they can fix their
issues in a timely manner.
If we want to assess the effort of supporting both or either of them
we can count the number of hours spent supporting each on release
management/security support/reverse depenencies' maintainer work.
I spent way more than 80 hours on XBMC/Kodi because of the absence of
FFmpeg in Debian for example.

Cheers,
Balint


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

Bug#763148: Prevent migration to jessie

[Bálint Réczey]

2015-04-29 15:38 GMT+02:00 Emilio Pozuelo Monfort :
> On 29/04/15 14:29, Bálint Réczey wrote:
>> The last word from the Security Team was Moritz's email which gave
>> ffmpeg green light after Jessie's release.
>
> No. He said that a decision between libav and ffmpeg would still have to be
> made. IOW, we won't ship Stretch with both libav and ffmpeg.
He gave a green light to migration, it is very clear.
Please answer my question, I'm not sure who I am talking to:
>> Please clarify if the opinion you shared here is your own private
>> opinion (as a DD) or the Release Team's official position.
>> Note that as a DD you can engage in discussions about ffmpeg but can't
>> keep the block alive.

Balint


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

Bug#763148: Prevent migration to jessie

[Bálint Réczey]

2015-04-29 15:27 GMT+02:00 Alessio Treglia :
> On Wed, Apr 29, 2015 at 12:47 PM, Andreas Cadhalpun
>  wrote:
>> Therefore I'm planning to discuss a possible transition from
>> Libav to FFmpeg with the maintainers of the reverse dependencies,
>> before asking the TC for a resolution.
>
> What if one or more maintainers do not agree with you to make his
> packages break away from libav? What result are you aiming to achieve?
> Splitting multimedia packages up in two groups, each one depending on
> a different implementation of the same interfaces? And on the basis of
> what?
Libav and ffmpeg provide different interfaces and different
implementation in ffmpeg's current packaging solution.
Having packages depending on alternative implementations is business
as usual and upstreams have different preferences. Usually maintainers
are free to choose any other package as dependency whichever they find
the best fit for their package and IMO it is a good practice. This bug
is not about removing Libav this bug is about handling ffmpeg fairly
and letting it migrate to testing at least for a year.

>
> I feel that we'd better *first* decide on which one between ffmpeg and
> libav we want to keep, and drop the alternative.
I think you have the wrong feeling. Please consider the costs and
benefits instead of feelings. We can have both in even stable. The
cost of Libav + FFmpeg is slightly more than Libav only, while
upstreams and users are screaming for FFmpeg.

Cheers,
Balint


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

Bug#763148: Prevent migration to jessie

[Bálint Réczey]

Dear Moritz,

Could you please clarify Security Team's position? Do the Security
Team still want to keep ffmpeg out of testing?

Cheers,
Balint

2015-04-29 15:55 GMT+02:00 Alessio Treglia :
> On Wed, Apr 29, 2015 at 2:46 PM, Bálint Réczey  wrote:
>> He gave a green light to migration, it is very clear.
>
> If you're thinking of this [1] then yes, it's very clear that is *NOT*
> a green light at all.
>
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763148#134
>
> --
> Alessio Treglia  | www.alessiotreglia.com
> Debian Developer | ales...@debian.org
> Ubuntu Core Developer|  quadris...@ubuntu.com
> 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A
>


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

Bug#763148: Prevent migration to jessie

[Bálint Réczey]

2015-04-29 16:17 GMT+02:00 Bálint Réczey :
> 2015-04-29 16:08 GMT+02:00 Alessandro Ghedini :
>> On Wed, Apr 29, 2015 at 03:28:40PM +0200, Andreas Cadhalpun wrote:
>>> Hi Alessandro,
>>>
>>> On 29.04.2015 14:58, Alessandro Ghedini wrote:
>>> > On mer, apr 29, 2015 at 02:29:43 +0200, Bálint Réczey wrote:
>>> >>> Since there are concerns on shipping both libav and ffmpeg, we won't 
>>> >>> allow
>>> >>> ffmpeg unless it is chosen to be the default and there is a clear 
>>> >>> transition
>>> >>> plan, so that we can switch from one to the other. Only then will the 
>>> >>> block hint
>>> >>> be removed.
>>> >> There are no technical reasons for not having both in testing an I see
>>> >> this the only fair solution. There are no name- nor symbol collision
>>> >> between the packages. They co-exist perfectly on my systems, too.
>>> >
>>> > There is at least one reason that I can think of. Assuming the decision 
>>> > to keep
>>> > either libav or ffmpeg (not both) stands,
>>>
>>> Great to hear that this is only an assumption and no definitive statement!
>>>
>>> > if ffmpeg is allowed to migrate and
>>> > other packages start depending on it,
>>>
>>> Packages already depend on FFmpeg, simply because they don't work with 
>>> Libav:
>>
>> Yes, but they won't migrate to testing either.
>>
>>> > and if before the stretch release ffmpeg
>>> > is deemed not release ready (e.g. if libav is chosen), then more work 
>>> > will be
>>> > required to untangle the dependencies and have ffmpeg removed from 
>>> > testing.
>>>
>>> If a preliminary decision is made in e.g. one years time, maintainers would 
>>> have
>>> plenty of time to adapt.
>>
>> The decision has to be taken *now*, not in one year.
> Nope. It is just your opinion. IMO this decision is not needed at all.
Or if this is Security Team's official opinion then please signal that.

Cheers,
Balint


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

Bug#763148: Prevent migration to jessie

[Bálint Réczey]

2015-04-29 16:08 GMT+02:00 Alessandro Ghedini :
> On Wed, Apr 29, 2015 at 03:28:40PM +0200, Andreas Cadhalpun wrote:
>> Hi Alessandro,
>>
>> On 29.04.2015 14:58, Alessandro Ghedini wrote:
>> > On mer, apr 29, 2015 at 02:29:43 +0200, Bálint Réczey wrote:
>> >>> Since there are concerns on shipping both libav and ffmpeg, we won't 
>> >>> allow
>> >>> ffmpeg unless it is chosen to be the default and there is a clear 
>> >>> transition
>> >>> plan, so that we can switch from one to the other. Only then will the 
>> >>> block hint
>> >>> be removed.
>> >> There are no technical reasons for not having both in testing an I see
>> >> this the only fair solution. There are no name- nor symbol collision
>> >> between the packages. They co-exist perfectly on my systems, too.
>> >
>> > There is at least one reason that I can think of. Assuming the decision to 
>> > keep
>> > either libav or ffmpeg (not both) stands,
>>
>> Great to hear that this is only an assumption and no definitive statement!
>>
>> > if ffmpeg is allowed to migrate and
>> > other packages start depending on it,
>>
>> Packages already depend on FFmpeg, simply because they don't work with Libav:
>
> Yes, but they won't migrate to testing either.
>
>> > and if before the stretch release ffmpeg
>> > is deemed not release ready (e.g. if libav is chosen), then more work will 
>> > be
>> > required to untangle the dependencies and have ffmpeg removed from testing.
>>
>> If a preliminary decision is made in e.g. one years time, maintainers would 
>> have
>> plenty of time to adapt.
>
> The decision has to be taken *now*, not in one year.
Nope. It is just your opinion. IMO this decision is not needed at all.

>
> Last year, just before the freeze, we (the multimedia team) sort of held a 
> vote
> to decide this, but it went in favour of libav. IIRC the reason people voted 
> in
> favour of libav was that we were too close to the freeze to do anything.
>
> Now would be the time to start that discussion again. So, instead of wasting
> energies arguing against the migration block, I suggest you be the one to
> restart that discussion, given that you are the maintainer of ffmpeg.
Just lift the block and it will end the the argument.
Asking Multimedia Team is wrong way is making the call. It is
_pretending_ to be cooperative.
Why don't you ask KDE maintainers if they want to see GNOME in the archive?

Cheers,
Balint


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

Bug#763148: Prevent migration to jessie

[Bálint Réczey]

Hi Joerg,

2015-04-29 18:12 GMT+02:00 Joerg Jaspert :
> On 13926 March 1977, Bálint Réczey wrote:
>> 2015-04-29 15:38 GMT+02:00 Emilio Pozuelo Monfort :
>>> On 29/04/15 14:29, Bálint Réczey wrote:
>>>> The last word from the Security Team was Moritz's email which gave
>>>> ffmpeg green light after Jessie's release.
>>> No. He said that a decision between libav and ffmpeg would still have to be
>>> made. IOW, we won't ship Stretch with both libav and ffmpeg.
>> He gave a green light to migration, it is very clear.
>> Please answer my question, I'm not sure who I am talking to:
>>>> Please clarify if the opinion you shared here is your own private
>>>> opinion (as a DD) or the Release Team's official position.
>>>> Note that as a DD you can engage in discussions about ffmpeg but can't
>>>> keep the block alive.
>
> Reading this thread and how release team members get hit to allow one
> package into testing makes me want to use my ftpmaster hat to remove it
> entirely from Debian. Have you read their delegation? It's the release
Thank you for not removing the package just because there are too many
discussions involving it. I appreciate your patience while I don't
share your feelings.

> teams right to keep a package out of testing, even if you don't like
> them using that right.
> And that goes for every single member, so sod the "your own private
> opinion or teams position", as soon as someone tells you "no", then its
> a no.
>
> As usual with people using their delegated rights you have ways to go
> get to change that. Tons of repeating on a list thread/bug is not one of
> them. Especially not as you got told how it can get unblocked.
IMO mandating the choice between the two libraries lacks technical
merit and is not fair to one or the other package maintainer/upstream.
I understand that we have limited resources but if the teams would
quantify the amount of workforce needed to support both libraries
vulunteers may apply to help them out.

Thanks,
Balint


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

Bug#763148: Prevent migration to jessie

[Bálint Réczey]

Hi All,

2015-04-29 20:36 GMT+02:00 Alessio Treglia :
> Hi Moritz,
>
> On Wed, Apr 29, 2015 at 7:22 PM, Moritz Mühlenhoff  wrote:
>> Having both for a year along each other will only waste people's time. Now
>> at the beginning of the release cycle is the time to make a decision,
>> not by dragging things into a year as of today. Picking one of the two
>> won't be any simpler in 12 months.
>
> I couldn't agree more.
> I'm bringing this up to pkg-multimedia-maintainers's attention by
> moving this into a separate thread on our mailing list to reduce the
> noise here.
For the interested parties the thread starts here [1] and continues
here [2] in May.

At the moment we have 4 votes for having ffmpeg, one for having both
and zero having for libav in testing.

The votes were cast in four days starting with Alessio's email and
there were no new votes in the last five days.

Alessio also mentioned that he had an opinion five days ago, but has
not disclosed it yet [4].

Andreas Cadhalpun also provided a transition plan which would work nicely IMO.

Cheers,
Balint

[1] 
http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2015-April/043928.html
[2] 
http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2015-May/043979.html
[3] 
http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2015-May/043980.html
[4] 
http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2015-May/044089.html


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

Bug#785326: libavcodec56: CVE-2014-7937 - Multiple off-by-one errors in libavcodec/vorbisdec.c

[Bálint Réczey]

2015-05-16 15:31 GMT+02:00 Sebastian Ramacher :
> On 2015-05-16 15:28:44, Arne Wichmann wrote:
>> begin  quotation  from Sebastian Ramacher (in 
>> <20150516130757.ga21...@ramacher.at>):
>> > On 2015-05-15 15:22:28, Alessandro Ghedini wrote:
>> > > On Fri, May 15, 2015 at 11:05:17AM +0200, Sebastian Ramacher wrote:
>> > > > Version: 6:11.3-1
>> > > >
>> > > > On 2015-05-14 20:41:15, Arne Wichmann wrote:
>> > > > > Package: libavcodec56
>> > > > > Version: 6:11.3-2
>> > > > > Severity: grave
>> > > > > Tags: security
>> > > > > Justification: user security hole
>> > > > >
>> > > > > Hi, as far as I can see this has not yet been reported or fixed:
>> > > > >
>> > > > > CVE-2014-7937 : Multiple off-by-one errors in libavcodec/vorbisdec.c 
>> > > > > in
>> > > > > FFmpeg before 2.4.2, as used in Google Chrome before 40.0.2214.91, 
>> > > > > allow
>> > > > > remote attackers to cause a denial of service (use-after-free) or 
>> > > > > possibly
>> > > > > have unspecified other impact via crafted Vorbis I data [1]
>> > > > >
>> > > > > I marked this as grave as the impact is unclear and might include 
>> > > > > arbitrary
>> > > > > code execution. Feel free do downgrade if this can be ruled out.
>> > > > >
>> > > > > (Actually I would like to have a look at the test case to check a 
>> > > > > bit more
>> > > > > thoroughly, but AFAICS I would need to talk to google for this.)
>> > > > >
>> > > > > [1] https://security-tracker.debian.org/tracker/CVE-2014-7937
>> > > > >   
>> > > > > https://lists.libav.org/pipermail/libav-devel/2015-January/066433.html
>> > > >
>> > > > A similar commit to the one maintained in this mailing list post was 
>> > > > applied to
>> > > > 11.3. So closing with that version.
>> > >
>> > > Do you mean the patch at [0]? Honestly it doesn't look like the ffmpeg 
>> > > patch at
>> > > all, and the commit message doesn't even mention the bug fix. How can 
>> > > you be so
>> > > sure that the bug is fixed?
>> >
>> > I might have read the commit wrong. Do you have a sample for this CVE?
>>
>> There is one referenced in various messages relating to CVE-2014-7937:
>> asan_heap-uaf_18dac2b_9_asan_heap-uaf_22eb375_208_beta3_test_small.ogg
>> unfortunately it is not publicly available AFAICS. You might ask upstream
>> about it.
>
> I did. libav developers do not seem to have it. So please provide a sample.
Why don't you/they ask FFmpeg upstream directly?

Cheers,
Balint


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

Bug#787018: src:xbmc: xbmc does not build on unstable

[Bálint Réczey]

Control: tags -1 wontfix

Hi Loong Jin,

2015-05-27 22:06 GMT+02:00 Chow Loong Jin :
> Package: src:xbmc
> Version: FTBFS on unstable (libcec changes?)
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
>
> Dear Maintainer,
>
> sbuild does not manage to rebuild xbmc in unstable. Attached is the build log.
>
> Specifically, here's the error:
>
> PeripheralCecAdapter.cpp: In member function 'void 
> PERIPHERALS::CPeripheralCecAdapter::SetConfigurationFromSettings()':
> PeripheralCecAdapter.cpp:1347:19: error: 'CEC::libcec_configuration' has no
> member named 'iDoubleTapTimeoutMs'
>m_configuration.iDoubleTapTimeoutMs = 
> GetSettingInt("double_tap_timeout_ms");
>^
>
> I believe that changes in libcec-dev have resulted in this FTBFS.
XBMC has been renamed to Kodi and I have already packaged it. It is
waiting for FTP Master approval in the NEW queue for some time.
I don't plan updating xbmc, just once, with an empty content to get
rid of the epoch while transitioning to kodi.

Cheers,
Balint


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

Bug#768751: ecb: FTBFS in jessie

[Bálint Réczey]

Control: tags -1 confirmed

Hi Lucas,

2014-11-09 8:31 GMT+01:00 Lucas Nussbaum :
> Source: ecb
> Version: 2.40+git20140216-1
> Severity: serious
> Tags: jessie sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20141108 qa-ftbfs
> Justification: FTBFS in jessie on amd64
>
> Hi,
>
> During a rebuild of all packages in jessie (in a jessie chroot, not a
> sid chroot), your package failed to build on amd64.
>
> Relevant part (hopefully):
>> make[2]: Entering directory '/ĢBUILDDIRģ/ecb-2.40+git20140216'
>> Makefile:38: Makefile.conf not found. Using defaults for Linux!
>> Makefile:39: Create Makefile.conf from Makefile.conf.template to override 
>> the defaults.
>> Byte-compiling ECB with LOADPATH= ...
>> emacs -batch -no-site-file -l ecb-compile-script --eval '(ecb-byte-compile 
>> t)'
>> ECB 2.40 uses CEDET 2.0 (contains semantic 2.2, eieio 1.4, speedbar 1.0).
>> All requirements for ECB 2.40 fulfilled - Enjoy it!
>> Wrote /ĢBUILDDIRģ/ecb-2.40+git20140216/ecb-advice-test.elc
>> Wrote /ĢBUILDDIRģ/ecb-2.40+git20140216/ecb-analyse.elc
>> Wrote /ĢBUILDDIRģ/ecb-2.40+git20140216/ecb-autogen.elc
>> Wrote /ĢBUILDDIRģ/ecb-2.40+git20140216/ecb-buffertab.elc
>> Wrote /ĢBUILDDIRģ/ecb-2.40+git20140216/ecb-cedet-wrapper.elc
>> Wrote /ĢBUILDDIRģ/ecb-2.40+git20140216/ecb-common-browser.elc
>> Wrote /ĢBUILDDIRģ/ecb-2.40+git20140216/ecb-compatibility.elc
>> Wrote /ĢBUILDDIRģ/ecb-2.40+git20140216/ecb-compilation.elc
>> Wrote /ĢBUILDDIRģ/ecb-2.40+git20140216/ecb-create-layout.elc
>> Wrote /ĢBUILDDIRģ/ecb-2.40+git20140216/ecb-cycle.elc
>> Wrote /ĢBUILDDIRģ/ecb-2.40+git20140216/ecb-eshell.elc
>> Wrote /ĢBUILDDIRģ/ecb-2.40+git20140216/ecb-examples.elc
>> Wrote /ĢBUILDDIRģ/ecb-2.40+git20140216/ecb-face.elc
>> Wrote /ĢBUILDDIRģ/ecb-2.40+git20140216/ecb-file-browser.elc
>> Wrote /ĢBUILDDIRģ/ecb-2.40+git20140216/ecb-help.elc
>> Wrote /ĢBUILDDIRģ/ecb-2.40+git20140216/ecb-jde.elc
>> Wrote /ĢBUILDDIRģ/ecb-2.40+git20140216/ecb-layout-defs.elc
>>
>> In ecb-display-buffer-xemacs:
>> ecb-layout.el:1997:38:Warning: `display-buffer-function' is an obsolete
>> variable (as of 24.3); use `display-buffer-alist' instead.
>> ecb-layout.el:2002:37:Warning: `display-buffer-function' is an obsolete
>> variable (as of 24.3); use `display-buffer-alist' instead.
>> ecb-layout.el:2235:40:Warning: `display-buffer-function' is an obsolete
>> variable (as of 24.3); use `display-buffer-alist' instead.
>> ecb-layout.el:2094:46:Warning: `special-display-function' is an obsolete
>> variable (as of 24.3); use `display-buffer-alist' instead.
>> ecb-layout.el:2097:38:Warning: `special-display-buffer-names' is an obsolete
>> variable (as of 24.3); use `display-buffer-alist' instead.
>> ecb-layout.el:2108:46:Warning: `special-display-function' is an obsolete
>> variable (as of 24.3); use `display-buffer-alist' instead.
>> ecb-layout.el:2126:46:Warning: `special-display-buffer-names' is an obsolete
>> variable (as of 24.3); use `display-buffer-alist' instead.
>> ecb-layout.el:2115:44:Warning: `special-display-function' is an obsolete
>> variable (as of 24.3); use `display-buffer-alist' instead.
>> ecb-layout.el:2102:31:Warning: `special-display-regexps' is an obsolete
>> variable (as of 24.3); use `display-buffer-alist' instead.
>> ecb-layout.el:2106:66:Warning: `special-display-function' is an obsolete
>> variable (as of 24.3); use `display-buffer-alist' instead.
>> ecb-layout.el:2112:52:Warning: `special-display-function' is an obsolete
>> variable (as of 24.3); use `display-buffer-alist' instead.
>>
>> In ecb-check-for-special-buffer:
>> ecb-layout.el:2899:36:Warning: `special-display-function' is an obsolete
>> variable (as of 24.3); use `display-buffer-alist' instead.
>> ecb-layout.el:2905:36:Warning: `special-display-buffer-names' is an obsolete
>> variable (as of 24.3); use `display-buffer-alist' instead.
>> ecb-layout.el:2913:68:Warning: `special-display-buffer-names' is an obsolete
>> variable (as of 24.3); use `display-buffer-alist' instead.
>> ecb-layout.el:2909:29:Warning: `special-display-regexps' is an obsolete
>> variable (as of 24.3); use `display-buffer-alist' instead.
>> Wrote /ĢBUILDDIRģ/ecb-2.40+git20140216/ecb-layout.elc
>> Wrote /ĢBUILDDIRģ/ecb-2.40+git20140216/ecb-method-browser.elc
>> Wrote /ĢBUILDDIRģ/ecb-2.40+git20140216/ecb-mode-line.elc
>> Wrote /ĢBUILDDIRģ/ecb-2.40+git20140216/ecb-multiframe.elc
>> Wrote /ĢBUILDDIRģ/ecb-2.40+git20140216/ecb-navigate.elc
>>
>> In toplevel form:
>> ecb-semantic-wrapper.el:292:7:Warning: `semantic-toplevel-bovine-cache' is an
>> obsolete variable (as of 23.2); use `semantic--buffer-cache' instead.
>> Wrote /ĢBUILDDIRģ/ecb-2.40+git20140216/ecb-semantic-wrapper.elc
>> Wrote /ĢBUILDDIRģ/ecb-2.40+git20140216/ecb-semantic.elc
>> Wrote /ĢBUILDDIRģ/ecb-2.40+git20140216/ecb-speedbar.elc
>>
>> In end of data:
>> ecb-symboldef.el:646:1:Warning: the function
>> `eieio-help-mode-augmentation-maybee' is not known to be defined.
>> Wrote /ĢBUILDDI

Bug#693623: icedtea-netx-common: netx.jar does not contain VariableX509TrustManagerJDK7 leaving PR1161 unsolved

[Bálint Réczey]

Package: icedtea-netx-common
Version: 1.3.1-1
Justification: renders package unusable
Severity: grave
Tags: patch

Dear Maintainer,

Since icedtea-web is built with Java 6, VariableX509TrustManagerJDK7.class is
not built and shipped with the icedtea-netx-common package.

This makes several Java applications using Java Web Start unusable like
https://ibank.cib.hu/ throwing the following exception:

OpenJDK Runtime Environment (IcedTea7 2.1.3) (7u3-2.1.3-1)
OpenJDK 64-Bit Server VM (build 22.0-b10, mixed mode)
Unable to find class net.sourceforge.jnlp.security.VariableX509TrustManagerJDK7
JAR https://ibank.cib.hu/cibib.jar not found. Continuing.
netx: Initialization Error: Could not initialize applet.
(ebank.applet.MainApplet)
netx: Initialization Error: Could not initialize applet.
(ebank.applet.MainApplet)
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error:
Could not initialize applet.
at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:754)
at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:687)
at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:905)
Caused by: java.lang.ClassNotFoundException: ebank.applet.MainApplet
at 
net.sourceforge.jnlp.runtime.JNLPClassLoader.loadClass(JNLPClassLoader.java:1609)
at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:744)
... 2 more
java.lang.NullPointerException
at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:154)

I'm submitting this bug with grave severity because in the support cycle of
Wheezy most users are expected to upgrade to Java 7 and Java Web Start will stop
working for them.

I have built icedtea-web 1.3.1-1 using Java 7 using the following little patch
and it solved the problem:

diff -Nru icedtea-web-1.3.1/debian/rules icedtea-web-1.3.1/debian/rules
--- icedtea-web-1.3.1/debian/rules  2012-09-06 23:06:17.0 +0200
+++ icedtea-web-1.3.1/debian/rules  2012-11-18 12:20:57.0 +0100
@@ -47,7 +47,7 @@
 archdir  := $(strip $(patsubst $(DEB_HOST_ARCH)=%, %, \
   $(filter $(DEB_HOST_ARCH)=%, $(archdir_map

-ifneq (,$(filter $(distrel),hardy intrepid jaunty karmic lucid
maverick natty oneiric precise lenny etch squeeze wheezy sid))
+ifneq (,$(filter $(distrel),hardy intrepid jaunty karmic lucid
maverick natty oneiric precise lenny etch squeeze))
   is7_default = no
   default_version = 6
 else


Cheers,
Balint


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (700, 'testing'), (650, 'unstable'), (600, 'experimental')
Architecture: amd64 (x86_64)

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

-- no debconf information


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

Bug#798190: reads nonexistant dir, segfaults Kodi on startup

[Bálint Réczey]

Hi Steinar,

2015-09-06 16:35 GMT+02:00 Steinar H. Gunderson :
> Package: libcec3
> Version: 3.0.1+dfsg2-4
> Severity: grave
>
> Hi,
>
> Recently, Kodi has started segfaulting on startup, pointing to libcec3.
> A backtrace reads:
>
> #0  0x7fffecf55789 in __readdir (dirp=dirp@entry=0x0) at 
> ../sysdeps/posix/readdir.c:44
> #1  0x7fffc81d8b74 in PLATFORM::CDRMEdidParser::GetPhysicalAddress 
> (this=this@entry=0x7fffc29e8550)
> at 
> /home/sesse/nmu/libcec-3.0.1+dfsg2/src/libcec/platform/drm/drm-edid.cpp:54
> #2  0x7fffc81e4c0e in 
> CEC::CUSBCECAdapterCommunication::GetPhysicalAddress (this=0x7fffb4000f50)
> at 
> /home/sesse/nmu/libcec-3.0.1+dfsg2/src/libcec/adapter/Pulse-Eight/USBCECAdapterCommunication.cpp:697
> #3  0x7fffc81baaec in CEC::CCECClient::AutodetectPhysicalAddress 
> (this=0x1a7cab0)
> at /home/sesse/nmu/libcec-3.0.1+dfsg2/src/libcec/CECClient.cpp:1224
> #4  0x7fffc81b884c in CEC::CCECClient::SetPhysicalAddress 
> (this=0x1a7cab0, configuration=...)
> at /home/sesse/nmu/libcec-3.0.1+dfsg2/src/libcec/CECClient.cpp:236
> #5  0x7fffc81bcdcb in CEC::CCECClient::OnRegister (this=0x1a7cab0) at 
> /home/sesse/nmu/libcec-3.0.1+dfsg2/src/libcec/CECClient.cpp:138
> #6  0x7fffc81cd4d2 in CEC::CCECProcessor::RegisterClient (this=0x1a76840, 
> client=std::shared_ptr (count 4, weak 0) 0x1a7cab0)
> at /home/sesse/nmu/libcec-3.0.1+dfsg2/src/libcec/CECProcessor.cpp:899
> #7  0x7fffc81d3e7a in CEC::CLibCEC::Open (this=0x1a78d10, 
> strPort=, iTimeoutMs=)
> at /home/sesse/nmu/libcec-3.0.1+dfsg2/src/libcec/LibCEC.cpp:91
> #8  0x010cdd39 in 
> PERIPHERALS::CPeripheralCecAdapter::OpenConnection() ()
> #9  0x010d0434 in PERIPHERALS::CPeripheralCecAdapter::Process() ()
> #10 0x0113f56f in CThread::Action() ()
> #11 0x0113f832 in CThread::staticThread(void*) ()
> #12 0x755ad0a4 in start_thread (arg=0x7fffc29e9700) at 
> pthread_create.c:309
> #13 0x7fffecf8807d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
>
> It would seem libcec3 unconditionally assumes /sys/class/drm exists
> (it does not on my system using the proprietary NVIDIA driver, since
> that driver doesn't use drm), and then segfaults when it doesn't.
>
> Could you please add a check for the NULL value?
Thank you for the detailed bug report.
Could you please test the fix built here?:
http://debomatic-amd64.debian.net/distribution#unstable/libcec/3.0.1+dfsg2-5

Thanks,
Balint

Bug#798190: reads nonexistant dir, segfaults Kodi on startup

[Bálint Réczey]

Hi Steinar,

2015-09-06 19:51 GMT+02:00 Steinar H. Gunderson :
> On Sun, Sep 06, 2015 at 07:48:24PM +0200, Bálint Réczey wrote:
>> Thank you for the detailed bug report.
>> Could you please test the fix built here?:
>> http://debomatic-amd64.debian.net/distribution#unstable/libcec/3.0.1+dfsg2-5
>
> Uhm, I must understand I couldn't figure that UI out at all. Do you have a
> patch?
>
> FWIW, I tried just returning immediately if the pointer from opendir is NULL,
> and that seems to have worked correctly. If your fix is anything like that,
> it should be fine.
OK, I tried that, too.
Could you please confirm if the latest upload fixed the bug?
I would forward the fix to upstream then.

Cheers,
Balint

Bug#768751: ecb: FTBFS in jessie

[Bálint Réczey]

Control: tags -1 help

2014-11-11 21:05 GMT+01:00 Bálint Réczey :
> Control: tags -1 confirmed
>
> Hi Lucas,
>
> 2014-11-09 8:31 GMT+01:00 Lucas Nussbaum :
>> Source: ecb
>> Version: 2.40+git20140216-1
>> Severity: serious
>> Tags: jessie sid
>> User: debian...@lists.debian.org
>> Usertags: qa-ftbfs-20141108 qa-ftbfs
>> Justification: FTBFS in jessie on amd64
>>
>> Hi,
>>
>> During a rebuild of all packages in jessie (in a jessie chroot, not a
>> sid chroot), your package failed to build on amd64.
>>
>> Relevant part (hopefully):
>>> make[2]: Entering directory '/ĢBUILDDIRģ/ecb-2.40+git20140216'
>>> Makefile:38: Makefile.conf not found. Using defaults for Linux!
>>> Makefile:39: Create Makefile.conf from Makefile.conf.template to override 
>>> the defaults.
>>> Byte-compiling ECB with LOADPATH= ...
>>> emacs -batch -no-site-file -l ecb-compile-script --eval '(ecb-byte-compile 
>>> t)'
>>> ECB 2.40 uses CEDET 2.0 (contains semantic 2.2, eieio 1.4, speedbar 1.0).
>>> All requirements for ECB 2.40 fulfilled - Enjoy it!
...
>>> Wrote /ĢBUILDDIRģ/ecb-2.40+git20140216/ecb-winman-support.elc
>>> Wrote /ĢBUILDDIRģ/ecb-2.40+git20140216/ecb.elc
>>> Wrote /ĢBUILDDIRģ/ecb-2.40+git20140216/silentcomp.elc
>>> Wrote /ĢBUILDDIRģ/ecb-2.40+git20140216/tree-buffer.elc
>>> Args out of range: 0
>>> make[2]: *** [ecb] Error 255
>>
>> The full build log is available from:
>>
>> http://aws-logs.debian.net/ftbfs-logs/2014/11/08/ecb_2.40+git20140216-1_jessie.log
> It seems the latest emacs24 upload introduced some Elisp changes breaking ECB.
> I will try to fix it for the release, but if someone is more familiar
> with the changes then feel free to check the regression.
>
> Cheers,
> Balint

I'm not sure if I can debug and fix this by 5 Dec, when the package is
scheduled for removal from testing.
If you are familiar with elisp please take a look.

Thanks,
Balint


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

Bug#772347: xbmc: bashism in /bin/sh script

[Bálint Réczey]

Control: severity -1 important
Control: tags -1 confirmed pending

Hi Raphael,

Thank you for the bug report.

2014-12-06 15:34 GMT+01:00 Raphael Geissert :
> Package: xbmc
> Severity: serious
> Version: 2:13.2+dfsg1-4
> User: debian-rele...@lists.debian.org
> Usertags: goal-dash
>
> Hi,
>
> I've ran checkbashisms (from the 'devscripts' package) over the whole
> archive and I found that your package has a /bin/sh script that uses a
> "bashism".
>
> checkbashisms' output:
>> possible bashism in ./usr/bin/xbmc line 81 (should be >word 2>&1):
>> if which systemd-coredumpctl &> /dev/null; then
>> possible bashism in ./usr/bin/xbmc line 82 (should be >word 2>&1):
>>   systemd-coredumpctl dump -o core xbmc.bin &> /dev/null
Those are bashisms indeed, but they are harmless IMO.
I will include the fix in next upload, but since the package is quite
big I wouldn't like to prepare an upload just to fix this bug.

Cheers,
Balint

>
> Not using bash (or a Debian Policy compliant shell interpreter that doesn't
> provide such an extra feature) as /bin/sh is likely to lead to errors or
> unexpected behaviours. Please be aware that dash is the default /bin/sh.
>
> Please closely examine the above output and the script, and determine
> what the proper severity of the bug is, and adjust it accordingly. If
> it's important or greater please hurry to get this fixed for jessie.
>
> Hints about how to fix bashisms can be found at:
> https://wiki.ubuntu.com/DashAsBinSh
>
> Thanks in advance,
> Raphael Geissert
>


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

Bug#768751: ecb: FTBFS in jessie

[Bálint Réczey]

Hi Rob,

2014-12-10 8:00 GMT+01:00 Rob Browning :
> Balint Reczey  writes:
>
>> It turned out to be an Emacs bug already fixed upstream.
>> Please see the attached NMU diff which fixes.
>> I'm uploading the fixed package to DELAYED/10 today.
>
> Did you get approval from the release team?
No, I did not and I have not asked for it for two reasons.
First, I wanted to give you, the maintainer some time to ACK/NACK the
patch and second IMHO this is the exact kind of change which does not
need prior approval (minimal fix for an RC bug) [1].

Are you happy with the upload? Would you like to ask for prior approval first?

Cheers,
Balint

[1] https://release.debian.org/jessie/freeze_policy.html


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

Bug#772233: bashism in /bin/sh script

[Bálint Réczey]

Hi,

2014-12-19 22:51 GMT+01:00 Holger Levsen :
> On Freitag, 19. Dezember 2014, Balint Reczey wrote:
>> If you don't have time I would happily prepare an NMU with the fix.
>
> Please go ahead. Thanks!
I just performed the NMU to DELAYED/2 with the attached patch.

Cheers,
Balint
diff -Nru gnunet-0.10.1/debian/changelog gnunet-0.10.1/debian/changelog
--- gnunet-0.10.1/debian/changelog	2014-10-15 21:44:30.0 +0200
+++ gnunet-0.10.1/debian/changelog	2014-12-20 10:00:17.0 +0100
@@ -1,3 +1,12 @@
+gnunet (0.10.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [Raphael Geissert]
+  * Fix bashisms (Closes: #772233)
+
+ -- Balint Reczey   Sat, 20 Dec 2014 09:59:13 +0100
+
 gnunet (0.10.1-2) unstable; urgency=medium
 
   * Put the upstream signing key in debian/upstream/signing-key.asc and remove
diff -Nru gnunet-0.10.1/debian/patches/fix-bashism.patch gnunet-0.10.1/debian/patches/fix-bashism.patch
--- gnunet-0.10.1/debian/patches/fix-bashism.patch	1970-01-01 01:00:00.0 +0100
+++ gnunet-0.10.1/debian/patches/fix-bashism.patch	2014-12-20 09:59:07.0 +0100
@@ -0,0 +1,54 @@
+Description: fix bashisms
+Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=7772233
+Author: Raphael Geissert 
+Forwarded: https://gnunet.org/bugs/view.php?id=3588
+
+Index: gnunet-0.10.1-2/src/gns/gnunet-gns-proxy-setup-ca
+===
+--- gnunet-0.10.1-2/src/gns/gnunet-gns-proxy-setup-ca
 gnunet-0.10.1-2/src/gns/gnunet-gns-proxy-setup-ca
+@@ -7,9 +7,9 @@
+ options=''
+ while getopts "c:" opt; do
+   case $opt in
+ c)
++  options="$options -c $OPTARG"
+-  options+="-c $OPTARG"
+   ;;
+ \?)
+   echo "Invalid option: -$OPTARG" >&2
+   exit 1
+@@ -38,16 +38,16 @@
+ for f in ~/.mozilla/firefox/*.default
+ do
+   if [ -d $f ]; then
+ echo "Importing CA info Firefox $f"
++certutil -D -n "GNS Proxy CA" -d ~/.mozilla/firefox/*.default >/dev/null 2>&1
+-certutil -D -n "GNS Proxy CA" -d ~/.mozilla/firefox/*.default >/dev/null 2&>1
+ certutil -A -n "GNS Proxy CA" -t CT,, -d ~/.mozilla/firefox/*.default < $GNSCERT
+   fi
+ done
+ 
+ if [ -d ~/.pki/nssdb ]; then
+   echo "Importing CA into Chrome"
++  certutil -D -n "GNS Proxy CA" -d ~/.pki/nssdb >/dev/null 2>&1
+-  certutil -D -n "GNS Proxy CA" -d ~/.pki/nssdb >/dev/null 2&>1
+   certutil -A -n "GNS Proxy CA" -t CT,, -d ~/.pki/nssdb < $GNSCERT
+ fi
+ 
+ 
+Index: gnunet-0.10.1-2/contrib/gnunet-gns-import.sh
+===
+--- gnunet-0.10.1-2/contrib/gnunet-gns-import.sh
 gnunet-0.10.1-2/contrib/gnunet-gns-import.sh
+@@ -25,9 +25,9 @@
+ 
+ while getopts "c:" opt; do
+   case $opt in
+ c)
++  options="$options -c $OPTARG"
+-  options+="-c $OPTARG"
+   ;;
+ \?)
+   echo "Invalid option: -$OPTARG" >&2
+   exit 1
diff -Nru gnunet-0.10.1/debian/patches/series gnunet-0.10.1/debian/patches/series
--- gnunet-0.10.1/debian/patches/series	2014-10-15 21:41:21.0 +0200
+++ gnunet-0.10.1/debian/patches/series	2014-12-20 09:44:17.0 +0100
@@ -3,3 +3,4 @@
 typos.diff
 noinst_set.diff
 kfreebsd_malloc_np.patch
+fix-bashism.patch

Bug#772233: bashism in /bin/sh script

[Bálint Réczey]

2014-12-20 10:30 GMT+01:00 Bálint Réczey :
> Hi,
>
> 2014-12-19 22:51 GMT+01:00 Holger Levsen :
>> On Freitag, 19. Dezember 2014, Balint Reczey wrote:
>>> If you don't have time I would happily prepare an NMU with the fix.
>>
>> Please go ahead. Thanks!
> I just performed the NMU to DELAYED/2 with the attached patch.
I made a typo in the bug number, please see the fixed patch attached.
I also reuploaded the package to DELAYED/2.

Cheers,
Balint
diff -Nru gnunet-0.10.1/debian/changelog gnunet-0.10.1/debian/changelog
--- gnunet-0.10.1/debian/changelog	2014-10-15 21:44:30.0 +0200
+++ gnunet-0.10.1/debian/changelog	2014-12-20 10:00:17.0 +0100
@@ -1,3 +1,12 @@
+gnunet (0.10.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [Raphael Geissert]
+  * Fix bashisms (Closes: #772233)
+
+ -- Balint Reczey   Sat, 20 Dec 2014 09:59:13 +0100
+
 gnunet (0.10.1-2) unstable; urgency=medium
 
   * Put the upstream signing key in debian/upstream/signing-key.asc and remove
diff -Nru gnunet-0.10.1/debian/patches/fix-bashism.patch gnunet-0.10.1/debian/patches/fix-bashism.patch
--- gnunet-0.10.1/debian/patches/fix-bashism.patch	1970-01-01 01:00:00.0 +0100
+++ gnunet-0.10.1/debian/patches/fix-bashism.patch	2014-12-20 10:34:36.0 +0100
@@ -0,0 +1,54 @@
+Description: fix bashisms
+Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772233
+Author: Raphael Geissert 
+Forwarded: https://gnunet.org/bugs/view.php?id=3588
+
+Index: gnunet-0.10.1-2/src/gns/gnunet-gns-proxy-setup-ca
+===
+--- gnunet-0.10.1-2/src/gns/gnunet-gns-proxy-setup-ca
 gnunet-0.10.1-2/src/gns/gnunet-gns-proxy-setup-ca
+@@ -7,9 +7,9 @@
+ options=''
+ while getopts "c:" opt; do
+   case $opt in
+ c)
++  options="$options -c $OPTARG"
+-  options+="-c $OPTARG"
+   ;;
+ \?)
+   echo "Invalid option: -$OPTARG" >&2
+   exit 1
+@@ -38,16 +38,16 @@
+ for f in ~/.mozilla/firefox/*.default
+ do
+   if [ -d $f ]; then
+ echo "Importing CA info Firefox $f"
++certutil -D -n "GNS Proxy CA" -d ~/.mozilla/firefox/*.default >/dev/null 2>&1
+-certutil -D -n "GNS Proxy CA" -d ~/.mozilla/firefox/*.default >/dev/null 2&>1
+ certutil -A -n "GNS Proxy CA" -t CT,, -d ~/.mozilla/firefox/*.default < $GNSCERT
+   fi
+ done
+ 
+ if [ -d ~/.pki/nssdb ]; then
+   echo "Importing CA into Chrome"
++  certutil -D -n "GNS Proxy CA" -d ~/.pki/nssdb >/dev/null 2>&1
+-  certutil -D -n "GNS Proxy CA" -d ~/.pki/nssdb >/dev/null 2&>1
+   certutil -A -n "GNS Proxy CA" -t CT,, -d ~/.pki/nssdb < $GNSCERT
+ fi
+ 
+ 
+Index: gnunet-0.10.1-2/contrib/gnunet-gns-import.sh
+===
+--- gnunet-0.10.1-2/contrib/gnunet-gns-import.sh
 gnunet-0.10.1-2/contrib/gnunet-gns-import.sh
+@@ -25,9 +25,9 @@
+ 
+ while getopts "c:" opt; do
+   case $opt in
+ c)
++  options="$options -c $OPTARG"
+-  options+="-c $OPTARG"
+   ;;
+ \?)
+   echo "Invalid option: -$OPTARG" >&2
+   exit 1
diff -Nru gnunet-0.10.1/debian/patches/series gnunet-0.10.1/debian/patches/series
--- gnunet-0.10.1/debian/patches/series	2014-10-15 21:41:21.0 +0200
+++ gnunet-0.10.1/debian/patches/series	2014-12-20 09:44:17.0 +0100
@@ -3,3 +3,4 @@
 typos.diff
 noinst_set.diff
 kfreebsd_malloc_np.patch
+fix-bashism.patch

Bug#760385: lowering severity of bugs not tracked by release team

[Bálint Réczey]

Hi Mike,

First, I had to cancel the upload because of too strict reverse
dependencies. Dear fellow JavaScript maintainers please figure out a
less strict dependency graph because every otherwise fully compatible
libv8 update would break several packages.

2014-12-21 2:13 GMT+01:00 Michael Gilbert :
> On Sat, Dec 20, 2014 at 7:52 PM, Bálint Réczey wrote:
>> The proper severity of this bug is grave as set by Moritz IMO. I'm
>> restoring it wearing my maintainer hat.
>
> It's not really constructive arguing over severity, so that's fine.
I appreciate the work done by the Security Team but to work together
we have to know what actions can be taken by the Security Team.
Increasing severity of bugs is business as usual and perfectly
reasonable, but _decreasing_ the severity _based on the availability
of security support_ was crossing a line IMO. It seems the line was
there based on Jonas' and Adam's email.
To clarify my position the Security Team can and is expected to
decrease the severity in case a security bug's impact turns out to be
less than originally expected but in this particular case this rule
does not seem to be applicable.

> You've saved yourself from needing to write an unblock request.
>
> The problem still remains that the backlog of libv8 security issues
> never get fixed (except for a new upstream every now and then), so
> treating this one as RC but not the others is rather inconsistent:
> https://security-tracker.debian.org/tracker/source-package/libv8
> https://security-tracker.debian.org/tracker/source-package/libv8-3.14
If there were bugs opened for those CVE-s those should have been
opened with grave severity, too.

>
> Note that unimportant there indicates lack of security support for the 
> package.
This is confusing. Please don't mark them as unimportant because in
this context unimportant is defined differently.

https://security-tracker.debian.org/tracker/status/unimportant :
"This page lists packages that are affected by issues that are
considered unimportant from a security perspective. These issues are
thought to be unexploitable or uneffective in most situations (for
example, browser denial-of-services)."

>
> If there is interest in security support for libv8, that is a good
> thing, but a lot more needs to be done for that to be true.
Well, there is a long way to go, I agree.

Thank you for helping the Security Team and keeping the bugs and CVE-s updated.

Cheers,
Balint


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

Bug#751498: closed by Laszlo Boszormenyi (GCS) (Bug#751498: fixed in python-greenlet 0.4.5-1)

[Bálint Réczey]

Hi Laszlo,

2014-12-22 9:11 GMT+01:00 László Böszörményi (GCS) :
> Hi Bálint,
>
> On Fri, Dec 19, 2014 at 10:21 PM, Balint Reczey  
> wrote:
>> On Sat, 15 Nov 2014 13:49:10 +0100 Ivo De Decker  wrote:
>>> The arm* build failure is fixed by this patch from ubuntu (tested on abel):
>>>
>>> http://patches.ubuntu.com/p/python-greenlet/python-greenlet_0.4.2-1ubuntu1.patch
>
>> T-p-u sounds a bit better, do you plan going this way?
>> If you don't have time now I would happily fix this in an NMU.
>  I've updated the package[1]. Can someone test it on any ARM
> architecture to see if it builds correctly? Will ask the Release Team
> for a t-p-u upload.
It built fine on armel.

Cheers,
Balint


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

Bug#741451: Bugfix

[Bálint Réczey]

Hi Thomasz,

2014-12-23 17:44 GMT+01:00 Tomasz Buchert :
> On 22/12/14 18:08, Tomasz Buchert wrote:
>> On 19/12/14 22:05, Balint Reczey wrote:
>> > Hi Jay,
>> >
>> > [...]
>> >
>> > Cheers,
>> > Balint
>> >
>>
>> Hi guys,
>> I didn't notice that upstream made a fix based on what I found.  I'll
>> try to prepare an NMU right now.
>>
>> Tomasz
>>
>
> Here is a NMU. Feel free to adapt it if you
> feel like it.
Thanks, I have uploaded it to DELAYED/5.

Cheers,
Balint


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

Bug#773671: [Pkg-javascript-devel] Bug#773671: libv8-3.14: multiple security issues

[Bálint Réczey]

Hi Moritz,

2014-12-29 3:01 GMT+01:00 Moritz Mühlenhoff :
> On Sun, Dec 21, 2014 at 03:19:42PM -0500, Michael Gilbert wrote:
>> package: src:libv8-3.14
>> severity: grave
>> tags: security
>>
>> Hi,
>>
>> the following vulnerabilities were published for libv8-3.14.
>
> So if I'm understanding the discussion on debian-devel correctly
> the libv8 maintainers want to see this treated as an RC-bug.
> Please clarify your intentions, do you
>
> a) intent to fix these issues with patches and if that's not possible
> remove libv8 along with its rev deps?
>
> b) want to keep this with RC severity and tag it jessie-ignore.
> I would consider that rather broken since foo-ignore is used for
> issues which are ignored for once, but which will be addressed
> in release+1. I don't see the libv8 situation change upstream...
The rationale behind opening the RC bugs was improving transparency on
my side. I think more people follow bugs than the security tracker.
I think the call between a) and b) is up to release management, but my
interpretation for b) is a bit different.
There are RC bugs ignored for several releases thus I think foo-ignore
is not strictly for one-off issues and b) would be the proper way of
letting liv8 released with Jessie if the security issues stay open.

Cheers,
Balint



>
> c) plan something else I'm missing
>
> Cheers,
> Moritz


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

Bug#776135: wireshark: Multiple security issues in 1.12.3 and prior versions

[Bálint Réczey]

Package: wireshark
Severity: serious
Tags: security fixed-upstream pending

Please see release notes:
https://www.wireshark.org/docs/relnotes/wireshark-1.12.3.html

Cheers,
Balint


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

Bug#776136: wireshark: Crashes when filter string is edited on Broadway

[Bálint Réczey]

Package: wireshark
Severity: serious
Tags: fixed-upstream pending

>From https://code.wireshark.org/review/#/c/6494/ :

The Broadway GDK backend does never sets event->string. This results in
a crash when filter_string_te_key_pressed_cb tries to read its
contents.Since the documentation marks reading the string as
deprecated, try to
handle the character conversion here. It is based on
_gdk_x11_event_translate_keyboard_string (from gtk+), but without trying
to interpret Escape as '\033', and without trying to convert control
characters (example: Ctrl + 1). A buffer of 6 bytes is used to hold a
UTF-8 code point (there is no zero terminator, so 7 bytes as found in
the original implementation is unnecessary).As g_locale_from_utf8
returns dynamically allocated memory, change the
control flow to have a single exit point where pointers are freed as
needed.Reproduce with gtk3:

$ broadwayd :5
$ GDK_BACKEND=broadway BROADWAY_DISPLAY=:5 wireshark-gtk
(now open http://localhost:8085/ and start typing in the display
filter)Keys tested: e € (AltGr + 5) ü (AltGr + ", u)

In the X11 backend, these still get displayed correctly. In the broadway
backend however, the accents are missing due to a bug in the broadway
implementation.

Cheers,
Balint


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

Bug#775715: [Pkg-javascript-devel] Bug#775715: libv8-3.14: limiting security support

[Bálint Réczey]

Hi Michael,

Control: tags -1 pending

2015-01-19 7:17 GMT+01:00 Michael Gilbert :
> package: libv8-3.14
> version: 3.14.5.8-8
> severity: grave
> tags: security
>
> Hi, the security team has decided that this package will not receive
> security support for jessie.  This has already been documented in the
> debian-security-support package for about two months:
>
> libv8-3.14 Not covered by security support, only suitable for trusted content
>
> Please include a README.Debian.security file describing the security
> support status and problems for the package.  See [0] for an example.
>
> Since this will be clearly documented in multiple places, it will no
> longer be necessary to treat unfixed security bugs as release
> critical.
>
> Best wishes,
> Mike
>
> [0] https://bugs.debian.org/702775
I have added the changes in git [1] and I plan uploading the fix this week.
I will check the outstanding security issues for easily fixable ones
and include the fixes in the same upload.

Cheers,
Balint

[1] 
https://anonscm.debian.org/cgit/collab-maint/libv8.git/commit/?h=jessie&id=8c56a4f1695dc6787a6861735defdb2ee8ec7253


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

Bug#756777: Dirac FTBFS on armhf and blocks migration of arm64 fix.

[Bálint Réczey]

2014-10-18 2:21 GMT+02:00 Jonas Smedegaard :
> Quoting peter green (2014-10-17 23:25:14)
>> peter green wrote:
>>> I've just tested and found that building with gcc/g++ 4.8 fixes the
>>> build.
>
> Gcc maintainer is pushing to drop gcc-4.8 for Jessie - see bug#765380.
In similar cases please consider using clang instead of an old,
to-be-retired version of gcc.

Cheers,
Balint


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

Bug#766190: xbmc: FTBFS on armel/armhf

[Bálint Réczey]

Hi,

Control: tags -1 confirmed pending

2014-10-21 14:43 GMT+02:00 Emilio Pozuelo Monfort :
> Source: xbmc
> Version: 2:13.2+dfsg1-2
> Severity: serious
>
> Your package failed to build on armel and armhf. This seems related to
> the changes in the last upload wrt vdpau:
>
> ../configure --host=arm-linux-gnueabihf [...] --disable-vdpau [...]
> [...]
> configure: == VDPAU support manually disabled. ==
> [...]
> In file included from 
> /«BUILDDIR»/xbmc-13.2+dfsg1/lib/xbmc-libav-hacks/libav_hacks.h:32:0,
>  from /«BUILDDIR»/xbmc-13.2+dfsg1/lib/DllAvUtil.h:48,
>  from /«BUILDDIR»/xbmc-13.2+dfsg1/lib/DllAvCodec.h:26,
>  from AddonCallbacksCodec.cpp:24:
> /usr/include/libavcodec/vdpau.h:52:25: fatal error: vdpau/vdpau.h: No such 
> file or directory
>  #include 
>  ^
> compilation terminated.
I have already prepared a fix in the packaging repository and I plan
uploading it bundled with other fixes this week..

Cheers,
Balint


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

Bug#759777: tt-rss: Partially broken by libjs-dojo-core/dijit upgrade

[Bálint Réczey]

Hi David,

2014-10-26 2:31 GMT+01:00 "David Prévot" :
>> On Sat, 30 Aug 2014 04:15:14 -0400 Matthew Gabeler-Lee
>>  wrote:
>>> Package: tt-rss
>
>>> After libjs-dojo-core/dijit just upgraded in testing (from 1.7.2+dfsg-1
>>> to 1.10.0+dfsg-1), tt-rss' UI is partially broken.
>
>> It would be nice if the maintainers of the two packages could find a way
>> of solving this issue.
>
> Sorry I didn’t noticed this issue sooner. It’s too late for Jessie (I
> don’t foresee myself being able to help debugging the issue in the next
> hours), but hopefully, we’ll be able to do a better job for Jessie+1.
Don't worry, jessie-backports would be almost as good as jessie and if
you could find a solution in a few days releasese managers may even
make an exception here.

Cheers,
Balint


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

Bug#607969: sqlite: Still useful?

[Bálint Réczey]

Hi Julien,

2014-10-29 10:48 GMT+01:00 Julien Cristau :
> On Wed, Oct 29, 2014 at 10:33:32 +0100, Balint Reczey wrote:
>
>> Dear Release Team, should this package be released with Jessie?
>>
> The only way I can see us not shipping it is if we remove it along with
> the remaining rdeps.  Now is not the time to migrate them over to
> sqlite3 in jessie.
I fully agree. How about marking this bug jessie-ignore or decreasing
the severity?
I periodically look for RC bugs to fix (like hopefully many others
:-)) and those would make that bug stop appearing on the list.

Cheers,
Balint


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

Bug#737030: libgcrypt uses processor features not allowed for armhf (and i386?)

[Bálint Réczey]

2014-10-31 18:29 GMT+01:00 Balint Reczey :
> Control: tags -1 moreinfo
>
> Hi Matthias,
>
> On Wed, 29 Jan 2014 16:09:38 +0100 Matthias Klose  wrote:
>> hmm, looking further into the code, it looks like libgcrypt implements it's 
>> own
>> way to detect hw features. But maybe somebody could confirm this.
> If the library did indeed use such processor features on i386(/armhf)
> many users would have experienced actual crashes.
>
> This bug seems human performed static analysis false positive.
Oh, I forgot the ":-)" here.
No offense. :-)


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

Bug#778995: forked-daapd: Does not work with iTunes 12.1

[Bálint Réczey]

Package: forked-daapd
Version: 0.22.0-1
Severity: serious
Tags: upstream fixed-upstream
Control: forwarded -1 https://github.com/ejurgensen/forked-daapd/issues/100

Latest iTunes can't work with forked-daapd.
Upstream has already released a fix.

Cheers,
Balint


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

Bug#780596: wireshark: Ctrl+C/Ctrl+V does not work in filter textbox

[Bálint Réczey]

Package: wireshark
Severity: serious
Control: forwarded -1 https://code.wireshark.org/review/7276
Tags: pending

A back-ported change fixing a crash when using Broadway interface
caused this problem.
IMO this regression should be fixed for Jessie by either dropping the
back-ported change and letting Broadway crash or back-porting the fix
of the change.

I plan uploading the fix along with the next set of security changes.

Cheers,
Balint


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

Bug#792361: redmine: dpkg --configure broken when installing ruby packages

[Bálint Réczey]

Hi,

2015-07-17 9:51 GMT+02:00 Pirate Praveen :
...
> Can this be even made a policy? "If a single application is blocking a
> library update the older version can be embedded in that application".
Does not sound like a good idea. It is also against Debian Policy.

Working with upstream to help them in migrating to the latest versions
of their dependencies is the established and proper way to go.

Cheers,
Balint


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

Bug#744330: groovy: makes xbmc FTBFS

[Bálint Réczey]

Package: groovy
Version: 1.8.6-2
Severity: serious


Hi,

Xbmc stopped building with latest groovy upload even with the
workaround for another groovy bug. :-(

touch xbmc/interfaces/python/generated/doxygenxml
mkdir -p xbmc/interfaces/python/generated
/usr/bin/swig -w401 -c++ -o
xbmc/interfaces/python/generated/AddonModuleXbmc.xml -xml -I./xbmc
-xmllang python xbmc/interfaces/swig/AddonModuleXbmc.i
# work around groovy crash
groovyc -cp 
"/usr/share/java/groovy-all-1.8.6.jar:/usr/share/java/commons-lang-2.6.jar:./tools/codegenerator:xbmc/interfaces/python"
-d tools/codegenerator tools/codegenerator/Helper.groovy
tools/codegenerator/SwigTypeParser.groovy
xbmc/interfaces/python/MethodType.groovy
xbmc/interfaces/python/PythonTools.groovy
groovy -cp 
"/usr/share/java/groovy-all-1.8.6.jar:/usr/share/java/commons-lang-2.6.jar:./tools/codegenerator:xbmc/interfaces/python"
\
./tools/codegenerator/Generator.groovy
xbmc/interfaces/python/generated/AddonModuleXbmc.xml
xbmc/interfaces/python/PythonSwig.cpp.template
xbmc/interfaces/python/generated/AddonModuleXbmc.cpp
xbmc/interfaces/python/generated/doxygenxml
java.lang.OutOfMemoryError: Java heap space
at java.util.ArrayList.(ArrayList.java:144)
at 
org.codehaus.groovy.reflection.GeneratedMetaMethod$DgmMethodRecord.loadDgmInfo(GeneratedMetaMethod.java:193)
at 
org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.registerMethods(MetaClassRegistryImpl.java:155)
at 
org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.(MetaClassRegistryImpl.java:83)
at 
org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.(MetaClassRegistryImpl.java:61)
at groovy.lang.GroovySystem.(GroovySystem.java:29)
at org.codehaus.groovy.runtime.InvokerHelper.(InvokerHelper.java:49)
at groovy.lang.GroovyObjectSupport.(GroovyObjectSupport.java:32)
at groovy.lang.Binding.(Binding.java:34)
at groovy.lang.GroovyShell.(GroovyShell.java:70)
at groovy.ui.GroovyMain.processOnce(GroovyMain.java:544)
at groovy.ui.GroovyMain.run(GroovyMain.java:337)
at groovy.ui.GroovyMain.process(GroovyMain.java:323)
at groovy.ui.GroovyMain.processArgs(GroovyMain.java:120)
at groovy.ui.GroovyMain.main(GroovyMain.java:100)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:108)
at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:130)
[xbmc/interfaces/python/generated/AddonModuleXbmc.xml,
xbmc/interfaces/python/PythonSwig.cpp.template,
xbmc/interfaces/python/generated/AddonModuleXbmc.cpp,
xbmc/interfaces/python/generated/doxygenxml]
Caught: groovy.lang.MissingMethodException: No signature of method:
[Ljava.lang.String;.each() is applicable for argument types:
(Generator$_run_closure1) values: [Generator$_run_closure1@201ce33e]
Possible solutions: wait(), wait(long), equals(java.lang.Object),
wait(long, int), getAt(java.lang.Integer)
groovy.lang.MissingMethodException: No signature of method:
[Ljava.lang.String;.each() is applicable for argument types:
(Generator$_run_closure1) values: [Generator$_run_closure1@201ce33e]
Possible solutions: wait(), wait(long), equals(java.lang.Object),
wait(long, int), getAt(java.lang.Integer)
at Generator.run(Generator.groovy:40)
make[2]: *** [xbmc/interfaces/python/generated/AddonModuleXbmc.cpp] Error 1
rm xbmc/interfaces/python/generated/AddonModuleXbmc.xml
make[2]: Leaving directory `/«BUILDDIR»/xbmc-12.3+dfsg2'
make[1]: *** [override_dh_auto_configure] Error 2
make[1]: Leaving directory `/«BUILDDIR»/xbmc-12.3+dfsg2'

This happened with a fully updated unstable sbuild chroot for rebuilding xbmc.

Thanks,
Balint


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

Bug#744330: groovy: makes xbmc FTBFS

[Bálint Réczey]

Hi Miguel,

2014-04-14 23:59 GMT+02:00 Miguel Landaeta :
> tags 744330 + confirmed
> thanks
>
> On Sun, Apr 13, 2014 at 02:25:44AM +0200, Bálint Réczey wrote:
>> Package: groovy
>> Version: 1.8.6-2
>> Severity: serious
>>
>>
>> Hi,
>>
>> Xbmc stopped building with latest groovy upload even with the
>> workaround for another groovy bug. :-(
>
> Hi,
>
> I'm investigating this since I did the last groovy upload to unstable
> with the goal of enabing support for Java 8.
>
> Gradle is also broken (#744337) probably due to the same reason.
I don't want to seem needy, but looking into #733234 which I had to
workaround upstream would also be nice. Caching classes at build time
does not seem to be a good design decision as it makes groovy die
using JRE-s other than the one it has been built with.

Thanks,
Balint


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

Bug#795002: nmu: motion

[Bálint Réczey]

Hi Sebastian,

2015-08-09 11:59 GMT+02:00 Sebastian Ramacher :
> On 2015-08-09 10:57:23, Balint Reczey wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: binnmu
>>
>> Dear Release Team,
>>
>> Motion seems to be built in an outdated chroot for the upload.
>> Please rebuild it to use the latest version of libav.*-dev packages
>> which are now built from ffmpeg.
>>
>> nmu motion_3.2.12+git20140228-6 . amd64 . unstable . -m "Rebuild against
>> ffmpeg"
>
> This will produce a build without any ffmpeg support at all. All the binaries
> from the buildds lack dependencies on the libraries from ffmpeg. motion needs 
> a
> source upload fixing the ffmpeg detection.
Thanks for pointing that out. I have added this bug to the ffmpeg
transition wiki [1].
Are there similar issues?
I'm preparing a delayed NMU for taoframework to help the transition finish.

Ximin, thanks for fixing the motion issue.

Cheers,
Balint

[1] https://wiki.debian.org/Debate/libav-provider/ffmpeg


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

Bug#787018: src:xbmc: xbmc does not build on unstable

[Bálint Réczey]

Hi Mattia,

2015-08-09 16:12 GMT+02:00 Mattia Rizzolo :
> On Wed, May 27, 2015 at 10:20:08PM +0200, Bálint Réczey wrote:
>> XBMC has been renamed to Kodi and I have already packaged it. It is
>> waiting for FTP Master approval in the NEW queue for some time.
>> I don't plan updating xbmc, just once, with an empty content to get
>> rid of the epoch while transitioning to kodi.
>
> Now kodi is even in testing.
> What about uploading this empty transition package of xbmc?
I think the proper way time of uploading the package would be after
uploading replacements for the PVR addons as well.
I'm discussing the situation with upstream here:
https://github.com/kodi-pvr/pvr.hts/issues/88

Cheers,
Balint


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

Bug#793015: [pkg-cli-libs-team] Bug#793015: taoframework: FTBFS, needs update of hardcoded sonames

[Bálint Réczey]

Hi Iain,

2015-08-10 10:17 GMT+02:00 Iain Lane :
> On Mon, Aug 10, 2015 at 12:55:12AM +0200, Balint Reczey wrote:
>> Hi,
>>
>> On Mon, 20 Jul 2015 15:35:00 +0200 Andreas Cadhalpun
>>  wrote:
>> > Source: taoframework
>> > Version: 2.1.svn20090801-10
>> > Tags: patch
>> > Severity: serious
>> > Justification: fails to build from source
>> >
>> > Dear maintainer,
>> >
>> > the ffmpeg-libav transition [1] is ongoing and thus the hardcoded sonames
>> > in taoframework need to be updated.
>> > Please apply attached patch doing that.
>> I will upload an NMU to DELAYED/5 with the attached patch soon.
>
> Please just directly upload, and commit to git when you do so, if that's
> okay.
OK, I'll do so in the next few days.

Cheers,
Balint


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

Bug#793015: [pkg-cli-libs-team] Bug#793015: taoframework: FTBFS, needs update of hardcoded sonames

[Bálint Réczey]

2015-08-10 10:20 GMT+02:00 Bálint Réczey :
> Hi Iain,
>
> 2015-08-10 10:17 GMT+02:00 Iain Lane :
...
>> Please just directly upload, and commit to git when you do so, if that's
>> okay.
> OK, I'll do so in the next few days.
It is maintained in subversion according to the control file.
This is the right repo, right?

Cheers,
Balint


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

Bug#793015: [pkg-cli-libs-team] Bug#793015: taoframework: FTBFS, needs update of hardcoded sonames

[Bálint Réczey]

2015-08-10 10:40 GMT+02:00 Iain Lane :
> On Mon, Aug 10, 2015 at 10:32:00AM +0200, Bálint Réczey wrote:
>> 2015-08-10 10:20 GMT+02:00 Bálint Réczey :
>> > Hi Iain,
>> >
>> > 2015-08-10 10:17 GMT+02:00 Iain Lane :
>> ...
>> >> Please just directly upload, and commit to git when you do so, if that's
>> >> okay.
>> > OK, I'll do so in the next few days.
>> It is maintained in subversion according to the control file.
>> This is the right repo, right?
>
> Could be - perhaps we didn't move this one over to git yet. If svn has
> the latest upload then this is fine to use.
It seems it has been migrated without updating the URL in the package:
http://anonscm.debian.org/cgit/pkg-cli-libs/packages/taoframework.git
I'll work in git then and make a few housekeeping changes like
updating the URLs after my application for joining the team is
accepted on Alioth.

Cheers,
Balint


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

Bug#795813: kodi: FTBFS with g++-5: multiple definitions of argument-parsing stuff

[Bálint Réczey]

Hi Simon,

2015-08-17 9:31 GMT+02:00 Simon McVittie :
> Source: kodi
> Version: 14.2+dfsg1-2
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
> Tags: patch
>
> kodi fails to build from source when binNMU'd for the libstdc++ transitions:
> 
>
> There are lots of errors like this:
>
> ../../lib/libmisc.a(argp-parse.o): In function `argp_usage':
> /«BUILDDIR»/kodi-14.2+dfsg1/xbmc/screensavers/rsxs-0.9/lib/argp.h:568: 
> multiple definition of `argp_usage'
> ../../lib/libmisc.a(argp-help.o):/«BUILDDIR»/kodi-14.2+dfsg1/xbmc/screensavers/rsxs-0.9/lib/argp.h:568:
>  first defined here
> ../../lib/libmisc.a(argp-parse.o): In function `_option_is_short':
> /«BUILDDIR»/kodi-14.2+dfsg1/xbmc/screensavers/rsxs-0.9/lib/argp.h:574: 
> multiple definition of `_option_is_short'
> ../../lib/libmisc.a(argp-help.o):/«BUILDDIR»/kodi-14.2+dfsg1/xbmc/screensavers/rsxs-0.9/lib/argp.h:574:
>  first defined here
>
> I believe this is because g++-5 changed the default interpretation of
> "inline T foo() { ... }" from historical GNU behaviour to Standard C++.
> 
>
> In Ubuntu, Matthias Klose patched kodi to use historical GNU inline
> semantics :
>
> diff -pruN 14.2+dfsg1-2/debian/rules 14.2+dfsg1-2ubuntu1/debian/rules
> --- 14.2+dfsg1-2/debian/rules   2015-06-04 08:33:30.0 +
> +++ 14.2+dfsg1-2ubuntu1/debian/rules2015-08-10 19:42:58.0 +
> @@ -37,6 +37,7 @@ DEB_CFLAGS ?=  $(shell dpkg-buildflags -
>  DEB_CXXFLAGS ?= $(shell dpkg-buildflags --get CPPFLAGS) \
>$(filter-out -g -O2, $(shell dpkg-buildflags --get CXXFLAGS))
>  DEB_LDFLAGS ?= $(shell dpkg-buildflags --get LDFLAGS) $(shell pkg-config 
> --libs ftgl)
> +DEB_CFLAGS += -fgnu89-inline
>  ENV_OPTIONS = CFLAGS="$(DEB_CFLAGS)" CXXFLAGS="$(DEB_CXXFLAGS)" \
>LDFLAGS="$(DEB_LDFLAGS)"
>
>
> This is probably an appropriate change for kodi in Debian too.
Thank you for the bug report and also for the patch.
I'm packaging Kodi 15 right now and it FTBFS-s multiple ways and some
of them are due to the embedded outdated gnulib files.
Instead of passing the cflag I plan removing the gnulib usage in the
next upload but for this particular problem the proposed patch would
be a solution indeed.

Cheers,
Balint

Bug#795718: Don't include libav in stretch

[Bálint Réczey]

Hi All,

2015-08-19 21:18 GMT+02:00 Andreas Cadhalpun :
> Hi Moritz,
>
> On 19.08.2015 15:53, Moritz Mühlenhoff wrote:
>> On Tue, Aug 18, 2015 at 08:08:01PM +0200, Andreas Cadhalpun wrote:
>>> On 16.08.2015 14:27, Moritz Muehlenhoff wrote:
 It was decided to switch to ffmpeg for stretch and it's now in
 testing.

 Please remove libav from testing (or rather from unstable unless
 someone wants to continue to maintain it in unstable/experimental
 only)
>>>
>>> It has been planned to remove the libav source package from unstable,
>>> once the transition to ffmpeg is fully finished.
>>> Unfortunately this transition is currently blocked by two packages:
>>>  * freerdp needs a new upstream version, but the maintainers are
>>>unresponsive. (#788557)
>>>  * vtk6 still has old binaries using Libav in testing, because
>>>the uncoordinated vtk6.1 -> vtk6.2 transition broke some
>>>of its reverese dependencies. (#793621)
>>
>> Ok, thanks. Let's wait until these are sorted out.
>
> I've now sent a minimal patch for freerdp to #788557.
> Maybe you feel like NMUing?
> I'm tempted to just ignore the vtk6 transition and request the
> removal of libav once freerdp is fixed, since there is no progress
> with that transition. And after all, it was not coordinated.
I have contacted Laszlo, one of the freerdp maintainters. AFAIK he
started looking into the issue thus the NMU should wait for a few days
IMO.

Cheers,
Balint

Bug#799979: /usr/lib/x86_64-linux-gnu/kodi/kodi.bin: not found

[Bálint Réczey]

Control: tags -1 confirmed pending

Hi Robert,

2015-09-25 2:31 GMT+02:00 Robert Luberda :
> Package: kodi
> Version: 15.2~rc1+dfsg1-1
> Severity: serious
>
> kodi tries to execute
> /usr/lib/x86_64-linux-gnu/kodi/kodi.bin
> 
> whereas the program in i386 is installed into
> /usr/lib/i386-linux-gnu/kodi/kodi.bin
>  
Thank you for the bug report. I have uploaded the fix to NEW and is
waiting for FTP Masters' approval.

Cheers,
Balint

Bug#831591: ffmpeg: kodi crash

[Bálint Réczey]

Hi,

2016-07-17 23:17 GMT+02:00 Sebastian Ramacher :
> Control: severity -1 serious
>
> On 2016-07-17 21:38:13, Carl Eugen Hoyos wrote:
>> Kodi reports "FFmpeg version: 3.0.1-3":
>> Could somebody test if the crash disappears after Kodi gets recompiled 
>> against
>> current FFmpeg?
>
> Wasn't 3.1.1 supposed to revert all the ABI breakage? Raising the severity 
> until
> this is resolved.

I have just uploaded a new kodi package to unstable thus this problem
can be easily tested.

Cheers,
Balint

Bug#831591: ffmpeg: kodi crash

[Bálint Réczey]

Hi,

2016-08-18 17:59 GMT+02:00 Bálint Réczey :
> Hi,
>
> 2016-07-17 23:17 GMT+02:00 Sebastian Ramacher :
>> Control: severity -1 serious
>>
>> On 2016-07-17 21:38:13, Carl Eugen Hoyos wrote:
>>> Kodi reports "FFmpeg version: 3.0.1-3":
>>> Could somebody test if the crash disappears after Kodi gets recompiled 
>>> against
>>> current FFmpeg?
>>
>> Wasn't 3.1.1 supposed to revert all the ABI breakage? Raising the severity 
>> until
>> this is resolved.
>
> I have just uploaded a new kodi package to unstable thus this problem
> can be easily tested.

Apparently the ABI breakage is still present in 7:3.1.2-1.
See #832364 for details.

Carl, it would be important to track the breakage.
http://abi-laboratory.pro/tracker/timeline/ffmpeg/ may give some help.

Cheers,
Balint

Bug#831591: ffmpeg: kodi crash

[Bálint Réczey]

Control: fixed -1 7:3.1.3-1

Hi Carl,

2016-09-07 20:21 GMT+02:00 Carl Eugen Hoyos :
> Hi Bálint!
>
>> I went throught the unclassified bugs and set the
>> proper state to help tracking them.
>
> This bug (#831591) and #832364 contain neither backtrace
> nor bisect. Note that they most likely have to be fixed
> in Kodi, FFmpeg will (afaict) not break ABI once more
> for the 3.1 release series to work-around bugs in other
> projects.
> (This analysis may of course be wrong but we cannot
> know better so far.)

I'm marking this bug fixed and close it because it does not affect
any package in unstable/testing.

I believe there was an unintended ABI breakage in FFmpeg and
it caused the kodi crash but since no one is really interested in
debugging that after recompiling solved it there is little value in
keeping it open.

>
> Bug #797965 contains no sample, I cannot reproduce.
> (Same for #833722 and #797963 which are marked as
> needs-more-info.)

In #797965 Christoph provided a way of reproducing it:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797965#126

Andreas even provided a patch thus I believe it is a valid bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797965#116

If I ever find time I'll create a reproducer based on Christoph's
guide, but it is unlikely to happen before Stretch's release.

>
> Bug #810224 is invalid: Behaviour is exactly as
> requested by you, my original analysis was wrong.

Closed that one, thanks.

>
> I do not understand why it makes sense to keep #493705
> and #528080 open: I believe Debian decided many years
> ago that they will not be fixed, FFmpeg has repeated
> its opinion that there is no bug last year (when
> Google stopped allowing such binaries in Android).
> (If you want you can fix both bugs anytime by adding
> --disable-asm to the configure options for x86_32.)

Those are known limitations of the Debian package and the bugs'
state reflects that.

> I have fixed #785690 upstream today, don't know how
> you proceed with the report here.
> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=3e886e7

Marked accordingly, thanks.
It can be closed with uploading a new upstream release containing the fix.
I don't think that this issue warrants a back-port.

Cheers,
Balint

Bug#831591: ffmpeg: kodi crash

[Bálint Réczey]

Hi Carl,

2016-08-24 22:55 GMT+02:00 Carl Eugen Hoyos :
> Hi!
>
> First, please understand that so far, no ABI breakage between
> FFmpeg 3.0 and FFmpeg 3.1 was found, only the usage of
> non-public api (that we decided to work-around for 3.1.1).

OK, then assume that Kodi uses non-public API and the rebuild made kodi
use the latest ABI.
Can I somehow find easily the places where the non-public API is used?


>
> Am I correct that no backtrace was provided for this issue?

Yes, AFAIK.

Cheers,
Balint

> But even with a backtrace, I fear a bisect may be necessary.
>
> Sorry, Carl Eugen

Bug#831591: ffmpeg: kodi crash

[Bálint Réczey]

Hi,

2016-08-27 15:48 GMT+02:00 Carl Eugen Hoyos :
> Hi!
>
>> 2016-08-24 22:55 GMT+02:00 Carl Eugen Hoyos :
>> >
>> > First, please understand that so far, no ABI breakage between
>> > FFmpeg 3.0 and FFmpeg 3.1 was found, only the usage of
>> > non-public api (that we decided to work-around for 3.1.1).
>>
>> OK, then assume that Kodi uses non-public API and the rebuild
>> made kodi use the latest ABI.
>
> I don't know!
> I just wanted to point out that so far, the "bugs" that were
> worked-around in FFmpeg 3.1.1 were bugs in other applications.
>
> I still do not understand completely: Is the crash still reproducible
> after recompiling Kodi or not?

Sorry for not being clear on this. In #832364 the test did show that
the crash is gone with the rebuild. My only assumption was that
it used to be caused by the ABI change.
Latest kodi works well with latest ffmpeg.


>
>> Can I somehow find easily the places where the non-public API is used?
>
> I don't know but...
>
>> > Am I correct that no backtrace was provided for this issue?
>>
>> Yes, AFAIK.
>
> ... adding a backtrace should work fast, no?
> If another developer looks at the backtrace, he might know what the
> issue is.

I don't have the test file. This has been discussed in #832364.

>
>> > But even with a backtrace, I fear a bisect may be necessary.
>
> Bisecting FFmpeg takes less than 20 minutes here, I know it would take
> you longer but if the backtrace does not help, this is the only way to
> find out what the issue is.
> I can try helping to create a specific configure line to speed up the
> backtrace.

Bug#831591: ffmpeg: kodi crash

[Bálint Réczey]

Hi Carl,

2016-09-06 11:39 GMT+02:00 Carl Eugen Hoyos :
> Hi Bálint!
>
>> I don't have the test file.
>
> In this case I suggest to close the relevant tickets:
> We cannot reproduce, there is no backtrace and no bisect.

Tobias has test files as he wrote in #832364 and he would
share it privately.

>
> Since FFmpeg has made three point releases with the ABI
> that is apparently incompatible with (old) Kodi, it is
> very unlikely that it will be changed again (we would
> likely brake mpv that intentionally uses the invalid API).

>From practical POV I'm OK with closing this bug since it does
not affect unstable nor testing. Knowing what broke could be
interesting for FFmpeg devs and in case the change is reverted
I could update ffmpeg in jessie-backports without recompiling
kodi. This is why I have not back-ported latest ffmpeg yet.


>
> Slightly related: More that half of the open tickets
> concerning FFmpeg in Debian either contain no samples to
> reproduce or will not be fixed or were never reproducible.
> If another FFmpeg developer were interested in fixing
> bugs reported here it would be very difficult for him to
> find something useful due to the low snr.

Those can be marked with the moreinfo tag and IMO it is
OK to close them after a reasonable amount of time if
the originator is asked to provide a test file but she/he
did not.

Thanks for helping in managing the FFmpeg bugs in Debian!

Cheers,
Balint

Bug#832364: kodi: Crashes on trying to play any TV recording

[Bálint Réczey]

Hi Tobias,

2016-08-19 19:54 GMT+02:00 Tobias Grimm :
> Hello Balint,
>
>> Tobias, could you please share the test file or test kodi again?
>
> I've just tested it. It crashes when playing a VDR TS recording with
> 16.1+dfsg1-1 and after upgrading to 16.1+dfsg1-2 it works fine for the
> same recording.

Could you please share the recording with Carl instead? He is an FFmpeg
dev thus probably can find the problem very quickly and maybe other
devs are interested as well.

>
> So I think 832364 can be closed.

I think merging with an other very similar bug reflects the situation
better (thus I did so).

Cheers,
Balint

Bug#831591: ffmpeg: kodi crash

[Bálint Réczey]

Hi Carl,

2016-09-06 12:41 GMT+02:00 Carl Eugen Hoyos :
> Hi!
>
>> Knowing what broke could be
>> interesting for FFmpeg devs
>
> It would most likely be even more interesting
> for the Kodi developers: We currently assume
> that there is an unknown bug in Kodi...

Well, the first suspect is ffmpeg because updating ffmpeg
broke kodi while there were no planned ABI change.

>
>> > Slightly related: More that half of the open tickets
>> > concerning FFmpeg in Debian either contain no samples to
>> > reproduce or will not be fixed or were never reproducible.
>> > If another FFmpeg developer were interested in fixing
>> > bugs reported here it would be very difficult for him to
>> > find something useful due to the low snr.
>>
>> Those can be marked with the moreinfo tag and IMO it is
>> OK to close them after a reasonable amount of time if
>> the originator is asked to provide a test file but she/he
>> did not.
>
> Are five months enough?

Generally I use a few years if I'm not pretty sure the bug is gone.
I agree with the concept that bugs are part of the documentation
thus closing possibly valid bugs is decreasing the quality of the
documentation, thus the software.

Note that there are way more users of stable and a bug not
reproducible on unstable may show up in stable later.

I went throught the unclassified bugs and set the proper state
to help tracking them.

Cheers,
Balint

Bug#818201: kodi: Jasper removal

[Bálint Réczey]

Hi Mattia,

2016-06-27 15:51 GMT+02:00 Mattia Rizzolo :
> Hi Balint,
>
> On Tue, Mar 15, 2016 at 02:45:43PM +0100, Bálint Réczey wrote:
>> > Hi, jasper will be removed from Debian for the stretch release (and
>> > following that, the archive in general).
>> Kodi 17 wil not use jasper [1] and is expected to be release before
>> Stretch's freeze.
>> I plan fixing this bug with the 17.0 upstream release.
>
> Can you please fix it before?
> I see there is an alpha release avaialbe that should already contain
> that fix, or maybe backport the patch.
>
> In a few days kodi is going to be the very last blocker for jasper
> removal (as today I NMUed a bunch, and paved the way for the others).

The new alpha releases are fixed indeed, but the fix is not simple and I'm
not comfortable with either back-porting it either with uploading 17.0
alphas to unstable. There are many add-on packages depending on Kodi's
API and they need to be updated as well with each major Kodi update
and I'm not sure if all the addon upstreams are ready for Kodi 17 already.

I'm uploading a fixed kodi 17 to experimental soon, but please keep jasper in
testing for kodi for a few short months.

Thanks,
Balint

Bug#837420: Bug#835148: please do not make GCC incompatible, we have dpkg-buildflags for this! (was Re: Bug#837420: Processed: PIE FTBFS are now RC)

[Bálint Réczey]

Hi Thorsten

2016-10-21 19:11 GMT+02:00 Thorsten Glaser :
> Adrian Bunk dixit:
>
>>gcc-6 6.2.0-7 uploaded to unstable on Tue 18 Oct 2016 defaults to PIE,
>>see #835148 for details.
>
> Oh, thanks.
>
> This is *so* *totally* the wrong approach, especially as we
> have dpkg-buildflags, which was introduced *precisely* for
> this purpose, and to make Debian’s GCC not incompatible even
> more with the rest of the world.

You may have missed them, but there was several lengthy threads [1]
on debian-devel discussing the possible solutions including the
inapplicability of dpkg-buildflags for this problem.

However, if you do have a better _working_ solution for enabling PIE
archive-wide, please share that.

I'm exploring possible options like patching (upstream) GCC to disable
PIE for kernel or patching (upstream) kernel to disable PIE when it can
be disabled.

AFAIK the linux package is the only problematic package were the
maintainer refused to disable PIE from packaging scripts.

Cheers,
Balint

[1] https://lists.debian.org/debian-devel/2016/05/msg00229.html

Bug#837420: Bug#835148: please do not make GCC incompatible, we have dpkg-buildflags for this! (was Re: Bug#837420: Processed: PIE FTBFS are now RC)

[Bálint Réczey]

Hi,

2016-10-22 1:00 GMT+02:00 Thorsten Glaser :
> Bálint Réczey dixit:
>
>>AFAIK the linux package is the only problematic package were the
>>maintainer refused to disable PIE from packaging scripts.
>
> So, how are you supposed to do that now, instead of filtering
> -fPIE from CFLAGS and -pie from LDFLAGS?

This reverts defaulting to no-PIE:
CC = $(CC) -no-pie
LD = $(LD) -no-pie

Very often appending -no-pie works, too, but not when compiling shared
libraries.
See:  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77464

If you show the FTBFS you are facing I can help more.

Cheers,
Balint

>
> Christian/zumbi: do you take care of dietlibc, or should I?
>
> Thanks,
> //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.

Bug#841050: MySQL 5.5.53 update for Debian wheezy?

[Bálint Réczey]

Hi Lars,

2016-10-27 18:07 GMT+02:00 Lars Tangvald :
>
> - bal...@balintreczey.hu wrote:
>
>> Hi Lars,
>>
>> I noticed you have prepared the MySQL update for wheezy in git:
>> https://anonscm.debian.org/cgit/pkg-mysql/mysql-5.5.git/log/?id=refs/heads/debian/wheezy
>>
>> Would you like the LTS Team to perform the upload and issue the DLA
>> like in the previous case?
>>
>> Thanks,
>> Balint
>>   on behalf of the Debian LTS team.
>
> Hi,
>
> I could have sworn I sent the debdiffs in to the security bug we filed for 
> the update (#841050), but they're not there, so guess not. Sorry about that.
> Yes, please do the update. I've also attached the debdiffs again here.
> As noted in the bug discussion, CVE-2016-6662 is listed as fixed in 5.5.53 
> because an issue was found with the fix for another platform. For Linux it 
> was fixed in 5.5.52
> Also note the behavior change to restrict import and export operations to 
> /var/lib/mysql-files (unless users configure it differently).

Thank you.

I have added mysql to out TODO list and someone from the team will
update it soon.

Cheers,
Balint