Re: Release status of i386 for Bullseye and long term support for 3 years?
On Sat, Dec 12, 2020 at 06:09:02PM +0200, Adrian Bunk wrote: > > Ubuntu have chosen to support the first use-case, and only the first > > use-case. They longer ship a complete, bootable i386 operating system; > > instead, they have an i386 second-class-citizen architecture that > > is sufficient to provide graphics drivers and other shared libraries > > for legacy 32-bit proprietary binaries. > >... > Ubuntu has a business-minded focus, which is fair enough. > But Debian should not blindly follow whatever Canonical > does with Ubuntu for business reasons.[3] > It does make sense for Debian to differenciate by providing support for > communities whose hardware is not or no longer supported by Ubuntu. It's obviously entirely appropriate for Debian to make its own decision here regarding what they want to support, but FTR the dropping of i386 was largely not a "business" focused decision for Ubuntu. While the ongoing costs of maintaining a full port were a consideration, of equal concern was the fact that we believed we would not be able to provide security support for the architecture as a whole at par with other architectures, due to, among other things, lack of adequate support from the upstream kernel/toolchain community. I'm not sure if i386 has caught up and now has adequate mitigation for Spectre etc, but it definitely wasn't available on an equivalent timeline as amd64. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Porter roll call for Debian Stretch
On Wed, Aug 31, 2016 at 11:26:55AM +0100, Dimitri John Ledkov wrote: > Hello, > > Results are available at > > https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/ > > I did a full rebuild with bindnow and PIE enabled, then rebuilt all > > failed packages with a pristine unstable chroot. > > You can take a look at > > https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/diff.txt > > and grep for "OK Failed" (failed with PIE+bindnow, built fine in > > unstable). (There are 1188 packages failing to build) > > Logs for both builds are available in the respective subdirectories. > Are you sure these are correct? The numbers for PIE+bindnow are a lot > higher than what we see in Ubuntu, for same unmodified packages. > E.g. looking at http://qa.ubuntuwire.org/ftbfs/ > amd64/ppc64el/s390x have PIE+bindnow enabled, and > i386/armhf/arm64/powerpc do not. here is nothing in the thousands > range. There might be a dozen packages with PIE+bindnow fixes in > ubuntu, that's not in debian, but that amount cannot be more than a > dozen or two. Note that enabling PIE by default is going to cause build failures for a number of packages which link against static libraries, if those static libraries have not been rebuilt yet with PIE/PIC. Ubuntu has worked through this transition, so a direct comparison would require a rebootstrap test in Debian instead of just a rebuild test (i.e.: test rebuild packages in dependency order, and build later packages against the output of the earlier rebuilds). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Bug#860608: [pkg-golang-devel] Bug#860608: Bug#860608: golang: FTBFS: Go version is "go1.6.1", ignoring -next /<>/api/next.txt
On Mon, May 15, 2017 at 08:56:08AM +0200, Michael Stapelberg wrote: > >> Package: golang-github-gosexy-gettext-dev > > vorlon, can we file for removal of this package? It wasn’t touched since > > 2013 and has no rdepends. > Done: https://bugs.debian.org/862612 Thanks for filing, 100% agreed. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Bug#860608: [pkg-golang-devel] Bug#860608: Bug#860608: golang: FTBFS: Go version is "go1.6.1", ignoring -next /<>/api/next.txt
On Mon, May 15, 2017 at 03:17:03PM -0700, Steve Langasek wrote: > On Mon, May 15, 2017 at 08:56:08AM +0200, Michael Stapelberg wrote: > > >> Package: golang-github-gosexy-gettext-dev > > > vorlon, can we file for removal of this package? It wasn’t touched since > > > 2013 and has no rdepends. > > Done: https://bugs.debian.org/862612 > Thanks for filing, 100% agreed. So, I double checked and: $ dak rm -R -n -s unstable golang-github-gosexy-gettext Will remove the following packages from unstable: golang-github-gosexy-gettext | 0~git20130221-1 | source golang-github-gosexy-gettext-dev | 0~git20130221-1 | all Maintainer: Steve Langasek --- Reason --- -- Checking reverse dependencies... # Broken Build-Depends: snapd: golang-github-gosexy-gettext-dev Dependency problem found. $ It certainly appears that we are still using this package, so I'm closing the bug report. (I wouldn't expect the ftpmasters to act on it in its current state anyway.) And I've uploaded a no-change rebuild of golang-github-gosexy-gettext-dev. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Proposed (lib)curl switch to openssl 1.1
rred name and CURL_FOO_3 is for compatibility only. (This is only worth doing if this increases binary compatibility; otherwise it's better to maintain bidirectional binary compatibility for Debian-built binaries.) - change the symbol versions for libcurl4 to CURL_OPENSSL_4. I would be willing to prepare a patch that implements this. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Proposed (lib)curl switch to openssl 1.1
Hi again, On Tue, Feb 20, 2018 at 06:16:34PM -0800, Steve Langasek wrote: > So, despite Julien's valid objection that core library conflicts cause > dist-upgrades to be more brittle, I think the right answer here is: > - keep all sonames as-is. > - rename libcurl3 to libcurl4. > - leave the package names of the other variants as-is. > - *if* libcurl-gnutls.so.4 and libcurl-nss.so.4 sonames are known to exist > elsewhere outside the Debian ecosystem, fix the symbol versions for > libcurl3-gnutls and libcurl3-nss to use symbol aliases, so that CURL_FOO_4 > is used as the preferred name and CURL_FOO_3 is for compatibility only. > (This is only worth doing if this increases binary compatibility; > otherwise it's better to maintain bidirectional binary compatibility for > Debian-built binaries.) > - change the symbol versions for libcurl4 to CURL_OPENSSL_4. > I would be willing to prepare a patch that implements this. I've done this now and raised an MP: https://salsa.debian.org/debian/curl/merge_requests/3 (I'm assuming there is no point in CURL_FOO_4 symbol version for libcurl-gnutls and libcurl-nss, because these sonames come from a Debian-specific patch and therefore there's no upstream binary compatibility to be concerned about.) Thoughts on this? In terms of ABI changes, this appears to be a strict subset of what Alessandro had proposed and would be binary-compatible for libcurl.so.4; so at minimum, we will probably adopt this change in Ubuntu and proceed with the transition ASAP there, even if Debian later decides to change the ABI for gnutls and nss variants also. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: transition: libmusicbrainz3 (GCC 5)
On Sun, Aug 16, 2015 at 11:26:51 +0200, Julien Cristau wrote:
> any particular reason you're changing the library's SONAME instead of
> leaving it alone and adding Conflicts/Replaces on the old package, which
> seems to be the more usual pattern?
Indeed, the standard practice here is to change the binary package name, but
not to change the library soname without upstream coordination because this
will make the Debian binary incompatible with any other third-party binaries
built against the new C++ ABI using upstream sources rather than the Debian
package.
If you want an soname change, this should be done via upstream, not via a
Debian patch to the upstream build system in an NMU.
I'm uploading a new NMU with the attached patch, which brings
libmusicbrainz3 in line with best practices for this transition.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -u libmusicbrainz3-3.0.2/debian/changelog
libmusicbrainz3-3.0.2/debian/changelog
--- libmusicbrainz3-3.0.2/debian/changelog
+++ libmusicbrainz3-3.0.2/debian/changelog
@@ -1,3 +1,12 @@
+libmusicbrainz3 (3.0.2-2.5) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Revert changes to upstream SONAME is previous NMU. The g++5 transition
+should not change upstream sonames without coordination.
+Closes: #791141.
+
+ -- Steve Langasek Sun, 16 Aug 2015 09:41:05 +
+
libmusicbrainz3 (3.0.2-2.4) unstable; urgency=medium
* Non-maintainer upload.
diff -u libmusicbrainz3-3.0.2/debian/control
libmusicbrainz3-3.0.2/debian/control
--- libmusicbrainz3-3.0.2/debian/control
+++ libmusicbrainz3-3.0.2/debian/control
@@ -9,6 +9,8 @@
Section: libs
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
+Conflicts: libmusicbrainz3-6
+Replaces: libmusicbrainz3-6
Description: library to access the MusicBrainz.org database
MusicBrainz is a community music metadatabase that attempts to create a
comprehensive music information site.
reverted:
--- libmusicbrainz3-3.0.2/debian/patches/gcc-5.patch
+++ libmusicbrainz3-3.0.2.orig/debian/patches/gcc-5.patch
@@ -1,18 +0,0 @@
-Description: Bump SONAME for GCC 5 transition
-Author: Sebastian Ramacher
-Last-Update: 2015-08-02
-
libmusicbrainz3-3.0.2.orig/CMakeLists.txt
-+++ libmusicbrainz3-3.0.2/CMakeLists.txt
-@@ -15,8 +15,8 @@
- MATH(EXPR musicbrainz3_SOVERSION_MINOR "${musicbrainz3_SOVERSION_AGE}")
- MATH(EXPR musicbrainz3_SOVERSION_PATCH "${musicbrainz3_SOVERSION_REVISION}")
-
--SET(musicbrainz3_VERSION
${musicbrainz3_SOVERSION_MAJOR}.${musicbrainz3_SOVERSION_MINOR}.${musicbrainz3_SOVERSION_PATCH})
--SET(musicbrainz3_SOVERSION ${musicbrainz3_SOVERSION_MAJOR})
-+SET(musicbrainz3_VERSION
${musicbrainz3_SOVERSION_MAJOR}v5.${musicbrainz3_SOVERSION_MINOR}.${musicbrainz3_SOVERSION_PATCH})
-+SET(musicbrainz3_SOVERSION ${musicbrainz3_SOVERSION_MAJOR}v5)
-
- SET(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake/modules)
- FIND_PACKAGE(Neon REQUIRED)
-
signature.asc
Description: Digital signature
Re: libstdc++ follow-up transitions
Hi Simon, On Mon, Aug 17, 2015 at 01:46:16PM +0100, Simon McVittie wrote: > I notice that Ubuntu has gone ahead with a lot of library renames. Did > the Ubuntu developers doing these uploads test the results, or did you > just "upload and hope"? One reason I have held back from doing more NMUs > is that for the majority of transitioning packages, I have no idea how > to smoke-test the results, and I'm not happy with putting my signature > on a package that I haven't tested. However, if we're going for a lower > standard of "successfully rebuilding the package and some random rdeps > is enough testing", then there are quite a lot of NMUs that can be done. Yes, this has been the standard in Ubuntu. First, because the presence of a C++ ABI change in a new version of the compiler does not imply an increased risk of wrong code compilation, and we normally assume (in both Debian and Ubuntu) that rebuilding without making other changes is safe; and second because if there's anything *beyond* buildability of reverse-dependencies that warrants testing as part of no-change rebuilds, the right way to express that is by declaration of autopkgtests. So a number of these library packages have gotten suitable smoke testing by way of autopkgtests (indeed, publishing these libraries to wily involved bypassing a number of buggy autopkgtests on reverse dependencies), and many others did not but are assumed to be ok unless someone reports otherwise. > If we wait for a maintainer who knows the relevant package (who is > likely on holiday and/or MIA in many cases) to inspect each of the > packages involved, then I don't think anything vaguely C++-related is > going to migrate for weeks, possibly months. That's a long time for > developers without the appropriate C++ or specific-library knowledge to > avoid touching unstable and hope security bug fixes get to them via t-p-u. Right. I certainly wouldn't recommend that Debian as a whole wait on individual maintainers to make these decisions. Indeed, in Ubuntu we went ahead and pushed "conservative" transitions - namely, assuming that everything needed to be renamed - with the rationale that in cases where we find out that the transition was not needed *and* someone in Debian cares enough to prevent having a transition, we can roll back the transition with some combination of Provides: and dummy packages. So the cost of waiting for careful evaluation of each package is high (weeks or months spent blocking testing), and the cost of having to revert a transition is low (revert the library name, throw in some Provides:, and carry on). > Having done more rebuilds in Ubuntu, it would be great if you could > publish a complete list of the transitions you believe to be necessary, > including those that are not ready to be uploaded until their > dependencies have transitioned, so we can get an idea of the size of the > problem. Here's the count of source packages in Ubuntu wily that produce binary packages ending in 'v5', which is probably a good approximation: $ grep-dctrl -n -sSource:Package -FPackage -r 'v5$' /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_wily*Packages | sort -u | wc -l 333 $ Full list attached. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org adplug afflib alglib assimp astyle atkmm1.6 atlas-cpp blackbox bobcat boolstuff botan1.10 bulletml cairomm cal3d camp canl-c++ cauchy ccfits cg3 cgal cigi-ccl clam clanlib clhep clipper clucene-core coin3 coinor-flopc++ coinor-ipopt coinutils colpack console-bridge cppunit csound ctemplate ctpp2 cvc3 cwidget cxxtools dar davix dbus-c++ dcmtk dolfin double-conversion ecasound eclib fbreader ffmpegthumbnailer flac flatzebra flightcrew flowcanvas flxmlrpc freefem freehdl ganv gconfmm2.6 gecode gemanx-gtk2 geos getfem++ gettext gflags ginac givaro glibmm2.4 gloox gmetadom gmsh gnome-chemistry-utils gnuift google-glog gr-air-modes gr-fcdproplus gr-osmosdr graphicsmagick gsmlib gtkmm2.4 gtkmm3.0 guichan gyoto h323plus hdf5 healpix-cxx hmat-oss htmlcxx hunspell ibutils id3lib3.8.3 ignition-math2 igraph imagemagick ipe kyotocabinet kytea lasi leveldb libabw libaria libassa libbinio libbitcoin libbpp-core libbpp-phyl libbpp-phyl-omics libbpp-popgen libbpp-qt libbpp-raa libbpp-seq libbpp-seq-omics libccrtp libcdr libcec libcec-platform libcgicc libclaw libcmis libcolumbus libcommoncpp2 libconfig libcoverart libcoyotl libcrypto++ libdap libdc0 libebml libetonyek libevocosm libftdi libftdi1 libgenome libgetopt++ libghemical libgig libgltf libgtextutils libgtksourceviewmm libhmsbeagle libitpp libixion libjsoncpp
Re: courier-authlib shlibs missing
On Thu, Aug 05, 2010 at 06:46:04PM +0100, Neil McGovern wrote: > With regards to #554788, is there a chance that this could be fixed, or > even replied to? I really would rather not remove courier from testing. Based on recent policy discussions, it appears one possible workaround which will generate dependencies in spite of the absence of soname by using symbols instead. I'm not confident that this workaround will continue to work, but it might be enough to get us to release with a downgraded bug. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
jobs for website rebuilds of the release notes?
Hello, I've started working on release notes for squeeze, in preparation for being able to send out a call for upgrade tests, and according to Martin Michlmayr, these changes are being reflected already on <http://www.debian.org/releases/lenny/releasenotes> (though not propagated to all hosts bearing that name - I can't see the changes myself). So apparently there's a cronjob regenerating these pages from the release notes trunk. Does anyone know where that job is? Can I get access to it in order to get the lenny release notes generation pointed at the right branch, and to set up output for <http://www.debian.org/releases/testing/releasenotes>? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
I'm a bad Debian citizen (request for input on pam upload)
Hi guys, I have an upload of pam in preparation that violates Neil's recently-posted list of criteria for freeze exceptions in every conceivable way. - no RC bugfixes - package is definitely not priority: optional or extra - includes fixes for bugs of normal or lower - includes upstream changes with no linked Debian bug report. So while I would vouch for this being a good set of improvements over the current package, you probably don't want the whole thing since it's also low-priority. :) But perhaps there's a subset of fixes that are worth considering? Below is the current debian changelog for the package, followed by my suggestions of which bits might be suitable input for a 'squeeze' package branch that I could upload to testing. If you say 'no' to all of it, I can just upload pam 1.1.2-1 to unstable since there are no ABI changes involved; but before that I'd like to confirm whether you'd like any part of this in squeeze. pam (1.1.2-1) UNRELEASED; urgency=low * New upstream release. - Add support for NSS groups to pam_group. Closes: #589019, LP: #297408. - Support cross-building the package. Thanks to Neil Williams for the patch. Closes: #284854. * debian/rules: pass getconf LFS_CFLAGS so that we get a 64-bit rlimit interface. Closes: #579402. * Drop patches conditional_module,_conditional_man and mkhomedir_linking.patch, which are included upstream. * debian/patches/hurd_no_setfsuid: pam_env and pam_mail now also use setfsuid, so patch them to be likewise Hurd-safe. * Update debian/source.lintian-overrides to clean up some spurious warnings. * debian/libpam-modules.postinst: if any 'min=n' options are found in /etc/pam.d/common-password, convert them on upgrade to 'minlen=n' for compatibility with upstream. * debian/NEWS: document the disappearance of 'min=n', in case users have encoded this option elsewhere outside of /etc/pam.d/common-password. * debian/patches/007_modules_pam_unix: drop compatibility handling of 'max=' no-op; use of this option will now log an error, as warned three years ago. * Bump Standards-Version to 3.9.1. * Add lintian overrides for a few more spurious warnings. * debian/patches-applied/no_PATH_MAX_on_hurd: define PATH_MAX for compatibility when it's not already set. Closes: #552043. * debian/local/pam-auth-update: Don't try to pass embedded newlines to debconf; backslash-escape them instead and use CAPB escape. * debian/local/pam-auth-update: sort additional module options before writing them out, so that we don't wind up with a different config file on every invocation. Thanks to Jim Paris for the patch. Closes: #594123. The bits I recommend taking are these: * debian/rules: pass getconf LFS_CFLAGS so that we get a 64-bit rlimit interface. Closes: #579402. * Update debian/source.lintian-overrides to clean up some spurious warnings. * Bump Standards-Version to 3.9.1. * Add lintian overrides for a few more spurious warnings. * debian/patches-applied/no_PATH_MAX_on_hurd: define PATH_MAX for compatibility when it's not already set. Closes: #552043. * debian/local/pam-auth-update: Don't try to pass embedded newlines to debconf; backslash-escape them instead and use CAPB escape. * debian/local/pam-auth-update: sort additional module options before writing them out, so that we don't wind up with a different config file on every invocation. Thanks to Jim Paris for the patch. Closes: #594123. The pam-auth-update fix for embedded newlines is a potential security issue with certain locally generated PAM module profiles (no bug filed). What would you like me to do? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: I'm a bad Debian citizen (request for input on pam upload)
On Sat, Sep 04, 2010 at 03:19:52PM +0200, Julien Cristau wrote: > On Fri, Sep 3, 2010 at 10:48:14 -0700, Steve Langasek wrote: > > The bits I recommend taking are these: > > * debian/rules: pass getconf LFS_CFLAGS so that we get a 64-bit rlimit > > interface. Closes: #579402. > > * Update debian/source.lintian-overrides to clean up some spurious > > warnings. > > * Bump Standards-Version to 3.9.1. > > * Add lintian overrides for a few more spurious warnings. > > * debian/patches-applied/no_PATH_MAX_on_hurd: define PATH_MAX for > > compatibility when it's not already set. Closes: #552043. > > * debian/local/pam-auth-update: Don't try to pass embedded newlines to > > debconf; backslash-escape them instead and use CAPB escape. > > * debian/local/pam-auth-update: sort additional module options before > > writing them out, so that we don't wind up with a different config file > > on every invocation. Thanks to Jim Paris for the patch. > > Closes: #594123. > > The pam-auth-update fix for embedded newlines is a potential security issue > > with certain locally generated PAM module profiles (no bug filed). > > What would you like me to do? > The above list sounds good to me. Ok, thanks - uploading and will file the needful bug once done. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#595685: unblock: pam/1.1.1-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package pam As discussed on debian-release, I have uploaded pam 1.1.1-5 to unstable with a set of final bugfixes for squeeze. Please review and unblock. The changelog for this upload is: * debian/rules: pass getconf LFS_CFLAGS so that we get a 64-bit rlimit interface. Closes: #579402. * Update debian/source.lintian-overrides to clean up some spurious warnings. * Bump Standards-Version to 3.9.1. * Add lintian overrides for a few more spurious warnings. * debian/patches-applied/no_PATH_MAX_on_hurd: define PATH_MAX for compatibility when it's not already set. Closes: #552043. * debian/local/pam-auth-update: Don't try to pass embedded newlines to debconf; backslash-escape them instead and use CAPB escape. * debian/local/pam-auth-update: sort additional module options before writing them out, so that we don't wind up with a different config file on every invocation. Thanks to Jim Paris for the patch. Closes: #594123. unblock pam/1.1.1-5 -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: armel (armv5tel) Kernel: Linux 2.6.30-1-iop32x Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100905195517.4134.55458.report...@becquer.dodds.net
Bug#595685: unblock: pam/1.1.1-5
retitle 595685 unblock: pam/1.1.1-6 thanks Christian Perrier has just pointed out privately to me that there was a pending debconf translation bug that didn't get included in this upload. I've therefore done a new upload of pam 1.1.1-6 to include this fix; bug retitled accordingly. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#596280: [Pkg-openldap-devel] Hacking slapd conffiles to fix an RC bug in kolabd (Was: Bug#596280: unblock: kolabd/2.2.4-20100624-2)
Hi Mathieu, On Sun, Sep 12, 2010 at 09:26:28PM +0200, Mathieu Parent (Debian) wrote: > The recent move of slapd package to runtime config (aka cn=config, aka > slapd.d) unfortunately broke kolabd. After a bootstrap by the user, > kolabd manages some configuration files including slapd.conf. Since > slapd 2.4.23-3, this is broken as described in #595539. > I have proposed an hacky workaround which set slapd back to > slapd.conf. Julien as Release Team member (thank you!), waits an ack > for your team about this change. So: What do you think? I don't think this is acceptable, sorry. The migration to cn=config by default is driven by upstream deprecation of slapd.conf, together with a recognition that it's *harder* for other packages to integrate with slapd when using slapd.conf. I don't think installing kolabd should result in having this change rolled back without asking; and anyway, the implementation here isn't going to be reliable as most systems are going to have SLAPD_CONF='' on upgrade anyway. > Note that kolabd for Wheezy will manage cn=config natively (most > probably by creating slapd.conf and using slaptest; but perhaps by > directly issuing ldap commands). Is there any reason this (slapd.conf + slaptest) couldn't be used as the workaround in squeeze? That still doesn't sound great to me given that it would overwrite any previously present cn=config settings, but it seems to be the existing practice that kolabd will overwrite slapd configs, so it should at least do so in the preferred location; and getting this right shouldn't be any harder than the policy-violating conffile overwrite. I'm sorry that the change to slapd.d by default has landed as late as it has, but again, I don't think it's acceptable for an external package to roll back this change on users' systems and leave them with new upgrade problems for wheezy, where slapd will *not* run the cn=config migration on upgrade. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
RFC: use of shlib bump for libc dependency on new multiarch directories?
Dear release team, Although the paths in which libraries will ultimately be installed for multiarch is not yet entirely settled, one thing that is clear is that on i386, we almost certainly will not be using the path which has been enabled in glibc up to now, namely /lib/i486-linux-gnu.[1] We will most likely be using either /lib/i386-linux-gnu or /lib/x86-linux-glibc instead, depending on the outcome of various ongoing discussions; and libraries installing to either one of these paths are going to need to make sure the new libc is installed first, or they'll instantly become unavailable on upgrade. We can handle this one of two ways. We can either bump the minimal dependency of *all* packages against libc, by adjusting shlibs/symbols in the eglibc package; or we can make adding the dependency a part of the standard library multiarchification recipe. The first approach means that every library on the system will depend on the new libc as soon as it's rebuilt, whether or not it's installed to the multiarch library path. However, my handwavy estimate is that by the time wheezy is out we should have better than 80% library coverage with multiarch, so maybe that's not an issue at all. But it also may not be sufficient to ensure smooth upgrades either; dependencies don't guarantee unpack order, so what happens if a library needed by apt+dpkg to finish the unpack of the new libc gets disappeared out of the system path before libc itself gets unpacked? do we need to special-case the addition of pre-depends to any libraries that are needed by the package manager? Do we want pre-depends for *all* libraries, just in case? The second approach is going to be more error prone; it's one more step that has to be added to the process for converting a library package to multiarch, which means it's one more step that maintainers can forget and one of the easiest to go unnoticed for long periods in unstable/testing. We could mitigate this somewhat by having debhelper do something here by default when it sees multiarch paths in use, but that won't give us 100% archive coverage either (and oh, how the work I've been doing on my multiarch proof-of-concept bootstrap makes me wish it would :-). It also isn't viable anywhere we decide we need Pre-Depends, since most packages simply won't have a substitution in place for Pre-Depends that debhelper can hook into. Since this is an issue with high potential impact on squeeze->wheezy upgrades, Aurélien suggested that we solicit input from the release team here. Do you guys have any recommendations on how we should handle this, or any other concerns that I may have overlooked? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org [1] i486 is an arbitrary name that happens to correspond to the base instruction set that was in use on Debian at the time multiarch was first formulated, but it doesn't match the current base instruction set on Debian (i586) or Ubuntu (i686), doesn't match the directory configured in the current eglibc package on Ubuntu (/lib/i686-linux-gnu), and is going to look weird to other distributions when we try to talk to them about this since they've also long since moved to i686 as their base compatibility. signature.asc Description: Digital signature
Re: RFC: use of shlib bump for libc dependency on new multiarch directories?
On Wed, Feb 23, 2011 at 11:15:02PM +0100, Philipp Kern wrote: > On Wed, Feb 23, 2011 at 01:52:35PM -0800, Steve Langasek wrote: > > [1] i486 is an arbitrary name that happens to correspond to the base > > instruction set that was in use on Debian at the time multiarch was first > > formulated, but it doesn't match the current base instruction set on Debian > > (i586) or Ubuntu (i686), doesn't match the directory configured in the > > current eglibc package on Ubuntu (/lib/i686-linux-gnu), and is going to look > > weird to other distributions when we try to talk to them about this since > > they've also long since moved to i686 as their base compatibility. > Sorry to skip multiarch[1], but I need to comment on this one. Isn't the > base instruction set still i486? I still haven't found any practical > example of a change of ISA between i486 and i586. For all means they seem > to be equivalent, with i686 being the next break. The only exception that > might be is that 486 can actually lack FPUs, while Pentiums don't. But > for all practically relevant cases I'd assume that they don't, and I'd be > surprised if we'd cater for that. Ah, I don't know the details; I take this as gospel from the GCC maintainers that There Are Differences. Perhaps the differences are only optimization rather than compatibility; but regardless, given that most distros use i586-linux-gnu or i686-linux-gnu as their toolchain triplet, i486-linux-gnu is an odd bird to propose to standardize on. > Out of curiosity: Where will optimized libraries be placed? Multiarch can be combined transparently with hwcaps; so you can have /lib/i386-linux-gnu/i686/cmov/, /lib/alpha-linux-gnu/ev67/, etc. Multiarch also does not require that the libraries installed to the base directory are backwards-compatible with anything that you don't care about, so it's fine to have i686 libraries directly in /lib/i386-linux-gnu on a distro whose baseline is i686, while they're in a hwcap directory for another distro. > [1] As you said pre-depends are messy but the safe bet. It would be best if > we could somehow ensure that libc6 is upgraded first and that everything > needed for the unpack is still there at that point (i.e. some liberal > use of pre-depends somewhere in just the base set instead of everywhere). Ok. I think that's certainly going to be more manageable than trying to add pre-depends to everything, anyway. Any concerns about bumping the dependency for all libraries via dpkg-shlibdeps? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: RFC: use of shlib bump for libc dependency on new multiarch directories?
On Wed, Feb 23, 2011 at 10:55:51PM +, Simon McVittie wrote:
> On Wed, 23 Feb 2011 at 13:52:35 -0800, Steve Langasek wrote:
> > we almost certainly will not be using the path which has been enabled
> > in glibc up to now, namely /lib/i486-linux-gnu.
> I'd heard that, and was somewhat concerned about whether that'd block
> multiarch for yet another release cycle; I'm glad to hear it isn't.
> One possibility that occurred to me is adding a Pre-Depends on a new package
> ("multiarch-enabler", perhaps) which is arch:any and just contains this
> file:
> # /etc/ld.so.conf.d/x86-linux-glibc.conf
> /lib/x86-linux-glibc
> /usr/lib/x86-linux-glibc
> Am I right in thinking that (probably only needed for the native architecture,
> even) would be enough to "bootstrap" support for the multiarch paths in the
> native architecture's linker far enough to perform the upgrade? A future
> libc6 could even Replace it or something.
> (It'd be a bit subtle by being transitively Essential, though.)
Currently I don't see any advantage of doing it this way, rather than having
libc provide this file directly and have affected package pre-depend on
libc. The only reason we might consider a separate binary package closer to
release is if we wind up with circular dependencies that break upgrades from
squeeze; so this is a good idea to keep in our back pocket as a fallback
plan, but until it's shown to be needed I think it's unnecessary complexity
that we should avoid.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
Re: RFC: use of shlib bump for libc dependency on new multiarch directories?
On Thu, Feb 24, 2011 at 12:03:18AM +0100, Andreas Barth wrote: > * Steve Langasek (vor...@debian.org) [110223 22:53]: > > We can handle this one of two ways. We can either bump the minimal > > dependency of *all* packages against libc, by adjusting shlibs/symbols in > > the eglibc package; or we can make adding the dependency a part of the > > standard library multiarchification recipe. > Or third, we could add the new path to eglibc in a stable point > update and into unstable, and either > a) have a virtual package provided, and for the core utilities > pre-depend on that virtual package (so that user systems are never > broken by the upgrade), or > b) don't multiarch the core utilities for the next stable release. b) doesn't help. This is about libraries changing location and making sure that they're on the runtime linker's path; this will affect every core library on the system and there's no way to except the core /utilities/ from that. (If you want a multiarch X stack this cycle, you need a multiarch zlib. Guess what depends on zlib? :) A virtual package is a good idea, though - in fact, it's such a good idea that I remember now we discussed this back at DebConf and I'd subsequently forgotten about it. Thanks for jogging my memory! :) Yes, whether or not we add support in a stable point release, I think that if we don't go the dpkg-shlibdeps route we should use a 'multiarch' or 'multiarch-foo' virtual package. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: RFC: use of shlib bump for libc dependency on new multiarch directories?
On Thu, Feb 24, 2011 at 01:55:57PM +0100, Raphael Hertzog wrote: > On Wed, 23 Feb 2011, Steve Langasek wrote: > > A virtual package is a good idea, though - in fact, it's such a good idea > > that I remember now we discussed this back at DebConf and I'd subsequently > > forgotten about it. Thanks for jogging my memory! :) Yes, whether or not > > we add support in a stable point release, I think that if we don't go the > > dpkg-shlibdeps route we should use a 'multiarch' or 'multiarch-foo' virtual > > package. > But you would put those Pre-Depends: multiarch-foo on the (core) libraries > that should not disappear, right? Yep, exactly. > It seems cleaner to put it there rather than on utilities. > I would also favor any solution that doesn't involve any shlibs bump in > libc. We've gone to great length to have symbols support in many > libraries, it would be a pity to lose the benefits due to multi-arch (even > if multi-arch is great too!). Right, I think there's a consensus to go this direction then, and only add dependencies on a multiarch metapackage for those libraries that install to the new paths. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#614345: pu: package libpng/1.2.44-2
On Sun, Feb 27, 2011 at 08:03:12PM +0100, Julien Cristau wrote: > On Mon, Feb 21, 2011 at 08:12:37 +, Aníbal Monsalve Salazar wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: pu > > I would like to fix an important bug in libpng3. Below is the debdiff > > between the libpng/1.2.44-1 and -2. Is it oaky to upload to p-u? > > diff -Nru libpng-1.2.44/debian/changelog libpng-1.2.44/debian/changelog > > --- libpng-1.2.44/debian/changelog 2010-06-26 13:33:46.0 +1000 > > +++ libpng-1.2.44/debian/changelog 2011-02-21 19:00:14.0 +1100 > > @@ -1,3 +1,11 @@ > > +libpng (1.2.44-2) unstable; urgency=low > > + > > + * debian/libpng3.links: fix up the compat symlink to point to /lib > > +Patch by Steve Langasek > > +Closes: #579074, LP: #284325 > > + > > + -- Anibal Monsalve Salazar Mon, 21 Feb 2011 18:52:13 > > +1100 > > + > > libpng (1.2.44-1) unstable; urgency=low > > > >* New upstream release > > diff -Nru libpng-1.2.44/debian/libpng3.links > > libpng-1.2.44/debian/libpng3.links > > --- libpng-1.2.44/debian/libpng3.links 2006-11-19 15:31:52.0 > > +1100 > > +++ libpng-1.2.44/debian/libpng3.links 2011-02-21 18:55:34.0 > > +1100 > > @@ -1,2 +1,2 @@ > > -/usr/lib/libpng12.so.0 /usr/lib/libpng.so.3 > > +/usr/lib/libpng12.so.0 /lib/libpng.so.3 > > /usr/share/doc/libpng12-0 /usr/share/doc/libpng3 > This looks broken. AIUI the symlink is supposed to be > /usr/lib/libpng.so.3 → /lib/libpng12.so.0, not the other way around. Yep, it's broken. Phooey, not sure how that passed visual inspection, maybe I had my eyes closed at the time. The right line is of course /lib/libpng12.so.0 /usr/lib/libpng.so.3 -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#614345: pu: package libpng/1.2.44-2
BTW, On Sun, Feb 27, 2011 at 08:03:12PM +0100, Julien Cristau wrote: > (Incidentally, for some reason my system seems to still have a > /usr/lib/libpng12.so.0, unknown to dpkg. Not sure where that comes > from.) That seems to be courtesy of ldconfig. If you have libpng-dev installed, ldconfig finds .so files in the directory with an soname of 'libpng12.so.0', doesn't find a file of that name in the directory, so creates a symlink... even though this was already available in /lib. I'd say this is misbehavior on the part of ldconfig since there's no need for this symlink and no way to get around its creation AFAICS. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#614345: pu: package libpng/1.2.44-2
On Sun, Feb 27, 2011 at 08:36:45PM +0100, Julien Cristau wrote: > On Sun, Feb 27, 2011 at 11:30:44 -0800, Steve Langasek wrote: > > On Sun, Feb 27, 2011 at 08:03:12PM +0100, Julien Cristau wrote: > > > (Incidentally, for some reason my system seems to still have a > > > /usr/lib/libpng12.so.0, unknown to dpkg. Not sure where that comes > > > from.) > > That seems to be courtesy of ldconfig. If you have libpng-dev installed, > > ldconfig finds .so files in the directory with an soname of 'libpng12.so.0', > > doesn't find a file of that name in the directory, so creates a symlink... > > even though this was already available in /lib. > Ah, thanks. > > I'd say this is misbehavior on the part of ldconfig since there's no need > > for this symlink and no way to get around its creation AFAICS. > In which case the /usr/lib/libpng.so.3 → libpng12.so.0 symlink isn't > actually broken (once ldconfig runs anyway) so this update isn't > necessary? *only* if you have libpng-dev installed does ldconfig create the symlink. Otherwise there's no target in /usr/lib for it to point to. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#614345: Bug#615558: Bug#614345: pu: package libpng/1.2.44-2
On Sun, Mar 13, 2011 at 03:39:27PM +1100, Aníbal Monsalve Salazar wrote: >* New upstream release > diff -Nru libpng-1.2.44/debian/libpng3.links > libpng-1.2.44/debian/libpng3.links > --- libpng-1.2.44/debian/libpng3.links2006-11-19 15:31:52.0 > +1100 > +++ libpng-1.2.44/debian/libpng3.links2011-03-13 14:40:24.0 > +1100 > @@ -1,2 +1,3 @@ > -/usr/lib/libpng12.so.0 /usr/lib/libpng.so.3 > +/lib/libpng12.so.0 /lib/libpng.so.3 Er, what is this link for? Looks like a gratuitous change. We should only need the link in /usr/lib. > +/lib/libpng12.so.0 /usr/lib/libpng.so.3 > /usr/share/doc/libpng12-0 /usr/share/doc/libpng3 -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#614345: Bug#615558: Bug#614345: pu: package libpng/1.2.44-2
On Sun, Mar 13, 2011 at 04:17:02PM +1100, Aníbal Monsalve Salazar wrote: > On Sat, Mar 12, 2011 at 08:51:16PM -0800, Steve Langasek wrote: > >On Sun, Mar 13, 2011 at 03:39:27PM +1100, Aníbal Monsalve Salazar wrote: > >> * New upstream release > >>diff -Nru libpng-1.2.44/debian/libpng3.links > >>libpng-1.2.44/debian/libpng3.links > >>--- libpng-1.2.44/debian/libpng3.links 2006-11-19 15:31:52.0 > >>+1100 > >>+++ libpng-1.2.44/debian/libpng3.links 2011-03-13 14:40:24.0 > >>+1100 > >>@@ -1,2 +1,3 @@ > >>-/usr/lib/libpng12.so.0 /usr/lib/libpng.so.3 > >>+/lib/libpng12.so.0 /lib/libpng.so.3 > >Er, what is this link for? Looks like a gratuitous change. We should only > >need the link in /usr/lib. > I don't think so. If /usr is not mounted yet, libpng.so.3 will be found > in /lib which also has libpng12.so.0. That was the argument to move > libpng12.so.0 to /lib. libpng3 is a compatibility package. There's no rational reason why this is needed at early boot. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#619988: transition: eglibc 2.13
Only four reverse-deps in the archive that have strict versioned deps on an upstream version of eglibc due to private symbols: libnss-db, dante, libnih, unscd. All leaf packages, currently up-to-date in testing, no entanglements with other current transitions. Other packages may pick up versioned deps on libc 2.13 when uploaded and block other transitions temporarily while eglibc clears, but no two-way entanglement and eglibc 2.13 seems to have been rather thoroughly tested in experimental already so there's reason to believe the transition will be quick. Ack from me, please go ahead. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Bits from the Release Team - Kicking off Wheezy
On Fri, Apr 29, 2011 at 11:28:43PM +0200, Andreas Barth wrote: > > - be less strict and keep old binaries (and thus 2 versions of the same > > source package) in testing. This applies in particular for libraries > > going through SONAME changes and which can happily coexist during a > > transition. > That was already discussed and approved for testing I think in > Helsinki. However, it needs someone implementing code, and isn't as > easy as it looks like. Feel free to submit patches though. I guess that the continued need to run both britney1 and britney2 in parallel is somewhat of a barrier for submitting patches. Any ETA for switching to britney2? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110430210843.gc14...@virgil.dodds.net
Re: move to britney2?
On Sat, Apr 30, 2011 at 11:35:22PM +0200, Andreas Barth wrote: > * Steve Langasek (vor...@debian.org) [110430 23:24]: > > On Fri, Apr 29, 2011 at 11:28:43PM +0200, Andreas Barth wrote: > > > > - be less strict and keep old binaries (and thus 2 versions of the same > > > > source package) in testing. This applies in particular for libraries > > > > going through SONAME changes and which can happily coexist during a > > > > transition. > > > That was already discussed and approved for testing I think in > > > Helsinki. However, it needs someone implementing code, and isn't as > > > easy as it looks like. Feel free to submit patches though. > > I guess that the continued need to run both britney1 and britney2 in > > parallel is somewhat of a barrier for submitting patches. Any ETA for > > switching to britney2? > Last I remember was "after the large transitions are done", which > would be ... now. And yes, that should happen. Ok, great :) > But re the "keeping old libs", that was already an issue before b2 > existed. Also, I seem to remember we discussed that already in > Vancouver, but you should know that better. ;) We certainly did. It's not a new idea, and I certainly don't suggest that switching to b2 will suddenly cause patches to appear. But OTOH, the current muddled state of britney maintenance does make it harder for anyone to submit patches should they wish to do so. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110430230303.gd14...@virgil.dodds.net
Re: nfs-common: compatibility between squeeze and sid broken
reassign 622146 nfs-kernel-server,src:krb5
found 622146 nfs-kernel-server/1:1.2.2-4
found 622146 src:krb5/1.8.3+dfsg-4
fixed 622146 nfs-kernel-server/1:1.2.4-1
fixed 622146 src:krb5/1.9.1+dfsg-1
tags 622146 patch
thanks
On Tue, Jul 19, 2011 at 05:42:34PM -0400, Sam Hartman wrote:
> I don't have checkouts handy, but my strong suspicion is that if someone
> is now passing in GSS_C_NT_HOSTBASED_SERVICE into gssd_acquire_cred and
> there isn't an argument slot, you can leave it off.
> gss_c_nt_hostbased_service has always been the default for gssd.
Ok, thanks. I've built packages of nfs-utils and krb5 using the referenced
backported patches, and can confirm that I'm now able to connect
successfully from an nfs-utils 1.2.4 client without having to set
permitted_enctypes on the server.
I've attached the patches for both packages to this mail. Phil, is it ok
for these to be uploaded to stable-proposed-updates? This fixes a bug that
makes squeeze kerberized NFS servers unusable with newer clients (e.g.,
wheezy).
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -u krb5-1.8.3+dfsg/debian/changelog krb5-1.8.3+dfsg/debian/changelog
--- krb5-1.8.3+dfsg/debian/changelog
+++ krb5-1.8.3+dfsg/debian/changelog
@@ -1,3 +1,11 @@
+krb5 (1.8.3+dfsg-4squeeze2) stable-proposed-updates; urgency=low
+
+ * Non-maintainer upload.
+ * Pull R24603 in MIT upstream subversion to fix support for NFS servers
+on kernels that only support DES. Closes: #622146.
+
+ -- Steve Langasek Fri, 22 Jul 2011 05:07:02 -0700
+
krb5 (1.8.3+dfsg-4squeeze1) stable; urgency=low
* Fix double free with pkinit on KDC, CVE-2011-0284, Closes: #618517
only in patch2:
unchanged:
--- krb5-1.8.3+dfsg.orig/src/lib/gssapi/krb5/accept_sec_context.c
+++ krb5-1.8.3+dfsg/src/lib/gssapi/krb5/accept_sec_context.c
@@ -583,6 +583,15 @@
goto fail;
}
+/* Limit the encryption types negotiated (if requested). */
+if (cred->req_enctypes) {
+if ((code = krb5_set_default_tgs_enctypes(context,
+ cred->req_enctypes))) {
+major_status = GSS_S_FAILURE;
+goto fail;
+}
+}
+
if ((code = krb5_rd_req(context, &auth_context, &ap_req,
cred->default_identity ? NULL : cred->name->princ,
cred->keytab,
diff -Nru nfs-utils-1.2.2/debian/changelog nfs-utils-1.2.2/debian/changelog
--- nfs-utils-1.2.2/debian/changelog 2010-08-26 16:11:45.0 -0700
+++ nfs-utils-1.2.2/debian/changelog 2011-08-01 01:28:03.0 -0700
@@ -1,3 +1,11 @@
+nfs-utils (1:1.2.2-4squeeze1) stable-proposed-updates; urgency=low
+
+ * Non-maintainer upload.
+ * Build with patch d6c1b35c6b40243bfd6fba2591c9f8f2653078c0 from upstream
+for bug #622146.
+
+ -- Steve Langasek Tue, 19 Jul 2011 20:54:17 +
+
nfs-utils (1:1.2.2-4) unstable; urgency=low
* mountd: fix path comparison for v4 crossmnt (Closes: #578317)
diff -Nru nfs-utils-1.2.2/debian/patches/16-negotiate-des-only.patch nfs-utils-1.2.2/debian/patches/16-negotiate-des-only.patch
--- nfs-utils-1.2.2/debian/patches/16-negotiate-des-only.patch 1969-12-31 16:00:00.0 -0800
+++ nfs-utils-1.2.2/debian/patches/16-negotiate-des-only.patch 2011-08-01 01:33:21.0 -0700
@@ -0,0 +1,413 @@
+Description: Upstream changes introduced in version 1:1.2.2-4.1
+ This patch has been created by dpkg-source during the package build.
+ Here's the last changelog entry, hopefully it gives details on why
+ those changes were made:
+ .
+ nfs-utils (1:1.2.2-4.1) UNRELEASED; urgency=low
+ .
+ * Non-maintainer upload.
+ * Build with patch d6c1b35c6b40243bfd6fba2591c9f8f2653078c0 from upstream
+ for bug #622146.
+ .
+ The person named in the Author field signed this changelog entry.
+Author: Steve Langasek
+
+---
+The information above should follow the Patch Tagging Guidelines, please
+checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
+are templates for supplementary fields that you might want to add:
+
+Origin: ,
+Bug:
+Bug-Debian: http://bugs.debian.org/
+Bug-Ubuntu: https://launchpad.net/bugs/
+Forwarded:
+Reviewed-By:
+Last-Update:
+
+--- /dev/null
nfs-utils-1.2.2/utils/gssd/svcgssd_krb5.c
+@@ -0,0 +1,200 @@
++/*
++ * COPYRIGHT (c) 2011
++ * The Regents of the University of Michigan
++ * ALL RIGHTS RESERVED
++ *
++ * Permission is granted to use, copy, create derivative works
++ * and redistribute this software and such derivative works
++ * for any purpose, so long as the name of The University of
++ * Michigan is not used in any advertising or publicity
++ * pertaining to the use o
Re: binNMUs?
On Thu, Aug 25, 2011 at 08:19:09PM +0200, Julien Cristau wrote: > On Mon, Aug 1, 2011 at 15:31:56 +0200, Andreas Barth wrote: > > Also, I think we still have a reason for +b(something) as sometimes we > > just need to rebuild on a single architecture (because something > > strange has happend there), and I don't want to get rid of that > > ability. > The more I think about it, the more I think we should move the binNMU > changelog out of /usr/share/doc and allow co-installation of different > binNMU versions of multi-arch: same packages. (IOW: agreed) Any reason not to ship it as /usr/share/doc/$pkg/changelog.$arch? (I.e., I think /usr/share/doc is still the right place for it, even if it can't be changelog.Debian.gz anymore.) Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Bug#629255: Perl transition blockers: candidates for testing removal
On Fri, Nov 18, 2011 at 06:25:16PM +0100, Luk Claes wrote: > The following packages block the perl transition and will become testing > removal candidates soon unless the bugs get fixed: > * ifeffit (#648839) > * uwsgi (#640347) > * libdbd-interbase-perl (#648857) > * libcrypt-gcrypt-perl (#634598) > * prima (#628500) > * nginx (#649061) > * libsignatures-perl (#636132) > * libpgplot-perl (#648842) > * libtokyocabinet-perl (#649060): maybe mipsel binary should be removed? > * genders (#646286): patch ready, maybe NMU? > * openscap (#649063): maintainer said he would upload today > * libdbd-sybase-perl (#629255): maintainer, this is your ping Ok, uploading. :) > * openldap (#649062): won't be removed, please help fixing it!!! I'll look into this over the weekend, but more help from sparcers is probably helpful here. It's a shame this wasn't caught earlier in the experimental rebuilds. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: gkrellm-snmp links against openssl without exception
tags 508292 lenny-ignore thanks David, Please don't NMU to version 1.1 via t-p-u. It should be sufficient to copy upstream's license exception statement into debian/copyright, which is a much more straightforward fix and avoids clobbering the maintainer's versioning (you should definitely not number an NMU 1.1-1.1 when there hasn't been a 1.1-1 upload by the maintainer!). In fact, I believe that this bug should already not be considered RC for lenny. The licensing information found in debian/copyright is correct, despite the fact that additional permissions have been granted; and because the permission has been granted, there are no licensing problems that make the package itself unreleasable. I'm therefore marking this bug 'lenny-ignore', but cc:ing debian-release so the RMs have an opportunity to override me if they disagree. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Draft for lenny release announcement
On Mon, Feb 09, 2009 at 11:07:28PM +0200, Eugene V. Lyubimkin wrote: > Ben Finney wrote: > > Adeodato Simó writes: > >>> Upgrades [… are automatically handled by the aptitude package > >>> management tool for most configurations, and to a certain degree > >>> also by the apt-get package management tool. > >> This should be consistent with the Release Notes. I haven't been > >> tracking the relevant section there very closely, but I thought > >> apt-get was preferred now over aptitude. > > Whereas I was sure the opposite is true (aptitude is now recommended > > over apt-get). > >> Could you investigate, and swap the order if that's the case? > The preferred tool is aptitude. This is not a matter for you to decide by fiat. The tools recommended in the release notes should be the ones that work most reliably for dist-upgrading from the previous release. Based on various upgrade reports I've seen over the past year, that isn't aptitude. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Whoos with GnuTLS and md5-signed certificates
On Fri, Feb 13, 2009 at 02:46:17PM +0100, Bastian Blank wrote: > GnuTLS stopped accepting MD5 as a proper signature type for certificates > just two weeks before the release. While I don't question the decision > themself, MD5 is broken since 4 years, I question the timing. > Yesterday several people started to complain that they could not longer > connect to their ldap servers, many of them using pam-ldap and nss-ldap. > A quick look showed certificates in the chain which was signed with MD5. > Even many commercial or non-commercial CAs out there have MD5 signed > certs somewhere in the chain and all of them will not longer work now > until this intermediate certs will be trusted explicitely. Most of them > already switched to SHA1 for their enduser certificates. > So now we have a change in Lenny which will break many, many machines. > It is neither properly documented in the NEWS file of the package > themself nor in the release notes. This also bit a number of Ubuntu users when security updates were issued for the GnuTLS CVE, because Ubuntu already had releases out with a GnuTLS-using OpenLDAP: https://bugs.launchpad.net/bugs/305264 The conclusion reached there is that it would be reasonable to patch the OpenLDAP package in the supported Ubuntu releases to allow V1 certs, for "feature"-parity when building with either OpenSSL or GnuTLS. I don't know that this would be appropriate for lenny. For Debian this wasn't a regression introduced in the server in a stable security update - etch's slapd is linked against OpenSSL - and this is only one of a pretty large number of behavior differences between etch's and lenny's slapd. On the client side, OTOH, it is a significant behavior change for both etch and lenny. As for other apps that use GnuTLS, I don't know. For some reason the only reports of problems have been from users of OpenLDAP, not of other TLS-capable services. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
please unblock freetype 2.3.9-4
Hi, freetype 2.3.9-4 is ready to go into testing, but it includes a udeb. debian-boot, is this ok to update? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
current status of alpha in squeeze
Hi Arthur, At DebConf, the release team has discussed the state of the various Debian ports and their viability for squeeze, and a number of concerns were expressed about alpha. I've added a couple more serious issues to the list on <http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-al...@lists.debian.org> which will need attention in order for alpha to release with squeeze, and I'm also told that upstream support for alpha has continued to atrophy - including poor kernel+glibc support, because there is no one taking care of the implementations of new syscalls for the kernel. Buildd statistics at https://buildd.debian.org/stats/graph-quarter-big.png and https://buildd.debian.org/stats/graph2-quarter-big.png are also heading the wrong way, and a recent thread on debian-alpha shows that eglibc 2.10 currently fails its testsuite. Furthermore, I'm told that some Debian folks have been trying to contact you about other matters, but that you may have been unresponsive due to real life committments. Do you still intend to carry the alpha port on your own? At this point, it doesn't look like it will be releasable with squeeze. The release team assessment is that there need to be signs that this is changing over the next month, or else alpha should be dropped from the release planning. Could you please let us know whether you will have time to work on this? Awaiting your reply, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
On Thu, Aug 06, 2009 at 02:21:49PM +0200, Cyril Brulebois wrote: > Luk Claes (06/08/2009): > > If the freeze date is well known in advance the question becomes moot > > unless some maintainer wants to work against the freeze AFAICS. Having > > a known freeze date is meant to help everyone to be able to plan > > better and refrain from doing high impact changes right before the > > freeze. > We already have maintainers working against any kind of common sense. We > have maintainers breaking transitions, delaying them, or starting them > when they're not welcome. We even have a mechanism to enforce sanity > (transition-related upload prevention/blocks). > Why would/should the freeze be treated in a different manner? There have always been, and always will be, a small subset of developers who work against our freezes out of ignorance or even hostility. For the most part, however, developers seem to be pretty good at acting in their own enlightened self-interest, and not behave in ways that are guaranteed to make the freeze longer by making it harder to release. It's hard to measure this quantitatively because you don't have a real control, but certainly my subjective experience is that this is very effective. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: X.org plans for the squeeze cycle
On Thu, Sep 10, 2009 at 09:07:34AM +0200, Vincent Danjean wrote: > Bastian Blank wrote: > > On Wed, Sep 09, 2009 at 11:37:18AM +0200, Julien Cristau wrote: > >> One more thing. Intel plans to deprecate userspace mode setting with > >> their Q4 2009 release (meaning December this year, so probably something > >> we'll want for squeeze, depending on the freeze date you pick). > > Oh, no. Not again. It does not yet properly work without the new memory > > manager (#538442). And KMS is completely unusable currently on this > > kernels. > And in 2.6.31-rc6, KMS is not stable enought to be used for my day-to-day > work. It even leads to data corruption. See #545517 > Since I remove KMS (ie since my bug report), I had no problem at all > (with many many suspend-resume cycles) Results vary, then; with my Intel 945, KMS in 2.6.31-rc8 is much more stable than EXA has been in the recent past. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: libjpeg62-dev -> libjpeg-dev transition
On Sat, Sep 19, 2009 at 07:40:28PM +0200, Pierre Habouzit wrote: > On Sat, Sep 19, 2009 at 07:20:40PM +0200, Pierre Habouzit wrote: > > On Sat, Sep 19, 2009 at 02:32:51PM +0200, Andreas Barth wrote: > > > * Pierre Habouzit (madco...@madism.org) [090919 01:08]: > > > > I'll put blocks in my hint file to be sure that both those packages will > > > > migrate in testing together (I'm unsure if britney is clever enough to > > > > block them until all the binNMUs are done, I don't think it is). Then > > > > please ask for binNMUs of all the package that B-D on libjpeg-dev. Then > > > > we will let that migrate. > > > The question is: Are libjpeg62 and libjepg7 co-useable? (This only > > > works if symbol versioning is turned on.) > > Huh, libjpeg62 and libjpet7 have different so-name so they are > > co-installable. I don't get what you mean with "co-useable" and it > > certainly has nothing to do with symbol versioning. > If you meant things built against libjpeg7 and loading plugins linked > against the libjpeg62 then yes, I think we're good, because libjpeg7 > uses symbol versioning. libjpeg62 doesn't though. Then they're not usable together under any circumstances where libjpeg7 will be loaded into memory first. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: GCC 4.4 run-time license and non-GPLv3 compilers
Hi all, On Fri, Apr 10, 2009 at 02:35:28PM +0200, Florian Weimer wrote: > Starting with version 4.4, the FSF the licenses the GCC run-time > library with a special exception: > | Under Section 7 of GPL version 3, you are granted additional > | permissions described in the GCC Runtime Library Exception, version > | 3.1, as published by the Free Software Foundation. > The exception is reproduced below. Code covered by the exception > includes routines in gcc/libgcc2.c, which are linked statically with > many GCC-compiled programs, providing functionality like 64/64 -> 64 > bit division for 32 bit architectures. (It's not just the C++ > unwinder, as I originally thought.) > > At least with a strict interpretation, the run-time exception suffers > from a significant issue with compilers which are not licensed under a > GPLv3-compatible license (such as the GPLv2, or the QPL), and which > are implemented in the language itself. (One such compiler is > Objective Caml.) After compilation with GCC 4.4, such a compiler is a > "work based on GCC" because it links to the GCC run-time library. > Therefore, it's output cannot use the run-time library exception (it's > not the result of an Eligible Compilation Process because it's neither > the result of running "GCC, alone or with other GPL-compatible > software," nor "it is done without using any work based on GCC"), and > the resulting binary is covered by the GPLv3 (potentially among other > licenses). Bootstrapping the compiler results in a > non-redistributable binary if the compiler is not licensed under a > GPLv3-compatible license (such as the QPL, in the Objective Caml > example). It's been suggested to me that it might help Debian move forward on this issue if I provide some background on why Canonical has chosen to not regard this issue as critical for Ubuntu. The Ubuntu 9.10 release has shipped with gcc 4.4 as the default compiler. Since Ubuntu imports the complete set of packages from Debian, this license incompatibility affects Ubuntu equally as much as Debian. However, unlike Debian, Canonical have concluded that the incompatibility is a nominal one that should not block the switch to gcc 4.4 by default, and have continued to track gcc upstream in the belief that this is a bug in the new license exception: - It is my informal understanding that the change in exception clause was triggered by a specific use case involving non-free language frontends. - The effect of prohibiting incompatibly- but freely-licensed language frontends from using gcc does not appear to be of either strategic or tactical benefit to the FSF or the promotion of Free Software in general. - The lack of prompt reaction from the FSF to this issue (assuming it's actually gotten in front of the right eyes at the FSF yet, which I can't speak to) is not unreasonable: if the exception change was made to fix a bug and has caused a regression, I would expect them to understandably wary of introducing further regressions as a result of further changes. - The Ubuntu development release included gcc 4.4 as the default compiler from April 2009 on, and Ubuntu 9.10 shipped three weeks ago with gcc 4.4 as default (and with a full ocaml rebuild due to a toolchain transition, so this issue definitely applies to the binary package contents of 9.10). The FSF has not contacted Canonical requesting a resolution, in spite of the fact that this has been a fairly high-profile issue (i.e., discussed in LWN). Based on this, I think that there's a preponderance of evidence that using gcc 4.4 together with other language compilers licensed under free but GPL-incompatible terms is consistent with the FSF's intent and as such is not unethical, nor does it pose a significant legal risk to the project or the ftpmasters. It is my recommendation that we therefore switch to gcc 4.4 by default in squeeze, while continuing to reach out to the FSF for resolution of the licensing bug. (In any case, the FSF has a clear history of prioritizing remediation over penalization in the case of unintended license violations, and Canonical is a bit bigger of a target than the Debian ftpmasters if the FSF were after money, so I don't think this should be a source of concern for the ftpmasters. I realize that I'm also not on the line personally for any legal liability on Canonical's side and as a result this may not be very persuasive, but it's my firm belief that this is the right standard for the Debian ftpmasters to use as well.) Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: GCC 4.4 run-time license and non-GPLv3 compilers
Hi Florian, On Sat, Nov 21, 2009 at 01:20:15PM +0100, Florian Weimer wrote: > > It's been suggested to me that it might help Debian move forward on this > > issue if I provide some background on why Canonical has chosen to not regard > > this issue as critical for Ubuntu. > My personal impression is that Debian does not view this issue as > critical, either. Switching the GCC default hasn't happened for other > reasons. Well, in conversations with Matthias, I understand that this is currently the main blocker. > >The FSF has not contacted Canonical requesting a resolution, > The FSF generally licenses their code under GPL, version x "or later", > so they are not affected by this at all. My understanding is that there is a violation of the gcc 4.4 license because the exception is insufficient. So whether or not the FSF holds the copyright on the application /being/ compiled, they're in a position to comment on whether this is the intended result - and in a position to resolve the conflict by amending the exception. > Developers who license their code under the GPL, version 2, and no > later version, have a reason to complain. The OpenSSL and KDE issues > are a precedents showing that we cannot rely on the system library > exception for linking to the run-time library here. So the project's > position will be slightly inconsistent, but I think we can live with > that. In the OpenSSL case, we had definite information that the license conflict would not be resolved. If it came to light that this recent license conflict was deliberate on the part of the FSF, I would certainly support handling it in a consistent manner. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Problems with Debian PowerPC
On Thu, Dec 17, 2009 at 11:39:39PM +0100, Frans Pop wrote: > This looks like a fairly likely reason: > http://packages.debian.org/squeeze/gnome-core > For some reason the package was forced to testing even though it was not > available on all architectures. > If that is the reason, then it means that Gnome is currently not > installable on all but 5 architectures. With powerpc probably the only one > very many people will really care about (though that's a steadily > declining number). > It's almost certain that both the relevant package maintainer and the > release team are already aware of this and that it has been a conscious > choice to accept the breakage. Given that the package version clearly indicates it reached testing by way of testing-proposed-updates, I think it's unwise to assume this. Cc:ing debian-release for input on the uninstallability of gnome in testing. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Please unblock twiki 1:4.0.5-9.1
On Wed, Feb 21, 2007 at 10:22:22AM +0100, Marc 'HE' Brockschmidt wrote: > Christian Perrier <[EMAIL PROTECTED]> writes: > > I have just uploaded a NMU of twiki, to fix its pending l10n > > issues (and, if needed, very minor QA issues). > Unblocked (including the security fix which needed to go to testing > anyway) But is blocked by a policy violation, #410803. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please unblock util-linux_2.12r-18
On Tue, Feb 20, 2007 at 04:39:42PM -0700, LaMont Jones wrote: > Please consider unblocking util-linux_2.12r-18. Unblocked, but -- > mips and mipsel successfully built on feb 5, although the binaries > haven't made it into the archive yet... sadness. This is a problem, it indicates that the mount package wasn't *built* on mips/mipsel -- all the other arch: any binaries are up-to-date on these archs... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnucash and etch freeze
On Tue, Feb 20, 2007 at 08:18:58PM -0800, Thomas Bushnell BSG wrote: > One of the unfortunate side-effects of a freeze is that it becomes very > hard to get necessary changes into etch when an upstream package is a > more rapidly moving target. > In the four months since gnucash 2.0.2 was released, much development > has happened, and upstream has released several more versions. The > general reliability of the program is much improved, with a thousand > small annoyances and crashes fixed. I am told also that some of these > fixes include security-related issues (most importantly, vulnerabilities > through /tmp). > Now I simply do not have the time to go through the changelog, pick out > changes that I think should be in etch and do them. > If the release team shrugs and says, well, ok, go ahead and upload the > new version and we'll consider it as-is for etch, that would be great, > but my understanding is that this is contrary to the release policy. Is > my understanding correct? Does the new upstream version fix the bug in 2.0.2 where it doesn't know the right direction to apply interest payments on bank accounts? I could probably be persuaded to spend quite a disproportionate amount of time reviewing a gnucash update if it takes care of that for me. Alternatively, I accept bribes in the form of RC bugfixes wrapped up with a bow on top. (/Not/ in the same package, it doesn't exactly save the release team any time in that case...) Anyway, there's no hard and fast policy against new upstream versions being allowed in during the freeze. The guidelines are those posted to d-d-a -- we want debdiffs to be small and free of extraneous changes so that they can be quickly reviewed without spending a lot of time puzzling over the impact of changes that aren't relevant in the first place to bugfixes that would warrant a freeze exception. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: unblock request: cups-pdf
On Wed, Feb 21, 2007 at 07:49:47AM +0200, Martin-Éric Racine wrote: > On 2/21/07, Steve Langasek <[EMAIL PROTECTED]> wrote: > >On Wed, Feb 21, 2007 at 04:56:00AM +0200, Martin-Éric Racine wrote: > >> On 2/21/07, Steve Langasek <[EMAIL PROTECTED]> wrote > >> >And has 2.4.2-3 been tested in Debian, given that 2.4.2-2 clearly > >wasn't? > >> kmuto tested it on his system. It works for him. > >Ok, unblocked. > Btw, I'm curious, about what the situation regarding > utf8-migration-tool is. My understanding was that fjp and bubulle > support including this one with Etch to help users migrating from > earlier releases, but earlier requests to this list on this issue > remain unanswered. Frans and Christian have supported the *principle* of having such a tool included in etch, but neither has indicated that they're able to speak for the quality of this *particular* tool. That makes it difficult to judge that allowing this new package in is a safe change that improves Debian, because there's a lack of information available, and this is precisely the sort of tool that screams "will cause data loss if anything goes wrong." Successful use reports from folks using this package in Debian might tip the balance; but in the absence of bug reports, "works good" is indistinguishable from "no one's using it". -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gquilt: RC bug fix (please unblock version 0.17-4)
On Wed, Feb 21, 2007 at 06:40:42PM +1100, Aníbal Monsalve Salazar wrote: > On Wed, Feb 21, 2007 at 01:59:16AM -0500, A. Christine Spang wrote: > >On Wed, Feb 21, 2007 at 05:53:46PM +1100, Aníbal Monsalve Salazar wrote: > >>I'll review it and if it's okay I'll upload it. > >>Could you please sign the .dsc with debsign? > >Done. > Uploaded. And unblocked. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Upgrade
On Wed, Feb 21, 2007 at 12:54:38PM +0100, Frank Küster wrote: > To me that looks a bit more complicated than one would like, but still > quite manageable, and acceptable for fixing a RC bug in etch. > What do you think? It's at least an order of magnitude more complicated (=error-prone) than the solution Romain has implemented, and it still doesn't address the FHS requirement for the actual configuration to be stored under /etc, so I don't see the point. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Upgrade
tags 388616 etch-ignore thanks On Wed, Feb 21, 2007 at 12:22:02PM +0100, Romain Beauxis wrote: > Le jeudi 8 février 2007 22:17, Steve Langasek a écrit : > > > I think the bug #388616 should be granted this etc-ignore. The > > > configuration file is never shiped with the package nor generated by the > > > software. It is generated in config/ directory, and happen normaly only > > > at first install. > > My question here is, if the software looks for the config in /var/lib out > > of necessity, why does the package ship a symlink under /etc/ when that > > symlink a) will overwrite any attempts by the user to turn this into a real > > file (for whatever reason), and b) will complicate upgrades in the future > > when mediawiki's FHS bug is fixed so that the conffile *can* be moved to > > /etc? > I have just uploaded a new package for mediawiki1.7 (-9) that fixes a > security > issue as published in the current 1.7.3 upstream release. > Since -6 I have removed the symlink, added a README and added two deconf > translations. > You may consider this package as an update candidate for mediawiki1.7 Unblocked. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please unblock FAI 3.1.7
Hi Thomas,
On Wed, Feb 21, 2007 at 12:33:21PM +0100, Thomas Lange wrote:
> I like to ask you to unlock FAI 3.1.7.
> If fixes two important bugs (see bug numbers below), and includes two
> documentation fixes.
> * subroutines: ifclass() should append to stderr (closes: #409059)
> * examples/simple/, lib/fai-mount-disk, lib/mount2dir: use bash for
> shell scripts (closes: #410084)
> * fix typo in bug number of older changelog entry
> * install_packages.8: add info for variable MAXPACKAGES
@@ -61,7 +61,7 @@
ifclass() {
-[ "$debug" ] && echo "Test if class $1 is in $classes" >/dev/stderr
+[ "$debug" ] && echo "Test if class $1 is in $classes" >>/dev/stderr
# test if a class is defined
local cl
local ret=1
@@ -69,7 +69,7 @@
for cl in $classes; do
[ x$cl = x$1 ] && ret=0 && break
done
-[ "$debug" ] && echo "ifclass returns $ret" >/dev/stderr
+[ "$debug" ] && echo "ifclass returns $ret" >>/dev/stderr
return $ret
}
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Hrm, this is odd. Why have you not simply written
[ "$debug" ] && echo "Test if class $1 is in $classes" >&2
?
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock texlive-bin
On Wed, Feb 21, 2007 at 03:25:38PM +0100, Frank Küster wrote: > please update the unblock hint for texlive-bin to > unblock texlive-bin/2005.dfsg.2-12 Unblocked. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock texlive-bin
On Wed, Feb 21, 2007 at 03:45:15PM +0100, Lionel Elie Mamane wrote: > > And also note that the fix for the RC bug relies on dvidvi_1.0-9 > > entering etch (if it doesn't, there's a new bug "no dvidvi for > > texlive users"). > He meant dvidvi_1.0-8etch1 (or 1.0-8); 1.0-9 was uploaded to > experimental, contains untested source code changes and should not be > placed in testing. Plus it lacks the changes in -8etch1 wrt to -8. Also unblocked. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock fontconfig 2.4.2-1.1
On Wed, Feb 21, 2007 at 04:08:13PM +0100, Christian Perrier wrote: > I have just uploaded a NMU of fontconfig, to fix its pending l10n > issues (and, if needed, very minor QA issues). > Could you consider hinting it to enter testing? This NMU isn't in incoming or in unstable. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock discover 2.1.1-2.1
On Wed, Feb 21, 2007 at 04:09:17PM +0100, Christian Perrier wrote: > Dear release team, > I have just uploaded a NMU of discover, to fix its pending l10n > issues (and, if needed, very minor QA issues). > Could you consider hinting it to enter testing? Unblocked. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Advice for bug fix
On Wed, Feb 21, 2007 at 06:52:02PM +0100, Thomas Weber wrote: > with the fix for #410070 in octave2.9-2.9.9-8, an FTBFS error in > octave2.9-forge was found (#410463). This turned out to be an error in > the way the unit tests for octave2.9-forge are created at build time. > Unfortunately, in fixing this bug in octave2.9-forge, we hit another bug > in Octave2.9 (which was already fixed upstream some time ago), namely > #411863: one of the unit tests lets Octave use all available memory > until the OOM killer kicks in. So, we currentyl can't build > octave2.9-forge with activated unit tests. > Now, I need your advice: > We can upload fixed packages for both octave2.9 and octave2.9-forge into > unstable and later on they are unblocked (the changes are only a few > lines diff for each bug fix). > Or we upload only a new package for octave2.9-forge, where the unit > tests are disabled. Does that mean the unit tests currently /are/ activated in octave2.9-forge version 2006.07.09+dfsg1-7? If so, of the two choices I would rather see octave2.9 fixed so the unit tests can be run; but I don't understand why you're asking about having fixes for /both/ packages. I certainly don't understand why you're referencing bug #410463, which is only reported against the unstable version of octave2.9. > Octave2.9-2.9.9-8 should enter testing, but I guess Luk mistyped the > numbers: > http://lists.debian.org/debian-release/2007/02/msg00287.html It isn't going to enter anyway right now, because there's an open RC bug; and knowing that the new version of octave2.9 breaks the builds of the octave2.9-forge currently in testing, that rather invalidates the rationale for a freeze exception in the first place, i.e., that it's a non-disruptive bugfix-only update. At the very least, octave2.9-forge needs to be fixed and allowed into testing /first/, before octave2.9 is considered again. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian-31r5-powerpc-binary-1.iso broken
On Thu, Feb 22, 2007 at 11:09:53AM +0100, Holger Levsen wrote: > http://cdimage.debian.org/debian-cd/3.1_r5/powerpc/iso-cd/debian-31r5-powerpc-binary-1.iso > doesnt boot on a "clamshell" ibook nor on a ibook g3 (800mhz). I know that > sarge r0 or r1 worked. > http://cdimage.debian.org/debian-cd/3.1_r5/powerpc/iso-cd/debian-31r5-powerpc-businesscard.iso > > works fine. > P.S.: This is the right lists for this, or? No, the release team doesn't create those images. Please contact debian-cd. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock usbmount
On Thu, Feb 22, 2007 at 12:48:23PM -0500, Noah Meyerhans wrote: > On Fri, Feb 16, 2007 at 12:23:12AM +0100, Richard Atterer wrote: > > If usbmount does not enter etch, this will mean that there is no easy way > > to make the system auto-mount a USB stick that you plug into the machine - > > that would be a bit embarassing! > Does hal take care of this? On my etch system, I plug my ipod or > digital camera into a USB port, and it is automatically mounted and > opened in a konqeror window or in the app of my choice. This worked > by default. hal detects the insertion and sends dbus notifications of the change. the mounting is handled by bits like gnome-volume-manager and whatever the KDE equivalent is called. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please consider myphpmoney for etch
On Thu, Feb 22, 2007 at 10:50:45AM -0200, Herbert P Fortes Neto wrote:
> I'm adopting myphpmoney's package and would
> like to check if the changes i made are acceptable
> for etch.
> ° translations:
> - update public_html/lang/brazilian.inc.php
> - update debian/po/pt_BR.po
> - update {french,english}.inc.php: inc/vars.inc.php -> config/vars.inc.php
> ° sql query. Some words OUT were left behind:
> - close bug #394609. Backquotes near OUT.
> (account.php, newop.php. Nobody complained, but calendar.php also
> need this fix.)
By description this sounds ok, but we'd have to have a final diff to review
(i.e., in the archive) before making any determinations.
> Link to diff.gz
> http://www.txtbox.xpg.com.br/myphpmoney/myphpmoney_1.3RC3+dfsg-2.1.diff.gz
If you're adopting the package, why does this diff have an NMU version
number?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: Bugfix uploads
On Thu, Feb 22, 2007 at 01:42:35AM +0100, Thibaut VARENE wrote: > Vorlon wrote: > >On Tue, Feb 20, 2007 at 03:32:18AM +0100, Thibaut VARENE wrote: > >> I just uploaded libapache-mod-musicindex 1.1.4-1 > >Fairly large diff, fairly low-impact bugs AFAICS; not unblocked. > Err, "fairly large"? The code almost hasn't changed. For a package that's a webserver module, changes to CSS and HTML certainly count as code changes. > The only thing that changed are text strings in said code because I > modified the html that is output (and checked it still valid, of course). > You can assert that by checking that the biggest changes are in html.c and > musicindex.css... I thought it'd be ok, even more since you ACK'd the same > kind of "formatting changes" for uptimed... My understanding is that the changes here are /functional/ changes, not formatting changes to the code: the changelog describes changes to how local overrides are allowed, which could conceivably interact poorly with other ways folks are already using the package even though the html/css shipped by the package itself validates fine. But I'm really not looking for proof that this doesn't happen -- the point is that it doesn't appear to be trivially provable, so given that these aren't updates that we *need* for the release, I'd rather give it a pass and spend my effort on those fixes we do still need in order to get etch out. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Making mediawiki FHS compliant (was: Upgrade)
On Thu, Feb 22, 2007 at 11:17:41AM +0100, Frank Küster wrote: > > It's at least an order of magnitude more complicated (=error-prone) than the > > solution Romain has implemented, > That's correct, not solving the FHS violation is simpler than doing it. > > and it still doesn't address the FHS > > requirement for the actual configuration to be stored under /etc, so I don't > > see the point. > Then we misunderstood each other. I'm always talking about moving the > actual configuration (LocalSettings.php and AdminSettings.php) to > /etc/mediawiki1.7. Ok, it was my understanding from previous comments in the bug history that this couldn't be done non-intrusively, because mediawiki would then look up the real directory and use that value for things that it shouldn't? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock probcons 1.11-1
On Thu, Feb 22, 2007 at 10:40:10AM +0900, Charles Plessy wrote: > the new upstream version of probcons is a bugfix. And how does it fix this bug? There's no information what these '--annot' and '-a' options are supposed to do, and the changes are pretty clearly not fixes to getopt handling... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock mysql-dfsg-5.0 5.0.32-3etch1
On Sat, Feb 24, 2007 at 12:48:19PM +0100, Christian Hammers wrote: > Please allow mysql-dfsg-5.0 version 5.0.32-3etch1 into testing. No, 5.0.32-7 has already been accepted into testing. Sorry, I'm not sure why you uploaded this to t-p-u; I think I said the only blocker for -6 was the translation regression, which is precisely what was fixed in -7? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock xmcd 2.6-19.1
On Fri, Feb 23, 2007 at 06:14:21AM +0100, Christian Perrier wrote: > I have just uploaded a NMU of xmcd, to fix its pending l10n > issues (and, if needed, very minor QA issues). > Could you consider hinting it to enter testing? Another one that never made it to the archive... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packagesearch propagating an important fix
On Fri, Feb 23, 2007 at 07:49:58PM +0100, Benjamin Mesing wrote: > could you please consider propagating the version of packagesearch > currently in unstable (2.2.5) to etch? > It fixes an annoying (important) Bug which made packagesearch crash, if > an invalid input was entered by the user (#408051). Unblocked. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#412006: dvidvi: Please Replace texlive-extra-utils (<< 2005.dfsg.2-12)
On Fri, Feb 23, 2007 at 10:44:53PM +0100, Lionel Elie Mamane wrote: > > The issue could be worked around if dvidvi had a line like > > Replaces: texlive-extra-utils (<< 2005.dfsg.2-12) > > in its control file. > Yes, that's right. I uploaded version 1.0-8etch2 with that fix. Please > consider for unblocking. Unblocked. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fixing the eel2 madness
On Fri, Feb 23, 2007 at 10:54:34PM +0100, Josselin Mouette wrote: > Because of various "small" ABI changes, it looks like *all* packages in > sarge that depend on libeel2-2 don't work with the etch version. To fix > that situation so late in the release process, I have added an > appropriate Conflicts: field and uploaded it to unstable. This is > 2.14.3-3. Unblocked. > Of course, the real solution is to change the SONAME correctly. Because > the ABI seems to have changed in all (well, maybe all but one) GNOME > releases from 2.8 to 2.16, I have added a release number corresponding > to the GNOME version and uploaded it to experimental, which means future > versions won't cause such trouble. This is 2.16.3-2. > If the release team feels like it, I can upload the same fix in > unstable, but it will require a handful of binNMUs for related packages. I'd say we should get 2.14.3-3 into testing first to ensure we have a fix, then we can consider a quick library transition afterwards, yes. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock mserv 0.35-6.3
On Sat, Feb 24, 2007 at 09:27:34AM +0100, Christian Perrier wrote: > I have just uploaded a NMU of mserv, to fix its pending l10n > issues (and, if needed, very minor QA issues). > Could you consider hinting it to enter testing? Unblocked. >* Debconf translations: > - Convert all files to UTF-8 Why this change, though? Isn't it up to l10n teams to decide which character set they choose to work in? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock shaper 2.2.12-0.7.3-2.2
On Sat, Feb 24, 2007 at 10:53:32AM +0100, Christian Perrier wrote: > Dear release team, > I have just uploaded a NMU of shaper, to fix its pending l10n > issues (and, if needed, very minor QA issues). > Could you consider hinting it to enter testing? Unblocked. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock tftp-hpa 0.43-1.1
On Sat, Feb 24, 2007 at 11:49:19AM +0100, Christian Perrier wrote: > Dear release team, > I have just uploaded a NMU of tftp-hpa, to fix its pending l10n > issues (and, if needed, very minor QA issues). > Could you consider hinting it to enter testing? Unblocked. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Securityfix for typo3-src in testing
On Sat, Feb 24, 2007 at 01:00:34PM +0100, Christian Welzel wrote: > There has been found a security vulnerability in typo3 4.0.2 currently > located > in testing. You can find further information here: > http://typo3.org/teams/security/security-bulletins/typo3-20070221-1/ > A bug has been filed against the packages: #412019. > I fixed that hole and made new packages (see debdiff in attachment). > Where should i ask my sponsor Daniel Baumann to upload the fixed packages to? Either to testing (as currently marked in the changelog), or, with the testing-security team's permission, to testing-security. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GNOME packages unblock requests
On Sat, Feb 24, 2007 at 02:28:27PM +0100, Josselin Mouette wrote: > here is another list of packages we'd like to migrate to testing. > atk1.0/1.12.4-2 > * Adds a missing symbolic link in the documentation directory. > gnome-desktop/2.14.3-2 > * New Malayalam translation. > gnome-menus/2.16.1-3 > * Gets gmenu-simple-editor to work again. > yelp/2.14.3-2 > * Now recommends ttf-dejavu, which includes all cabalistic symbols > needed by some manuals. All unblocked. > libxklavier/2.2-5 > * Fixes a scary realloc bug (yes, look at the patch, it's scary > that people write such code). Hahaha, awesomesauce. Also unblocked. > metacity/1:2.14.5-4 > * Fixes a long-standing bug that can make the session lock for 2 > minutes upon login. I don't follow all the consequences of this change, so not unblocked at this point. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Accept keyutils 1.2-2
On Sat, Feb 24, 2007 at 03:36:08PM +0100, Daniel Baumann wrote: > please accept keyutils 1.2-2 where the binary packages were renamed to > match the common naming scheme. --- keyutils-1.2/debian/compat +++ keyutils-1.2/debian/compat @@ -1 +1 @@ -4 +5 Not appropriate during a freeze. Otherwise looks ok; please revert this debhelper bump and it can be unblocked. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: update upgrade-manager in Etch
On Sat, Feb 24, 2007 at 02:06:17PM -0200, Gustavo Noronha Silva wrote: > Sven Arvidsson provided us with a Debianized version of the > update-manager manual (making it refer to Debian repository names and > using the Debian release names). This went into update-manager > 0.42.2ubuntu22-11. I would like to request that it be approved for Etch > as soon as possible. > update-manager (0.42.2ubuntu22-11) unstable; urgency=low >* debian/manual.tar.uu, debian/rules: >- install the Debian specific version of the manual > modified by Sven Arvidsson <[EMAIL PROTECTED]> (Closes: #410916) Hrm. Why is this not available as a simple diff against the manual, instead of as a uuencoded blob? Unblocked anyway as a documentation update, but I wonder if you wouldn't want something a little bit more maintainable in the future... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please unblock mdadm 2.5.6-9
On Sat, Feb 24, 2007 at 05:07:54PM +0100, martin f krafft wrote: > Hi release team, > please unblock mdadm 2.5.6-9. I only added two debconf translations: > http://packages.qa.debian.org/m/mdadm/news/20070224T160206Z.html Unblocked. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please allow libimdb-film-perl into testing
On Sat, Feb 24, 2007 at 05:37:29PM +0100, Bas Zoetekouw wrote: > I just uploaded a new version of libimdb-film-perl. It fixes the package to > work with the new IMDB.com layout that was rolled out earlier this week. The > old version, which is currently in testing, (0.22-1) is pretty much useless > with the new IMDB.com site. Could you please allow the new package into > testing? This sudden breakage speaks to the suitability of such a package for stable; we can't really support a screen-scraper module that depends on the stability of a third-party website. Wouldn't it be better to drop this package from etch, and push it over to volatile? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock xmcd 2.6-19.1
On Sat, Feb 24, 2007 at 06:05:10PM +0100, Christian Perrier wrote: > > > Could you consider hinting it to enter testing? > > Another one that never made it to the archive... > Sigh. Happens sometimes when I upload from work as I have to rebound > through my home server, which prompts for a passphrasewhich I > sometimes just forget to type..:) > Re-uploaded. @@ -4,11 +4,11 @@ -Description: Enter the device name of the CD drive for xmcd to use: +_Description: Device name of the CD drive for xmcd to use: + In order to function properly, xmcd requires at least a device name of the + CD drive which should be used for playback. Possible examples of the CD drive + device names are /dev/cdrom (this is usually a symbolic link), /dev/sr0 or + /dev/scd0 (for SCSI or SCSI-emulated devices), /dev/hdc or /dev/hdd (for IDE + devices). Based on the supplied value the default configuration files will be + generated. You can always reconfigure and customize xmcd by running the + /usr/sbin/xmcdconfig script later. + . See /usr/share/doc/xmcd/README.Debian for important information on how to properly enable access to CD drives and CD database for unprivileged users. - . - In order to function properly, xmcd requires at least a device name of the - CD drive which should be used for playback. Possible examples of the CD drive - device names are /dev/cdrom (this is usually a symbolic link), /dev/sr0 or - /dev/scd0 (for SCSI or SCSI-emulated devices), /dev/hdc or /dev/hdd (for IDE - devices). Based on the supplied value the default configuration files will be - generated. You can always reconfigure and customize xmcd by running the - /usr/sbin/xmcdconfig script later. This change isn't documented in the changelog. Have these template changes been approved of by the maintainer? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock tvtime 1.0.2-0.2
On Sat, Feb 24, 2007 at 07:29:59PM +0100, Christian Perrier wrote: > I have just uploaded a NMU of tvtime, to fix its pending l10n > issues (and, if needed, very minor QA issues). > - Convert all po-debconf translations to UTF-8 In this case, this includes a Japanese translation, so I'm very much not comfortable with approving such a change unless I know it's been signed off on by a member of the Japanese l10n team. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock amavisd-new 1:2.4.2-6.1
On Sat, Feb 24, 2007 at 07:39:39PM +0100, Christian Perrier wrote: > I have just uploaded a NMU of amavisd-new, to fix its pending l10n > issues (and, if needed, very minor QA issues). Unblocked. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please unblock kino 0.92-3
Hi Paul, On Sat, Feb 24, 2007 at 08:37:20PM +0100, Paul Brossier wrote: > Video capture in kino was fixed in 0.92-3 (#406670). It would be nice if > this version could be unblocked. * Rebuild with --without-dv1394 instead of --with-dv1394 (closes: 406670) This is obviously a change with non-local effects. Is this going to break anything else? Should I understand that the effect of --without-dv1394 is to cause kino to use some internal dv1394 implementation instead of the libdv1394 in the archive? In that case, why should we accept a workaround such as this instead of looking for a proper fix for whatever libdv1394 incompatibility exists? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock xmcd 2.6-19.1
On Sun, Feb 25, 2007 at 07:27:29AM +0100, Christian Perrier wrote: > > This change isn't documented in the changelog. Have these template changes > > been approved of by the maintainer? > Yes. The whole NMU has been coordinated with the maintainer who is > currently trying to recover his GPG key in the keyring which had been > deactivated a while ago.. Ok, unblocked. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RC bug fixed in qps
Marc has already noted why this fix is insufficient. Some further comments
below.
On Sun, Feb 25, 2007 at 03:30:04AM +0100, René Mérou wrote:
> Here is the interdiff:
> ---
> interdiff qps_1.9.18.6-1.diff qps_1.9.18.6-2.diff
> diff -u qps-1.9.18.6/debian/changelog qps-1.9.18.6/debian/changelog
> --- qps-1.9.18.6/debian/changelog
> +++ qps-1.9.18.6/debian/changelog
> @@ -1,3 +1,9 @@
> +qps (1.9.18.6-2) unstable; urgency=low
> +
> + * Does not fails to build. Closes: #411845
> +
> + -- René <[EMAIL PROTECTED]> Sat, 24 Feb 2007 17:37:04 +0100
> +
This is not a proper changelog entry. A changelog is for recording what you
*changed*; all you've given here is a text description of the bug.
> this are the changes made in rules:
> before:
> clean:
> dh_testdir
> dh_testroot
> rm -f build-stamp
> rm -f proc.cpp
> [ ! -f Makefile ] || { $(MAKE) distclean && rm -f Makefile; }
> after:
> clean:
> dh_testdir
> dh_testroot
> rm -f build-stamp
> #rm -f proc.cpp
Please don't leave useless comments behind when changing code; this
needlessly clutters the code later, and in fact makes reviewing the diff
more time-consuming.
> [ ! -f Makefile ] || { $(MAKE) distclean && rm -f Makefile; }
> dh_clean proc.cpp
FWIW, an ideal fix is for the upstream distclean rule to clean up this file
it's created, so I highly recommend that as the long-term fix. For the
immediate fix, that's not a requirement.
But the build failures on alpha, mips, and mipsel also show an error in the
upstream distclean target; they're creating, and leaving behind, .obj
directories owned by the user running the clean target (with -rsudo, this is
root), instead of leaving a genuinely clean build directory.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Accept keyutils 1.2-2
On Sun, Feb 25, 2007 at 08:14:39AM +0100, Daniel Baumann wrote: > Steve Langasek wrote: > > please revert this debhelper bump and it can be > > unblocked. > done, uploaded 1.2-3. And unblocked. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mozilla codebase releases 1.8.1.2 and 1.8.0.10
On Sun, Feb 25, 2007 at 09:39:46AM +0100, Mike Hommey wrote: > I'll let the RMs decide whether iceape and icedove upgrades are less > problematic since they don't involve reverse dependencies. Less problematic, certainly. Hopefully these updates won't have the problem of past mozilla new-upstream-version "security" fixes, where every single file shows up in the diff because of cvs keywords? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#388616: Making mediawiki FHS compliant
On Mon, Feb 26, 2007 at 09:25:42AM +0100, Frank Küster wrote: > > You say that while later on you claimed not to understand everything about > > the > > package (update script). Don't you have the impression that this judgement > > is > > also based on incomplete information on the package ? > Of course, but how does that matter? The point is simply, if the > release managers intend to keep the etch-ignore pattern, What "pattern" are you talking about? > Therefore I'm asking the release team whether they still think that the > etch-ignore tag should stay. Yes, it should. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please unblock kino 0.92-3
On Sun, Feb 25, 2007 at 03:20:37PM +0100, Daniel Kobras wrote: > On Sat, Feb 24, 2007 at 07:32:39PM -0800, Steve Langasek wrote: > > * Rebuild with --without-dv1394 instead of --with-dv1394 (closes: 406670) > > This is obviously a change with non-local effects. Is this going to break > > anything else? > > Should I understand that the effect of --without-dv1394 is to cause kino to > > use some internal dv1394 implementation instead of the libdv1394 in the > > archive? In that case, why should we accept a workaround such as this > > instead of looking for a proper fix for whatever libdv1394 incompatibility > > exists? > There is no libdv1394 -- you're probably mixing it up with libdv. dv1394 > is a kernel interface to capture dv data that has been deprecated for > quite a while. It's superseded by libiec61883, and that's what kino uses > now. I don't know why the --with-dv1394 was added to the Debian package > in the first place, but this option is strongly discouraged upstream and > gave rise to several problem reports both upstream and in the Debian BTS > whereas capture via libiec61883 is in good, supported shape and just > works. Ok, thanks for the clarification; unblocked. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please really unblock fdutils 5.5-20060227-1.1
On Mon, Feb 26, 2007 at 08:23:42AM +0100, Christian Perrier wrote: > Marc 'HE' Brockschmidt a écrit : > > Christian Perrier <[EMAIL PROTECTED]> writes: > >> I have just uploaded a NMU of fdutils, to fix its pending l10n > >> issues (and, if needed, very minor QA issues). > >> Could you consider hinting it to enter testing? > > Doesn't seem to be uploaded. > Now uploaded. And unblocked. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: zd1211-firmware: diff for NMU version 2.16.0.0-0.1
On Wed, Feb 21, 2007 at 04:26:28PM -0500, Joey Hess wrote: > [debian-release: This mail serves as both an NMU diff an an unblock request. > Please review and unblock.] Unblocked. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please unblock fltk1.1 1.1.7-3 (translation-only upload)
On Mon, Feb 26, 2007 at 04:49:08PM -0500, Aaron M. Ucko wrote: > Could you please allow fltk1.1 1.1.7-3 into etch once its waiting > period runs out? As the attached interdiff shows, it merely adds one > new translation and bumps the Standards-Version: field. Unblocked. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock whereami 0.3.31
On Tue, Feb 27, 2007 at 05:20:50PM +1300, Andrew McMillan wrote: > > | diff -Nru /tmp/qpzj5f816b/whereami-0.3.29/debian/rules > > /tmp/Kw0yU5sM8K/whereami-0.3.31/debian/rules > > | --- /tmp/qpzj5f816b/whereami-0.3.29/debian/rules2006-11-12 > > 00:33:18.0 + > > | +++ /tmp/Kw0yU5sM8K/whereami-0.3.31/debian/rules2007-02-25 > > 18:46:51.0 + > > | @@ -11,10 +11,6 @@ > > | # Uncomment this to turn on verbose mode. > > | export DH_VERBOSE=1 > > | > > | -# This is the debhelper compatability version to use. > > | -export DH_COMPAT=3 > > Not unblocked. Changing the dh compat level changes the build process, > > and I really don't want to fish trough all possible consequences for > > some minor fixes. If you really want the new version in etch, re-upload > > with this change reverted. > Is it better to exactly revert this change, or to change the level in > debian/compat from 4 (what it is at the present) to 3? The aim is to exactly revert the effect of this change. The DH_COMPAT=3 is what takes precedence, so that's the only thing that should be changed. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock htdig 1:3.2.0b6-3.1
On Tue, Feb 27, 2007 at 08:32:41AM +0100, Christian Perrier wrote: > I have just uploaded a NMU of htdig, to fix its pending l10n > issues (and, if needed, very minor QA issues). Unblocked. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock ax25-apps 0.0.6-14.1
On Tue, Feb 27, 2007 at 08:33:44AM +0100, Christian Perrier wrote: > > I have just uploaded a NMU of ax25-apps, to fix its pending l10n > issues (and, if needed, very minor QA issues). Again includes a switch to UTF-8 for a Japanese translation; need confirmation from the Japanese l10n team that this is ok before I'll unblock it. Otherwise ok. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock ax25-apps 0.0.6-14.1
On Tue, Feb 27, 2007 at 09:42:10PM +0900, Kenshi Muto wrote: > At Tue, 27 Feb 2007 04:19:43 -0800, > Steve Langasek wrote: > > On Tue, Feb 27, 2007 at 08:33:44AM +0100, Christian Perrier wrote: > > > I have just uploaded a NMU of ax25-apps, to fix its pending l10n > > > issues (and, if needed, very minor QA issues). > > Again includes a switch to UTF-8 for a Japanese translation; need > > confirmation from the Japanese l10n team that this is ok before I'll unblock > > it. > It seems OK for me. Ok, unblocked. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock wide-dhcpv6 20061016-2
Hi Jérémie, On Tue, Feb 27, 2007 at 12:44:25AM +0100, Jérémie Corbier wrote: > A new version of wide-dhcpv6 has been uploaded to unstable a few days ago. > Could > you please let it enter etch? > Changelog entry: > wide-dhcpv6 (20061016-2) unstable; urgency=low > >* debian/control: added lsb-base as a dependency. Why are you adding this as a dependency? Is this currently a /missing/ dependency? There's nothing else in the diff that explains why this would be added. >* debian/patches: > -> Added 01_bugfixes_20061227.dpatch: >+ Bug fixes from CVS 20061227. >+ dhcp6relay accepts Unique Local IPv6 unicast Addresses. >+ Fix an IA allocation failure from pool in dhcp6s. >+ Fix "-P" option in dhcp6s. None of which appear to be major problems in the package today? > -> Updated 02_Makefile.in.dpatch. Which is a rename of an earlier patch, making review more time-consuming; and parts of the original patch are apparently merged upstream (and the rest is redundant in light of dh_fixperms). This doesn't look like a candidate for a freeze exception to me. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock octave2.9-2.9.9-8etch1 and octave2.9-forge-2006.07.09+dfsg1-8 [was: Re: Advice for bug fix]
On Tue, Feb 27, 2007 at 02:04:09PM +0100, Thomas Weber wrote: > (I would appreciate if you could give octave2.9 back on arm. The build > timed out when creating a shared library.) Done. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: request for transition of mesa, and binNMU of xorg-server
On Tue, Feb 27, 2007 at 07:56:48PM +0100, Julien Cristau wrote: > the latest mesa NMU fixed a bug which caused an X server crash when > using blender. Could you please unblock mesa/6.5.1-0.6 and schedule > binNMUs of xorg-server to completely fix this bug? binNMUs scheduled on all archs except s390. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock ifplugd 0.28-2.3
On Tue, Feb 27, 2007 at 07:57:09PM +0100, Christian Perrier wrote: > I have just uploaded a NMU of ifplugd, to fix its pending l10n > issues (and, if needed, very minor QA issues). Unblocked. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock wide-dhcpv6 20061016-2
On Wed, Feb 28, 2007 at 04:03:00AM +0100, Jérémie Corbier wrote: > On Tue, Feb 27, 2007 at 04:57:11PM -0800, Steve Langasek wrote: > > > wide-dhcpv6 (20061016-2) unstable; urgency=low > > > > > >* debian/control: added lsb-base as a dependency. > > This doesn't look like a candidate for a freeze exception to me. > Well, I would not have asked for an upload if I had not received [0] > confirmation that it could be a candidate for a freeze exception. Ok, then I guess Marc has already looked at the package, and should add the unblock hint as well. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#412904: openser: CVE-2006-6875 / CVE-2006-6876 still unfixed in Etch
On Thu, Mar 01, 2007 at 09:57:34AM +0100, Julien BLACHE wrote: > >>> While these two vulnerabilities have been fixed in sid in 1.1.1, they > >>> still affect Etch: > >> OpenSER 1.1.1 is a bugfix-only release, so I am again requesting an > >> unblock for openser 1.1.1-1, in light of those two CVEs. > > We can continue this game, though it won't bring us anywhere... > > 116 files changed, 4498 insertions(+), 3113 deletions(-) > There are indeed a lot of bug fixes; there's a reason why I'm asking > for the unblock, you know. On terms contrary to the release team's freeze guidelines, which exist for a reason. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock eject_2.1.4-3
On Thu, Mar 01, 2007 at 01:38:12PM +0100, Frank Lichtenheld wrote: > Please allow eject 2.1.4-3 into etch, it only contains l10n changes. > eject builds an udeb. Unblocked. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock linsmith for etch
On Wed, Feb 28, 2007 at 12:50:15PM -0300, Margarita Manterola wrote: > The linsmith version in sid was updated 20 days ago to include a couple > of bugfixes. This is the changelog entry: > linsmith (0.99.1-2) unstable; urgency=low >* Added font_name_buffer.dpatch from 0.99.2 to fix a possible > buffer overflow with very long font names. >* Added other_buffers.dpatch from 0.99.3 to fix some other, less important, > buffer overflows. (Closes: #403298) > -- Margarita Manterola <[EMAIL PROTECTED]> Thu, 8 Feb 2007 17:05:16 > These bugs are not RC, since the buffer overflows are not easy to > exploit, but they are still buffer overflows, and thus I'd like to see > this fixes in etch. Unblocked. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
