I personally don't think it's a good idea to get such patches into stable. Anyway if someone wants to proceed anyway, here are a few things I spotted:
Johannes Schauer <j.scha...@email.de> (2014-07-28): > apt (0.9.7.9+deb7u2) wheezy-security; urgency=high > > * SECURITY UPDATE: apt-get source validation (closes: #749795) > diff -Nru apt-0.9.7.9+deb7u2/debian/libapt-pkg4.12.symbols > apt-0.9.7.9+deb7u3/debian/libapt-pkg4.12.symbols > --- apt-0.9.7.9+deb7u2/debian/libapt-pkg4.12.symbols 2013-03-01 > 10:51:21.000000000 +0000 > +++ apt-0.9.7.9+deb7u3/debian/libapt-pkg4.12.symbols 2014-07-28 > 11:32:23.000000000 +0000 > @@ -369,6 +369,7 @@ > (c++)"debListParser::VersionHash()@Base" 0.8.0 > (c++)"debListParser::Architecture()@Base" 0.8.0 > (c++)"debListParser::ParseDepends(char const*, char const*, > std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, > std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, > unsigned int&, bool const&, bool const&)@Base" 0.8.0 > + (c++)"debListParser::ParseDepends(char const*, char const*, > std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, > std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, > unsigned int&, bool const&, bool const&, bool const&)@Base" 0.9.7.9+deb7u2 This is wrong. > (c++)"debListParser::ParseDepends(pkgCache::VerIterator&, char const*, > unsigned int)@Base" 0.8.0 > (c++)"debListParser::ParseProvides(pkgCache::VerIterator&)@Base" 0.8.0 > (c++)"debListParser::ArchitectureAll()@Base" 0.8.0 > diff -Nru python-apt-0.8.8.2/debian/changelog > python-apt-0.8.8.2+deb7u1/debian/changelog > --- python-apt-0.8.8.2/debian/changelog 2013-03-14 20:25:26.000000000 > +0000 > +++ python-apt-0.8.8.2+deb7u1/debian/changelog 2014-07-28 > 11:46:26.000000000 +0000 > @@ -1,3 +1,19 @@ > +python-apt (0.8.8.2+deb7u1) stable; urgency=low > + > + * Non-maintainer upload. > + * Minimal support for restriction list Build-Depends syntax extension > + - the syntax is described at https://wiki.debian.org/BuildProfileSpec > + - apt will correctly parse and interpret build profile annotations > + in build dependencies of source packages > + - it will not allow to set any build profiles and will always assume > + that no build profile is set > + - this allows apt to not throw an error when encountering source > packages > + that make use of build profiles in stable versions of Debian with apt > + version 0.9.16.1 or later in which full support for build profiles > + was implemented > + > + -- Johannes Schauer <j.scha...@email.de> Mon, 28 Jul 2014 11:45:53 +0000 > + > python-apt (0.8.8.2) unstable; urgency=low > > [ David Prévot ] > diff -Nru python-apt-0.8.8.2/debian/control > python-apt-0.8.8.2+deb7u1/debian/control > --- python-apt-0.8.8.2/debian/control 2013-03-13 22:25:59.000000000 +0000 > +++ python-apt-0.8.8.2+deb7u1/debian/control 2014-07-28 11:46:59.000000000 > +0000 > @@ -10,7 +10,7 @@ > apt-utils, > debhelper (>= 7.3.5), > fakeroot, > - libapt-pkg-dev (>= 0.8.11), > + libapt-pkg-dev (= 0.9.7.9+deb7u3), I'm pretty sure this a bad idea. This happened not so long ago: [12 Jun 2014] DSA-2958 apt - security update Next apt update would mean python-apt is no longer buildable in stable. > python-all-dev (>= 2.6.6-3~), > python-all-dbg, > python3-all-dev (>= 3.1.2-10~), > diff -Nru python-apt-0.8.8.2/python/apt_pkgmodule.cc > python-apt-0.8.8.2+deb7u1/python/apt_pkgmodule.cc > --- python-apt-0.8.8.2/python/apt_pkgmodule.cc 2013-03-13 > 22:31:33.000000000 +0000 > +++ python-apt-0.8.8.2+deb7u1/python/apt_pkgmodule.cc 2014-07-28 > 11:45:11.000000000 +0000 > @@ -186,7 +186,7 @@ > "only contains those dependencies for the architecture set in the\n" > "configuration variable APT::Architecture"; > static PyObject *RealParseDepends(PyObject *Self,PyObject *Args, > - bool ParseArchFlags, std::string name, > + bool ParseArchFlags, bool > ParseRestrictionsList, std::string name, > bool debStyle=false) > { > std::string Package; > @@ -210,7 +210,7 @@ > break; > > Start = debListParser::ParseDepends(Start,Stop,Package,Version,Op, > - ParseArchFlags, StripMultiArch); > + ParseArchFlags, StripMultiArch, > ParseRestrictionsList); > if (Start == 0) > { > PyErr_SetString(PyExc_ValueError,"Problem Parsing Dependency"); > @@ -243,11 +243,11 @@ > } > static PyObject *ParseDepends(PyObject *Self,PyObject *Args) > { > - return RealParseDepends(Self, Args, false, "parse_depends"); > + return RealParseDepends(Self, Args, false, false, "parse_depends"); > } > static PyObject *ParseSrcDepends(PyObject *Self,PyObject *Args) > { > - return RealParseDepends(Self, Args, true, "parse_src_depends"); > + return RealParseDepends(Self, Args, true, true, "parse_src_depends"); > } > #ifdef COMPAT_0_7 > static PyObject *ParseDepends_old(PyObject *Self,PyObject *Args) I know nothing about python bindings but anyway, it looks like you're not updating doc strings. More importantly, what's the impact in packages using those functions? Were packages identified, their code reviewed, and their features tested? Mraw, KiBi.
signature.asc
Description: Digital signature
