Bug#1071384: RFS: udftools/2.3-2 [RC] -- tools for UDF filesystems and DVD/CD-R(W) drives
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "udftools": * Package name : udftools Version : 2.3-2 Upstream contact : Pali Rohár * URL : https://github.com/pali/udftools * License : GPL-2+ * Vcs : [fill in URL of packaging vcs] Section : otherosfs The source builds the following binary packages: udftools - tools for UDF filesystems and DVD/CD-R(W) drives To access further information about this package, please visit the following URL: https://mentors.debian.net/package/udftools/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/u/udftools/udftools_2.3-2.dsc Changes since the last upload: udftools (2.3-2) unstable; urgency=medium . * Change Build-Depends from udev to systemd-dev (Closes: #1060477) Regards, -- Pali Rohár
Bug#879723: can get stuck in state INSANE and stop responding
On Saturday 16 December 2023 11:26:14 Pali Rohár wrote: > On Friday 15 December 2023 21:53:08 Chris Hofstaedtler wrote: > > On Wed, Oct 25, 2017 at 12:01:32AM -0400, Joey Hess wrote: > > > If the netplug script fails to bring up the interface, netplug can > > > put it into state INSANE. Unfortunately, it never leaves that state, > > > preventing netplug from responding to further link changes. > > [..] > > > > A user on #Debian today reported something similar, on their > > downstream distro vyos: https://vyos.dev/T5686 > > > > I'm leaving this here, just in case somebody has any use for this > > info. > > Thanks for reminder, I will look at it during next weeks. I have looked at the whole netplugd state machine and transitions between states. I identified more bugs than the one described in this issue report. I have prepared fixes for all of them. Joey, would you be interested in testing netplugd fixes? Btw, I was trying to contact vyos people but they are not interested in any discussion about netplugd, so I see no reason to link vyos issues.
Bug#1058767: netplug: unmaintained
On Wednesday 20 December 2023 22:32:38 Chris Hofstaedtler wrote: > Hi, > > * Pali Rohár [231216 11:35]: > > On Friday 15 December 2023 21:56:01 Chris Hofstaedtler wrote: > > Hello, I talked with the author of the netplug (Bryan O'Sullivan) and I > > got permission to continue working on this project. I can continue > > maintaining this package on Debian, so please let me know what is needed > > to fix for preventing its removal. Thanks. > > Well, the immediate thing to do is: close this bug. Ok, I have closed it. > But the more important thing: actually maintain the package, > including ongoing quality work in the packaging, responding > to/fixing bugs, etc. > > If I were in your shoes, I'd make sure to know if/where the users of > this package are. If all users are using vyos, then maybe its better > maintained as part of vyos, and removed from Debian. > Debian has a number of other things that can react to network > events, some of those have active upstreams ... > > Best, > Chris I'm going to ask vyos what they think about it and decide next steps then. Thanks.
Bug#1058767: netplug: unmaintained
On Friday 15 December 2023 21:56:01 Chris Hofstaedtler wrote: > Source: netplug > Version: 1.2.9.2-3.2 > Severity: serious > > I'm filing this to get netplug removed from testing, with the goal > of removing it from unstable later, and before that happens, anyone > who wants to actually maintain this package can speak up. > > As demonstrated today, having packages in stable that end up used in > downstream distros, and at the same time being completely > unmaintained in Debian for ~7 years is bad for everybody. > > If you like to keep netplug in Debian, please start maintaining it > and then close this bug. > > Otherwise I'll also file an RM bug for unstable later in this > development cycle. > > Chris Hello, I talked with the author of the netplug (Bryan O'Sullivan) and I got permission to continue working on this project. I can continue maintaining this package on Debian, so please let me know what is needed to fix for preventing its removal. Thanks.
Bug#879723: can get stuck in state INSANE and stop responding
On Friday 15 December 2023 21:53:08 Chris Hofstaedtler wrote: > On Wed, Oct 25, 2017 at 12:01:32AM -0400, Joey Hess wrote: > > If the netplug script fails to bring up the interface, netplug can > > put it into state INSANE. Unfortunately, it never leaves that state, > > preventing netplug from responding to further link changes. > [..] > > A user on #Debian today reported something similar, on their > downstream distro vyos: https://vyos.dev/T5686 > > I'm leaving this here, just in case somebody has any use for this > info. Thanks for reminder, I will look at it during next weeks.
Bug#775962: udftools: No means of repairing a UDF filesystem i.e. no fsck.udf
On Sunday 10 December 2023 01:29:42 Christoph Anton Mitterer wrote: > On Sun, 2023-12-10 at 01:23 +0100, Pali Rohár wrote: > > There is also beta version of udffsck for udftools: > > https://github.com/pali/udftools/pull/7 > > Ah nice. Is that going to be released/packaged? > > Thanks, > Chris It is not finished yet for production usage.
Bug#775962: udftools: No means of repairing a UDF filesystem i.e. no fsck.udf
There is also beta version of udffsck for udftools: https://github.com/pali/udftools/pull/7
Bug#983312: RFS: udfclient/0.8.11-2 [RC] -- userland implementation of the UDF filesystem
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "udfclient": * Package name: udfclient Version : 0.8.11-2 Upstream Author : Reinoud Zandijk * URL : http://www.13thmonkey.org/udfclient/ * License : BSD-4-Clause, BSD-3-Clause, Clarified-Artistic, free-use, BSD-2-Clause Section : otherosfs It builds those binary packages: udfclient - userland implementation of the UDF filesystem To access further information about this package, please visit the following URL: https://mentors.debian.net/package/udfclient/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/u/udfclient/udfclient_0.8.11-2.dsc Changes since the last upload: udfclient (0.8.11-2) unstable; urgency=medium . * Call autoconf in debian/rules to fix compile issues (Closes: #982717) (Patch by Dennis Filder) Regards, -- Pali Rohár
Bug#982717: udfclient: FTBFS: bmake[1]: no target to make.
On Monday 15 February 2021 18:11:16 Dennis Filder wrote: > The current bmake backend for debhelper no longer inherits from the > autoconf backend. The attached patch devises an override that > restores the old behaviour, and I've verified that it works. Hello Dennis! Thank you for investigation and the patch. Will you update also the package? Or should I do it? Note that I do not have Debian Developer permissions so I can update new version of package only to mentors server (which takes a long to appear in Debian archive...). -- Pali Rohár pali.ro...@gmail.com
Bug#982717: udfclient: FTBFS: bmake[1]: no target to make.
On Saturday 13 February 2021 18:32:17 Lucas Nussbaum wrote:
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
> Relevant part (hopefully):
> > debian/rules build
> > dh build --buildsystem=bmake
> >dh_update_autotools_config -O--buildsystem=bmake
> > install -d debian/.debhelper/bucket/files
> > cp -an --reflink=auto config.guess
> > debian/.debhelper/bucket/files/420138cb266d63505ec54f169a34e1cc9aba80dc20a1eeac76b7bf5c9e5ff74e.tmp
> > mv
> > debian/.debhelper/bucket/files/420138cb266d63505ec54f169a34e1cc9aba80dc20a1eeac76b7bf5c9e5ff74e.tmp
> >
> > debian/.debhelper/bucket/files/420138cb266d63505ec54f169a34e1cc9aba80dc20a1eeac76b7bf5c9e5ff74e
> > cp -f /usr/share/misc/config.guess ./config.guess
> > cp -an --reflink=auto config.sub
> > debian/.debhelper/bucket/files/6585881331b69439aec3e94b9167983f9c3609b1b5dca9fa77d6941a3f79ccc2.tmp
> > mv
> > debian/.debhelper/bucket/files/6585881331b69439aec3e94b9167983f9c3609b1b5dca9fa77d6941a3f79ccc2.tmp
> >
> > debian/.debhelper/bucket/files/6585881331b69439aec3e94b9167983f9c3609b1b5dca9fa77d6941a3f79ccc2
> > cp -f /usr/share/misc/config.sub ./config.sub
> >dh_autoreconf -O--buildsystem=bmake
> > find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path '*/.hg/*'
> > -o -path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a -type f
> > -exec md5sum {} + -o -type l -printf "symlink %p
> > " > debian/autoreconf.before
> > grep -q ^XDT_ configure.ac
> > autoreconf -f -i
> > find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path '*/.hg/*'
> > -o -path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a -type f
> > -exec md5sum {} + -o -type l -printf "symlink %p
> > " > debian/autoreconf.after
> >dh_auto_configure -O--buildsystem=bmake
> >dh_auto_build -O--buildsystem=bmake
> > bmake
> > bmake[1]: no target to make.
> >
> > bmake[1]: stopped in /<>
> > dh_auto_build: error: bmake returned exit code 2
Hello Lucas!
This looks like a bug in dh_auto_configure. dh_autoreconf correctly
started autoreconf but dh_auto_configure did not start ./configure.
So ./configure did not generated Makefile and bmake complained.
> > make: *** [debian/rules:8: build] Error 25
>
> The full build log is available from:
>http://qa-logs.debian.net/2021/02/13/udfclient_0.8.11-1_unstable.log
>
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
>
> If you reassign this bug to another package, please marking it as
> 'affects'-ing
> this package. See https://www.debian.org/Bugs/server-control#affects
>
> If you fail to reproduce this, please provide a build log and diff it with me
> so that we can identify if something relevant changed in the meantime.
>
> About the archive rebuild: The rebuild was done on EC2 VM instances from
> Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> failed build was retried once to eliminate random failures.
--
Pali Rohár
pali.ro...@gmail.com
Bug#961462: closed by Debian FTP Masters (reply to Chris Boot ) (Bug#961462: fixed in ppp 2.4.9-1+1)
On Friday 08 January 2021 15:32:43 Chris Boot wrote: > On 08/01/2021 11:26, Pali Rohár wrote: > > I would not say that this issue as described in the first post is fixed. > > > > pppoe-discovery with -U option is in Debian Buster still broken. > > As I understand it the issue is fixed in the version I uploaded the other > day, is that not the case? It is indeed not fixed in Buster, but the bug > will be closed with a particular version so it will show as unfixed in > Buster (but should be fine for Bullseye). Now I have tested pppoe-discovery binary from ppp_2.4.9-1+1_arm64.deb package and it is working with with -U option. Version from package ppp_2.4.7-2+4.1+deb10u1_arm64.deb which is in Buster is broken and does not work. -- Pali Rohár pali.ro...@gmail.com
Bug#961462: closed by Debian FTP Masters (reply to Chris Boot ) (Bug#961462: fixed in ppp 2.4.9-1+1)
I would not say that this issue as described in the first post is fixed. pppoe-discovery with -U option is in Debian Buster still broken.
Bug#979249: RFS: udftools/2.3-1 -- tools for UDF filesystems and DVD/CD-R(W) drives
On Tuesday 05 January 2021 01:40:09 Paul Wise wrote: > On Mon, Jan 4, 2021 at 5:21 PM Pali Rohár wrote: > > >* New upstream release (Closes: #511059, #288455) > > Please put these bug closings on separate lines and include some > descriptive information. > > You may like to review the best practices for Debian changelog files: > > https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.en.html#best-practices-for-debian-changelog > https://www.debian.org/doc/debian-policy/ch-source.html#debian-changelog-debian-changelog Thanks! Now I updated package with fixed changelog file.
Bug#979265: RFS: igmpproxy/0.3-1 -- IGMP multicast routing daemon
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "igmpproxy": * Package name: igmpproxy Version : 0.3-1 Upstream Author : Pali Rohár * URL : https://github.com/pali/igmpproxy * License : BSD-3-clause and GPL-2+ Section : net It builds those binary packages: igmpproxy - IGMP multicast routing daemon To access further information about this package, please visit the following URL: https://mentors.debian.net/package/igmpproxy/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/i/igmpproxy/igmpproxy_0.3-1.dsc Changes since the last upload: igmpproxy (0.3-1) unstable; urgency=medium . * New upstream release Regards, -- Pali Rohár
Bug#979249: RFS: udftools/2.3-1 -- tools for UDF filesystems and DVD/CD-R(W) drives
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "udftools": * Package name: udftools Version : 2.3-1 Upstream Author : Pali Rohár * URL : https://github.com/pali/udftools * License : GPL-2+ Section : otherosfs It builds those binary packages: udftools - tools for UDF filesystems and DVD/CD-R(W) drives To access further information about this package, please visit the following URL: https://mentors.debian.net/package/udftools/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/u/udftools/udftools_2.3-1.dsc Changes since the last upload: udftools (2.3-1) unstable; urgency=medium . * New upstream release (Closes: #511059, #288455) Regards, -- Pali Rohár
Bug#972387: [Info-mtools] mtools does not work in Turkish locale
Hello! On Thursday 22 October 2020 16:55:04 Chris Lamb wrote: > $ LC_CTYPE=tr_TR.UTF-8 mtools > Syntax error at line 5 for drive A: column 9 in file /etc/mtools.conf: > unrecognized keyword > > $ echo $? > 1 > ... > As I describe in my followup to that bug, I can confirm that this is > indeed locale issue, as commenting out the setlocale(3) call at the > top of the "main" entry point fixes this issue. > > The following "patch" against mtools.c also ""works"" for me: > > +#ifdef HAVE_SETLOCALE > + char *old_locale = setlocale(LC_ALL, NULL); > + setlocale(LC_ALL, "C"); > + read_config(); > + setlocale(LC_ALL, old_locale); > +#else > read_config(); > +#endif > > > .. but this is obviously not right, as it would mean that genuine > syntax errors printed in read_config() would not be translated into, > well, Turkish. Can't seem to get a "C" locale version of toupper(3) to > work right this second, and am assuming you folks will have a cleaner > solution anyway, hence forwarding this to you. IIRC toupper() for lowercase i with dot in Turkish locale returns uppercase I with dot. In English or C locale it is uppercase I without dot. I guess that for case-insensitive parsing of config options (which are written in English) should be used toupper() variant in C locale. There is a standard POSIX function toupper_l() which takes as a second argument locale. So I think that for reading config file it should be used function toupper_l() with C locale instead of locale-dependent toupper() function. -- Pali Rohár pali.ro...@gmail.com
Bug#966484: RFS: udfclient/0.8.11-1 [RC] -- userland implementation of the UDF filesystem
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "udfclient": * Package name: udfclient Version : 0.8.11-1 Upstream Author : Reinoud Zandijk * URL : http://www.13thmonkey.org/udfclient/ * License : free-use, Clarified-Artistic, BSD-2-Clause, BSD-4-Clause, BSD-3-Clause Section : otherosfs It builds those binary packages: udfclient - userland implementation of the UDF filesystem To access further information about this package, please visit the following URL: https://mentors.debian.net/package/udfclient/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/u/udfclient/udfclient_0.8.11-1.dsc Changes since the last upload: udfclient (0.8.11-1) unstable; urgency=medium . * New upstream release - Minor release fixing compilation errors on gcc 10 (Closes: #957893) - Also corrected some minor spelling mistakes Regards, -- Pali Rohár
Bug#922154: ITP: libldac -- A lossy audio codec for Bluetooth connections
On Sunday 10 May 2020 10:34:52 Andrej Shadura wrote: > On Fri, May 08, 2020 at 12:51:10PM +0200, Pali Rohár wrote: > > On Friday 08 May 2020 12:44:27 Andrej Shadura wrote: > > > Thanks but it's already done, on Salsa and in NEW :) > > > Ou, I have not spotted it. Week ago it was not there. > > True. I recalled I filed the ITP this week when I was thinking about > re-routing audio cables in my room or maybe getting rid of them altogether > :D > > > I looked at it and I see that you are not using direct upstream sources. > > Is there any reason for it? I guess that packaging should be done from > > upstream project (in this case Android). > > Well, it was a tiny bit easier, and also I was under an (incorrect) > impression libldac was a part of a monorepo, but in fact it is in a > separate Git repository. > > I think I will update libldac to use the upstream source directly and also > use bits of your patch, thanks very much for it! Ok! Feel free to reuse parts of my patch. -- Pali Rohár pali.ro...@gmail.com
Bug#961462: ppp: Buster pppoe-discovery -U is broken
Package: ppp Version: 2.4.7-2+4.1+deb10u1 Control: subscribe -1 Hello! pppoe-discovery with -U option (Use Host-Unique to allow multiple PPPoE sessions) is in Debian Buster currently broken. Its output on PPPoE network via eth0 interface is just: # pppoe-discovery -U -I eth0 Timeout waiting for PADO packets But tcpdump on eth0 interface confirms that PADO packets were received: # tcpdump -n -p - -i eth0 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes ... 21:04:23.835174 PPPoE PADI [Service-Name] [Host-Uniq 0x0DCC] 21:04:23.853135 PPPoE PADO [Service-Name] [AC-Name "ke-pols-bras-1"] [Host-Uniq 0x0DCC] [AC-Cookie 0x37591CD0FA31C63720E0CF08D4340C61] 21:04:23.853396 PPPoE PADO [Service-Name] [AC-Name "po-maue-bras-1"] [Host-Uniq 0x0DCC] [AC-Cookie 0xEC3CB571EEF00E875E46F71059CA58F9] 21:04:26.853685 PPPoE PADO [Service-Name] [AC-Name "ba-jros-bras-3"] [Host-Uniq 0x0DCC] [AC-Cookie 0x7D802A631A6DC4F1F3C70737DA71678A] 21:04:31.858854 PPPoE PADI [Service-Name] [Host-Uniq 0x0DCC] 21:04:31.868204 PPPoE PADO [Service-Name] [AC-Name "ke-pols-bras-1"] [Host-Uniq 0x0DCC] [AC-Cookie 0x37591CD0FA31C63720E0CF08D4340C61] 21:04:31.868358 PPPoE PADO [Service-Name] [AC-Name "po-maue-bras-1"] [Host-Uniq 0x0DCC] [AC-Cookie 0xEC3CB571EEF00E875E46F71059CA58F9] 21:04:34.948714 PPPoE PADO [Service-Name] [AC-Name "ba-jros-bras-3"] [Host-Uniq 0x0DCC] [AC-Cookie 0x7D802A631A6DC4F1F3C70737DA71678A] 21:04:39.953858 PPPoE PADI [Service-Name] [Host-Uniq 0x0DCC] 21:04:39.962591 PPPoE PADO [Service-Name] [AC-Name "ke-pols-bras-1"] [Host-Uniq 0x0DCC] [AC-Cookie 0x37591CD0FA31C63720E0CF08D4340C61] 21:04:39.962649 PPPoE PADO [Service-Name] [AC-Name "po-maue-bras-1"] [Host-Uniq 0x0DCC] [AC-Cookie 0xEC3CB571EEF00E875E46F71059CA58F9] 21:04:43.048720 PPPoE PADO [Service-Name] [AC-Name "ba-jros-bras-3"] [Host-Uniq 0x0DCC] [AC-Cookie 0x7D802A631A6DC4F1F3C70737DA71678A] ... Without -U option pppoe-discovery is working fine: # pppoe-discovery -I eth0 Access-Concentrator: ke-pols-bras-1 Got a cookie: 37 59 1c d0 fa 31 c6 37 20 e0 cf 08 d4 34 0c 61 -- AC-Ethernet-Address: 24:21:24:e9:be:3f Access-Concentrator: po-maue-bras-1 Got a cookie: ec 3c b5 71 ee f0 0e 87 5e 46 f7 10 59 ca 58 f9 -- AC-Ethernet-Address: 20:e0:9c:3e:98:01 Access-Concentrator: ba-jros-bras-3 Got a cookie: 7d 80 2a 63 1a 6d c4 f1 f3 c7 07 37 da 71 67 8a -- AC-Ethernet-Address: 24:21:24:b9:76:3f It looks like that ppp package in Debian Buster has custom patch which implements -U option [1] which differs from upstream implementation of -U option [2] [3]. I compiled pppoe-discovery from upstream ppp project with upstream -U patch [3] and this is working fine. Output is: # ./pppd/plugins/rp-pppoe/pppoe-discovery -U -I eth0 Access-Concentrator: ke-pols-bras-1 Got a cookie: 37 59 1c d0 fa 31 c6 37 20 e0 cf 08 d4 34 0c 61 AC-Ethernet-Address: 24:21:24:e9:be:3f -- Access-Concentrator: po-maue-bras-1 Got a cookie: ec 3c b5 71 ee f0 0e 87 5e 46 f7 10 59 ca 58 f9 AC-Ethernet-Address: 20:e0:9c:3e:98:01 -- Access-Concentrator: ba-jros-bras-3 Got a cookie: 7d 80 2a 63 1a 6d c4 f1 f3 c7 07 37 da 71 67 8a AC-Ethernet-Address: 24:21:24:b9:76:3f -- So it means that Debian's custom patch in Buster [1] is broken. Please replace this broken Debian patch by working upstream patch [3]. To make pppoe-discovery from ppp package in Debian working. [1] - https://sources.debian.org/patches/ppp/2.4.7-2+4.1+deb10u1/pr-28-pppoe-custom-host-uniq-tag.patch/ [2] - https://github.com/paulusmack/ppp/pull/97 [3] - https://github.com/paulusmack/ppp/commit/c9d9dbfb8459b528ab56bd1cf0c41460801bbfdf -- Pali Rohár pali.ro...@gmail.com
Bug#922154: ITP: libldac -- A lossy audio codec for Bluetooth connections
On Friday 08 May 2020 12:44:27 Andrej Shadura wrote: > Thanks but it's already done, on Salsa and in NEW :) Ou, I have not spotted it. Week ago it was not there. I looked at it and I see that you are not using direct upstream sources. Is there any reason for it? I guess that packaging should be done from upstream project (in this case Android). -- Pali Rohár pali.ro...@gmail.com
Bug#922154: ITP: libldac -- A lossy audio codec for Bluetooth connections
On Tuesday 12 February 2019 18:11:52 Andrej Shadura wrote:
> * Package name: libldac
> Version : 2.0.2
> Upstream Author : Sony Corporation
> * URL : https://android.googlesource.com/platform/external/libldac
> https://github.com/EHfive/ldacBT
> * License : Apache 2.0
> Programming Lang: C
> Description : A lossy audio codec for Bluetooth connections
>
> LDAC is an audio coding technology developed by Sony.
> It enables the transmission of High-Resolution Audio content,
> even over a Bluetooth connection.
>
> This library comes AOSP, having been released by Sony.
Hello! I tried to prepare Debian packaging for this library. Diff for
debian files is attached. There are two problems which I do not know how
to easily fix:
1) Upstream is stored only in git repository, there are no release tarballs
2) Upstream uses Android build system (Android.bp) which Debian does not
support and moreover this library (in Android.bp) has specified that
is built only for ARM architecture.
In attached debian files I fixed second problem by building library
directly in debian/rules file. It is just one 'gcc' call (or better
$(CC) call with passing all flags) so I think it does not make sense to
emulate Android.bp or create a new build system when it is such simple.
And library can be compiled also on x86, it is plain C so there is no
reason to not support non-ARM architectures. Android probably limited it
for ARM as Android in majority runs only on ARM... But I do not know
what to do with first problem.
--
Pali Rohár
pali.ro...@gmail.com
diff -Nurp debian/control debian/control
--- debian/control 1970-01-01 01:00:00.0 +0100
+++ debian/control 2020-05-08 11:08:45.542150125 +0200
@@ -0,0 +1,31 @@
+Source: libldac
+Maintainer: Name
+Section: libs
+Priority: optional
+Build-Depends: debhelper-compat (= 12)
+Standards-Version: 4.5.0
+Homepage: https://android.googlesource.com/platform/external/libldac
+Rules-Requires-Root: no
+
+Package: libldac2
+Architecture: any
+Multi-Arch: same
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Sony LDAC audio codec, shared libraries
+ LDAC is an audio coding technology developed by Sony that enables the
+ transmission of High Resolution (Hi-Res) Audio content even over a
+ Bluetooth connection.
+ .
+ This package contains the shared libraries.
+
+Package: libldac-dev
+Architecture: any
+Multi-Arch: same
+Section: libdevel
+Depends: libldac2 (= ${binary:Version}), ${misc:Depends}
+Description: Sony LDAC audio codec, development headers
+ LDAC is an audio coding technology developed by Sony that enables the
+ transmission of High Resolution (Hi-Res) Audio content even over a
+ Bluetooth connection.
+ .
+ This package contains the development headers.
diff -Nurp debian/copyright debian/copyright
--- debian/copyright 1970-01-01 01:00:00.0 +0100
+++ debian/copyright 2020-05-08 11:08:45.542150125 +0200
@@ -0,0 +1,29 @@
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Upstream-Name: libldac
+Upstream-Contact: jeffbai...@google.com, rtenn...@google.com
+Copyright: 2003-2017, Sony Corporation
+Source: https://android.googlesource.com/platform/external/libldac
+License: Apache-2.0
+
+Files: *
+Copyright: 2003-2017, Sony Corporation
+License: Apache-2.0
+
+Files: debian/*
+License: Apache-2.0
+
+License: Apache-2.0
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+ .
+ https://www.apache.org/licenses/LICENSE-2.0
+ .
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ .
+ On Debian systems, the complete text of the Apache version 2.0 license
+ can be found in "/usr/share/common-licenses/Apache-2.0".
diff -Nurp debian/changelog debian/changelog
--- debian/changelog 1970-01-01 01:00:00.0 +0100
+++ debian/changelog 2020-05-08 11:08:45.542150125 +0200
@@ -0,0 +1,5 @@
+libldac (2.0.2-1) unstable; urgency=low
+
+ * Initial release (Closes: #922154)
+
+ -- Name Fri, 08 May 2020 11:04:14 +0200
diff -Nurp debian/libldac-dev.install debian/libldac-dev.install
--- debian/libldac-dev.install 1970-01-01 01:00:00.0 +0100
+++ debian/libldac-dev.install 2020-05-08 11:08:45.542150125 +0200
@@ -0,0 +1,2 @@
+usr/include/*
+usr/lib/*/lib*.so
diff -Nurp debian/libldac2.install debian/libldac2.install
--- debian/libldac2.install 1970-01-01 01:00:00.0 +0100
+++ debian/libldac2.install 2020-05-08 11:08:45.542150125 +0200
@@ -0,0 +1 @@
+usr/lib/*/lib*.so.*
diff -Nurp debian/libldac2.symbols debian/libldac2.symbols
--
Bug#954189: Backport to buster?
On Monday 27 April 2020 11:15:30 Paul van Tilburg wrote: > Hi! > > This bug report was originally about buster and in my opinion a > backport is necessary (stretch also had one). I reckon mostly servers > use Let's Encrypt, and they mostly run Debian buster/stable. > Given that upstream doesn't seem to change to that much, is that a > possibility? > > I didn't reopen this bug report and will leave that to the maintainer's > discretion, however, I did want to mention this. Yes, I reported this bug to Debian Buster, but in Buster release this bug is not still fixed. So I think it should stay open. -- Pali Rohár pali.ro...@gmail.com
Bug#954189: acmetool: Buster acmetool stops working in June 1, 2020
Package: acmetool Version: 0.0.62-3+b11 Severity: grave Hello! I'm using Debian Buster 10.3 on servers with acmetool for updating Let's encrypt certificates and I got following email from letsencrypt: According to our records, the software client you're using to get Let's Encrypt TLS/SSL certificates issued or renewed at least one HTTPS certificate in the past two weeks using the ACMEv1 protocol. Here are the details of one recent ACMEv1 request from each of your account(s): ... User agent: acmetool acmeapi Go-http-client/1.1 linux/amd64 ... Beginning June 1, 2020, we will stop allowing new domains to validate using the ACMEv1 protocol. You should upgrade to an ACMEv2 compatible client before then, or certificate issuance will fail. For most people, simply upgrading to the latest version of your existing client will suffice. You can view the client list at: https://letsencrypt.org/docs/client-options/ It means that acmetool package which is in Debian Buster stops working in June 1, 2020. So please update this package in Debian Buster repository to a new version which supports ACMEv2 protocol. Also I would suggest to put acmetool version number into User agent string so it could be easier to identify exact version which is used. I'm marking this issue with severity grave as it matches that description "makes the package in question unusable", which really happens in two months and few days. -- Pali Rohár pali.ro...@gmail.com
Bug#949665: mtools: please support operating on large files
On Friday 24 January 2020 12:55:40 Helmut Grohne wrote: > Control: tags -1 + upstream > > Hi Chris, > > On Thu, Jan 23, 2020 at 06:08:47PM +0100, Chris Lamb wrote: > > forwarded 949665 > > https://lists.gnu.org/archive/html/info-mtools/2020-01/msg0.html > > Duly noted; I had assumed this to be the case; I won't hold you to your > > initial thoughts! > > > > Based on your message, I've forwarded this all "upstream" here: > > > > https://lists.gnu.org/archive/html/info-mtools/2020-01/msg0.html > > Thank you. I wasn't aware of AC_SYS_LARGEFILE. Thanks to Pali Rohár for > pointing this out. I confirm that after adding it to configure.in, my > proposed testcase succeeds on armhf. (It also is nice that I can just > cross build mtools from amd64 out of the box to test for this.) Please > add AC_SYS_LARGEFILE to configure.in. > > Helmut Hello! Another option is to put into debian/rules following line: export DEB_BUILD_MAINT_OPTIONS = future=+lfs This should not require to modify upstream source code, so it could be more cleaner solution until upstream adds AC_SYS_LARGEFILE m4 macro into configure.in file. -- Pali Rohár pali.ro...@gmail.com
Bug#950120: RFS: udftools/2.2-1 -- tools for UDF filesystems and DVD/CD-R(W) drives
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "udftools" * Package name: udftools Version : 2.2-1 Upstream Author : Pali Rohár * URL : https://github.com/pali/udftools * License : GPL-2+ * Vcs : None Section : otherosfs It builds those binary packages: udftools - tools for UDF filesystems and DVD/CD-R(W) drives To access further information about this package, please visit the following URL: https://mentors.debian.net/package/udftools Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/u/udftools/udftools_2.2-1.dsc Changes since the last upload: * New upstream release Regards, -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#949665: [Info-mtools] Error when operating on large files
On Thursday 23 January 2020 17:01:00 Chris Lamb wrote: > [please retain all CCs upon replying, I am not subscribed to this list] > > Hi, > > I'm the maintainer of the "mtools" package in Debian. The following > bug report was just filed there which I will quote in full, but it can > also be viewed here: > > https://bugs.debian.org/949665 > > > Running e.g. mdir -i $SOMEFILE@@$LARGEOFFSET fails when the offset > > exceeds around 2GB. The error message is: > > > > | seek: Invalid argument > > | init :: could not read boot sector > > | Cannot initialize '::' > > > > Using strace one can see that mtools tries to seek the image to a > > negative offset that results from treating the desired offset as a > > signed 32bit number. > […] > > Most likely, it can be fixed by adding -D_FILE_OFFSET_BITS=64 to the > > CFLAGS. > > I then briefly asked whether this would be suitable for inclusion > upstream, to which the reporter was in agreement. Please see https:// > bugs.debian.org/949665#15 for more on this, including the sketchings > of a patch. Hello! For handling problems with large files, autoconf has m4 macro: AC_SYS_LARGEFILE It automatically checks if some special compiler flags are needed for handling large files and if yes, this macro automatically modifies compiler flags. So I think adding AC_SYS_LARGEFILE into configure.ac should fix this problem for all platforms (supported by autoconf). -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#919188: [sslh] Re: severity of 919188 is critical
Hi! On Monday 17 June 2019 16:56:49 Axel Beckert wrote: > Control: tag -1 - moreinfo + patch > > Hi Pali, > > thanks for the quick response! Let's try to figure out the difference > between our configurations to find the culrprit. > > Pali Rohár wrote: > > > Pali Rohár wrote: > > > > severity 919188 critical > > > > > > Why? You neither explained that it breaks the whole system nor that it > > > causes other, unrelated packages to break nor that it causes serious > > > data-loss. > > > > > > Please check https://www.debian.org/Bugs/Developer#severities and > > > explain why you think that the severity you've chosen fits this bug > > > report. > > > > Hi! The reason is that it breaks boot process. > > Just to make this clear: > > It actually doesn't finish to boot and other services which would > start after sslh are not starting at all, correct? Currently seems that everything was started. But I do not know if it is because of parallelism or it is intended due to to forking of startpar. Or if there is race condition... Such bugs which affects boot process, where is involved parallelism or forking are annoying; plus they needs full reboot of machine, etc... > > startpar is still running and sslh stdout output is going to tty1 > > where /dev/console points. > > The latter is definitely annoying, but I wouldn't consider that part > "breaking the boot process". > > JFTR: For me, the log messages of sslh go to either /var/log/user.log > (if started via inetd) or /var/log/auth.log (if started as standalone > daemon via init script). > > > > Addtionally I can't reproduce this bug no matter which variant I'm > > > trying. And I'm running sslh under sysvinit on Debian Testing since > > > 2012 (in standalone and single-thread mode): > > > > Strange, it happens for me on all Debian servers where sslh is > > installed and in use. Also exactly same problem is on small Raspberry PI > > installation. And proposed fix fixes it... > > Ah right, you've added a patch. Forgot to tag the bug report as > "patch". Done now. > > (I also checked that I don't have a similar patch like you proposed in > place. That would have been embarrassing. But I haven't. :-) > > > Some maybe configuration of something other takes effect on it too? > > I suspect so. > > > For me it is 100% reproducible, no race condition or randomness. > > Same here, just the other way round. ;-) > > > > So please also show your sslh entry in /etc/inetd.conf and your > > > /etc/default/sslh. > [...] > > $ cat /etc/default/sslh > > # Default options for sslh initscript > > # sourced by /etc/init.d/sslh > > > > # Disabled by default, to force yourself > > # to read the configuration: > > # - /usr/share/doc/sslh/README.Debian (quick start) > > # - /usr/share/doc/sslh/README, at "Configuration" section > > # - sslh(8) via "man sslh" for more configuration details. > > # Once configuration ready, you *must* set RUN to yes here > > # and try to start sslh (standalone mode only) > > > > RUN=yes > > > > # binary to use: forked (sslh) or single-thread (sslh-select) version > > # systemd users: don't forget to modify /lib/systemd/system/sslh.service > > DAEMON=/usr/sbin/sslh > > > > DAEMON_OPTS="--user sslh --transparent --listen MYDOMAIN:443 --ssh > > localhost:22 --http localhost:80 --ssl localhost:443 --pidfile > > /var/run/sslh/sslh.pid" > > Here's my working configuration for comparison: > > --- > $ cat /etc/default/sslh > # Default options for sslh initscript > # sourced by /etc/init.d/sslh > > # Disabled by default, to force yourself > # to read the configuration: > # - /usr/share/doc/sslh/README.Debian (quick start) > # - /usr/share/doc/sslh/README, at "Configuration" section > # - sslh(8) via "man sslh" for more configuration details. > # Once configuration ready, you *must* set RUN to yes here > # and try to start sslh (standalone mode only) > > RUN=yes > > # binary to use: forked (sslh) or single-thread (sslh-select) version > DAEMON=/usr/sbin/sslh-select > > DAEMON_OPTS="--user sslh --listen 0.0.0.0:443 --ssh 127.0.0.1:22 --ssl > 127.0.0.1:442 --pidfile /var/run/sslh/sslh.pid" > --- > > I already tested that /usr/sbin/sslh-select (single-thread) vs > /usr/sbin/sslh (forking) doesn't make a dif
Bug#919188: severity of 919188 is critical
On Monday 17 June 2019 04:34:38 Axel Beckert wrote: > Control: tag -1 + unreproducible moreinfo > Control: severity -1 important > > Hi Pali, > > Pali Rohár wrote: > > severity 919188 critical > > Why? You neither explained that it breaks the whole system nor that it > causes other, unrelated packages to break nor that it causes serious > data-loss. > > Please check https://www.debian.org/Bugs/Developer#severities and > explain why you think that the severity you've chosen fits this bug > report. Hi! The reason is that it breaks boot process. startpar is still running and sslh stdout output is going to tty1 where /dev/console points. > I'm neither the package maintainer nor a release team member (just a > happy sslh user), but this bug is at most "grave" even according to > your description. > > Addtionally I can't reproduce this bug no matter which variant I'm > trying. And I'm running sslh under sysvinit on Debian Testing since > 2012 (in standalone and single-thread mode): Strange, it happens for me on all Debian servers where sslh is installed and in use. Also exactly same problem is on small Raspberry PI installation. And proposed fix fixes it... Some maybe configuration of something other takes effect on it too? For me it is 100% reproducible, no race condition or randomness. > # ps auxf | fgrep sslh > root 24116 0.0 0.0 8472 908 pts/1S+ 03:08 0:00 | \_ grep > -F sslh > sslh 12185 0.0 0.2 14004 2648 ?Ss May07 2:49 > /usr/sbin/sslh-select --user sslh --listen 0.0.0.0 443 --ssh 127.0.0.1 22 > --ssl 127.0.0.1 442 --pidfile /var/run/sslh/sslh.pid > # dpkg -l sysvinit-core startpar > 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 Architecture Description > +++-==---= > ii startpar 0.61-1 amd64run processes in parallel and > multiplex their output > ii sysvinit-core 2.93-8 amd64System-V-like init utilities > # lsb_release -a > No LSB modules are available. > Distributor ID: Debian > Description:Debian GNU/Linux 10 (buster) > Release:10 > Codename: buster > # uptime > 03:13:44 up 94 days, 2:26, 2 users, load average: 0,03, 0,23, 0,65 > # > > The above is from before a reboot, but I just rebooted and there's > still only one sslh-select process. Tried "service sslh stop" and > "service sslh start" as well as rebooting. No difference, no issue. I > also tried using the forked variant instead of the single-thread I > used so far. But still, neither stopping and starting nor rebooting > showed a hanging startpar. Here's after the switch to the forked > version and two reboots: > > # ps auxf | fgrep sslh > root 2791 0.0 0.0 8476 908 pts/1S+ 03:49 0:00 > \_ grep -F sslh > sslh 2515 0.0 0.1 4760 1660 ?Ss 03:47 0:00 > /usr/sbin/sslh --user sslh --listen 0.0.0.0 443 --ssh 127.0.0.1 22 --ssl > 127.0.0.1 442 --pidfile /var/run/sslh/sslh.pid > sslh 2518 0.0 0.0 4760 176 ?S03:47 0:00 \_ > /usr/sbin/sslh --user sslh --listen 0.0.0.0 443 --ssh 127.0.0.1 22 --ssl > 127.0.0.1 442 --pidfile /var/run/sslh/sslh.pid > # > > Hence tagging it as unreproducible and downgrading the severity: > > Since this issue doesn't even "rendering it completely unusable" for > all sysvinit users (which is considered to be "serious" or "grave") > nor for either sslh or sslh-select, this is at most "a bug which has a > major effect on the usability of a package, without rendering it > completely unusable to everyone.", i.e. severity "important". > > And please also show the complete options to sslh, because this > behaviour could e.g. stem from using the -i (inetd) option (which is > meant to listen on STDIN and sending to STDOUT) together with starting > sslh via init script. If that's the case, it's a configuration error > and no bug. (Except maybe that it should listen on port 443 at all > then. :-) It is standalone configuration, no inetd is involved. > But even if I configure sslh for both, inetd and as a standalone > service, this issue does not happen since the standalone service fails > to start because inetd already occupies the HTTPS port. > > So please also show your sslh entry in /etc/inetd.conf and your > /etc/default/sslh. $ cat /etc/inetd.conf cat: /etc/inetd.conf: No such file or directory $ cat /etc/default/sslh # Default options for sslh initscrip
Bug#930604: RFS: sslh/1.18-1.1 [NMU] [RC]
Package: sponsorship-requests Severity: important Dear mentors, I saw that package "sslh" is already in autoremove queue https://udd.debian.org/cgi-bin/autoremovals.cgi so I'm sending NMU change for that package to prevent package removal. NMU change fixes bug #919188 with linked patch which is in that bug ticket: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919188 Package name: sslh Version : 1.18-1.1 Upstream Author : Yves Rutschle URL : http://www.rutschle.net/tech/sslh.shtml License : GPL-2.0+ Section : net It builds those binary packages: sslh - Applicative protocol multiplexer To access further information about this package, please visit the following URL: https://mentors.debian.net/package/sslh Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/sslh/sslh_1.18-1.1.dsc More information about sslh can be obtained from http://www.rutschle.net/tech/sslh.shtml Changes since the last upload: * Detach sslh from terminal in init script (Closes: #919188) Regards, Pali Rohár signature.asc Description: PGP signature
Bug#919188: sslh daemon does not detach from terminal
Package: sslh Version: 1.18-1 sslh daemon itself does not close 0, 1 and 2 file descriptors when forking into background. And uses fprintf(stderr, "...") for reporting errors even when running in background mode. When using sslh init.d script for starting sslh daemon, then sslh daemon stay connected with terminal from which was started and prints there stderr logs. It is even worse when using sysv init daemon and having sslh to be automatically started at boot time. startpar (which also starts sslh) stays running forever as it waits until sslh detach from terminal. Therefore sslh stderr messages are forwarded to tty 1 console and flood it every time when sslh prints something to stdout. startpar really should not be running after boot process finish. See outputs: $ ps auxf | grep sslh sslh 2567 0.0 0.5 2276 880 ?Ss2018 0:00 /usr/sbin/sslh ... sslh 2570 0.0 0.2 2276 420 ?S 2018 0:00 \_ /usr/sbin/sslh ... sslh 2571 0.0 0.2 2276 420 ?S 2018 0:00 \_ /usr/sbin/sslh ... root 2599 0.0 0.5 1716 880 ?Ss2018 0:00 startpar -f -- sslh $ ls -l -a /proc/2567/fd total 0 dr-x-- 2 root root 0 Jan 13 14:43 . dr-xr-xr-x 7 sslh sslh 0 Dec 27 17:48 .. lrwx-- 1 root root 64 Jan 13 14:43 0 -> /dev/console lrwx-- 1 root root 64 Jan 13 14:43 1 -> /dev/pts/3 lrwx-- 1 root root 64 Jan 13 14:43 2 -> /dev/pts/3 lrwx-- 1 root root 64 Jan 13 14:43 3 -> socket:[6986] lrwx-- 1 root root 64 Jan 13 14:43 4 -> socket:[6987] lrwx-- 1 root root 64 Jan 13 14:43 5 -> socket:[6997] $ ls -l -a /proc/2599/fd total 0 dr-x-- 2 root root 0 Jan 13 14:43 . dr-xr-xr-x 7 root root 0 Dec 27 17:48 .. lrwx-- 1 root root 64 Jan 13 14:43 0 -> /dev/ptmx lrwx-- 1 root root 64 Jan 13 14:43 1 -> /dev/console lrwx-- 1 root root 64 Jan 13 14:43 2 -> /dev/console To fix this problem, it is needed to tell start-stop-daemon in sslh init script to automatically close 0, 1 and file descriptors. start-stop-daemon does this automatically when invoked with --background option (0, 1 and 2 are reopened with /dev/null). So here is simple patch for sslh init.d script which fixes this problem: --- /etc/init.d/sslh2012-05-25 18:38:40.0 +0200 +++ /etc/init.d/sslh2019-01-13 15:05:44.0 +0100 @@ -67,7 +67,7 @@ do_start() start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test > /dev/null \ || return 1 - start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \ + start-stop-daemon --start --quiet --background --pidfile $PIDFILE --exec $DAEMON -- \ $DAEMON_OPTS \ || return 2 # Add code here, if necessary, that waits for the process to be ready After applying this patch, file descriptor list for sslh is: $ pidof sslh 19138 19137 19135 $ ls -l -a /proc/19135/fd total 0 dr-x-- 2 root root 0 Jan 13 15:06 . dr-xr-xr-x 7 sslh sslh 0 Jan 13 15:06 .. lrwx-- 1 root root 64 Jan 13 15:06 0 -> /dev/null lrwx-- 1 root root 64 Jan 13 15:06 1 -> /dev/null lrwx-- 1 root root 64 Jan 13 15:06 2 -> /dev/null lrwx-- 1 root root 64 Jan 13 15:06 3 -> socket:[496978] lrwx-- 1 root root 64 Jan 13 15:06 4 -> socket:[496979] lrwx-- 1 root root 64 Jan 13 15:06 5 -> socket:[496984] So daemon is finally detached from terminal. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#917549: Development file udev.pc is in main udev package
On Friday 28 December 2018 21:36:03 Michael Biebl wrote: > What also needs to be considered is, that quite a few packages already > build-depend on udev. > By splitting out udev.pc, we might break those packages. Hm... right, it is not simple then as those packages would need to be fixed too... -- Pali Rohár pali.ro...@gmail.com
Bug#917549: Development file udev.pc is in main udev package
On Friday 28 December 2018 15:32:45 Michael Biebl wrote: > Control: severity -1 wishlist > > Am 28.12.18 um 15:11 schrieb Pali Rohár: > > Package: udev > > Version: 240-2 > > > > Currently pkg-config's udev.pc file is in main udev package. Therefore > > other packages which needs udev.pc for compilation need to install whole > > udev. So they need to declare Build-Depends: udev. > > What exactly is the problem with build-depending on udev? On most > systems it will be installed anyway and the footprint of udev and its > dependencies is not that much. E.g. it installs udev into system. Also building can be done in chroot or in minimal installation where udev package is not available. And installing and running whole udev daemon is not necessary for compilation. > > File udev.pc is for development and compilation of other packages, > > therefore it should be in separate some -dev package. > > What exactly do you need from udev.pc? udevdir More exactly, get location where udev rules files should be installed. > If you link against libudev, you want libudev.pc which is shipped in > libudev-dev. I'm not linking with libudev. I'm not using any udev library. > Splitting out only udev.pc into a new binary package udev-dev seems a > bit like overkill. I think that installing and running udev daemon just for compilation is more overkill. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#917549: Development file udev.pc is in main udev package
Package: udev Version: 240-2 Currently pkg-config's udev.pc file is in main udev package. Therefore other packages which needs udev.pc for compilation need to install whole udev. So they need to declare Build-Depends: udev. File udev.pc is for development and compilation of other packages, therefore it should be in separate some -dev package. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#917542: RFS: udftools/2.1-1 [RC]
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "udftools" * Package name: udftools Version : 2.1-1 Upstream Author : Pali Rohár * URL : https://github.com/pali/udftools * License : GPL-2+ Section : otherosfs It builds those binary packages: udftools - tools for UDF filesystems and DVD/CD-R(W) drives To access further information about this package, please visit the following URL: https://mentors.debian.net/package/udftools Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/u/udftools/udftools_2.1-1.dsc More information about udftools can be obtained from https://github.com/pali/udftools. Changes since the last upload: * New upstream release (Closes: #916006) * Update Standards-Version to 4.3.0 * Update to debhelper 11 * Update copyright and signing-key.asc Regards, Pali Rohár signature.asc Description: PGP signature
Bug#901246: closed by Bernhard Schmidt (Re: linphone-nogtk depends on X and OpenGL)
> This was indeed quite bad in 3.6.1 which was present in stretch. > > In 3.12 the situation has improved a lot. It is not perfect yet, since > linphone depends on libmediastreamer-voip10, which in turn depends on a > lot of media libraries that sometimes do have a dependency on GL or X > (i.e. libmediastreamer-voip10 -> libavcodec-extra58 -> libcairo2 or > libmediastreamer-voip10 -> libavcodec-extra58 -> librsvg2-2 -> libpango). > > I don't think these can be fixed in linphone. Could you at least provide 3.12 for stretch-backports? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#916006: udftools FTBFS with glibc 2.28
On Sunday 09 December 2018 13:20:49 Adrian Bunk wrote: > main.c: In function 'is_whole_disk': > main.c:170:8: warning: implicit declaration of function 'major' > [-Wimplicit-function-declaration] > maj = major(st.st_rdev); > ^ > main.c:171:8: warning: implicit declaration of function 'minor'; did you mean > 'mknod'? [-Wimplicit-function-declaration] > min = minor(st.st_rdev); > ^ Hi! This problem is already fixed in upstream udftools git repository and I'm planning to release a new version of udftools in this month, including new Debian package upload. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#619757: Bug #619757 breaks DVD reading by default now
On Thursday 25 October 2018 22:47:15 Anthony DeRobertis wrote: > I just finally managed to figure out why DVDs were not working on my machine > after a few hours of banging my head against a wall and ultimately grabbing > another drive... Turns out it was because of this bug. Except I never > explicitly enabled this; it now happens by default via > /lib/udev/rules.d/80-pktsetup.rules. > > # blockdev --getsize64 /dev/sr0 > 3847454720 > # pktsetup -d 252:0 > # blockdev --getsize64 /dev/sr0 > 7235895296 > > ... yeah, works a lot better after that! Hi! This sounds like a kernel bug. Can you provide dmesg output and kernel version? Also can you reproduce it with different DVD discs or with different DVD drive? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#911023: memory leak in the backlight control of the dell-laptop module
Latency: 0 > Interrupt: pin A routed to IRQ 127 > Region 1: Memory at ef10 (32-bit, non-prefetchable) [size=4K] > Capabilities: > Kernel driver in use: rtsx_pci > Kernel modules: rtsx_pci > > 02:00.0 Network controller [0280]: Intel Corporation Wireless 8265 / 8275 > [8086:24fd] (rev 78) > Subsystem: Intel Corporation Wireless 8265 / 8275 [8086:0050] > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- DisINTx+ > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-Latency: 0 > Interrupt: pin A routed to IRQ 131 > Region 0: Memory at ef00 (64-bit, non-prefetchable) [size=8K] > Capabilities: > Kernel driver in use: iwlwifi > Kernel modules: iwlwifi > > > ** USB devices: > Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub > Bus 001 Device 002: ID 0bda:568c Realtek Semiconductor Corp. > Bus 001 Device 004: ID 0a5c:5832 Broadcom Corp. > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > > > -- System Information: > Debian Release: buster/sid > APT prefers unstable > APT policy: (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) > Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8), > LANGUAGE=it_IT.utf8 (charmap=UTF-8) > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages linux-image-4.18.0-2-amd64 depends on: > ii initramfs-tools [linux-initramfs-tool] 0.132 > ii kmod25-1 > ii linux-base 4.5 > > Versions of packages linux-image-4.18.0-2-amd64 recommends: > ii apparmor 2.13-8 > ii firmware-linux-free 3.4 > pn irqbalance > > Versions of packages linux-image-4.18.0-2-amd64 suggests: > pn debian-kernel-handbook > ii grub-efi-amd64 2.02+dfsg1-6 > pn linux-doc-4.18 > > Versions of packages linux-image-4.18.0-2-amd64 is related to: > pn firmware-amd-graphics > pn firmware-atheros > pn firmware-bnx2 > pn firmware-bnx2x > pn firmware-brcm80211 > pn firmware-cavium > pn firmware-intel-sound > pn firmware-intelwimax > pn firmware-ipw2x00 > pn firmware-ivtv > ii firmware-iwlwifi 20180825+dfsg-1 > pn firmware-libertas > pn firmware-linux-nonfree > ii firmware-misc-nonfree 20180825+dfsg-1 > pn firmware-myricom > pn firmware-netxen > pn firmware-qlogic > pn firmware-realtek > pn firmware-samsung > pn firmware-siano > pn firmware-ti-connectivity > pn xen-hypervisor > > -- no debconf information > -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#907803: closed by Adam Borowski (Re: Bug#907803: RFS: udfclient/0.8.9-1)
On Monday 03 September 2018 01:15:28 Adam Borowski wrote: > On Sun, Sep 02, 2018 at 11:37:43PM +0200, Pali Rohár wrote: > > On Sunday 02 September 2018 21:33:03 Debian Bug Tracking System wrote: > > > Nitpick: these warnings are trivial to fix: > > > W: udfclient source: dep5-copyright-license-name-not-unique bsd-2-clause > > > (paragraph at line 37) > > > W: udfclient source: dep5-copyright-license-name-not-unique bsd-2-clause > > > (paragraph at line 62) > > > W: udfclient source: dep5-copyright-license-name-not-unique bsd-4-clause > > > (paragraph at line 149) > > > so it'd be nice if you could get rid of them in the future. Not an > > > important thing, but less noise is good. > > > > How to fix this problem? There are basically 3 different texts of BSD > > licenses in source files. > > You need to give them unique names. If the body of a license is different, > so must be its short name. > > Yeah, that's somewhat unpleasant, but the reason is obvious. Ok. So which short names should I use? I used "bsd-*-clause" name as described in table at: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name -- Pali Rohár pali.ro...@gmail.com
Bug#907803: closed by Adam Borowski (Re: Bug#907803: RFS: udfclient/0.8.9-1)
On Sunday 02 September 2018 21:33:03 Debian Bug Tracking System wrote: > Nitpick: these warnings are trivial to fix: > W: udfclient source: dep5-copyright-license-name-not-unique bsd-2-clause > (paragraph at line 37) > W: udfclient source: dep5-copyright-license-name-not-unique bsd-2-clause > (paragraph at line 62) > W: udfclient source: dep5-copyright-license-name-not-unique bsd-4-clause > (paragraph at line 149) > so it'd be nice if you could get rid of them in the future. Not an > important thing, but less noise is good. How to fix this problem? There are basically 3 different texts of BSD licenses in source files. > Then there are missing man pages... I have already contacted upstream about manpage problems. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#907803: RFS: udfclient/0.8.9-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "udfclient" * Package name: udfclient Version : 0.8.9-1 Upstream Author : Reinoud Zandijk * URL : http://www.13thmonkey.org/udfclient/ * License : Clarified Artistic License Section : otherosfs It builds those binary packages: udfclient - userland implementation of the UDF filesystem To access further information about this package, please visit the following URL: https://mentors.debian.net/package/udfclient Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/u/udfclient/udfclient_0.8.9-1.dsc More information about hello can be obtained from http://www.13thmonkey.org/udfclient/. Changes since the last upload: * New upstream release * Update Standards-Version to 4.2.1 * Update to debhelper 11 * Use https:// for copyright format URI Regards, Pali Rohár signature.asc Description: PGP signature
Bug#868170: libemail-address-perl: Email::Address->parse() is vulnerable to CVE-2015-7686
On Thursday 26 July 2018 15:48:31 Pali Rohár wrote: > On Sunday 22 July 2018 16:47:00 gregor herrmann wrote: > > On Sat, 07 Jul 2018 22:16:05 +0200, Pali Rohár wrote: > > > And about remaining, should I fill a bug for duck, cil, > > > libhtml-fromtext-perl and libtemplate-plugin-clickable-email-perl > > > packages? Or do you have a better idea how to handle > > > libregexp-common-email-address-perl and libemail-find-perl? > > > > Well, the question is what the bug reports are about or what the > > packages are supposed to do. > > duck is Debian specific, so it should be possible to come up with a > > fix; for the others I'd suggest to discuss this with upstream first. > > Email::Find has last release from year 2007 and has open 6 years bugs: > https://metacpan.org/pod/Email::Find > https://rt.cpan.org/Public/Dist/Display.html?Name=Email-Find > > And Regexp::Common::Email::Address is from year 2005: > https://metacpan.org/pod/Regexp::Common::Email::Address > https://rt.cpan.org/Public/Dist/Display.html?Name=Regexp-Common-Email-Address > > Dependent modules: > > HTML::FromText is from same author as Email::Address: > https://metacpan.org/pod/HTML::FromText > > And Template::Plugin::Clickable::Email had only one version, year 2005: > https://metacpan.org/pod/Template::Plugin::Clickable::Email > > So it does not look like there is active development... Well, what are the next steps then? I think I did everything what I could and probably cannot help more with investigation. -- Pali Rohár pali.ro...@gmail.com
Bug#868170: libemail-address-perl: Email::Address->parse() is vulnerable to CVE-2015-7686
On Sunday 22 July 2018 16:47:00 gregor herrmann wrote: > On Sat, 07 Jul 2018 22:16:05 +0200, Pali Rohár wrote: > > And about remaining, should I fill a bug for duck, cil, > > libhtml-fromtext-perl and libtemplate-plugin-clickable-email-perl > > packages? Or do you have a better idea how to handle > > libregexp-common-email-address-perl and libemail-find-perl? > > Well, the question is what the bug reports are about or what the > packages are supposed to do. > duck is Debian specific, so it should be possible to come up with a > fix; for the others I'd suggest to discuss this with upstream first. Email::Find has last release from year 2007 and has open 6 years bugs: https://metacpan.org/pod/Email::Find https://rt.cpan.org/Public/Dist/Display.html?Name=Email-Find And Regexp::Common::Email::Address is from year 2005: https://metacpan.org/pod/Regexp::Common::Email::Address https://rt.cpan.org/Public/Dist/Display.html?Name=Regexp-Common-Email-Address Dependent modules: HTML::FromText is from same author as Email::Address: https://metacpan.org/pod/HTML::FromText And Template::Plugin::Clickable::Email had only one version, year 2005: https://metacpan.org/pod/Template::Plugin::Clickable::Email So it does not look like there is active development... -- Pali Rohár pali.ro...@gmail.com
Bug#868170: libemail-address-perl: Email::Address->parse() is vulnerable to CVE-2015-7686
On Saturday 07 July 2018 22:16:05 Pali Rohár wrote: > So for two packages from six are patches available, just needs to be > send to upstream. Are you as Debian downstream maintainers handle those > two Data::Validate::Email and Perl::Critic modules and try to find > contact of upstream projects? > > About request-tracker4 can you try to check what is current state? > > And about remaining, should I fill a bug for duck, cil, > libhtml-fromtext-perl and libtemplate-plugin-clickable-email-perl > packages? Or do you have a better idea how to handle > libregexp-common-email-address-perl and libemail-find-perl? PING, any comments? -- Pali Rohár pali.ro...@gmail.com
Bug#903844: RFS: smpq/1.6-2
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "smpq" * Package name: smpq Version : 1.6-2 Upstream Author : Pali Rohár * URL : https://launchpad.net/smpq * License : GPL-3+ Section : utils It builds those binary packages: smpq - StormLib MPQ archiving utility To access further information about this package, please visit the following URL: https://mentors.debian.net/package/smpq Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/smpq/smpq_1.6-2.dsc More information about smpq can be obtained from https://launchpad.net/smpq. Changes since the last upload: * Update Standards-Version to 4.1.5 * Update to debhelper 11 * Update watch and signing-key.asc * Enable LFS support * Use https links in copyright * Drop KDE4 package kio-smpq (Closes: #875182) Regards, Pali Rohár signature.asc Description: PGP signature
Bug#901244: [Linphone-developers] linphone crash on every incoming call
That is a version available in current Debian Stretch stable release.
Therefore I reported it.
On Saturday 07 July 2018 09:27:47 Russell Treleaven wrote:
> That version of linphone is ancient.
> please see http://linphone.org/technical-corner/linphone/downloads
>
> On Sun, Jun 10, 2018 at 10:40 AM, Pali Rohár wrote:
>
> > Package: linphone
> > Version: 3.6.1-3
> > Severity: important
> >
> > Dear maintainer, linphone always crashes when there is incoming call.
> > Basically it makes it unusable. I'm CCing also linphone developers.
> >
> > The most important for crash is stacktrace. So here is output from gdb:
> >
> > Thread 1 "linphone" received signal SIGSEGV, Segmentation fault.
> > linphone_core_update_upnp_from_remote_media_description
> > (call=call@entry=0x55abea90,
> > md=0x0) at upnp.c:684
> > 684 for (i = 0; i < md->n_total_streams; i++) {
> >
> > (gdb) print md
> > $1 = (const SalMediaDescription *) 0x0
> >
> > (gdb) bt
> > #0 linphone_core_update_upnp_from_remote_media_description
> > (call=call@entry=0x55abea90, md=0x0) at upnp.c:684
> > #1 0x77bb3b29 in linphone_call_new_incoming
> > (lc=lc@entry=0x558a4410,
> > from=from@entry=0x55abe9d0, to=to@entry=0x55abea30,
> > op=op@entry=0x55aa6f20)
> > at linphonecall.c:571
> > #2 0x77ba6331 in call_received (h=0x55aa6f20) at
> > callbacks.c:256
> > #3 0x77ba0763 in inc_new_call (ev=0x7fffa0003e70,
> > sal=0x55990bc0) at sal_eXosip2.c:1435
> > #4 process_event (ev=0x7fffa0003e70, sal=0x55990bc0) at
> > sal_eXosip2.c:2779
> > #5 sal_iterate (sal=0x55990bc0) at sal_eXosip2.c:2907
> > #6 0x77b95783 in linphone_core_iterate (lc=0x558a4410) at
> > linphonecore.c:2107
> > #7 0x5556c290 in ?? ()
> > #8 0x7fffef5b6123 in ?? () from /lib/x86_64-linux-gnu/libglib-
> > 2.0.so.0
> > #9 0x7fffef5b56aa in g_main_context_dispatch () from
> > /lib/x86_64-linux-gnu/libglib-2.0.so.0
> > #10 0x7fffef5b5a60 in ?? () from /lib/x86_64-linux-gnu/libglib-
> > 2.0.so.0
> > #11 0x7fffef5b5d82 in g_main_loop_run () from
> > /lib/x86_64-linux-gnu/libglib-2.0.so.0
> > #12 0x776503b7 in gtk_main () from /usr/lib/x86_64-linux-gnu/
> > libgtk-x11-2.0.so.0
> > #13 0x55569cfc in main ()
> >
> > So linphone is trying to do NULL pointer dereference on line 684 which
> > makes instant segfault.
> >
> > Looking at the problematic libphonecall.c file and function
> > linphone_call_new_incoming()... and there is really a logical error.
> >
> > md=sal_call_get_remote_media_description(op);
> > ...
> > if (md) {
> > ...
> > call->params.has_video &= linphone_core_media_
> > description_contains_video_stream(md);
> > }
> > ...
> > linphone_core_update_ice_from_remote_media_description(call,
> > sal_call_get_remote_media_description(op));
> > ...
> > if (linphone_core_update_upnp_from_remote_media_description(call,
> > sal_call_get_remote_media_description(op))<0) {
> >
> > First there is call to the sal_call_get_remote_media_description()
> > function and then return value is checked for NULL.
> >
> > Later there is again call for sal_call_get_remote_media_description()
> > but return value is not check and it is passed to functions
> > linphone_core_update_ice_from_remote_media_description() and
> > linphone_core_update_upnp_from_remote_media_description().
> >
> > And functions linphone_core_update_upnp_from_remote_media_description()
> > and linphone_core_update_ice_from_remote_media_description() then
> > dereference md argument without doing any check for NULL.
> >
> > for (i = 0; i < md->n_total_streams; i++) {
> >
> > if ((md->ice_pwd[0] != '\0') && (md->ice_ufrag[0] != '\0')) {
> >
> > So check for NULL pointer needs to be done to fix this problem.
> > Otherwise whole linphone application is unusable as it is not possible
> > to receive any call.
> >
> > --
> > Pali Rohár
> > pali.ro...@gmail.com
> >
> > ___
> > Linphone-developers mailing list
> > linphone-develop...@nongnu.org
> > https://lists.nongnu.org/mailman/listinfo/linphone-developers
> >
> >
>
>
--
Pali Rohár
pali.ro...@gmail.com
Bug#868170: libemail-address-perl: Email::Address->parse() is vulnerable to CVE-2015-7686
Hi! Here is update summary. Currently there are only six open blocked bugs and their state is: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887547 - libperl-critic-perl Fixed in git and is awaiting for an upload. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887548 - libregexp-common-email-address-perl Module just exports problematic regex and therefore needs to be removed together with Email::Address. The only one reverse dependency is duck. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887543 - libemail-find-perl Module has not been updated since 2007. So it is questionable if it ever going to be fixed. Reverse dependences are: cil, libhtml-fromtext-perl, libtemplate-plugin-clickable-email-perl. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887538 - libdata-validate-email-perl Patch for that module is attached in the bug tracker. As upstream does not have any git repository nor way for creating a pull requests, somebody need to try contacting upstream and sending them prepared patch. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887542 - libemail-address-list-perl Module exports similar set of regexes as Email::Address and depends on Email::Address. So it is not easy to fix it. But Email::Address::XS provides functionality offered by Email::Address::List and the only reverse dependency is request-tracker4. So it should be removed together with Email::Address. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887551 - request-tracker4 Last update is from April that upstream is going to look at this problem for 4.6 cycle. So for two packages from six are patches available, just needs to be send to upstream. Are you as Debian downstream maintainers handle those two Data::Validate::Email and Perl::Critic modules and try to find contact of upstream projects? About request-tracker4 can you try to check what is current state? And about remaining, should I fill a bug for duck, cil, libhtml-fromtext-perl and libtemplate-plugin-clickable-email-perl packages? Or do you have a better idea how to handle libregexp-common-email-address-perl and libemail-find-perl? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#887546: libnet-abuse-utils-perl depends on libemail-address-perl
Fix in now available in the upstream version 0.27: https://metacpan.org/release/MIKEGRB/Net-Abuse-Utils-0.27 -- Pali Rohár pali.ro...@gmail.com
Bug#887539: libdist-zilla-localetextdomain-perl depends on libemail-address-perl
I created simple pull request to upstream project which replace Email::Address by Email::Address::XS: https://github.com/theory/dist-zilla-localetextdomain/pull/18 -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#887543: libemail-find-perl depends on libemail-address-perl
Module Email::Find was last time updated in year 2007, see: https://metacpan.org/pod/Email::Find So I'm skeptical that this problem is ever going to be fixed... -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#887536: dh-make-perl depends on libemail-address-perl
On Tuesday 26 June 2018 19:11:03 gregor herrmann wrote:
> On Tue, 26 Jun 2018 14:26:00 +0200, Pali Rohár wrote:
>
> > Seems that very similar code is in license-reconcile package. So very
> > similar patch like above should be applied also for license-reconcile
> > package (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887550).
>
> In this case the info would be in a better place if added to #887550
>
> Cc'ing this bug to add a pointer there.
In attachment is a patch for license-reconcile. It is exactly same as
for dh-make. I have not tested it yet.
--
Pali Rohár
pali.ro...@gmail.com
diff -Nurp license-reconcile-0.14.orig/Build.PL license-reconcile-0.14/Build.PL
--- license-reconcile-0.14.orig/Build.PL 2017-01-28 15:51:20.0 +0100
+++ license-reconcile-0.14/Build.PL 2018-06-30 17:01:04.596353038 +0200
@@ -25,7 +25,7 @@ my $builder = Module::Build->new(
'Debian::Copyright' => '0.2',
'Dpkg::Version' => 0,
'Parse::DebianChangelog' => 0,
-'Email::Address' => 0,
+'Email::Address::XS' => '1.01',
'List::MoreUtils'=>0,
'Readonly'=>0,
'File::Slurp' => 0,
diff -Nurp license-reconcile-0.14.orig/lib/Debian/LicenseReconcile/Filter/ChangeLog.pm license-reconcile-0.14/lib/Debian/LicenseReconcile/Filter/ChangeLog.pm
--- license-reconcile-0.14.orig/lib/Debian/LicenseReconcile/Filter/ChangeLog.pm 2017-01-28 15:51:20.0 +0100
+++ license-reconcile-0.14/lib/Debian/LicenseReconcile/Filter/ChangeLog.pm 2018-06-30 17:04:57.643697170 +0200
@@ -4,33 +4,7 @@ use 5.006;
use strict;
use warnings;
use base qw(Debian::LicenseReconcile::Filter);
-use Readonly;
-
-Readonly my $ACTUAL_NAME_RE => '\pL[\s\pL\-\'\.]*\pL';
-
-# See http://www.faqs.org/rfcs/rfc2822.html
-# Section 3.4.1
-use Email::Address;
-Readonly my $EMAIL_RE => $Email::Address::addr_spec;
-
-Readonly my $EMAIL_CHANGES_RE => qr{
-^ # beginining of line
-\s+\*\s # item marker
-Email\schange:\s# email change token
-($ACTUAL_NAME_RE) # actual name
-\s+->\s+# gap between name and email
-($EMAIL_RE) # email address
-$ # end of line
-}xms;
-
-Readonly my $PERSON_PARSE_RE => qr{
-\A # beginining of string
-($ACTUAL_NAME_RE) # actual name
-\s # gap
-\<$EMAIL_RE\> # logged email
-\z # end of string
-}xms;
-
+use Email::Address::XS 1.01;
sub get_info {
my $self = shift;
@@ -42,17 +16,23 @@ sub get_info {
my $date= $_->Date;
my @date_pieces = split( " ", $date );
my $year= $date_pieces[3];
-if (my %changes = ($_->Changes =~ m/$EMAIL_CHANGES_RE/xmsg)) {
+if (my %changes = ($_->Changes =~ m/^\s+\*\sEmail\schange:\s+(.*?)\s+->\s+(.*?)\s*$/xmsg)) {
# This way round since we are going backward in time thru changelog
foreach my $p (keys %changes) {
-$changes{$p} =~ s{[\s\n]+$}{}xms;
+# Parse bare email address; undef if it not an email address
+my $address = Email::Address::XS->parse_bare_address($changes{$p})->address();
+if ($address) {
+$changes{$p} = $address;
+} else {
+delete $changes{$p};
+}
}
%email_changes = (
%changes,
%email_changes
);
}
-if (my ($name) = ($person =~ $PERSON_PARSE_RE)) {
+if (my $name = Email::Address::XS->parse($person)->phrase()) {
if (exists $email_changes{$name}) {
$person = "$name <$email_changes{$name}>";
}
signature.asc
Description: PGP signature
Bug#887548: libregexp-common-email-address-perl depends on libemail-address-perl
On Tuesday 26 June 2018 19:12:04 gregor herrmann wrote: > On Tue, 26 Jun 2018 14:30:53 +0200, Pali Rohár wrote: > > > This package just exports vulnerable regex from Email::Address module. > > Therefore it should be removed together with libemail-address-perl > > package (bug 868170). > > Which would mean that someone needs to fix its reverse dependencies > first: > > * ciderwebmail Last changelog should indicate that it is fixed: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887535#14 > * duck So this one is remaining. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#887549: libsvn-notify-perl depends on libemail-address-perl
On Tuesday 26 June 2018 19:44:27 gregor herrmann wrote: > On Tue, 26 Jun 2018 14:59:29 +0200, Pali Rohár wrote: > > > This problem was already fixed in upstream by pull requests: > > https://github.com/theory/svn-notify/pull/19 > > https://github.com/theory/svn-notify/pull/20 > > And if they had released it, we might have updated our package > already :) > > Anyway, when I apply the patch from PR 19, I get tons of > > Argument contains empty address at > /build/libsvn-notify-perl-2.86/blib/lib/SVN/Notify.pm line 1476. > > in the test suite (full build log attached. > This looks a bit fishy to me, to be honest. I have not tested that patch, just spotted that there are new pull requests in upstream project... Anyway, thanks for testing, seems that this problem is now solved in upstream repository. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#887538: libdata-validate-email-perl depends on libemail-address-perl
It looks like that there is no upstream github repository... I wrote
simple patch which ports this perl module to use Email::Address::XS.
Patch is attached.
--
Pali Rohár
pali.ro...@gmail.com
diff -Nurp Data-Validate-Email-0.06/Email.pm Data-Validate-Email-0.06/Email.pm
--- Data-Validate-Email-0.06/Email.pm 2017-10-29 16:31:54.0 +0100
+++ Data-Validate-Email-0.06/Email.pm 2018-06-27 21:08:34.630821085 +0200
@@ -6,7 +6,7 @@ use vars qw($VERSION @ISA @EXPORT @EXPOR
require Exporter;
use AutoLoader 'AUTOLOAD';
-use Email::Address;
+use Email::Address::XS 1.01;
use Data::Validate::Domain;
@ISA = qw(Exporter);
@@ -215,7 +215,7 @@ Returns the untainted address on success
=item I
-This check uses Casey West's Email::Address module to do its validation.
+This check uses L module to do its validation.
The function does not make any attempt to check whether an address is
genuinely deliverable. It only looks to see that the format is email-like.
@@ -230,12 +230,9 @@ sub is_email_rfc822{
return unless defined($value);
- #warn $Email::Address::mailbox;
-
my $address;
- if($value =~ /^$Email::Address::mailbox$/){
- #warn $&;
- $address = $&;
+ if(Email::Address::XS->parse($value)->is_valid()){
+ ($address) = $value =~ m/^(.*)$/s;
}
return $address;
diff -Nurp Data-Validate-Email-0.06/Makefile.PL Data-Validate-Email-0.06/Makefile.PL
--- Data-Validate-Email-0.06/Makefile.PL 2017-10-29 16:18:29.0 +0100
+++ Data-Validate-Email-0.06/Makefile.PL 2018-06-27 21:13:26.604696534 +0200
@@ -7,7 +7,7 @@ WriteMakefile(
'DISTNAME' => 'Data-Validate-Email',
'AUTHOR' => 'Richard Sonnen (son...@richardsonnen.com)',
'PREREQ_PM' => {
-'Email::Address' => 0,
+'Email::Address::XS' => 1.01,
'Data::Validate::Domain' => 0.04,
},
'dist' => {
diff -Nurp Data-Validate-Email-0.06/README Data-Validate-Email-0.06/README
--- Data-Validate-Email-0.06/README 2017-10-29 16:18:29.0 +0100
+++ Data-Validate-Email-0.06/README 2018-06-27 21:13:12.204604030 +0200
@@ -102,7 +102,7 @@ FUNCTIONS
Returns the untainted address on success, undef on failure.
*Notes, Exceptions, & Bugs*
-This check uses Casey West's Email::Address module to do its
+This check uses Email::Address::XS module to do its
validation.
The function does not make any attempt to check whether an
signature.asc
Description: PGP signature
Bug#887546: libnet-abuse-utils-perl depends on libemail-address-perl
I created upstream pull request for porting code to Email::Address::XS: https://github.com/mikegrb/Net-Abuse-Utils/pull/28 -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#902452: Kamailio TLS module in Debian Stretch is unusable
Package: kamailio-tls-modules Version: 4.4.4-2+deb9u1 Severity: grave After installation of kamailio-tls-modules package on Debian Stretch and enabling TLS support in kamailio.cfg via #!define WITH_TLS I'm just getting following fatal error (in syslog): Jun 27 00:19:57 pali /usr/sbin/kamailio[15055]: : tls [tls_init.c:651]: init_tls_h(): ERROR: tls: init_tls_h: openssl compile options mismatch: library has kerberos support disabled and Kamailio tls enabled (unstable configuration)#012 (tls_force_run in kamailio.cfg will override this check) Jun 27 00:19:57 pali /usr/sbin/kamailio[15055]: CRITICAL: [main.c:2592]: main(): could not initialize tls, exiting... And kamailio refuse to start. Therefore current version of kamailio-tls-modules package in Debian Stretch is unusable as TLS support which it provides cannot be enabled. It looks like this package needs to be (re)compiled against correct version of openssl with correct configure options or it needs to runtime depends on correct version of openssl libraries. As package currently does not work at all, I'm marking this issue with severity grave. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#887549: libsvn-notify-perl depends on libemail-address-perl
This problem was already fixed in upstream by pull requests: https://github.com/theory/svn-notify/pull/19 https://github.com/theory/svn-notify/pull/20 -- Pali Rohár pali.ro...@gmail.com
Bug#887548: libregexp-common-email-address-perl depends on libemail-address-perl
This package just exports vulnerable regex from Email::Address module. Therefore it should be removed together with libemail-address-perl package (bug 868170). -- Pali Rohár pali.ro...@gmail.com
Bug#887536: dh-make-perl depends on libemail-address-perl
On Saturday 19 May 2018 18:18:03 Pali Rohár wrote:
> On Saturday 19 May 2018 15:28:14 gregor herrmann wrote:
> > On Wed, 17 Jan 2018 20:50:05 +0100, Pali Rohár wrote:
> >
> > > Hi! Package dh-make-perl depends on libemail-address-perl which is
> > > vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl
> > > provides perl module Email::Address which is now unmaintained. There is
> > > a new perl module Email::Address::XS which is API compatible replacement
> > > for Email::Address and is available in libemail-address-xs-perl. Please
> > > port dh-make-perl package to use libemail-address-xs-perl.
> >
> > dh-make-perl uses
> >
> > % grep -r Email::Address
> > Build.PL:'Email::Address'=> 0,
> > lib/DhMakePerl/Command/Packaging.pm:use Email::Address;
> > lib/DhMakePerl/Command/Packaging.pm:my $EMAIL_RE =
> > $Email::Address::addr_spec;
> >
> > And I think there is no ::addr_spec in libemail-address-xs-perl?
>
> Yes, Email::Address::XS does not have these regexes defined.
>
> > > If you need
> > > help with porting let me know.
> > >
> > Yes, please :)
>
> I looked at that Packaging.pm file and I'm really not sure that it is
> doing...
>
> For me it looks like that $PERSON_PARSE_RE just extract phrase (display
> name) from the email address. For this action simple ->parse() method
> should be enough and then ->phrase() would return it.
>
> $EMAIL_CHANGES_RE seems to extract list of pairs
> which matches some specific format. So the only thing needed here is to
> check if _address_ is really email address without phrase and angle
> brackets. For parsing ->parse_bare_address() method can be used and then
> check ->address() that returned something.
>
> I created patch with these changes, but I'm not sure if it is correct
> due to fact that I do not know what that code should do. So it would be
> needed to properly test these changes.
>
> Anyway, do you really need to parse email address according to RFC2822?
> And is not (.*) in these cases enough?
>
> Here is patch:
>
> diff --git a/Build.PL b/Build.PL
> index eb88fa8..a54fc0f 100644
> --- a/Build.PL
> +++ b/Build.PL
> @@ -25,7 +25,7 @@ my $builder = My::Builder->new(
> 'Cwd' => 0,
> 'Dpkg' => 0,
> 'Dpkg::Source::Package' => '1.01',
> -'Email::Address'=> 0,
> +'Email::Address::XS'=> '1.01',
> 'Email::Date::Format' => 0,
> 'File::Basename'=> 0,
> 'File::Copy'=> 0,
> diff --git a/lib/DhMakePerl/Command/Packaging.pm
> b/lib/DhMakePerl/Command/Packaging.pm
> index 8f14caa..9fb9a9e 100644
> --- a/lib/DhMakePerl/Command/Packaging.pm
> +++ b/lib/DhMakePerl/Command/Packaging.pm
> @@ -35,6 +35,7 @@ use Debian::Control::FromCPAN;
> use Debian::Dependencies;
> use Debian::Rules;
> use DhMakePerl::PodParser ();
> +use Email::Address::XS 1.01;
> use File::Basename qw(basename dirname);
> use File::Find qw(find);
> use File::Path ();
> @@ -1210,31 +1211,6 @@ sub upsurl {
> }
>
>
> -my $ACTUAL_NAME_RE = '\pL[\s\pL\-\'\.]*\pL';
> -
> -# See http://www.faqs.org/rfcs/rfc2822.html
> -# Section 3.4.1
> -use Email::Address;
> -my $EMAIL_RE = $Email::Address::addr_spec;
> -
> -my $EMAIL_CHANGES_RE = qr{
> -^ # beginining of line
> -\s+\*\s # item marker
> -Email\schange:\s# email change token
> -($ACTUAL_NAME_RE) # actual name
> -\s+->\s+# gap between name and email
> -($EMAIL_RE) # email address
> -$ # end of line
> -}xms;
> -
> -my $PERSON_PARSE_RE = qr{
> -\A # beginining of string
> -($ACTUAL_NAME_RE) # actual name
> -\s # gap
> -\<$EMAIL_RE\> # logged email
> -\z # end of string
> -}xms;
> -
> # This is what needs fixing.
> sub copyright_from_changelog {
> my ( $self, $firstmaint, $firstyear ) = @_;
> @@ -1248,17 +1224,23 @@ sub copyright_from_changelog {
> my $date= $_->Date;
> my @date_pieces = split( " ", $date );
> my $year= $date_pieces[3];
> -if (my %changes = ($_->Changes =~ m/$EMAIL_CHANGES_RE/xmsg)) {
> +if (my %changes = ($_->Changes =~
> m/^\s+\*\sEmail\schange:\s+(.*?)\s+->\s+(.*?)\s*$/xmsg)) {
Bug#901873: CVE-2018-12558: DOS vulnerability in perl module Email::Address
Package: libemail-address-perl
Version: 1.909-1
Perl module Email::Address, also in the last version 1.909 is vulnerable
to Algorithm Complexity problem and can cause Denial of Service when
attacker prepares specially crafted input. Root of this problem is that
parsing of email addresses in Email::Address module is done by regular
expressions, which in perl can be exponential.
The trivial input is 30 form-fields characters. You can test it with
following oneliner:
$ perl -MEmail::Address -E 'Email::Address->parse("\f" x 30)'
Vulnerable are all applications which receive (untrusted) emails and
parse address headers (From/To/Cc/...) by Email::Address module. Such
application can be DOSed by sending email with 30 form-fields characters
in From or To header.
Note that this is not the only one problematic input, due to way how is
Email::Address implemented it should be possible to prepare more
non-trivial inputs.
This problem was already reported to Debian Security Team and they
suggested to ask MITRE for assigning CVE identifier. MITRE now assigned
CVE-2018-12558.
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: PGP signature
Bug#901246: linphone-nogtk depends on X and OpenGL
Package: linphone-nogtk Version: 3.6.1-3 Severity: important Dear maintainer, the purpose of linphone-nogtk package is to provide light-wight/headless command line client linphonec, but apparently Debian package depends on X11 libraries, X Video extension libraries, OpenGL libraries and other insane stuff which command line application really should not use. Looking at linphone's ./configure script and there are options like --disable-x11 --enable-gtk_ui=no --enable-notify=no which should be used together with --enable-console_ui=yes for compiling just that command line client. I would suggest to revisit all those dependences of linphone-nogtk package. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#901244: linphone crash on every incoming call
Package: linphone
Version: 3.6.1-3
Severity: important
Dear maintainer, linphone always crashes when there is incoming call.
Basically it makes it unusable. I'm CCing also linphone developers.
The most important for crash is stacktrace. So here is output from gdb:
Thread 1 "linphone" received signal SIGSEGV, Segmentation fault.
linphone_core_update_upnp_from_remote_media_description
(call=call@entry=0x55abea90, md=0x0) at upnp.c:684
684 for (i = 0; i < md->n_total_streams; i++) {
(gdb) print md
$1 = (const SalMediaDescription *) 0x0
(gdb) bt
#0 linphone_core_update_upnp_from_remote_media_description
(call=call@entry=0x55abea90, md=0x0) at upnp.c:684
#1 0x77bb3b29 in linphone_call_new_incoming
(lc=lc@entry=0x558a4410, from=from@entry=0x55abe9d0,
to=to@entry=0x55abea30, op=op@entry=0x55aa6f20) at linphonecall.c:571
#2 0x77ba6331 in call_received (h=0x55aa6f20) at callbacks.c:256
#3 0x77ba0763 in inc_new_call (ev=0x7fffa0003e70, sal=0x55990bc0)
at sal_eXosip2.c:1435
#4 process_event (ev=0x7fffa0003e70, sal=0x55990bc0) at sal_eXosip2.c:2779
#5 sal_iterate (sal=0x55990bc0) at sal_eXosip2.c:2907
#6 0x77b95783 in linphone_core_iterate (lc=0x558a4410) at
linphonecore.c:2107
#7 0x5556c290 in ?? ()
#8 0x7fffef5b6123 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#9 0x7fffef5b56aa in g_main_context_dispatch () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x7fffef5b5a60 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x7fffef5b5d82 in g_main_loop_run () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x776503b7 in gtk_main () from
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#13 0x55569cfc in main ()
So linphone is trying to do NULL pointer dereference on line 684 which
makes instant segfault.
Looking at the problematic libphonecall.c file and function
linphone_call_new_incoming()... and there is really a logical error.
md=sal_call_get_remote_media_description(op);
...
if (md) {
...
call->params.has_video &=
linphone_core_media_description_contains_video_stream(md);
}
...
linphone_core_update_ice_from_remote_media_description(call,
sal_call_get_remote_media_description(op));
...
if (linphone_core_update_upnp_from_remote_media_description(call,
sal_call_get_remote_media_description(op))<0) {
First there is call to the sal_call_get_remote_media_description()
function and then return value is checked for NULL.
Later there is again call for sal_call_get_remote_media_description()
but return value is not check and it is passed to functions
linphone_core_update_ice_from_remote_media_description() and
linphone_core_update_upnp_from_remote_media_description().
And functions linphone_core_update_upnp_from_remote_media_description()
and linphone_core_update_ice_from_remote_media_description() then
dereference md argument without doing any check for NULL.
for (i = 0; i < md->n_total_streams; i++) {
if ((md->ice_pwd[0] != '\0') && (md->ice_ufrag[0] != '\0')) {
So check for NULL pointer needs to be done to fix this problem.
Otherwise whole linphone application is unusable as it is not possible
to receive any call.
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: PGP signature
Bug#887539: libdist-zilla-localetextdomain-perl depends on libemail-address-perl
Seems that there is no package which depends on libdist-zilla-localetextdomain-perl. -- Pali Rohár pali.ro...@gmail.com
Bug#899179: libemail-mime-createhtml-perl depends on libemail-address-perl
On Sunday 20 May 2018 13:05:17 Pali Rohár wrote: > Version: 0.98 Sorry, wrong version, it should be last: 1.042-1 Anyway, this package has only build time dependency on Email::Address due to one unit test which needs it. Email::Address is not needed at runtime. 3 months ago I sent patch for that unit test to upstream project to use Email::Address::XS. It is still open on github: https://github.com/vanstyn/Email-MIME-CreateHTML/pull/2 -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#899179: libemail-mime-createhtml-perl depends on libemail-address-perl
Package: libemail-mime-createhtml-perl Version: 0.98 Severity: wishlist Hi! Package libemail-mime-createhtml-perl depends on libemail-address-perl which is vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl provides perl module Email::Address which is now unmaintained. There is a new perl module Email::Address::XS which is API compatible replacement for Email::Address and is available in libemail-address-xs-perl. Please port libemail-mime-createhtml-perl package to use libemail-address-xs-perl. If you need help with porting let me know. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#887542: libemail-address-list-perl depends on libemail-address-perl
Perl module Email::Address::List is probably not possible to fix. But perl module Email::Address::XS already provides methods for parsing list/groups of email addresses -- functionality which is provided by Email::Address::List. Therefore applications which depends on Email::Address::List can be rewritten to use Email::Address::XS. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#887544: libemail-reply-perl depends on libemail-address-perl
I sent patch which fixes this problem to upstream project 3 months ago: https://github.com/Perl-Email-Project/Email-Reply/pull/6 -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#887545: libemail-sender-perl depends on libemail-address-perl
I sent patch which fixes this problem to upstream project 4 months ago: https://github.com/rjbs/Email-Sender/pull/57 -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#887536: dh-make-perl depends on libemail-address-perl
On Saturday 19 May 2018 15:28:14 gregor herrmann wrote:
> On Wed, 17 Jan 2018 20:50:05 +0100, Pali Rohár wrote:
>
> > Hi! Package dh-make-perl depends on libemail-address-perl which is
> > vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl
> > provides perl module Email::Address which is now unmaintained. There is
> > a new perl module Email::Address::XS which is API compatible replacement
> > for Email::Address and is available in libemail-address-xs-perl. Please
> > port dh-make-perl package to use libemail-address-xs-perl.
>
> dh-make-perl uses
>
> % grep -r Email::Address
> Build.PL:'Email::Address'=> 0,
> lib/DhMakePerl/Command/Packaging.pm:use Email::Address;
> lib/DhMakePerl/Command/Packaging.pm:my $EMAIL_RE = $Email::Address::addr_spec;
>
> And I think there is no ::addr_spec in libemail-address-xs-perl?
Yes, Email::Address::XS does not have these regexes defined.
> > If you need
> > help with porting let me know.
> >
> Yes, please :)
I looked at that Packaging.pm file and I'm really not sure that it is
doing...
For me it looks like that $PERSON_PARSE_RE just extract phrase (display
name) from the email address. For this action simple ->parse() method
should be enough and then ->phrase() would return it.
$EMAIL_CHANGES_RE seems to extract list of pairs <name, bare_address>
which matches some specific format. So the only thing needed here is to
check if _address_ is really email address without phrase and angle
brackets. For parsing ->parse_bare_address() method can be used and then
check ->address() that returned something.
I created patch with these changes, but I'm not sure if it is correct
due to fact that I do not know what that code should do. So it would be
needed to properly test these changes.
Anyway, do you really need to parse email address according to RFC2822?
And is not (.*) in these cases enough?
Here is patch:
diff --git a/Build.PL b/Build.PL
index eb88fa8..a54fc0f 100644
--- a/Build.PL
+++ b/Build.PL
@@ -25,7 +25,7 @@ my $builder = My::Builder->new(
'Cwd' => 0,
'Dpkg' => 0,
'Dpkg::Source::Package' => '1.01',
-'Email::Address'=> 0,
+'Email::Address::XS'=> '1.01',
'Email::Date::Format' => 0,
'File::Basename'=> 0,
'File::Copy'=> 0,
diff --git a/lib/DhMakePerl/Command/Packaging.pm
b/lib/DhMakePerl/Command/Packaging.pm
index 8f14caa..9fb9a9e 100644
--- a/lib/DhMakePerl/Command/Packaging.pm
+++ b/lib/DhMakePerl/Command/Packaging.pm
@@ -35,6 +35,7 @@ use Debian::Control::FromCPAN;
use Debian::Dependencies;
use Debian::Rules;
use DhMakePerl::PodParser ();
+use Email::Address::XS 1.01;
use File::Basename qw(basename dirname);
use File::Find qw(find);
use File::Path ();
@@ -1210,31 +1211,6 @@ sub upsurl {
}
-my $ACTUAL_NAME_RE = '\pL[\s\pL\-\'\.]*\pL';
-
-# See http://www.faqs.org/rfcs/rfc2822.html
-# Section 3.4.1
-use Email::Address;
-my $EMAIL_RE = $Email::Address::addr_spec;
-
-my $EMAIL_CHANGES_RE = qr{
-^ # beginining of line
-\s+\*\s # item marker
-Email\schange:\s# email change token
-($ACTUAL_NAME_RE) # actual name
-\s+->\s+# gap between name and email
-($EMAIL_RE) # email address
-$ # end of line
-}xms;
-
-my $PERSON_PARSE_RE = qr{
-\A # beginining of string
-($ACTUAL_NAME_RE) # actual name
-\s # gap
-\<$EMAIL_RE\> # logged email
-\z # end of string
-}xms;
-
# This is what needs fixing.
sub copyright_from_changelog {
my ( $self, $firstmaint, $firstyear ) = @_;
@@ -1248,17 +1224,23 @@ sub copyright_from_changelog {
my $date= $_->Date;
my @date_pieces = split( " ", $date );
my $year= $date_pieces[3];
-if (my %changes = ($_->Changes =~ m/$EMAIL_CHANGES_RE/xmsg)) {
+if (my %changes = ($_->Changes =~
m/^\s+\*\sEmail\schange:\s+(.*?)\s+->\s+(.*?)\s*$/xmsg)) {
# This way round since we are going backward in time thru changelog
foreach my $p (keys %changes) {
-$changes{$p} =~ s{[\s\n]+$}{}xms;
+# Parse bare email address; undef if it not an email address
+my $address =
Email::Address::XS->parse_bare_address($changes{$p})->address();
+if ($address) {
+$changes{$p} = $address;
+} else {
+delete $changes{$p};
+}
}
%email_changes = (
%changes,
Bug#898343: /lib/hdparm/hdparm-functions cause kernel ata errors
On Thursday 10 May 2018 20:39:26 Alex Mestiashvili wrote: > Thank you for reporting and providing the workaround, but this issue is > already fixed in hdparm version 9.54+ds-1. > See this bug for the details: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23891051 Ou, I have not know about it. I just started again to workaround this bug about which I discussed 3 years ago at lkml: https://lkml.org/lkml/2015/8/1/120 Anyway, that check for ID_ATA_FEATURE_SET_APM is working for me too, so I'm happy with it. Is there any chance to backport that fix into stable debian? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#898343: /lib/hdparm/hdparm-functions cause kernel ata errors
Package: hdparm
Version: 9.51+ds-1
Part of debian package hdparm is a file /lib/hdparm/hdparm-functions
which is not available in the upstream hdparm project. Therefore this
file is debian specific.
On every startup of my computer I'm seeing following errors in dmesg.
[9.004058] ata1.00: exception Emask 0x1 SAct 0x0 SErr 0x0 action 0x0
[9.004127] ata1.00: CPB resp_flags 0x11: , CMD error
[9.004171] ata1.00: failed command: SET FEATURES
[9.004219] ata1.00: cmd ef/05:fe:00:00:00/00:00:00:00:00/40 tag 6
[9.004219] res 51/04:fe:00:00:00/00:00:00:00:00/40 Emask 0x1
(device error)
[9.004333] ata1.00: status: { DRDY ERR }
[9.004368] ata1.00: error: { ABRT }
I debugged it and this error is triggered by that shell fragment file
/lib/hdparm/hdparm-functions when it calls command:
/sbin/hdparm -B254 $DRIVE
When I call this command manually I'm getting:
$ sudo hdparm -B254 /dev/sda
/dev/sda:
setting Advanced Power Management level to 0xfe (254)
SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 04 51 40 fe 21 04
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
APM_level = not supported
(plus above errors in dmesg)
Call -B without APM level issue just get command and it does not trigger
above dmesg error. Moreover output is clear, that APM is not supported:
$ sudo hdparm -B /dev/sda
/dev/sda:
APM_level = not supported
Therefore I would propose following change to the hdparm-funcions file
to skip setting APM when it is unsupported.
--- /lib/hdparm/hdparm-functions2017-01-24 12:20:05.0 +0100
+++ /lib/hdparm/hdparm-functions2018-05-09 14:37:20.795077941 +0200
@@ -56,6 +56,9 @@ hdparm_try_apm()
return 1
;;
esac
+if hdparm -B "$1" 2>/dev/null | grep -q 'not supported'; then
+return 1
+fi
return 0
}
With applied this patch I'm no longer getting dmesg errors at computer
startup time. Function hdparm_try_apm() is there to skip setting APM for
some Firewire or USB devices, so it should skip it also when APM is not
supported at all.
Just to note, I'm using SATA controller which is managed by sata_nv.ko
kernel module on nvidia nforce4 motherboard and identified in lspci as:
00:07.0 IDE interface [0101]: NVIDIA Corporation CK804 Serial ATA Controller
[10de:0054] (rev f3) (prog-if 85 [Master SecO PriO])
00:08.0 IDE interface [0101]: NVIDIA Corporation CK804 Serial ATA Controller
[10de:0055] (rev f3) (prog-if 85 [Master SecO PriO])
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: PGP signature
Bug#894389: Dovecot imap process periodically crash on Debian Stretch
Package: dovecot-core Version: 1:2.2.27-3+deb9u2 Dovecot is periodically crashing on Debian Stretch when sieve plugin and virtual folders are loaded and used. Dovecot imap process crashes on every status change in mailbox. In dovecot log are repeating following entries: dovecot: imap: Panic: file imap-sieve-storage.c: line 616: unreached dovecot: imap: Error: Raw backtrace: /usr/lib/dovecot/libdovecot.so.0(+0x95e92) [0x7f08e1546e92] -> /usr/lib/dovecot/libdovecot.so.0(+0x95f8d) [0x7f08e1546f8d] -> /usr/lib/dovecot/libdovecot.so.0(i_fatal+0) [0x7f08e14dca91] -> /usr/lib/dovecot/modules/lib95_imap_sieve_plugin.so(+0x669a) [0x7f08dfe6d69a] -> /usr/lib/dovecot/libdovecot-storage.so.0(mailbox_transaction_commit_get_changes+0x51) [0x7f08e18145b1] -> /usr/lib/dovecot/libdovecot-storage.so.0(mailbox_transaction_commit+0x1e) [0x7f08e181467e] -> /usr/lib/dovecot/modules/lib20_virtual_plugin.so(virtual_backend_box_sync_mail_unset+0x3c) [0x7f08e0d0558c] -> /usr/lib/dovecot/modules/lib20_virtual_plugin.so(virtual_storage_sync_init+0xc40) [0x7f08e0d08460] -> /usr/lib/dovecot/libdovecot-storage.so.0(mailbox_sync_init+0x3b) [0x7f08e181402b] -> dovecot/imap(imap_sync_init+0x68) [0x55e612307d48] -> dovecot/imap(cmd_sync_delayed+0x23c) [0x55e612308c0c] -> dovecot/imap(client_handle_input+0x26d) [0x55e6122fbf0d] -> dovecot/imap(client_continue_pending_input+0x46) [0x55e6122fbfa6] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_call_io+0x52) [0x7f08e155b9f2] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0x109) [0x7f08e155d029] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0x3c) [0x7f08e155ba8c] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_run+0x38) [0x7f08e155bc38] -> /usr/lib/dovecot/libdovecot.so.0(master_service_run+0x13) [0x7f08e14e2fd3] -> dovecot/imap(main+0x328) [0x55e6122eee68] -> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f08e11322e1] -> dovecot/imap(_start+0x2a) [0x55e6122eefea] dovecot: imap: Fatal: master: service(imap): child 10660 killed with signal 6 (core dumps disabled) It makes Dovecot IMAP which is available in Debian Stretch repository absolutely unusable and cause corruption of indexes. I was looking at this problem and found out that other people already reported it on dovecot mailing list, and problem was fixed in git: https://www.dovecot.org/list/dovecot/2016-November/106001.html https://www.dovecot.org/list/dovecot/2016-November/106012.html -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#853991: bts: Patches for smtp+starttls:// & Net::SMTP::TLS
On Thursday 02 February 2017 22:25:47 Pali Rohár wrote: > Package: devscripts > > Hi! I'm sending two patches for bts to bugs as Mattia Rizzolo wanted. > Originally I sent those patches to devscripts-devel mailing list. PING, more then year passed... can somebody review/comment these patches? Mattia? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#890461: RFS: igmpproxy/0.2.1-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "igmpproxy" * Package name: igmpproxy Version : 0.2.1-1 Upstream Author : Pali Rohár <pali.ro...@gmail.com> * URL : https://github.com/pali/igmpproxy * License : BSD-3-clause and GPL-2+ Section : net It builds those binary packages: igmpproxy - IGMP multicast routing daemon To access further information about this package, please visit the following URL: https://mentors.debian.net/package/igmpproxy Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/i/igmpproxy/igmpproxy_0.2.1-1.dsc More information about igmpproxy can be obtained from https://github.com/pali/igmpproxy. Changes since the last upload: * New upstream release * Update Standards-Version to 4.1.3 * Update to debhelper 10 * Use https links in copyright Regards, Pali Rohár signature.asc Description: PGP signature
Bug#890458: RFS: udftools/2.0-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "udftools" * Package name: udftools Version : 2.0-2 Upstream Author : Pali Rohár <pali.ro...@gmail.com> * URL : https://github.com/pali/udftools * License : GPL-2+ Section : otherosfs It builds those binary packages: udftools - tools for UDF filesystems and DVD/CD-R(W) drives To access further information about this package, please visit the following URL: https://mentors.debian.net/package/udftools Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/u/udftools/udftools_2.0-2.dsc More information about udftools can be obtained from https://github.com/pali/udftools. Changes since the last upload: * Fix installation in chroot (Closes: #890224) Regards, Pali Rohár signature.asc Description: PGP signature
Bug#890224: udftools: Cannot be upgraded inside a chroot due to udevadm call in postinst
Hi! I uploaded proposed fix for this problem to mentors: https://mentors.debian.net/package/udftools Can you test this new version if it fixes your problem? In attachment I'm sending debdiff between old and new version. -- Pali Rohár pali.ro...@gmail.com diff -Nru udftools-2.0/debian/changelog udftools-2.0/debian/changelog --- udftools-2.0/debian/changelog 2018-01-16 23:47:19.0 +0100 +++ udftools-2.0/debian/changelog 2018-02-12 18:06:15.0 +0100 @@ -1,3 +1,9 @@ +udftools (2.0-2) unstable; urgency=medium + + * Fix installation in chroot (Closes: #890224) + + -- Pali Rohár <pali.ro...@gmail.com> Mon, 12 Feb 2018 18:06:15 +0100 + udftools (2.0-1) unstable; urgency=medium * New upstream release diff -Nru udftools-2.0/debian/udftools.postinst udftools-2.0/debian/udftools.postinst --- udftools-2.0/debian/udftools.postinst 2018-01-16 23:46:48.0 +0100 +++ udftools-2.0/debian/udftools.postinst 2018-02-12 18:06:08.0 +0100 @@ -3,9 +3,10 @@ if [ "$1" = "configure" ]; then if which udevadm 1>/dev/null 2>&1; then - udevadm control --reload - if dpkg --compare-versions "$2" le "2.0-1~"; then - udevadm trigger --action=add --subsystem-match=block --property-match=ID_CDROM=1 + if udevadm control --reload; then + if dpkg --compare-versions "$2" le "2.0-1~"; then + udevadm trigger --action=add --subsystem-match=block --property-match=ID_CDROM=1 || true + fi fi fi fi signature.asc Description: PGP signature
Bug#753471: konqueror: Black picture when trying to play youtube videos using html5
Hi! I fixed same problem on Debian Stretch by installing gstreamer1.0-libav and phonon-backend-gstreamer packages followed by system reboot. It looks like there is a problem in KDE4/Qt4 version of Phonon to play mp4 video contrainer and only gstreamer with libav plugin (libgstlibav.so) is able to do that for Phonon. -- Pali Rohár pali.ro...@gmail.com
Bug#887839: RFS: udftools/2.0-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "udftools" * Package name: udftools Version : 2.0-1 Upstream Author : Pali Rohár <pali.ro...@gmail.com> * URL : https://github.com/pali/udftools * License : GPL-2+ Section : otherosfs It builds those binary packages: udftools - tools for UDF filesystems and DVD/CD-R(W) drives To access further information about this package, please visit the following URL: https://mentors.debian.net/package/udftools Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/u/udftools/udftools_2.0-1.dsc More information about udftools can be obtained from https://github.com/pali/udftools. Changes since the last upload: * New upstream release * Update Suggests (remove pmount, add udfclient) * Update Descriptions (add new tools into list) * Update Standards-Version to 4.1.2 * Update to debhelper 10 * Update copyright, watch and signing-key.asc * Remove /etc/init.d/udftools init script and /etc/default/udftools file - Replace them by a new upstream udev rule and load it at postinst - Remove lsb-base dependency (was needed only for init script) - Closes: #510907, #645352, #583380 - LP: #345158, #347067, #1076126 Regards, Pali Rohár signature.asc Description: PGP signature
Bug#868170: libemail-address-perl: Email::Address->parse() is vulnerable to CVE-2015-7686
On Thursday 18 January 2018 18:16:44 gregor herrmann wrote:
> On Thu, 18 Jan 2018 18:10:38 +0100, Pali Rohár wrote:
>
> > > Thinking about upstream, I had another idea: If Email-Address is
> > > unmaintained on the CPAN, you could take it over (request co-maint)
> > > and then
> > > - change Email::Address to a wrapper around Email::Address::XS;
> > > - or remove the Email-Address distro and move the Email::Address
> > > module, again changed to a wrapper, into the Email-Address-XS
> > > distribution;
> > > - or, maybe least controversial, improve Email::Address to load
> > > Email::Address::XS if it's installed. In that case we could in
> > > Debian just add a dependency on libemail-address-xs-perl to
> > > libemail-address-perl.
> >
> > I had a discussion about Email::Address module and decision was to not
> > do such things as Email::Address is pure Perl module and
> > Email::Address::XS needs C compiler. There are lot of Perl systems where
> > C compiler is not available and there only pure Perl modules can be
> > installed/loaded.
>
> I totally see this point; that's why I added my third proposal above
> and marked it as least controversial ("use ::XS if it is available").
> This would fix the issue in Debian, because here we can guarantee it
> by a dependency, and it would at least improve the situation for
> parts of rest of the world (the part which has a C compiler).
This does not fix the issue completely. Email::Address module exports
"vulnerable" regexes, see:
https://metacpan.org/source/RJBS/Email-Address-1.908/lib/Email/Address.pm#L126
And these regexes are not provided by Email::Address::XS module (as XS
module parses email by own sequential parser).
So it is better to not load Email::Address at all when application is
known to work correctly with Email::Address::XS to prevent usage of
insecure regexes.
--
Pali Rohár
pali.ro...@gmail.com
Bug#868170: libemail-address-perl: Email::Address->parse() is vulnerable to CVE-2015-7686
On Thursday 18 January 2018 17:54:16 gregor herrmann wrote: > Thinking about upstream, I had another idea: If Email-Address is > unmaintained on the CPAN, you could take it over (request co-maint) > and then > - change Email::Address to a wrapper around Email::Address::XS; > - or remove the Email-Address distro and move the Email::Address > module, again changed to a wrapper, into the Email-Address-XS > distribution; > - or, maybe least controversial, improve Email::Address to load > Email::Address::XS if it's installed. In that case we could in > Debian just add a dependency on libemail-address-xs-perl to > libemail-address-perl. I had a discussion about Email::Address module and decision was to not do such things as Email::Address is pure Perl module and Email::Address::XS needs C compiler. There are lot of Perl systems where C compiler is not available and there only pure Perl modules can be installed/loaded. -- Pali Rohár pali.ro...@gmail.com
Bug#868170: libemail-address-perl: Email::Address->parse() is vulnerable to CVE-2015-7686
On Friday 17 November 2017 23:42:19 Moritz Muehlenhoff wrote: > On Fri, Nov 17, 2017 at 09:36:46PM +0100, Pali Rohár wrote: > > On Friday 17 November 2017 12:36:54 Moritz Muehlenhoff wrote: > > > On Fri, Nov 17, 2017 at 12:03:26PM +0100, Pali Rohár wrote: > > > > What > > > > about next, do you have some script or any other tool which can create > > > > those wishlist bugs for all packages which depend on > > > > libemail-address-perl package? > > > > > > There's a mass-bug script in 'devscripts", but since there's less than > > > 20 packages you could also simply file these manually. > > > > Will you or any other maintainer of perl packages do that? > > Anyone can file bugs in the Debian BTS, so why not do it yourself? Done: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887535 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887536 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887537 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887538 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887539 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887542 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887543 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887544 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887545 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887546 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887547 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887548 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887549 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887550 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887551 -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#887551: request-tracker4 depends on libemail-address-perl
Package: request-tracker4 Version: 4.4.2-1 Severity: wishlist Hi! Package request-tracker4 depends on libemail-address-perl which is vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl provides perl module Email::Address which is now unmaintained. There is a new perl module Email::Address::XS which is API compatible replacement for Email::Address and is available in libemail-address-xs-perl. Please port request-tracker4 package to use libemail-address-xs-perl. If you need help with porting let me know. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#887550: license-reconcile depends on libemail-address-perl
Package: license-reconcile Version: 0.14 Severity: wishlist Hi! Package license-reconcile depends on libemail-address-perl which is vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl provides perl module Email::Address which is now unmaintained. There is a new perl module Email::Address::XS which is API compatible replacement for Email::Address and is available in libemail-address-xs-perl. Please port license-reconcile package to use libemail-address-xs-perl. If you need help with porting let me know. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#887549: libsvn-notify-perl depends on libemail-address-perl
Package: libsvn-notify-perl Version: 2.86-1 Severity: wishlist Hi! Package libsvn-notify-perl depends on libemail-address-perl which is vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl provides perl module Email::Address which is now unmaintained. There is a new perl module Email::Address::XS which is API compatible replacement for Email::Address and is available in libemail-address-xs-perl. Please port libsvn-notify-perl package to use libemail-address-xs-perl. If you need help with porting let me know. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#887548: libregexp-common-email-address-perl depends on libemail-address-perl
Package: libregexp-common-email-address-perl Version: 1.01-4 Severity: wishlist Hi! Package libregexp-common-email-address-perl depends on libemail-address-perl which is vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl provides perl module Email::Address which is now unmaintained. There is a new perl module Email::Address::XS which is API compatible replacement for Email::Address and is available in libemail-address-xs-perl. Please port libregexp-common-email-address-perl package to use libemail-address-xs-perl. If you need help with porting let me know. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#887544: libemail-reply-perl depends on libemail-address-perl
Package: libemail-reply-perl Version: 1.204-1 Severity: wishlist Hi! Package libemail-reply-perl depends on libemail-address-perl which is vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl provides perl module Email::Address which is now unmaintained. There is a new perl module Email::Address::XS which is API compatible replacement for Email::Address and is available in libemail-address-xs-perl. Please port libemail-reply-perl package to use libemail-address-xs-perl. If you need help with porting let me know. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#887546: libnet-abuse-utils-perl depends on libemail-address-perl
Package: libnet-abuse-utils-perl Version: 0.25-1 Severity: wishlist Hi! Package libnet-abuse-utils-perl depends on libemail-address-perl which is vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl provides perl module Email::Address which is now unmaintained. There is a new perl module Email::Address::XS which is API compatible replacement for Email::Address and is available in libemail-address-xs-perl. Please port libnet-abuse-utils-perl package to use libemail-address-xs-perl. If you need help with porting let me know. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#887547: libperl-critic-perl depends on libemail-address-perl
Package: libperl-critic-perl Version: 1.130-1 Severity: wishlist Hi! Package libperl-critic-perl depends on libemail-address-perl which is vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl provides perl module Email::Address which is now unmaintained. There is a new perl module Email::Address::XS which is API compatible replacement for Email::Address and is available in libemail-address-xs-perl. Please port libperl-critic-perl package to use libemail-address-xs-perl. If you need help with porting let me know. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#887545: libemail-sender-perl depends on libemail-address-perl
Package: libemail-sender-perl Version: 1.300031-1 Severity: wishlist Hi! Package libemail-sender-perl depends on libemail-address-perl which is vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl provides perl module Email::Address which is now unmaintained. There is a new perl module Email::Address::XS which is API compatible replacement for Email::Address and is available in libemail-address-xs-perl. Please port libemail-sender-perl package to use libemail-address-xs-perl. If you need help with porting let me know. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#887543: libemail-find-perl depends on libemail-address-perl
Package: libemail-find-perl Version: 0.10-dfsg-3 Severity: wishlist Hi! Package libemail-find-perl depends on libemail-address-perl which is vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl provides perl module Email::Address which is now unmaintained. There is a new perl module Email::Address::XS which is API compatible replacement for Email::Address and is available in libemail-address-xs-perl. Please port libemail-find-perl package to use libemail-address-xs-perl. If you need help with porting let me know. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#887542: libemail-address-list-perl depends on libemail-address-perl
Package: libemail-address-list-perl Version: 0.05-1 Severity: wishlist Hi! Package libemail-address-list-perl depends on libemail-address-perl which is vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl provides perl module Email::Address which is now unmaintained. There is a new perl module Email::Address::XS which is API compatible replacement for Email::Address and is available in libemail-address-xs-perl. Please port libemail-address-list-perl package to use libemail-address-xs-perl. If you need help with porting let me know. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#887539: libdist-zilla-localetextdomain-perl depends on libemail-address-perl
Package: libdist-zilla-localetextdomain-perl Version: 0.91-1 Severity: wishlist Hi! Package libdist-zilla-localetextdomain-perl depends on libemail-address-perl which is vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl provides perl module Email::Address which is now unmaintained. There is a new perl module Email::Address::XS which is API compatible replacement for Email::Address and is available in libemail-address-xs-perl. Please port libdist-zilla-localetextdomain-perl package to use libemail-address-xs-perl. If you need help with porting let me know. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#887538: libdata-validate-email-perl depends on libemail-address-perl
Package: libdata-validate-email-perl Version: 0.06-1 Severity: wishlist Hi! Package libdata-validate-email-perl depends on libemail-address-perl which is vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl provides perl module Email::Address which is now unmaintained. There is a new perl module Email::Address::XS which is API compatible replacement for Email::Address and is available in libemail-address-xs-perl. Please port libdata-validate-email-perl package to use libemail-address-xs-perl. If you need help with porting let me know. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#887537: libcourriel-perl depends on libemail-address-perl
Package: libcourriel-perl Version: 0.45-1 Severity: wishlist Hi! Package libcourriel-perl depends on libemail-address-perl which is vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl provides perl module Email::Address which is now unmaintained. There is a new perl module Email::Address::XS which is API compatible replacement for Email::Address and is available in libemail-address-xs-perl. Please port libcourriel-perl package to use libemail-address-xs-perl. If you need help with porting let me know. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#887535: ciderwebmail depends on libemail-address-perl
Package: ciderwebmail Version: 1.05+20150729-3 Severity: wishlist Hi! Package ciderwebmail depends on libemail-address-perl which is vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl provides perl module Email::Address which is now unmaintained. There is a new perl module Email::Address::XS which is API compatible replacement for Email::Address and is available in libemail-address-xs-perl. Please port ciderwebmail package to use libemail-address-xs-perl. If you need help with porting let me know. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#887536: dh-make-perl depends on libemail-address-perl
Package: dh-make-perl Version: 0.98 Severity: wishlist Hi! Package dh-make-perl depends on libemail-address-perl which is vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl provides perl module Email::Address which is now unmaintained. There is a new perl module Email::Address::XS which is API compatible replacement for Email::Address and is available in libemail-address-xs-perl. Please port dh-make-perl package to use libemail-address-xs-perl. If you need help with porting let me know. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#886469: RFS: stormlib/9.22-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "stormlib" * Package name: stormlib Version : 9.22-1 Upstream Author : Ladislav Zezula <la...@zezula.net> * URL : http://www.zezula.net/en/mpq/stormlib.html * License : MIT Section : libs It builds those binary packages: libstorm-dev - Library for accessing the MPQ archives (development files) libstorm9 - Library for accessing the MPQ archives To access further information about this package, please visit the following URL: https://mentors.debian.net/package/stormlib Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/stormlib/stormlib_9.22-1.dsc More information about stormlib can be obtained from http://www.zezula.net/en/mpq/stormlib.html. Changes since the last upload: * New upstream release Regards, Pali Rohár signature.asc Description: This is a digitally signed message part.
Bug#886467: RFS: igmpproxy/0.2-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "igmpproxy" * Package name: igmpproxy Version : 0.2-1 Upstream Author : Pali Rohár <pali.ro...@gmail.com> * URL : https://github.com/pali/igmpproxy * License : BSD-3-clause and GPL-2+ Section : net It builds those binary packages: igmpproxy - IGMP multicast routing daemon To access further information about this package, please visit the following URL: https://mentors.debian.net/package/igmpproxy Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/i/igmpproxy/igmpproxy_0.2-1.dsc More information about igmpproxy can be obtained from https://github.com/pali/igmpproxy. Changes since the last upload: * New upstream release * Change upstream location * Update upstream license Regards, Pali Rohár signature.asc Description: This is a digitally signed message part.
Bug#866807: kopete: Can not connect due to missing auth-mechanism
On Sat, 01 Jul 2017 23:44:58 +0200 "Daniel 'DaB.' Baur" <deb...@dabpunkt.eu> wrote: Package: kopete Version: 4:16.08.1-3 Severity: important Dear Maintainer, I updated today from Debian Jessie to Debian Stretch. Unfortunantly now kopete is not long able to connect to my XMPP-accout at jabber.ccc.de :-(. It worked perfectly before the update, and I did not changed my config – in fact: pidgig is still able to connect on my laptop (which was not updated yet). Upon start, kopete tells me that “no appropriate authentication mechanism [is] avaible”. The XML-console tells me that PLAIN, X-OAUTH2 and SCRAM-SHA1 would be possible (see below). http://jabber.org/protocol/caps; node="http://www.process-one.net/en/ejabberd/; ver="8TBgyHso9WGvSCtDfDqtKZKKD8E=" hash="sha-1"/> http://jabber.org/features/iq-register"/> http://jabber.org/features/compress;> zlib PLAIN X-OAUTH2 SCRAM-SHA-1 I have the feeling that I miss a libary or something, but I could not find which. I also tried to start with a clean config, but it changed nothing. Please tell me if I did something wrong, or you need more infos. Sincerely, DaB. Hi! Can you try *removing* QCA cyrus SASL plugin library and (re)start Kopete? On 64bit system is it stored there: /usr/lib/x86_64-linux-gnu/qca/crypto/libqca-cyrus-sasl.so -- Pali Rohár pali.ro...@gmail.com
Bug#875182: [smpq] Future Qt4 removal from Buster
Hi! Source package smpq builds two binary packages: smpq and kio-smpq. First one contains only command line utility which does not depends on Qt4, second one contains only KIO KDE4 library. Currently there is no plan for porting KIO KDE4 library to KF5. Source package itself can be configured to compile only command line ulity without need to have KDE4 development libraries installed. So if this is suitable solution, we can drop kio-smpq binary package and smpq source package would build only smpq binary package which does not depend nor need any KDE4 or Qt4 library. -- Pali Rohár pali.ro...@gmail.com
