Bug#1036884: transition: time64_t
Please binNMU fyba on armhf and armel. The maintainer uploaded it without versioned build-deps so it is renamed but has wrong ABI. This needs to be built with dpkg-dev (>= 1.5.22), gcc-13 (>= 13.2.0-16.1). -- 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
Bug#1036884: transition: time64_t
We are going to need a lot of binNMUs for the time_t transition of course, but we're not quite ready to do the mass binNMUs. In the short term, can you please binNMU apt for libgnutls30t64? This needs to be built with dpkg-dev (>= 1.5.22), gcc-13 (>= 13.2.0-16.1), and libgnutls28-dev (>= 3.8.3-1.1). -- 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
Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timelineg
On Wed, Jan 17, 2024 at 09:33:12PM -0800, Steve Langasek wrote:
> And my proposal for checking that set, since we're only talking about
> runtime library packages, is to check whether any of the contents of these
> packages in bookworm match ^/lib - as a runtime library package NOT matching
> this pattern, but matching a pattern for one of the other aliased
> directories, would be something ... special.
Binary packages in bookworm shipping libs in /lib* (i.e. /lib, /lib32,
/lib64):
$ ssh -C coccia.debian.org zcat \
/srv/mirrors/debian/dists/bookworm/'*'/Contents-armhf.gz \
| awk -F/ '/^lib.*\.so/ { print $NF }' | sort -u | wc -l
222
$
Binary packages in experimental that are to be renamed:
$ for pkg in $(cat reports/lfs-and-depends-time_t reports/runtime-libs); do \
sed -n -e"s/Package: \($pkg\)$/\1/p" \
/var/lib/apt/lists/*experimental*Packages; \
done | sort -u | wc -l
130
$
$ join -j1 usrmerge-libs experimental-libs
libpam0g
$
I'll follow up on that.
--
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
Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hi Colin,
On Tue, Jan 09, 2024 at 01:32:11PM +, Colin Watson wrote:
> On Mon, Jan 08, 2024 at 03:01:11PM -0800, Steve Langasek wrote:
> > On Fri, Jan 05, 2024 at 09:17:52PM +0100, Paul Gevers wrote:
> > > On 05-01-2024 17:36, Rene Engelhard wrote:
> > > > Also a problem is that experimental also might already contain totally
> > > > unrelated updates like new upstream versions...
> > > I share this worry. Have you thought about how to handle the cases where
> > > you
> > > don't have experimental to upload to? How big is this problem?
> In the current situation, though, not having experimental available
> means that there's no opportunity for dumat to weigh in regarding
> usrmerge interactions, which seems problematic given Helmut's
> preliminary analysis.
I guess this is a reply to the bits of context I retained above rather than
directly a reply to my most immediate preceding message. In a separate
subthread, I laid out what I thought the process should be for handling the
transition of packages in that situation; but you are raising a separate
point.
Which parallels what Helmut had to say:
> Whenever you face files in aliased locations (other than systemd units),
> please go via experimental to let dumat judge your upload. Check the
> bookworm package for files in aliased locations, not the unstable one.
I have also had other out-of-band conversations with Helmut about the
overlapping issues between usrmerge and time_t, so this was generally
speaking on my radar although I didn't address it in my proposed transition
plan.
I think it is unrealistic to ask experimental to be otherwise quiesced of
transitions to ensure that we can stage all of the affected libraries in
experimental, and I also think that making false transitions for packages
that are ALREADY in experimental because of transitions would be
counterproductive. ("False" because if the library package has a different
soname between unstable and experimental, then renaming the runtime library
package in the *experimental* version is unnecessary because there's nothing
"in the wild" depending on that package name but with the old ABI for which
upgrade compatibility is of concern.)
My preferred path forward here would be, as Helmut suggests, to check which
libraries are in the intersection of (packages in experimental for which we
won't stage time_t uploads) and (packages that exist in bookworm and need
transitioning of aliased paths), and ensure that these packages are handled
carefully according to Helmut's own guidance. My optimistic expectation is
that the intersection will be null, or nearly; but in any case I will bring
data.
And my proposal for checking that set, since we're only talking about
runtime library packages, is to check whether any of the contents of these
packages in bookworm match ^/lib - as a runtime library package NOT matching
this pattern, but matching a pattern for one of the other aliased
directories, would be something ... special.
--
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
Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Fri, Jan 05, 2024 at 09:17:52PM +0100, Paul Gevers wrote: > Hi Steve, > On 05-01-2024 17:36, Rene Engelhard wrote: > > Also a problem is that experimental also might already contain totally > > unrelated updates like new upstream versions... > I share this worry. Have you thought about how to handle the cases where you > don't have experimental to upload to? How big is this problem? > Another worry, how will you provide the required changes to the maintainers > of the packages? Via BTS? For those working on salsa: MR? Both? Something > else? Obviously we should not end in the situation that a new upload goes > back to the old name (or are the ftp-masters so keen on this transition that > that won't happen? But what about newer versions with the old name already > in experimental, conform the former worry?). I've seen NMU's being ignored > by subsequent uploads by the maintainer, even when they fixed RC issues > which were then reintroduced. I would intend to provide diffs via the BTS. This remains the standard policy for NMUs in Debian per the Developer's Reference, and as far as I know has worked effectively for all such previous ABI transitions. I think it is reasonable to expect maintainers to pay attention to their bug mail as our defined Debian process. I don't think it would be reasonable to expect people working on cross-archive toolchain transitions to cater to individual maintainer preference in this regard. If a maintainer ignores the NMU and drops the rename, they'll be introducing a new library transition again on 32-bit archs. Won't they also be caught again in binary NEW, for those packages that don't have the same runtime library package name in experimental? It seems to me there's ample opportunity to catch such mistakes if they happen. -- 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
Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Mon, Jan 08, 2024 at 04:12:42PM +0100, Julian Andres Klode wrote: > > - once these packages have all cleared binary NEW, the new dpkg defaults > > will be uploaded to unstable > What happened to the plan to workaround this by doing dak database > shenanigans prior to uploading to avoid binary-NEW altogether, that > I chatted about with mhy/#debian-ftp and you? Did that not work out? That wasn't called out here but is part of the implementation details of the plan. The intention is still to go through binary NEW in experimental before copying to unstable, because it will take time to get all the binary uploads done (longer than it will take to get the sourceful uploads to unstable done), so it's better to stage in experimental to minimize the window in unstable when uploads can be broken. -- 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
Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Sat, Jan 06, 2024 at 09:25:52AM +0100, Rene Engelhard wrote:
> Hi,
> Am 06.01.24 um 06:51 schrieb Steve Langasek:
> > > > - dpkg will be uploaded to experimental with 64-bit time_t in the
> > > > default
> > > > flags
> > [...]
> > What about the suggestion to not push changes to experimental for packages
> > that already have new versions in experimental, and do the binary package
> > renames in unstable instead, leaving the package in experimental alone?
> How does that play together with the needed dpkg only in experimental?
> You can't build stuff for unstable involving experimental packages (except
> manually with binary upload, which would block testing migration)
The ordering here would be:
- dpkg will be uploaded to experimental with 64-bit time_t in the default
flags
- the source packages which need an ABI change
("source-packages"+"lfs-and-depends-time_t") and do not already have
versions in experimental, will have sourceful NMUs to experimental with
the new binary package names in order to clear binary NEW, in coordination
- once these packages have all cleared binary NEW, the new dpkg defaults
will be uploaded to unstable
- source packages which need an ABI change but already have versions in
experimental will be uploaded to unstable, with binaries, to clear binary
NEW
- sourceful NMUs of all the libraries will be reuploaded to unstable
(without binaries, so that they can be promoted to testing without
additional uploads).
- perl will also get a sourceful upload, to manually handle 'perlapi'
Provides.
- binNMUs will be scheduled for all of the reverse-dependencies.
--
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
Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Sat, Jan 06, 2024 at 09:07:15AM +0100, Rene Engelhard wrote:
> Am 06.01.24 um 06:51 schrieb Steve Langasek:
> > > > - dpkg will be uploaded to experimental with 64-bit time_t in the
> > > > default
> > > > flags
> > > I think at that point in time one should know what breaks and whatnot.
> > > Archive rebuild?
> > > (Probably in stages)
> > What kind of breakage are you looking to avoid here?
> build failures/test failures.
> > As mentioned in other points in the thread, regressions as a result of
> > this change should be rare and easy to fix. I do not think it's a good
> > use of time / CPU power to do test rebuilds for this instead of just
> > landing the transition.
> Here especially LibreOffices bridge code worries me.
> That one is tied to ABI and calling conventions. I don't see time_t
> mentioned there but "just" in the public libraries (sal), but I am not sure
> what making a type bigger will cause.
> (And since already
> - i386 needs gcc-12 to build since otherwise the test fails
> - armhf (and other archs like ppc64el and s390x) need Java disabled[1] -
> without any help from any porter to prevent this - I *do* want to avoid
> breakage here.
> If you say you are going to fix eventual breakage (and not ignoring the test
> results!) and if that means fixing asm on all affected archs, then it's OK
> :)
Well, yes; though I hope we would see some help from e.g. arm porters if
there were actually breakage of this nature. Alternatively, maybe it would
be better to stop shipping libreoffice on 32-bit archs, in that case? I'm
not sure how usable libreoffice is these days on such archs.
popcon.debian.org doesn't appear to have the granularity to tell us if there
actually *are* users; and with only 615 armhf popcon reports (vs 215,562 on
amd64) we don't exactly have a statistically significant sample there.
> > > > - the source packages which need an ABI change
> > > > ("source-packages"+"lfs-and-depends-time_t" will have sourceful
> > > > NMUs to
> > > I get that you probably want NMUs for not needing to ping every
> > > maintainer,
> > > but this is bad.
> > > That e.g. would cause me to upload libreoffice 24.2 rc2 to sid immediately
> > > when tagged end of next week to not have this caught in the transition.
> > > (see
> > > also below for the comment about new upstream versions in experimental.)
> > What about the suggestion to not push changes to experimental for packages
> > that already have new versions in experimental, and do the binary package
> > renames in unstable instead, leaving the package in experimental alone?
> If at all - *both*. At the same time.
Most of these packages that are staged in experimental are going to be there
because of library transitions... so I think we definitely don't want to be
renaming those binary packages, they should just drop the t64 suffix when
they move to unstable.
> But yes, that could work.
> (In this specific case I an worrying that the transition will take some
> time, and that I am stuck with 7.6.x instead of uploading 24.2 when it is
> released.)
Ok. I don't think there would be any need for you to wait before uploading
24.2. It might have to wait for time_t for testing migration, but I don't think that should really be long.
> > > > experimental with the new binary package names in order to clear
> > > > binary
> > > > NEW, in coordination
> > > And what about skipped ones? When will those be tried?
> > What do you mean here by "skipped ones"?
> https://adrien.dcln.fr/misc/armhf-time_t/2023-12-18/results_skipped.txt
> (which incidentially contains libreoffice)
Ah! These are packages that have been omitted from the analysis because
they've been manually identified as packages that don't have C or
C++-compatible header files related to a shared library, and therefore even
if they do need updated for 64-bit time_t, they are not affected by CPPFLAGS
and are not part of this transition. (I am not 100% sure this is accurate
for ObjC; in any case ObjC headers are impossible to analyze using
abi-compliance-checker so if ObjC libraries are possibly affected, someone
would have to figure out what to do with them.)
I'm not sure precisely why Adrien found it necessary/useful to add
libreoffice-dev to this exclude list, but I can confirm that it's
reasonable, as this particular package contains only a single header file
with #define's and no function prototypes; so in effect it has been manually
analyzed and determined to be unaffected.
--
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
Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Fri, Jan 05, 2024 at 05:36:10PM +0100, Rene Engelhard wrote:
> > My strawman proposal is to give this thread 2 weeks from today for feedback
> > and further refinement, and also to further reduce the number of
> > false-positives included in the transition. Then, starting on Jan 18:
> > - dpkg will be uploaded to experimental with 64-bit time_t in the default
> >flags
> I think at that point in time one should know what breaks and whatnot.
> Archive rebuild?
> (Probably in stages)
What kind of breakage are you looking to avoid here? As mentioned in other
points in the thread, regressions as a result of this change should be rare
and easy to fix. I do not think it's a good use of time / CPU power to do
test rebuilds for this instead of just landing the transition.
> > - the source packages which need an ABI change
> >("source-packages"+"lfs-and-depends-time_t" will have sourceful NMUs to
> I get that you probably want NMUs for not needing to ping every maintainer,
> but this is bad.
> That e.g. would cause me to upload libreoffice 24.2 rc2 to sid immediately
> when tagged end of next week to not have this caught in the transition. (see
> also below for the comment about new upstream versions in experimental.)
What about the suggestion to not push changes to experimental for packages
that already have new versions in experimental, and do the binary package
renames in unstable instead, leaving the package in experimental alone?
libreoffice libs only have one reverse-dep, zemberek-ooo; so the risk of
entanglement here is small anyway.
I think the above proposal, to skip packages already in experimental from
the set of uploads to experimental, would address your concern. It's not as
if there is going to be any time that it's ok to tell maintainers they can't
use experimental at all because we're doing this transition.
> >experimental with the new binary package names in order to clear binary
> >NEW, in coordination
> And what about skipped ones? When will those be tried?
What do you mean here by "skipped ones"?
--
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
Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Fri, Jan 05, 2024 at 12:05:57PM +, Simon McVittie wrote: > On Fri, 05 Jan 2024 at 00:17:04 -0800, Steve Langasek wrote: > > - In multi-library packages, there is no reliable way to map from a set of > > headers in a dev package to specific shared libraries in a runtime library > > package that's not additionally computationally prohibitive; we therefore > > conservatively assume that if any headers from a source package show > > time_t ABI changes, all the runtime library packages from the source > > package are affected by the transition. > > 0 dbus-tests > Please ignore this specific binary package. The only public API/ABI > of src:dbus is in libdbus-1-3 + libdbus-1-dev, so analyzing those two > is enough. (dbus-tests accidentally contains one header file, but that's > a minor bug.) > libdbus-1-dev is widely depended-on, so I hope that taking src:dbus off > your list will avoid some unnecessary rebuilds? > > 0 gobject-introspection > Similarly the only public API/ABI of src:gobject-introspection is in > libgirepository1.0-dev, libgirepository-1.0-1, and (in experimental) > libgirepository-1.0-dev. gobject-introspection contains some source > and header files that are used by other packages' regression tests, > but they are not public ABI. Yes, sorry - the way my scripts are set up to do the analysis right now, these packages still show up in the `sorted-revdep-count` list but there are manual overrides mapping both of these to an empty set of runtime libraries. So you'll see they don't show up in the `runtime-libs` or `source-packages` lists, and none of the reverse-dependencies of libdbus or libgirepository are tagged for rebuild. https://salsa.debian.org/adrien-n/armhf-time_t/-/blob/c62a594236374469b2181e9c5578ed124b57c48c/packagelist.py#L304 -- 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
Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
e included in the transition. I have
identified a list of 53 packages in this category (list attached); these in
turn have 174 additional reverse-dependencies that would need rebuilt (list
attached).
== Migration plan ==
I have yet to receive any feedback from the Release Team on this bug
regarding finding a slot for this transition.
https://release.debian.org/transitions/ shows some ongoing transitions of
libraries that need to be included in the time64 transition (gmsh,
gnuradio...) and I have no opinion about whether these need to be resolved
first before proceeding with the mass rebuild.
My strawman proposal is to give this thread 2 weeks from today for feedback
and further refinement, and also to further reduce the number of
false-positives included in the transition. Then, starting on Jan 18:
- dpkg will be uploaded to experimental with 64-bit time_t in the default
flags
- the source packages which need an ABI change
("source-packages"+"lfs-and-depends-time_t" will have sourceful NMUs to
experimental with the new binary package names in order to clear binary
NEW, in coordination
- once these packages have all cleared binary NEW, the new dpkg defaults
will be uploaded to unstable
- the sourceful NMUs of the libraries will be reuploaded to unstable
(without binaries, so that they can be promoted to testing without
additional uploads).
- perl will also get a sourceful upload, to manually handle 'perlapi'
Provides.
- binNMUs will be scheduled for all of the reverse-dependencies.
Please let me know of any problems with this plan.
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 Developer https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
[0] https://lists.debian.org/debian-devel/2023/07/msg00232.html
[1] https://lists.debian.org/debian-devel/2023/07/msg00302.html
1938 qt5-qmake
1745 qtbase5-private-gles-dev
253 libgfortran-13-dev
253 gfortran-13
228 postgresql-server-dev-16
228 libpq-dev
201 libpython3.11-dbg
178 ruby3.1-dev
152 krb5-multidev
132 octave-dev
126 qt6-base-private-dev
126 qmake6
126 libqt6opengl6-dev
100 libhdf5-mpich-dev
92 wx3.2-headers
80 libcanberra-gtk-common-dev
79 qtwebengine5-private-dev
76 cups-ppdc
63 libd3dadapter9-mesa-dev
54 libphonon4qt6experimental-dev
51 htslib-test
48 samba-dev
48 libldb-dev
46 libperl5.36
43 qtquickcontrols2-5-private-dev
43 libnetcdf-dev
42 libhiredis-dev
41 libuv1-dev
41 libminizip-dev
40 sudo-ldap
39 qttools5-private-dev
39 libopencv-videoio-dev
39 libopencv-ml-dev
39 libopencv-imgproc-dev
39 libopencv-flann-dev
39 libopencv-core-dev
39 libopencv-contrib-dev
38 libgeos++-dev
33 libstdc++-12-dev
33 libgfortran-12-dev
33 libgccjit-12-dev
33 gnat-12
33 gfortran-12
33 gcc-12-plugin-dev
26 libpython3.12-dev
26 libpython3.12-dbg
26 libfuse3-dev
25 llvm-16-dev
25 libunwind-16-dev
25 libpolly-16-dev
25 libmlir-16-dev
25 libloadpng4-dev
25 libclc-16-dev
25 libclang-rt-16-dev
25 libclang-16-dev
25 libc++-16-dev
25 liballeggl4-dev
24 qtwayland5-private-dev
22 libobs-dev
22 libboost1.83-dev
21 librosbag-storage-dev
21 libimath-dev
20 libvtk9-dev
19 libstdc++-9-dev
19 libgfortran-9-dev
19 libgccjit-9-dev
19 libgcc-9-dev
19 gfortran-9
19 gcc-9-plugin-dev
18 libnma-headers
16 lua-socket-dev
16 libscotchmetis-dev
16 libarpack2-dev
16 libanthyinput-dev
15 libbpp-core-dev
14 liborc-0.4-dev
14 libnode-dev
14 gnuradio
13 libtss2-dev
12 rados-objclass-dev
12 libradosstriper-dev
12 libphobos2-ldc-shared-dev
12 libomniorb4-dev
12 android-platform-system-core-headers
12 android-libnativehelper-dev
12 android-libbase-dev
10 libsmpeg-dev
10 libplib-dev
10 libmumps-headers-dev
10 libmagickcore-6-headers
10 libmagickcore-6-arch-config
10 libgccjit-13-dev
10 libformsgl-dev
10 heimdal-multidev
9 qt6-webengine-private-dev
9 lxc-dev
9 libwebsockets-dev
9 libpskc-dev
9 libopenmpt-dev
9 libogre-1.9-dev
9 libgirara-dev
9 libgegl-dev
9 libc-client2007e-dev
8 qt6-websockets-private-dev
8 libzbargtk-dev
8 libvolk-dev
8 libkf5akonadisearch-dev
8 libgnunet-dev
8 libefisec-dev
8 libdynamicedt3d-dev
8 libcamera-calibration-parsers-dev
7 libstonith1-dev
7 libsofia-sip-ua-dev
7 libqglviewer-headers
7 libmono-2.0-dev
7 liblrm2-dev
7 libini-config-dev
7 libgnome-bluetooth-dev
7 libdune-common-dev
7 libbullet-extras-dev
7 libagg-dev
7 gsoap
6 libslepc64-real3.18-dev
6 libslepc64-complex3.18-dev
6 libslepc-real3.18-dev
6 libslepc-complex3.18-dev
6 libqpdf-dev
6 libcolord-gtk-headers
6 asterisk-dev
6 aircrack-ng
5 skalibs-dev
5 qt6-tools-private-dev
5 python3-pyopencolorio
5 llvm-14-dev
5 libxqdbm-dev
5 libxdp-dev
5 libwolfssl-dev
5 libvibrant6-dev
5 libunwind-14-dev
5 libsynfig-dev
5 libstdc++-10-dev
5 libsource-highlight-dev
5 libsmc-dev
5 libsigrokcxx-dev
5 libowfat-dev
5 libopenmm-dev
5 libogre1.12.10
5 libogre-1.12-dev
5 libncbi6-dev
5 libnauty2-dev
5 libmutter-
Bug#1036884: 64-bit time_t: an update
Hi folks, Two months ago, I posted with a proposal for how to handle a transition to 64-bit time_t on 32-bit archs in the trixie cycle. https://lists.debian.org/debian-devel/2023/05/msg00168.html We have pretty good consensus on the path forward; however, at the time I posted I had hoped to have an archive analysis done within a month, so that this could be staged as the first major transition after trixie opened. This timeline proved to be very optimistic. The problem is that, to understand the impact that a change to the size of time_t will have on a library's ABI, it must be possible to compile the headers that expose that API; and we have a significant number of -dev packages in the archive that for one reason or another don't straightforwardly compile out of the box. The Ubuntu Foundations team have been putting in effort over the past two months, package-by-package, to figure out how to make them compile so that we know if their ABI is affected. However, despite a significant investment of effort, we still have roughly 1500 -dev packages still in need of analysis, and have sustained a rate of processing only around 50 -dev packages a week. The "good" news is that, although there are over 1500 -dev packages yet to be analyzed, we have prioritized libraries based on the number of reverse-dependencies and therefore these 1500 -dev packages have among them less than 300 reverse-build-dependencies that have not already been identified as part of the transition (800 of these -dev packages have no reverse-build-dependencies at all). Therefore, I would like to propose the following. - Assume the remaining 1500 -dev packages are affected by the ABI breakage. This will increase the number of library packages included in the transition requiring sourceful uploads from < 500 to 2000[1], but will only increase the number of packages requiring rebuilds from 5300 to 5600. - Agree a target window together with the Release Team for when the transition will be uploaded to unstable; and based on this, set a deadline beforehand for finalizing the list of library packages whose binary package names will be changed. - We in Ubuntu Foundations will continue on a best effort basis to drive down the list of -dev packages which cannot be analyzed, until that deadline. - Any party (maintainer or otherwise) interested in having some of these library packages excluded from the transition is welcome to contribute fixes up to that deadline that will let us analyze them and show that the ABI has not changed. Your thoughts? -- 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 [1] All numbers approximate: the analysis that has been completed so far has been done against Ubuntu lunar as a stable reference base. The Debian transition will of course be done based on a complete analysis of unstable, which is in progress separately. libgnome-rr-4-dev libhfsp-dev libhx-dev libibnetdisc-dev libip6tc-dev libipmiconsole-dev libipset-dev libisns-dev libisoburn-dev libixion-dev libjpeg-turbo8-dev libklibc-dev libkrad-dev libksba-dev liblasso3-dev libldacbt-abr-dev libldb-dev liblouisutdml-dev liblrm2-dev libmaa-dev libmircommon-dev libmiroil-dev libmirplatform-dev libmirwayland-dev libmlir-14-dev libmozjs-102-dev libmutter-11-dev libnetplan-dev libntirpc-dev libnutscan-dev liborcus-dev libotf-dev libpils2-dev libportal-dev libpskc-dev libptexenc-dev libpython3.10-dev libpython3.11-dev libradosstriper-dev libreoffice-dev libsource-highlight-dev libsss-certmap-dev libsss-simpleifp-dev libstdc++-11-dev libstdc++-12-dev libstonith1-dev libsysmetrics-dev libtotem-dev libunwind-14-dev libunwind-15-dev libusbredirhost-dev libuwac0-dev libverto-dev libvolume-key-dev libwhoopsie-dev libwhoopsie-preferences-dev lua-rrd-dev python3-ldb-dev python3-talloc-dev rhythmbox-dev ruby3.0-dev ruby3.1-dev samba-dev slapi-dev libblimps3-dev libfishcamp-dev libopenvr-dev libparmetis-dev libtestu01-0-dev libttspico-dev 389-ds-base-dev android-libandroidfw-dev android-libselinux-dev android-libsepol-dev android-libunwind-dev angelscript-dev atfs-dev cairo-dock-dev casacore-dev cauchy-dev codeblocks-dev coinor-libbonmin-dev coinor-libcbc-dev libfprint-2-tod-dev dovecot-dev irssi-dev isc-dhcp-dev libaal-dev libapache2-mod-perl2-dev bind9-dev libcanberra-gtk-common-dev libclc-14-dev libclc-15-dev libd3dadapter9-mesa-dev libdpkg-dev libfreeradius-dev libglvnd-core-dev libmirrenderer-dev libpinyin-common-dev libpolly-15-dev libradospp-dev libreiser4-dev libreofficekit-dev libubi-dev mir-renderer-gl-dev ocfs2-tools-dev php8.1-dev rados-objclass-dev remmina-dev zsh-dev libamgcl-dev libjulius-dev libthrust-dev notion-dev ableton-link-dev android-libbase-dev android-libcutil
Bug#1036884: transition: time64_t
Package: release.debian.org User: release.debian@packages.debian.org Usertags: transition Severity: normal Dear Release Team, I had started a thread on debian-devel[1] about the need to migrate 32-bit architectures to 64-bit time_t in preparation for 2038, an ABI-breaking change. As the discussion on debian-devel has died down, I think it's time to formally put this request on debian-release's radar. I believe the last time we had an archive ABI change was before the Release Team's current policy on transitions was put into place. As mentioned in that thread, there are probably more than 400 libraries whose ABIs/package names are affected (380 identified to date); a list of these is attached. I've provided a mock ben config below; a real one could be synthesized once the analysis is finished, though I'm not sure how useful it would be. Also mentioned in the thread[2], it would be quite cumbersome to start this transition in experimental (since it's toolchain-driven rather than source-driven) but getting all of the binary packages through NEW in experimental (with the wrong ABI) may help with timing. I'm open to guidance here. Due to the broad and disruptive nature of this change, I am writing to request a slot for the transition, preferably the first in the upcoming trixie cycle. I have not build-tested the reverse-build-dependencies. There are at least 5000 source packages in unstable that need rebuilt as part of this transition. Some of them will likely show they have regressed in buildability, including some that are currently in testing; hopefully a very small number since we are about to release. There is discussion of whether we should enable -Werror=implicit-function-declaration as part of the ABI transition. If so, that will increase the number of build failures, though also hopefully only a bit. I do not expect build failures as a direct result of the ABI transition. If you do want build tests before upload to unstable, guidance is welcome. Ben file: title = "time64_t"; is_affected = .depends ~ "old=/^.*$/" | .depends ~ "new=/^.*64t$/"; is_good = .depends ~ "new=/^.*64t$/"; is_bad = .depends ~ "old=/^.*$/"; -- 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 [1] https://lists.debian.org/debian-devel/2023/05/msg00168.html [2] https://lists.debian.org/debian-devel/2023/05/msg00260.html libevince-dev binutils-dev libabsl-dev libaio-dev libapr1-dev libaprutil1-dev libarchive-dev libasound2-dev libatm1-dev libatspi2.0-dev libauparse-dev libbtrfsutil-dev libc-ares-dev libcamel1.2-dev libclamav-dev libcups2-dev libcupsfilters-dev libcupsimage2-dev libcurl4-gnutls-dev libcurl4-nss-dev libcurl4-openssl-dev libdb5.3++-dev libdb5.3-dev libdb5.3-stl-dev libdbi-dev libdv4-dev libelf-dev libevent-dev libfcgi-dev libfido2-dev libgnutls28-dev libgphoto2-dev libgpod-dev libgps-dev libgsound-dev libgxps-dev libieee1284-3-dev libipa-hbac-dev libisofs-dev libiw-dev libknet-dev libmemcached-dev libmtdev-dev libmtp-dev libnatpmp-dev libnpth0-dev libnutclient-dev liboath-dev libp11-dev libpam0g-dev libparted-dev libpath-utils-dev libpcap0.8-dev libpkcs11-helper1-dev libpng-dev libpoppler-glib-dev libpsl-dev librados-dev librasqal3-dev libraw-dev librdf0-dev libreadline-dev librrd-dev librsync-dev libsoup2.4-dev libstatgrab-dev libtevent-dev libtokyocabinet-dev libudf-dev libupsclient-dev libv4l-dev libvformat-dev pacemaker-dev uuid-dev libopenzwave1.6-dev libricohcamerasdk-dev android-libboringssl-dev libext2fs-dev libglibmm-2.4-dev libgnome-bg-4-dev libgnome-desktop-4-dev apache2-ssl-dev libglib2.0-dev android-liblog-dev clearsilver-dev davix-dev drac-dev hexchat-dev itcl3-dev itk3-dev libace-flreactor-dev libace-foxreactor-dev libace-htbp-dev libace-inet-dev libace-inet-ssl-dev libace-rmcast-dev libace-ssl-dev libace-tmcast-dev libace-xtreactor-dev libacexml-dev libadns1-dev libaldmb1-dev liballegro-acodec5-dev liballegro-audio5-dev liballegro-dialog5-dev liballegro-physfs5-dev liballegro-ttf5-dev liballegro-video5-dev libapache2-mod-form-dev libaribb24-dev libbamf3-dev libbitstream-dev libbpp-phyl-omics-dev libbpp-popgen-dev libbpp-qt-dev libbpp-raa-dev libbpp-seq-dev libcapi20-dev libcbf-dev libccrtp-dev libcdk5-dev libchicken-dev libclalsadrv-dev libcli-dev libclthreads-dev libcmis-dev libcmph-dev libcmtspeechdata-dev libcoap2-dev libcppdb-dev libcpuset-dev libctemplate-dev libcudf-dev libcw-dev libcwiid-dev libczmq-dev libdaq-dev libdigidoc-dev libdmtx-dev libeasyloggingpp-dev libeb16-dev libebook-contacts1.2-dev libebook1.2-dev libecal2.0-dev libedata-book1.2-dev libedata-cal2.0-dev libedataserverui4-dev libev-dev libev-libevent-dev libevemu-dev libexplain-dev libfixbuf-dev libfizmo-
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: 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: Proposed (lib)curl switch to openssl 1.1
is 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: 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 <vor...@debian.org> --- 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: 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: 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: 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 libkexiv2 libkml libkolab libkolabxml libktoblzcheck libloki libmatroska libmediainfo libmems libmsn libmusicbrainz3 libmusicbrainz5 libmwaw libnzb libodfgen libofa libopenraw
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 vor...@debian.org 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 sramac...@debian.org
-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: Release Team Sprint Results
Hi Jonathan, On Sun, Nov 09, 2014 at 11:52:31AM +, Jonathan Wiltshire wrote: Release notes = We seek patches and editors for the release notes. We identified the following topics as being particularly important: - init system changes - How to choose (before upgrading) - Pros / cons of upgrading - i486 support dropped I'm rather certain that i486 hasn't been supported in Debian for at least the past 4 years (and probably much longer, my memory is fuzzy; but as a data point, https://lists.debian.org/debian-devel/2011/11/msg00687.html). Why is this on the release team's radar as something that needs to be documented in the release notes for jessie? -- 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: Release Team Sprint Results
On Mon, Nov 10, 2014 at 09:33:07PM +, Adam D. Barratt wrote: [re-adding -devel@] On Mon, 2014-11-10 at 21:20 +, Adam D. Barratt wrote: On Mon, 2014-11-10 at 13:08 -0800, Steve Langasek wrote: Hi Jonathan, On Sun, Nov 09, 2014 at 11:52:31AM +, Jonathan Wiltshire wrote: [...] - i486 support dropped I'm rather certain that i486 hasn't been supported in Debian for at least the past 4 years (and probably much longer, my memory is fuzzy; but as a data point, https://lists.debian.org/debian-devel/2011/11/msg00687.html). Why is this on the release team's radar as something that needs to be documented in the release notes for jessie? I believe this was intended as a reference to this change in the latest Linux kernel upload: * [i386] Rename 486 flavour to 586, as it has not worked on 486 processors since we enabled CC_STACKPROTECTOR (Closes: #766105) Ok, well, given that Debian didn't work on 486 for years before that, I think this is a non-event that doesn't need to be release-noted. However, given that this fatal bug has not (so far as I know) been reported in the 5 years since it was introduced in unstable, I suspect you're one of a very few people still using Debian on a 486, and you may find many other things broken. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766105#28 -- 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: Re: Re-Proposal - preserve freedom of choice of init systems
On Sat, Oct 18, 2014 at 03:26:57AM +0100, Jonathan de Boyne Pollard wrote: Perhaps if you picked something other than runit you'd make your point more effectively. Try using the case of someone who makes a tool that depends from System V init running as process #1. It is hardly farfetched. I've seen at least two people publicly point out in the past several months that they had something set up in /etc/inittab that broke when they switched to an alternative bootstrap system. (A lot of people conflate init with rc. It's not System V init that other bootstrap systems sometimes provide shims and compatibility mechanisms for. It's System V rc, more specifically the /etc/rc?.d/* scripts that it runs.) There's also a Debian bug or two. So the question that you should be asking to make your point is probably this: The resolution says that In general, software may not require a specific init system to be pid 1.. Does this mean that softwares that make use of /etc/inittab, which is peculiar to (in Ian Jackson's own words) a specific init system (its contents, outwith sometimes the run level line, being not processed at all by any of upstart, systemd, runit-init, s6-svscan, the nosh system or service managers, minit, jinit, or finit), are unfit for inclusion in Debian according to Ian Jackson's resolution? Yes, they almost certainly would be unfit for inclusion. Which is actually the status quo today, as inittab is a non-conffile config file with no management interface to permit additional packages to hook into it - making it a policy violation for other packages to edit this file. So I believe the requirements here are symmetric, and there's certainly no reason to think that the requirements are onerous because it would forbid integrating with /etc/inittab. -- 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#731261: transition: Qt5 switching qreal == double for all platforms
On Tue, Dec 10, 2013 at 01:01:06PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: On Friday 06 December 2013 16:02:50 Steve Langasek wrote: Best practice for the case where upstream has changed ABI without changing SONAME is to keep the SONAME the same (for consistency with third-party binaries), but to change the Debian package name. For past examples of this, see the C++ c2a transition; the libc5/libc6 'g' transition; the ldbl transition; the odbcinst1debian2 package; etc. While Debian could get away with doing a spot rebuild and not change the package name for the ABI change (since there are few revdeps and the library hasn't made it into a stable release), Ubuntu cannot because Ubuntu has had a stable release that made heavy use of qt5. As Ubuntu would like to stay as close as possible to Debian for Qt packaging, I (and other Ubuntu developers) would appreciate it if Debian did do the library package name change (which is per se more correct, anyway). The cost to Debian is fairly small for doing this, just a single round-trip through NEW, and it simplifies the handling of the revdeps since you don't need to add any versioned conflicts against each of them to ensure a consistent system. I see your point here. And I think the only lib we would really need to rename is libqt5core5 to libqt5core5a. The rest depends heavily on it, so this single change should simply work. Does that seems OK for you? That sounds like it meets the requirements. Note that renaming only the one package may in practice make the upgrade path more difficult to calculate; you may want to rename more of the libraries based on practical feedback once you've uploaded. -- 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#731261: transition: Qt5 switching qreal == double for all platforms
Hi folks, Best practice for the case where upstream has changed ABI without changing SONAME is to keep the SONAME the same (for consistency with third-party binaries), but to change the Debian package name. For past examples of this, see the C++ c2a transition; the libc5/libc6 'g' transition; the ldbl transition; the odbcinst1debian2 package; etc. While Debian could get away with doing a spot rebuild and not change the package name for the ABI change (since there are few revdeps and the library hasn't made it into a stable release), Ubuntu cannot because Ubuntu has had a stable release that made heavy use of qt5. As Ubuntu would like to stay as close as possible to Debian for Qt packaging, I (and other Ubuntu developers) would appreciate it if Debian did do the library package name change (which is per se more correct, anyway). The cost to Debian is fairly small for doing this, just a single round-trip through NEW, and it simplifies the handling of the revdeps since you don't need to add any versioned conflicts against each of them to ensure a consistent system. 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 Archive: http://lists.debian.org/20131207000250.gc5...@virgil.dodds.net
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
On Sun, Nov 03, 2013 at 11:54:34AM +0100, Niels Thykier wrote: On 2013-10-29 17:48, Ian Jackson wrote: Niels Thykier writes (Re: Bits from the Release Team (Jessie freeze info)): [...] As mentioned we are debating whether the 5 DDs requirement still makes sense. Would you say that we should abolish the requirement for DD porters completely? I.e. Even if there are no (soon to be) DDs, we should consider the porter requirements fulfilled as long as they are enough active porters behind the port[0]? I don't have a good feel for the answer to that question. It's just that if it is the case that a problem with ports is the lack of specifically DDs, rather than porter effort in general, then sponsorship is an obvious way to solve that problem. If you feel that that's not really the main problem then a criterion which counts porters of any status would be better. I suppose a sponsor-only DD could be sufficient, provided that the sponsor knows the porters well enough to be willing to sign off on e.g. access to porter boxes. I guess the sponsor would also need to dedicate time to mentor (new?) porters on workflows and on quicks like when is a FTBFS RC and when it isn't etc. Why would the sponsor need to be involved in getting the porters access to porter boxes? Porter boxes exist so that DDs *not* involved in a port have access to a machine of the architecture and can keep their packages working. I've never heard of a porter who didn't have access to their own box for porting work. -- 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#708248: transition: json-c
On Fri, May 17, 2013 at 12:27:20PM +0200, Ondřej Surý wrote: I have verified that libjson0 with just symlinks works (running psensor), and building with libjson0-dev ends with libjson-c2 as ^^ dependency (upstart). Thus I am ready to upload the package to unstable. Again, you should not be renaming the libjson0 package to libjson-c2. The binary package name should *only* change when there is a backwards-incompatible ABI change, which there isn't here as long as libjson.so.0 is provided as a symlink. So this should be a *non* transition. Having newly-built packages end up with an ELF dependency on libjson-c.so.2 is fine - but the binary package name should remain libjson0. -- 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 Ondrej On Thu, May 16, 2013 at 1:29 PM, Ondřej Surý ond...@sury.org wrote: Good question. I guess I got stuck in the upstream way of 'compatibility'. That's the best solution. I'll prepare the packages in experimental and we'll see. Ondřej Surý On 16. 5. 2013, at 12:03, Julien Cristau jcris...@debian.org wrote: On Thu, May 16, 2013 at 08:25:32 +0200, Ondřej Surý wrote: Hi Steve, On Thu, May 16, 2013 at 5:41 AM, Steve Langasek vor...@debian.org wrote: Hi Ondřej, On Tue, May 14, 2013 at 03:12:02PM +0200, Ondřej Surý wrote: JSON-C upstream has renamed the library from libjson.so to libjson-c.so, headers are now in /usr/include/json-c and pkg-config is called json-c. There's a compatibility layer (symlinks and libjson.so.0), but since the library has so few r-deps, I feel that we might not need it to make things more simple in the future. The upstream is planning to drop the compatibility layer in next release anyway, so we would have to do the transition in some other point in time. Not necessarily. If the ABI has not changed, there is no reason that we should not keep the compatibility layer in place in Debian *indefinitely*. For another example of this, see libcurl3-gnutls. There are some new symbols in libjson-c library and _no_ symbols in libjson Why isn't libjson.so.0 a symlink to libjson-c.so.2 then? Cheers, Julien -- Ondřej Surý ond...@sury.org signature.asc Description: Digital signature
Bug#708248: transition: json-c
Hi Ondřej, On Tue, May 14, 2013 at 03:12:02PM +0200, Ondřej Surý wrote: JSON-C upstream has renamed the library from libjson.so to libjson-c.so, headers are now in /usr/include/json-c and pkg-config is called json-c. There's a compatibility layer (symlinks and libjson.so.0), but since the library has so few r-deps, I feel that we might not need it to make things more simple in the future. The upstream is planning to drop the compatibility layer in next release anyway, so we would have to do the transition in some other point in time. Not necessarily. If the ABI has not changed, there is no reason that we should not keep the compatibility layer in place in Debian *indefinitely*. For another example of this, see libcurl3-gnutls. I wrote to fabien, and I still need to hear from him, but I took the liberty to build the packages and you can find preliminary updated packages here: https://www.sury.org/json-c/ There are no library symbols removed (just added), so the transition should be relatively painless (you will just have to do s/json/json-c/ in your packages). Ben file: title = json-c; is_affected = .depends ~ libjson0 | .depends ~ libjson-c2; is_good = .depends ~ libjson-c2; is_bad = .depends ~ libjson0; It looks like you're coupling a transition of the runtime library package name with a transition of the build-time API. The first is not required at all - the runtime library package name should change IFF there is a backwards-incompatible ABI change, which there isn't in this case *unless* we drop the compat symlink (which we therefore should just never do). The second could arguably be made a soft transition, with backwards-compatibility support added so that this doesn't gum up testing transitions unnecessarily; but as you point out, the set of affected packages is small, and as long as it's not coupled with an unnecessary change to the runtime lib package name this is probably acceptable - but this is a question the release team should decide on. -- 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#707301: release-notes: odbcinst1debian2 : Breaks: tdsodbc ( 0.82-8) but 0.82-7 is to be installed
-mysql [ amd64 ] none
- 1.7.2-3 ( misc ) (= 1.7.2-3)
Considering akonadi-backend-mysql:amd64 -1 as a solution to
akonadi-server:amd64 1
Try Installing akonadi-backend-mysql [ amd64 ] none - 1.7.2-3 ( misc )
before changing akonadi-server:amd64
Investigating (1) tdsodbc [ amd64 ] 0.82-7 - 0.91-2 ( libs )
Broken tdsodbc:amd64 Breaks on libiodbc2 [ amd64 ] 3.52.6-4 - 3.52.7-2 (
libs )
Considering libiodbc2:amd64 2 as a solution to tdsodbc:amd64 0
Holding Back tdsodbc:amd64 rather than change libiodbc2:amd64
Investigating (2) odbcinst1debian2 [ amd64 ] 2.2.14p2-1 - 2.2.14p2-5 (
libs )
Broken odbcinst1debian2:amd64 Breaks on tdsodbc [ amd64 ] 0.82-7 - 0.91-2
( libs ) ( 0.82-8)
Considering tdsodbc:amd64 0 as a solution to odbcinst1debian2:amd64 3
Upgrading tdsodbc:amd64 due to Breaks field in odbcinst1debian2:amd64
Investigating (2) tdsodbc [ amd64 ] 0.82-7 - 0.91-2 ( libs )
Broken tdsodbc:amd64 Breaks on libiodbc2 [ amd64 ] 3.52.6-4 - 3.52.7-2 (
libs )
Considering libiodbc2:amd64 2 as a solution to tdsodbc:amd64 0
Holding Back tdsodbc:amd64 rather than change libiodbc2:amd64
snip here - repeats until recursion limit is reached
Done
The following packages have unmet dependencies:
odbcinst1debian2 : Breaks: tdsodbc ( 0.82-8) but 0.82-7 is to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by
held packages.
--
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 -Nru soprano-2.7.6+dfsg.1/debian/changelog soprano-2.7.6+dfsg.1/debian/changelog
--- soprano-2.7.6+dfsg.1/debian/changelog 2013-03-01 07:57:01.0 -0800
+++ soprano-2.7.6+dfsg.1/debian/changelog 2013-05-11 11:44:33.0 -0700
@@ -1,3 +1,11 @@
+soprano (2.7.6+dfsg.1-2wheezy1.1) UNRELEASED; urgency=low
+
+ * Non-maintainer upload.
+ * Build without iODBC, to make KDE co-installable with multiarch-enabled
+ODBC drivers. Closes: #639300, LP: #901638.
+
+ -- Steve Langasek vor...@debian.org Sat, 11 May 2013 11:25:31 -0700
+
soprano (2.7.6+dfsg.1-2wheezy1) testing-proposed-updates; urgency=low
* Team upload.
diff -Nru soprano-2.7.6+dfsg.1/debian/control soprano-2.7.6+dfsg.1/debian/control
--- soprano-2.7.6+dfsg.1/debian/control 2013-02-07 05:40:14.0 -0800
+++ soprano-2.7.6+dfsg.1/debian/control 2013-05-11 11:25:18.0 -0700
@@ -6,7 +6,7 @@
Build-Depends: debhelper (= 7.4.15), cmake (= 2.6.2), pkg-kde-tools (= 0.12),
dpkg-dev (= 1.15.5), libclucene-dev (= 0.9.21b), libqt4-dev (= 4:4.5.3),
libraptor1-dev (= 1.4.16), librdf0-dev (= 1.0.13),
- doxygen (= 1.7.1), graphviz, libiodbc2-dev
+ doxygen (= 1.7.1), graphviz, libvirtodbc0, unixodbc-dev
Standards-Version: 3.9.3
Homepage: http://soprano.sourceforge.net
Vcs-Browser: http://git.debian.org/?p=pkg-kde/kde-req/soprano.git
@@ -15,7 +15,7 @@
Package: soprano-daemon
Section: utils
Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: libvirtodbc0, ${shlibs:Depends}, ${misc:Depends}
Recommends: libsoprano4 (= ${binary:Version})
Suggests: virtuoso-minimal
Breaks: libsoprano4 ( 2.3.0+dfsg.1-1), libsoprano-dev ( 2.3.0+dfsg.1-1)
diff -Nru soprano-2.7.6+dfsg.1/debian/patches/no-odbc-dm soprano-2.7.6+dfsg.1/debian/patches/no-odbc-dm
--- soprano-2.7.6+dfsg.1/debian/patches/no-odbc-dm 1969-12-31 16:00:00.0 -0800
+++ soprano-2.7.6+dfsg.1/debian/patches/no-odbc-dm 2013-05-11 11:24:46.0 -0700
@@ -0,0 +1,41 @@
+Description: Build without iODBC
+ Add support for soprano to link directly against virtodbc_r.so instead of
+ using the libiodbc driver manager. Given that virtuoso is hard-coded as
+ the driver, the use of a driver manager is an unnecessary indirection; and
+ the manner of the hard-coding makes it harder than it ought to be to
+ switch from iODBC to UnixODBC - so just eliminate the DM entirely.
+ .
+ This does mean we're using an rpath, but that's a lesser evil given that
+ the path to the library is otherwise hard-coded in the source anyway.
+Author: Steve Langasek vor...@debian.org
+Bug-Debian: http://bugs.debian.org/639300
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/901638
+
+Index: soprano-2.7.5+dfsg.1/cmake/modules/FindIODBC.cmake
+===
+--- soprano-2.7.5+dfsg.1.orig/cmake/modules/FindIODBC.cmake
soprano-2.7.5+dfsg.1/cmake/modules/FindIODBC.cmake
+@@ -57,10 +57,7 @@
+ ${iodbc_INCLUDE_DIRS}
+ )
+
+-find_library(IODBC_LIBRARIES NAMES iodbc
+- HINTS
+- ${iodbc_LIBRARY_DIRS}
+- )
++set(IODBC_LIBRARIES /usr/lib/odbc/virtodbc_r.so)
+
+ if (IODBC_LIBRARIES AND IODBC_INCLUDE_DIR)
+ # set(IODBC_INCLUDE_DIR ${IODBC_INCLUDE_DIR}/iodbc)
+Index: soprano-2.7.5+dfsg.1/backends/virtuoso/CMakeLists.txt
Re: Bug#707301: release-notes: odbcinst1debian2 : Breaks: tdsodbc ( 0.82-8) but 0.82-7 is to be installed
On Sat, May 11, 2013 at 09:18:03PM +0200, Sune Vuorela wrote: [recipients trimmed] I recommend applying the patch from bug #639300 in a stable update, instead of leaving akonadi/virtuoso un-coinstallable with all ODBC drivers in wheezy. Attached is an updated patch for this issue. My recommendation is to have unixodbc drop the useless and broken Breaks. The breaks are not from unixodbc, they are from the ODBC *drivers*, which are no longer in a path that libiodbc2 will find. No one has stepped up to make libiodbc2 multiarch-capable, and I find it unlikely that this would be acceptable to fix in a stable update. Thus the breaks are legitimate and correct. KDE maintainers: would you prefer to prepare a different fix yourselves for this issue, or upload this patch yourself? I guess I can NMU unixodbc if you prefer, given that is the good fix. No, you have misunderstood the problem. iodbc is what upstream and most distributions uses here, and I see no reason to deviate from upstream here. iodbc is the one supported and written by virtuoso upstream, so that's the one we prefer to use. iodbc is the one being *abused* by virtuoso upstream. Soprano does not work with arbitrary ODBC drivers; the use of a driver manager (in this case, iODBC) is a pointless indirection - as I've demonstrated, with my tested patch. The iodbc package in Debian has been unmaintained for years; a simple patch to soprano to remove the dependency on iodbc altogether is all that's needed here. If you're willing to maintain libiodbc2 just for the sake of virtuoso, then fine, maintain it. But no one has been maintaining it for 4 years, and it went out the door broken and unusable as an ODBC DM because no one has ported it for use with multiarch while almost all of the ODBC drivers have been multiarch-enabled in wheezy. The only reason this bug doesn't affect soprano as well is that soprano isn't *using* it as a DM except in the loosest sense of the word. So as things stand now, libiodbc2 is useless as a DM because it's incompatible with any of the drivers that users are going to configure it to use, and the Breaks are there to reflect that and ensure partial upgrades don't give users broken ODBC for other squeeze revdeps of libiodbc2. -- 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: Incompatible change in the ifupdown hooks interface
Hi Joss, On Tue, Mar 05, 2013 at 08:39:45PM +0100, Josselin Mouette wrote: while investigating on #699749 (which apparently affects many machines using NM, but not all of them), I discovered that the interface for ifupdown hooks has changed since squeeze. From the manpage: When ifupdown is being called with the --all option, before doing any‐ thing to interfaces, if calls all the hook scripts (pre-up or down) with IFACE set to --all, LOGICAL set to the current value of --allow parameter (or auto if it's not set), ADDRFAM=meta and METHOD=none. After all the interfaces have been brought up or taken down, the appropriate scripts (up or post-down) are executed. After discussing this on IRC, the ifupdown maintainer disagrees this is an incompatible interface change. Some of the existing hooks were not broken by this change, by pure chance. Some were fixed in subsequent uploads since squeeze. At least avahi was not. What is the position of the Release Team? * Is it a bug in avahi (and probably other packages)? * Is it a bug in ifupdown to have changed the interface? Given how close we are to the release, the simplest solution is probably to upload a fixed avahi and hope there aren’t any other scripts remaining. However this will not fix partial upgrades or manually updated scripts. FWIW, I agree with Andrew that this isn't an interface change; this is a latent bug in the avahi hook which has merely been exposed by this behavior change in ifupdown. ifupdown supports more address families than ipv4 and ipv6 (specifically, it supports ipx); if a user had configured a system with only ipx interfaces statically configured (as unlikely as that would be in the 21st century), it appears that avahi would have misbehaved in the same way. I don't know why these --all calls are a useful thing for ifupdown to do, but I do think it's the responsibility of the avahi package to sensibly ignore values of $ADDRFAM that it doesn't understand. -- 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#686387: unblock: upstart/1.5-1, mountall/2.39, ifupdown/0.7.3, udev/175-8 sysvinit/2.88dsf-33
Hi, Sorry for not replying to this sooner. On Mon, Dec 31, 2012 at 12:16:54PM +0100, intrigeri wrote: *However*, one possible regression was spotted (#696509), so it's getting less clear to me. Steve, what's your take on that regression? For the record, I don't think this is a credible report of a regression. There were no changes between 175-7 and 175-7.1 to any relevant udev code. -- 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#686387: unblock: upstart/1.5-1, mountall/2.39, ifupdown/0.7.3, udev/175-8 sysvinit/2.88dsf-33
On Tue, Feb 26, 2013 at 11:09:21AM +, Adam D. Barratt wrote: On 31.08.2012 20:02, Steve Langasek wrote: I discussed this briefly with Neil at DebConf, and he seemed to think it would be ok; if you disagree, it's his fault. ;) The version of upstart currently in testing is ancient. Getting it updated has been blocked on prerequisite changes in other packages of which I am not the maintainer (e.g. plymouth), so while I was fully intending to have this in before freeze, that clearly didn't happen. Sorry about that. The pieces have now come together to the point that it seems worth filing an unblock request with the details. AFAICT, all of the pieces involved here have now migrated, so I'm closing this request. Steve - I did notice there's a new version of mountall in sid (2.47 vs 2.46) but wasn't sure what the plan was there; in any case, it seems the required changes to support the newer upstart have migrated. Yep, thanks - mountall 2.47 would be better than 2.46 but the changes are probably nothing critical, so I wasn't planning to request an unblock with any sort of priority. -- 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: unblock-udeb for udev 175-7.1
On Mon, Feb 25, 2013 at 02:01:09PM +0100, Cyril Brulebois wrote:
Steve Langasek vor...@debian.org (06/02/2013):
Apologies for taking as long as I have to get around to sending this mail.
Ditto for the reply.
I would like to request an unblock of the udev udeb at version 175-7.1.
unblock-udeb udev/175-7.1
This package is a prerequisite for having a useful version of upstart in
wheezy (bug #686387), and the change should be a no-op with respect to the
installer:
$ debdiff ~/ftp/pool/main/u/udev/udev-udeb_175-7{,.1}_i386.udeb
File lists identical (after any substitutions)
Control files: lines which differ (wdiff format)
Installed-Size: [-427-] {+422+}
Version: [-175-7-] {+175-7.1+}
$
Are there any objections from the d-i side to letting this package into
testing?
The source diff looks OK too, and I saw no obvious regressions from
some quick tests, so that's fine with me.
Thanks, udeb unblock added!
--
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#699808: tech-ctte: syslinux vs the wheezy release
On Thu, Feb 07, 2013 at 01:55:11AM +0100, Cyril Brulebois wrote: On a personal note, I'm unsure how we came up with a situation where a single maintainer can *actively* stall a release… Not caring about the release process put into place years ago is a thing. Stopping people from fixing problems created by such carelessness is another one… Speaking as an ex-RM, I think the answer here is that it used to be that when a maintainer made such an upload (and it did happen), we would revert it without hesitation and without apology. I'm having a hard time deciding, with my TC member hat on, if I think this is actually an ok thing to do. But whether or not it's ok, I do think I would still do it today if I were in your position on the grounds that it's easier to ask forgiveness than to ask permission, and asking explicit permission from every maintainer who is in a position to become a critical blocker for the release is a good way to make sure releases don't happen. -- 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
unblock-udeb for udev 175-7.1
Hi all,
Apologies for taking as long as I have to get around to sending this mail.
I would like to request an unblock of the udev udeb at version 175-7.1.
unblock-udeb udev/175-7.1
This package is a prerequisite for having a useful version of upstart in
wheezy (bug #686387), and the change should be a no-op with respect to the
installer:
$ debdiff ~/ftp/pool/main/u/udev/udev-udeb_175-7{,.1}_i386.udeb
File lists identical (after any substitutions)
Control files: lines which differ (wdiff format)
Installed-Size: [-427-] {+422+}
Version: [-175-7-] {+175-7.1+}
$
Are there any objections from the d-i side to letting this package into
testing?
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#695971: unblock: freetds/0.91-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package freetds, which fixes bug #645726, an issue that affects upgrades from squeeze to wheezy. This is not a release-critical bug in freetds, but having this fix in will likely make upgrades happier for users. There are no other changes in this version of the package. unblock freetds/0.91-2 -- System Information: Debian Release: 6.0.6 APT prefers stable APT policy: (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/20121215003632.6698.15880.report...@becquer.dodds.net
Bug#686387: unblock: upstart/1.5-1, mountall/2.39, ifupdown/0.7.3, udev/175-8 sysvinit/2.88dsf-33
On Wed, Oct 31, 2012 at 04:39:03PM +0100, intrigeri wrote: Julien Cristau wrote (19 Sep 2012 17:42:01 GMT) : Looks sane to me, other than the init_is_upstart inlining in the udev init script I mentioned on IRC. If I understand this sentence right, this is a blocker. Gentle ping, then: Steve, what's happening on this front? It's a trivial change to the patch; the maintainer hasn't had time to look at the patch at all, so I'm preparing an NMU for udev now with the change Julien indicated. -- 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#690660: unblock: ifupdown/0.7.3
On Fri, Oct 19, 2012 at 10:44:19AM +0200, Andrew Shadura wrote: Hello, Anything on the bug? May we upload the package? The other change here looks like a reasonable, contained bugfix suitable for release. Yes, please upload. -- 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/20121030133236.gb30...@virgil.dodds.net
Bug#686387: unblock: upstart/1.5-1, mountall/2.39, ifupdown/0.7.3, udev/175-8 sysvinit/2.88dsf-33
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock I discussed this briefly with Neil at DebConf, and he seemed to think it would be ok; if you disagree, it's his fault. ;) The version of upstart currently in testing is ancient. Getting it updated has been blocked on prerequisite changes in other packages of which I am not the maintainer (e.g. plymouth), so while I was fully intending to have this in before freeze, that clearly didn't happen. Sorry about that. The pieces have now come together to the point that it seems worth filing an unblock request with the details. There are patches pending to ifupdown and udev to add necessary upstart integration for the core events needed for an event-based boot: http://bugs.debian.org/679549 http://bugs.debian.org/686378 I have tested these patches to confirm that they don't cause regressions when booting with sysvinit. In addition, I have a small patch to sysvinit, needed to allow the umountnfs.sh script to emit an event to upstart (when upstart is present). I'll hold off on committing this to sysvinit trunk until the other sysvinit RC bug has been dealt with (bug #672959; unblock request, bug #685278). Once these three changes are available in unstable, I have a package of upstart 1.5 that's ready to be uploaded. It introduces new versioned dependencies on the above, so it doesn't make sense to upload it until the prerequisites are done. The package is available for inspection at: https://code.launchpad.net/~vorlon/debian/sid/upstart/debian but a debdiff is not really useful to review here. Finally, mountall 2.39 in unstable is a new package (the one that was blocked on plymouth). It's a dependency of upstart so mostly not useful on its own, so I haven't requested an unblock before now; but it will need to go into testing for upstart to be updated. Provisional release team approval of the ifupdown/udev changes in particular could be helpful, as the maintainers may be wary of uploading these changes if they may not get into wheezy. unblock upstart/1.5-1 unblock mountall/2.39 upstart ifupdown/0.7.3 upstart udev/175-8 upstart sysvinit/2.88dsf-33 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. vor...@debian.org http://www.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/20120831200248.710.62287.report...@borges.dodds.net
Bug#686199: unblock: xen-api/1.3.2-11
On Thu, Aug 30, 2012 at 06:07:55PM +0800, Thomas Goirand wrote: On 08/30/2012 03:20 AM, Adam D. Barratt wrote: On Thu, 2012-08-30 at 03:01 +0800, Thomas Goirand wrote: Please unblock package xen-api. The PAM fix which we did for version 1.3.2-10 wasn't correct, and thanks to the help of Steve Langasek, we have it in a good shape now. The details of the conversation is available in the Ubuntu BTS here: https://bugs.launchpad.net/ubuntu/+source/xen-api/+bug/1033899 Trying to view that conversation gives me: Launchpad.net Lost something? This page does not exist, or you may not have permission to see it. That's not particularly helpful... :/ Indeed, this is a permission problem in this page, its marked as Private Security. I'm not sure how the Ubuntu stuff works though. I'm not a PAM specialist, and I'm afraid I can't comment much in here. Mike is unfortunately away for a while (I'm not sure I should disclose why), so he wont be able to explain what was wrong in version -10. I have to admit that I was busy doing other stuff, and that I'm not sure what the problem was. Steve, can you comment about the changes in the PAM settings committed in this latest version of XCP, and explain to the release team why we needed to change it and unblock the fixed xen-api/1.3.2-11? Thanks in advance. I've talked to the Ubuntu security team and they've unembargoed the bug; there's no reason to keep it private when there's public conversation pointing at the fact that it's a security issue. So that link works now. -- 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#681687: missing mime entry
On Thu, Jul 26, 2012 at 04:48:59PM +0100, Ian Jackson wrote: Josselin Mouette writes (Bug#681687: missing mime entry): Le jeudi 26 juillet 2012 à 12:50 +0100, Ian Jackson a écrit : 4. We do not disagree with the Release Team's assessment that the failure of the evince package to provide a mime type entry is a release critical bug. Before you vote on that: with the maintainer’s hat, I’d appreciate if the ruling could also make explicit which MIME types it applies to. I am content to leave that decision to the release team. I'm happy to clarify. So I hereby propose the following TC resolution (and withdraw my previous versions): 1. The Technical Committee agrees with Neil McGovern's analysis of the situation regarding evince's missing mime type entry. 2. If changes are desirable to our system for dealing with mime type entries and desktop files, including changes to policy or additional automation, these should be made via the usual development and policy amendment processes. 3. We agree with the Release Team that it is now too late to deploy such automation in wheezy. I don't actually agree that it's too late, but I would vote for a resolution that says: 3. We defer to the Release Team's decision that it is now too late to deploy such automation in wheezy. 4. We do not disagree with the Release Team's assessment that the failure of the evince package to provide a mime type entry is a release critical bug. 5. We therefore decline to overrule the Release Team. The bug remains RC against evince. 6. The release team should clarify which mime types the RC-bugginess applies to. We recommend that the starting point should be those mime types advertised by evince via the mime system in squeeze. Otherwise I have no objections here. -- 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#681687: missing mime entry
On Sat, Jul 21, 2012 at 11:12:25PM +0200, Michael Biebl wrote: A patch providing this converter has been available for a few months [1]. The mime-support maintainer just never got around to upload it or even comment on it. The new mime support maintainer team, which took over the package just a few days ago, did ask the release team, if it would be possible to still apply this patch for wheezy [2]. I think this should be the solution we should aim for and I would appreciate if the release team could give the mime-support maintainers a green light for the unstable upload. I agree that we should aim for such an automated, long-term solution. In the meantime, I think it's correct to say that evince has a release-critical bug. I think that the right thing for the evince maintainers to do is to upload the package *now* with re-added mime-support handling, and worry about dropping it only after mime-support .desktop support has proven itself - knowing that this may not happen in time for the wheezy release. (And if you disagree, well, it's an RC bug... so someone can upload an NMU for it...) If the converter solution turns out to be too buggy or requires larger changes, we have a simple contigency plan, i.e. just drop the converter again. I would really appreciate if we could try to fix this *whole* issue for good for *wheezy*. Re-adding the mime file in evince can still be done if the proper mime-support fix has not been done in say a month or two. From the discussion so far, there are two issues that in the release managers' position, I would be concerned about seeing addressed before endorsing this as a solution for wheezy. - The .desktop format does not include an equivalent to the mailcap 'priority' field; it's not clear what the expected / desirable handling is when multiple packages provide .desktop files for the same mime type. The documented default priority is '5', which is probably a reasonable starting point, but there's still a loss of expressiveness that seems to require an extension of the .desktop file format (especially since priority values are meant to be per-mime-type). - It's not clear what the transitional behavior should be when a package includes both a .desktop file and a usr/lib/mime/packages file. There's no reliable way to associate the contents of the two files, so this probably ends up with duplicated entries in /etc/mailcap, possibly with small variations; just from a quick look on my system, I find that the libreoffice .desktop and mime files use quite different program invocations. This is of course exactly why we want to not maintain duplicate information in multiple files, but we should have a clear idea about which we expect to take precedence, and make sure this is implemented, so that users don't wind up with buggy behavior on their systems due to random ordering. If this update-mime change is accepted for wheezy, the transition will most definitely be ongoing at release time, so we really ought to get this right. But that's just my two cents; the release managers may have a different set of concerns. Either way, my recommendation to the GNOME maintainers is that if you think it's important to not have to re-add the mime file to evince for wheezy, you should participate in finding a solution to these issues and not regard it as the mime-support maintainer's problem to fix - which I have the impression has been the general approach up to this point. On Sun, Jul 22, 2012 at 03:43:10PM +0100, Adam D. Barratt wrote: If Steve and other members of the ctte consider such a tool as an approriate way to solve this bug, would the release team also acknowledge this approach or not? If it's the solution that the TC decide on to resolve the issue, it sounds like something we could work with, at least imho, from what I've seen so far. I've CCed -release for any further comments, as I don't know how many members of the team are following -ctte and/or this bug. Broadly speaking, I think the correct long-term solution is to first add support to update-mime for reading both .desktop files and mime files, and then to update policy to tell maintainers to use .desktop files instead of mime files. And I think it's better for Debian if we can get the first part done prior to the wheezy release. But I would like the release team to make their own determination of whether the patch that's currently up for consideration is of sufficient quality, and sufficiently safe, to be granted a freeze exception. For clarity, the current proposal would be http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=35;filename=mime-support-desktop.patch;att=1;bug=497779 , or something similar? Yes. The nascent mime-support maintenance team has also committed a patch to the repo at http://anonscm.debian.org/gitweb/?p=collab-maint/mime-support.git;a=summary, probably best to reference the version there. -- Steve
Re: The future (or non-future) of ia32-libs
On Sun, Jun 24, 2012 at 03:57:29PM +0800, Thomas Goirand wrote: Release notes are meant to be read once, not every time you upgrade a system. Having a debconf note once might be appropriate. The second time, you'll go right, I've seen that before. The third time you go sigh, yes, I know, fuck off. The fourth time, you hit ctrl-C, and run DEBIAN_FRONTEND=noninteractive apt-get upgrade -- and then miss something that was actually important and didn't occur on previous installs. Please, let's keep upgrade information in the release notes. If some people don't read them, that's something we should try to fix; not by trying to work around the release notes, but by making them more accessible, easier to find, and more obvious instead. Well, if you update apt + dpkg first, then --add-architecture i386, and *then only* dist-upgrade (or if we manage to update apt / dpkg in stable, so that it does that automatically), it wouldn't display the debconf. So if you were doing lots of upgrades, it would display the debconf screen only if you do the mistake to forget about the --add-architecture i386. So I don't think that my proposal is an abuse of debconf as you describe. It's an abuse of debconf because if you know the system is broken, we should do better than just to tell the user that the system is broken. We should either give them the option to automatically fix it on upgrade, or - better by far - we should automatically fix it for them on upgrade. Why would anyone who has the ia32-libs package installed want anything *but* to have 'dpkg --add-architecture i386' on upgrade? That said, I'm not sure I wouldn't also consider it an abuse of base-files to make that package do this on upgrade. If you're going to task some package with transitioning to multiarch, it probably makes more sense to do it in dpkg itself. -- 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/20120624153041.gc26...@virgil.dodds.net
Re: The future (or non-future) of ia32-libs
On Fri, Jun 22, 2012 at 08:18:03PM +0200, Goswin von Brederlow wrote: May I suggest that upon upgrade, we have a debconf message telling about it? We could add this in base-files or any essential package, probably one with some debconf messages already in would be a better pick. Instructions would show, IF ia32-libs old version is currently installed AND the --add-architecture i386 hasn't bee done. I know we have release notes, but some don't know about them or would simply not read them. A debconf message seem really appropriate IMO. Something along with: Problem is that frontends will complain about ia32-libs being not upgradable and might suggest removing it instead of keeping it back way before that. Why would they do that? Has anyone seen this happening in practice? The ia32-libs package has trivial dependencies, none of which should run into conflicts on upgrade from squeeze to wheezy. Some of the biarch library packages that ia32-libs depends on *might* go away before wheezy release, but none have yet. So there's no reason for a frontend to remove the ia32-libs package /at all/ on upgrade; it should be held back because the dependencies of the new version of the package aren't satisfiable until the package database is updated with knowledge of multiarch, but it certainly shouldn't be removed. At which point, the user just has to enable multiarch, apt-get update, and do a second apt-get dist-upgrade pass. I don't see why we would want to try any of the kludgy solutions being discussed in this thread without evidence that the above can't be made to work and kept working for release. Then we just need to document this in the release notes, which users ought to be reading anyway, and they can complete the upgrade at their leisure. -- 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: 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: 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 vor...@debian.org 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 steve.langa...@ubuntu.com 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 steve.langa...@ubuntu.com
+
+---
+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: vendor|upstream|other, url of original patch
+Bug: url in upstream bugtracker
+Bug-Debian: http://bugs.debian.org/bugnumber
+Bug-Ubuntu: https://launchpad.net/bugs/bugnumber
+Forwarded: no|not-needed|url proving that it has been forwarded
+Reviewed-By: name and email of someone who approved the patch
+Last-Update: -MM-DD
+
+--- /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
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
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
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#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 ani...@debian.org 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
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] disabled root account / distinct group for users with administrative privileges
On Tue, Oct 19, 2010 at 09:48:58AM +0200, Jesús M. Navarro wrote: On Tuesday 19 October 2010 08:15:56 Josselin Mouette wrote: [...] Le mardi 19 octobre 2010 à 02:12 +0200, Jesús M. Navarro a écrit : What about the old-fashioned wheel group[1]? This would be an even worse disaster than “admin”, for similar reasons. Users of the “wheel” group were not supposed to get root privileges with their own password. Ok. But since this group is conceptually the same than the old wheel group, one that provides additional special system privileges that empower a user to execute restricted commands that ordinary user accounts cannot access, why not make a bit of a joke of it? How about bigwheel (since that's where wheel derives from)? It is *semantically* different. The worst possible way to implement this is by overtaking a pre-existing group that *we have defined* to have different semantics than what it's being proposed for. Defining a new group that may conflict with existing local groups on particular installed systems is not much better, but it's as good as we can get. On the other hand, is it really necessary a new group? Can't adm or operator be overloaded with this new functionality? (think Ockham's razor). No. Both of those groups also have other meanings. -- 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: Udev 151-2 upgrade problem on debian-testing-'squeeze' i386 cd binary1 20090302-04-:09
Ciao Marco, I've been working on wrapping my head fully around the various issues with the udev and kernel upgrade, to ensure we have it documented properly in the release notes. It's clear to me that we will need to include documentation of this issue in the release notes no matter what changes are made to the packages, because users will need to know that the new udev won't work correctly with the Debian 2.6.26 kernels. At the same time, I think something needs to change in the packages to improve the 'dist-upgrade' experience, because we both know many users won't read the release notes. First, what happened to the idea of using 'Breaks'? This was proposed months ago, but it hasn't been implemented yet in the package. Should I provide a patch that implements this? Second, I've done some research and testing regarding the nature of the incompatibility with CONFIG_SYSFS_DEPRECATED. From what I see, the primary impact of dropping the compat code from udev is that udev rules will no longer be applied to certain devices, such as block devices and network devices. This will break /etc/udev/rules.d/70-persistent-net.rules, and break any permission-setting on disks (e.g., the 'disk' and 'floppy' groups) and certain alias symlinks for CD drives, but those are the only problems I've been able to identify on a standard as a result of running udev 160 with CONFIG_SYSFS_DEPRECATED; and of these, only 70-persistent-net.rules is potentially a boot-breaker, and would still permit booting the system far enough to rescue by hand at console (i.e., the same process one would use if a newer kernel was installed but not configured to boot by default, which is one of the scenarios that currently permits bypassing this preinst error). So do you know of any other things that will break, or can you provide pointers to other areas I should look at? You mention in the bug that some rules will not work in ways beyond most people's ability to understand, but I don't even see any documentation here for those of us who *do* have the ability to understand and want to try to explain it to the others. :-) If there aren't any other issues, then IMHO the case is clear for downgrading the CONFIG_SYSFS_DEPRECATED handling from a preinst abort to a preinst debconf note (i.e.: interrupt the upgrade before udev unpack, to make sure the admin gets the message before we proceed). Right now, the cure (aborting the install of a core package during a dist-upgrade, leaving apt in a difficult-to-fix state) is definitely much worse than the disease (some devices not fully configured after reboot if the kernel isn't upgraded, requiring the user to grab a console shell to install a proper kernel). Third, you write that the old udev *also* won't work with the new kernel. Can you be more specific? In my testing, this also works fine; I wasn't able to identify anything out of place when rebooting to a 2.6.32 Debian kernel with a lenny udev. Finally, you comment in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571255#89 that the new kernel (indirectly) depends on a newer udev. In my testing, I'm able to install a 2.6.32-5 kernel package from squeeze directly onto lenny without upgrading udev in the process. When you say it indirectly depends, do you mean that there is a *logical* dependency that isn't reflected in the package dependencies, or are you referring to some earlier situation whereby upgrading the kernel package did pull in a udev upgrade at the same time? To summarize, with the information I have available, I believe there are two changes that should be made to the udev package: - add the Breaks: linux-image-2.6-$flavor ( $SYSFS_DEPRECATED_fixed_version) to udev, as discussed - change the preinst CONFIG_SYSFS_DEPRECATED abort to a debconf error note warning users about the network, permissions problems if they don't install a new kernel But I know that I may have overlooked some details. If you see any problems with my suggestion, please let me know what they are so that I can look for better solutions. And if there aren't problems with this proposal, I'm happy to prepare a patch to the package for this if that would be helpful to you. 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#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
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
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 j...@jtan.com 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 j...@jtan.com 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
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 codeh...@debian.org 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 j...@jtan.com 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 j...@jtan.com 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
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
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
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: 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: 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: 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: 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: On cadence and collaboration
On Thu, Aug 06, 2009 at 02:21:49PM +0200, Cyril Brulebois wrote: Luk Claes l...@debian.org (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
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
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
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
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ó d...@net.com.org.es writes: pUpgrades [… 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: 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: doubts about Lenny and available QA tools, release and security team, drivers
On Sun, Oct 19, 2008 at 01:24:40PM -0200, Andre Felipe Machado wrote: Hello, I am trying to answer some questions from Serpro [1], an interested government agency that receive attention [0] from Debian Partners Program. How many separate lists do you think you need to post this to? - Expected release date for Lenny. The release team has targeted the last quarter of 2008, but meeting that goal is entirely contingent on being able to resolve the bugs that have been identified as critical for this release. - How test/guarantee today high end hardware (SAN, blades , etc) work fully with Lenny? Are there regression tests? Debian is a volunteer-run distribution. We provide no guarantees of compatibility with any particular hardware. If you need such guarantees, you should probably contract with one of the various companies who support Debian, to provide you with this guarantee. But you might be better off contracting directly with a member of the Debian kernel team to support the hardware of interest to you, since they're the ones who ultimately have the power to fix it if it doesn't work. But it's rather late in the cycle for that anyway - you would have been better off testing for the hardware of interest several months earlier in the development cycle, not when we're in the middle of the full release freeze. - How help Debian at this task of high end hw drivers? Test, report bugs, and if necessary, give Debian kernel developers access to the hardware in question. By and large, Debian will support the hardware supported by the upstream Linux kernel; but some upstream kernel versions work better with particular hardware than others do, so this kind of feedback is essential to ensure that the kernel we release with is usable for your use case. - How much time takes a security patch to be issued? It varies. There are public studies comparing the response times of the Debian security team with those of other distros (including the commercial distros); I suggest you look at those, since no one in Debian is going to promise you a fixed time frame. - Are there regression tests to allow distro consistency of a security fix backport to a VERY old version of a sw, already outside of security team action scope? (Lets say, a Pg 6.x on Lenny, unmaintained even at upstream. Please, do not discuss the merit of this approach, as it is _their_ IT mgmt problem to solve.) How release team verify distro consistency? No. Why would Debian be providing regression tests for software we don't ship? Could you point an url with the correct answers to these questions? No. -- 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/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems with Lintian refusing to understand Depends: php5-cli | php4-cli
On Sat, Oct 18, 2008 at 03:36:20AM +0800, Thomas Goirand wrote: My package depends on php5-cli | php4-cli, and it was fine, supporting backports to Etch and all. php4-cli is *not* required for etch backports. etch includes php5. I'm a bit stuck with lintian producing an error, and my package can't be uploaded. It's a bit silly, as what I wrote as dependency is correct I don't agree that it's correct. Excess ORed dependencies add cruft to the dependency graph of the Debian archive; they're justifiable when they help backports, but this doesn't help backports. Now, is it fine to add a lintian override only for that problem to be ignored? Would the release team accept the package? Definitely not. -- 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/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing libdb 4.3
On Sun, Oct 05, 2008 at 02:32:50PM -0700, Thomas Bushnell BSG wrote: On Sun, 2008-10-05 at 10:24 +0200, Pierre Habouzit wrote: On Fri, Oct 03, 2008 at 04:59:03PM +, Thomas Bushnell BSG wrote: I completely agree that libdb4.3 is ancient grot, and it should be removed from the archive. I am distressed that the maintainers decided to wait until the freeze to do that. This is entirely *backwards*. The time to decide, hey, this library should be removed is at the *beginning* of the release cycle, not at the end. FWIW bugs were filed way before the start of the freeze. We're only discussing several months old bugs afaict. So it seems that your rant is off. Also debian-release is not a discussion list, and such a post should be on -devel. TIA. Actually, no, you're wrong. The bug was filed against mmorph on September 29. Please pay attention. It would be easier to pay attention if your message had given any indication this was the package you were referring to. As far as I could tell, this was a continuation of the reprepro discussion in the new thread. The bug on mmorph was not filed by the db maintainers, it was filed by a release manager. I guess mmorph was overlooked when the db maintainers filed bugs requesting migration to db4.6 a year ago. That's unfortunate, but it's not a reason to keep db4.3 around in lenny when we can easily dispense with 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. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Permission to upload insight 6.6-1.1?
On Sun, Oct 05, 2008 at 12:42:15AM +0100, Chris Lamb wrote: Marc 'HE' Brockschmidt wrote: I'm not sure you noticed, but 6.6-1lenny2 failed to build on some architectures: http://buildd.debian.org/pkg.cgi?pkg=insight;dist=testing Thanks for chasing this up. So some context for the !Installed packages is: alpha: [..] In file included from trad-core.c:44: /usr/include/sys/user.h:27:22: error: asm/page.h: No such file or directory make[5]: *** [trad-core.lo] Error 1 hppa: [..] In file included from trad-core.c:44: /usr/include/sys/user.h:27:22: error: asm/page.h: No such file or directory make[5]: *** [trad-core.lo] Error 1 Hm, so are the alpha and hppa chroots sane? Yes. It's your package's code that's not sane; asm/page.h is a deprecated header, because userspace apps should not make assumptions about the kernel page size at build time. There is a sysconf interface, sysconf(_SC_PAGESIZE), which should be used instead if you really need to know the kernel's page size at runtime. -- 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/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: severity of 442668 is serious
On Fri, Sep 26, 2008 at 12:22:10PM +0200, Bernhard R. Link wrote: * Luk Claes [EMAIL PROTECTED] [080926 05:50]: # we want to get rid of db4.3 severity 442668 serious Could I please get any explanation for this? Redundant versions of BDB in the archive unnecessarily bloat the release and Debian's install footprint, and impose a burden on the Debian DB packaging team. There are currently five versions of BDB in lenny, whereas there are only 7 packages in lenny that depend on db4.3 - *all* of which ought to have transitioned off of it at least a year ago (when db4.6 became available; db4.4 became available in 2005, but was not free of regressions for all use cases). And all but three of these are fixed in unstable. It is not justifiable for apps that make only the most basic use of BDB, as reprepro does, to get to keep their own copy of libdb for a release. Is this a request to make a last-minute disruptive change upload before the release (it might only be a few chars in the source, but I'd be less frightened about several hundered untested line changes than the change from one libdb version to another frommy experience with those)? Maybe if you had looked at this back in December when you were asked, instead of making the absurd request of a stable backport as a precondition of maintaining your package, you wouldn't find it so frightening now? It's arrogant to think that your package needs special handling for the disruptive change from db4.3 to db4.6, when dozens of packages have already made this transition without incident. I've reviewed the reprepro source code, and there's nothing extraordinary about its use of BDB - nothing that should break when switching to db4.6, and nothing (such as transactions) that requires special upgrade handling. If yes, then please express this explicitly and I'll do an according upload. Consider it made explicit; please upload. -- 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/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gnucash 2.2.6-2: please allow into testing
Hi Thomas, On Thu, Aug 28, 2008 at 11:32:49PM -0700, Thomas Bushnell BSG wrote: Please allow gnucash 2.2.6-2 into testing; this has a minimally invasive patch to avoid a dangerous data-loss bug in an unusual usage case. (It turns out that sshfs returns ENOSYS on a link call. This is wildly wrong; it has no business doing so, especially when EPERM is already the documented error for the filesystem-doesn't-support-it case.) Regardless, gnucash did poorly in this case, and the patch in 2.2.6-2 fixes the (release-critical) problem. Given that sshfs's errno return is wildly wrong, is there a release-critical bug filed about this somewhere too? Possibly on glibc, which I think is responsible for ensuring that the errno values returned from its userspace functions are compliant, even when the kernel's return values need to be mapped? -- 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/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gnucash 2.2.6-2: please allow into testing
On Fri, Sep 12, 2008 at 09:24:55AM +0200, Bastian Blank wrote: On Thu, Sep 11, 2008 at 11:44:00PM -0700, Steve Langasek wrote: Given that sshfs's errno return is wildly wrong, The errors are not wrong. The lists in the documentation are not terminal. The open group spec say[1]: | The ERRORS section on each page specifies whether an error will be returned, or | whether it may be returned. Implementations will not generate a different error | number from the ones described here for error conditions described in this | specification, but may generate additional errors unless explicitly disallowed | for a particular function. Possibly on glibc, which I think is responsible for ensuring that the errno values returned from its userspace functions are compliant, even when the kernel's return values need to be mapped? And which value should they be mapped to? EPERM The file system containing oldpath and newpath does not support the creation of hard links. That seems to cover any case where the kernel might return ENOSYS... -- 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/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gnucash 2.2.6-2: please allow into testing
On Fri, Sep 12, 2008 at 12:38:14AM -0700, Thomas Bushnell BSG wrote: On Fri, 2008-09-12 at 00:32 -0700, Steve Langasek wrote: EPERM The file system containing oldpath and newpath does not support the creation of hard links. That seems to cover any case where the kernel might return ENOSYS... Yes, but this is not glibc's responsibility; it is the kernel's. and, i think the kernel should pass back the error it gets too. it is sshfs which should do the same thing as everyone else. clearly someone read and misunderstood the ENOSYS documentation. FWIW, I know there have been other cases in the past where glibc has handled ENOSYS returns for unimplemented syscalls and fallen back to older, less-preferred interfaces to avoid returning ENOSYS to the caller for a case where the ENOSYS is an implementation detail between glibc and the kernel. I can see that this isn't completely analogous to the sshfs case, though, since link isn't exactly a new syscall... So if this should be regarded as an sshfs bug, that's fine with 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. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock avahi 0.6.23-2
On Sun, Sep 07, 2008 at 07:13:15PM +0200, Petter Reinholdtsen wrote: [Marc Brockschmidt] What about a simple solution: Ask dpkg if sysvrc is installed. If not: Do the update-rc.d remove/start dance as currently implemented. If it used, check the current state of /etc/rc?.d/ and insert the new links accordingly to that. Would you be willing to implement this? It wouldn't worsen the situation, would improve it for a large majority of users and doesn't require APIs that are not available (yet). Note that sysv-rc is installed also when dependency based boot sequencing (insserv) is enabled, and when it is enabled, the sequence numbers are not fixed. So it is not enough to check if sysv-rc is installed. Why do sequence numbers matter for *dependency*-based boot sequences? -- 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/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Freeze Exception for Python Django 1.0
Hi David, On Thu, Aug 28, 2008 at 06:35:24PM -0700, David Spreen wrote: I know you have a lot of work so I'll try to be concise hopefully without leaving anything out. I am a member of the Debian Python Modules Team and have spent quite some work on the packages for Python Django 1.0 (I packaged alpha2, beta1 and beta2 for experimental). Django is going to release version 1.0 early next week and I want to ask you to make a freeze exception for it once it is in unstable (which will be on the same day or the day after the release). Having seen the thread on debian-python and subsequently spoken with a member of upstream about this, I would add/reiterate the following points: - Django 0.96.2 is already too far out of date for most applications (i.e., it's been too old for the past 6 months), and has been in security-updates-only mode for over a year; if it comes down to releasing with 0.96.2 or not including django in the release, it appears to be better to release without django. - Django is a rather popular framework, so it would be very nice to have 1.0 in lenny rather than having nothing. - However, to date the most recent package available in Debian is 1.0~beta1 (the 1.0~beta2 package being stuck in NEW due to the addition of a -doc package), and this only to experimental, which means that the testing audience for these packages is vastly reduced. If there's to be /any/ chance of this package being included in Lenny, I recommend getting a package into unstable /immediately/ rather than waiting for the upstream 1.0 release - bypassing the NEW queue by re-dropping the -doc package, if necessary. 1. Django 1.0 is backwards incompatible. Applications that have been written for earlier stable and development releases will most likely not work with Django 0.96 which means that most likely 0.96 will be of little value for developers soon after the release next week. It is my understanding that Django 0.96 is already of little value for most users. 2. A freeze exception would be low-impact. Currently there is no application that depends on Django in unstable or testing. There are two applications that Suggest Django because Django can use it but they don't use the framework itself and are therefore compatible with the new version. More than this, the python-django package has no reverse-dependencies or reverse-build-deps in the archive. So yes, the impact is low. It is my recommendation to the release team that python-django 1.0 be accepted for lenny on a provisional basis, with the understanding that 0.96 is not release-worthy, and that if the 1.0 packages also fail to be releasable on the proper time table, that they be cut from the release. 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/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Pending transitions
On Mon, Aug 25, 2008 at 11:37:18AM -0300, Otavio Salvador wrote: parted == parted is ready to transition, except that I agreed with Otavio he'd ack me migrating it, and I haven't been able to get hold of him by IRC. In any case, the important bit is that while udeb-only packages have been binNMUed for this transition (partconf and partman-base), they SHOULD NOT be migrated at all. parted-udeb, otoh, should be migrated with its source package as usual (parted). Yes, parted can go however 1.7 binaries cannot be removed from lenny until we do RC1 release. What are these 1.7 binaries you refer to? AFAICS, parted has been at version 1.8.8.git.2008.03.24-8 in testing since August 8, and there are no parted 1.7 binaries (udebs or otherwise) in testing. Also, would it really be a release candidate if it were missing a major new upstream version of parted like this...? -- 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/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock chicken 3.2.7-2
On Mon, Aug 25, 2008 at 01:52:14PM +0200, Davide Puricelli wrote: chicken revision 3.2.7-1 had a possible security problem because of RPATH pointing to insecure location (see #495753 for reference), 3.2.7-2 fixes it calling chrpath into debian/rules. Already 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/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing update of 'mafft' to fix #496366 (grave security bug).
On Tue, Aug 26, 2008 at 01:40:01PM +0900, Charles Plessy wrote: [ Charles Plessy ] * debian/control: - Moved the Homepage: field out from the package's description. - Enhances: t-coffee. * Updated my email address. * Securisation of the temorary files of mafft-homologs: - debian/control: build-depend on quilt. - debian/rules: modified to use quilt. - debian/README.source: signals that the package uses quilt. - debian/patches: added a patch to use mktemp (Closes: #496366). - debian/mafft-homologs.1*, debian/README.Debian: document that the program is patched. [ David Paleino ] * debian/mafft.1, debian/mafft-homologs.1 added - manpages built statically. * debian/control: - B-D updated (see above) - added myself to Uploaders - moved XS-Vcs-* fields to Vcs-* - Updated to Standards-Version 3.7.3 (no changes needed) * debian/rules: - reflecting static build of manpages - minor changes Would you accept this package in Lenny to fix #496366? If the diff is in line with this description, yes. 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/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please binNMU librsvg
On Sun, Aug 24, 2008 at 10:13:07AM +0200, Mike Hommey wrote: Please binNMU librsvg against libxml2 2.6.32.dfsg-2+lenny1, due to bug #496125. Can you elaborate on why a binNMU is appropriate here, please? If this is ABI breakage in libxml2, that's a serious bug that should be fixed in that package, not papered over with binNMUs. And anyway, no, libxml2 2.6.32.dfsg-2+lenny1 isn't in testing (or testing-proposed-updates), so binNMUs into testing are not exactly possible at present. -- 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/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock avahi 0.6.23-2
On Sat, Aug 23, 2008 at 03:52:00AM +0200, Petter Reinholdtsen wrote: [Steve Langasek] So it's not at all true that it's not an option in Debian - it just happens to not be the option you prefer. I, OTOH, think it's the better option; Just for the record, I would prefer Debian to drop file-rc, and avoid the complexity of having two different systems manipulated by the update-rc.d API. It would make a lot of things easier, both with documentation and configuration. But until it is dropped, I believe it would be a mistake to pretend file-rc does not exist and do things in packages that only work with one of them. The problem is that the alternative solution that's been implemented works correctly with *none* of them. And insserv doesn't even enter the argument here, because insserv is dependency-based and shouldn't need any configuration changes anyway... Actually, disabling services when using insserv have the same problem. All changes need to go through the update-rc.d API, and there is no way to enable or disable single runlevels. The sequence number can be ignored in the insserv case, but not the state of the service in each runlevel. Well, so the current solution breaks all of file-rc, sysv-rc, and insserv; is unnecessary for insserv (because the sequence numbers don't need to be reset for a dependency-based init system); and there's another way to handle sysv-rc. I really don't see how this is a superior solution. -- 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/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pwlib-titan needs to be binNMU'd on sparc
On Sat, Aug 23, 2008 at 08:14:10PM +0100, Jurij Smakov wrote: It appears that pwlib-titan version currently in unstable got miscompiled on sparc somehow, that's currently causing RC build failures of gnugk (#478502, note that this fails on a number of architectures, so other people should test whether rebuilding pwlib-titan on failing arches fixes it) and openh323-titan (#475601). I have rebuilt pwlib-titan with the current sid toolchain, installed the resulting packages in the sid chroot and was able to successfully build both gnugk and openh323-titan. Please binNMU pwlib-titan on sparc (or let me know if I should do it myself), that should fix two outstanding RC bugs. BinNMU scheduled; gnugk and openh323-titan given back with dep-waits set. 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/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock avahi 0.6.23-2
On Fri, Aug 22, 2008 at 10:10:36AM +0200, Michael Biebl wrote: Marc 'HE' Brockschmidt wrote: Michael Biebl [EMAIL PROTECTED] writes: Marc 'HE' Brockschmidt wrote: The diff for the debian related changes is in debian.diff.gz +# update init script symlinks for new runlevels and priorities for upgrades +# from older versions +if dpkg --compare-versions $2 lt-nl 0.6.22-4; then + echo Reinstalling init script for new runlevels and priorities ... 2 + # remove old init script symlinks; dh_installinit adds the proper + # update-rc.d snippet later on + update-rc.d -f avahi-daemon remove /dev/null +fi Dude. That's going to remove all my carefully renamed /etc/rc[2345].d/K??avahi-daemon links, just to replace them with new start links. Not nice. There is no better way to do that unfortunately. update-rc.d has no API to update and preserve existing configuration. Please keep in mind, that we have to support other systems like file-rc. The above approach is recommend by the sysvinit maintainer and commonly used. I guess that would be the same sysvinit maintainer who wants people to migrate off of sysv-rc to a dependency-based init system... Commonly used or not (I've had to change init script sequences before, and I've certainly never done it this way!), it does stomp on local changes to the runlevel settings. I don't see why the needs of a handful of file-rc users should outweigh the needs of everyone using the *standard* way to disable 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/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock avahi 0.6.23-2
On Fri, Aug 22, 2008 at 11:39:41AM +0200, Petter Reinholdtsen wrote: Question is, if there are more users out there that use file-rc / insserv or have disabled/modified avahi-daemon start symlinks (which usually only knowledgeable users will do). Please keep in mind that insserv was confirmed as a release goal, so what should I do? I'm open to better suggestions. I do not have any better solutions. The only bad alternative I have seen used is to remove known symlinks directly in /etc/rcX.d/, and this do not work with file-rc and insserv. It is done in Ubuntu, because they have dropped file-rc. It is as I see it, not an option in Debian. According to http://popcon.debian.org/main/by_inst.gz, 142 people have file-rc installed - vs. 577 users with insserv, and 73598 with sysv-rc. So roughly .2% of popcon reporters use file-rc. I don't think it's anything near a sure bet that less than .2% of users have disabled *some* service by changing symlinks in /etc/rc*.d. So it's not at all true that it's not an option in Debian - it just happens to not be the option you prefer. I, OTOH, think it's the better option; I'm not sure why anyone would want to run file-rc in the first place, but I know exactly why someone would want to disable a service by changing symlinks in /etc/rc*.d - because it's the *right* way to do it in the context of sysv-rc. And insserv doesn't even enter the argument here, because insserv is dependency-based and shouldn't need any configuration changes anyway... -- 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/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
freeze exception: freetype, RC bug but includes udeb
This is a request for a freeze exception on freetype 2.3.7-1, just uploaded to unstable to fix RC bug #487101. The full debdiff is attached. This is a straightforward fix, but freetype provides a udeb, so I'm asking here before unblocking. -- 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/ [EMAIL PROTECTED] [EMAIL PROTECTED] diff -u freetype-2.3.7/debian/changelog freetype-2.3.7/debian/changelog --- freetype-2.3.7/debian/changelog +++ freetype-2.3.7/debian/changelog @@ -1,3 +1,12 @@ +freetype (2.3.7-2) unstable; urgency=high + + * High-urgency upload for RC bugfix. + * Add debian/patches-freetype/no-segfault-on-load_mac_face, patch from +upstream to fix a segfault due to uninitialized memory in certain +failures of FT_Stream_New. Closes: #487101. + + -- Steve Langasek [EMAIL PROTECTED] Thu, 21 Aug 2008 12:09:17 -0700 + freetype (2.3.7-1) unstable; urgency=low * New upstream release diff -u freetype-2.3.7/debian/patches-freetype/series freetype-2.3.7/debian/patches-freetype/series --- freetype-2.3.7/debian/patches-freetype/series +++ freetype-2.3.7/debian/patches-freetype/series @@ -5,0 +6 @@ +no-segfault-on-load_mac_face only in patch2: unchanged: --- freetype-2.3.7.orig/debian/patches-freetype/no-segfault-on-load_mac_face +++ freetype-2.3.7/debian/patches-freetype/no-segfault-on-load_mac_face @@ -0,0 +1,50 @@ +2008-08-19 suzuki toshiya [EMAIL PROTECTED] + + * src/base/ftobjs.c (FT_Stream_New): Initialize *astream + always, even if passed library or arguments are invalid. + This fixes a bug that uninitialized stream is freed when + an invalid library handle is passed. Originally proposed + by Mike Fabian, 2008/08/18 on freetype-devel. + (FT_Open_Face): Ditto (stream). + (load_face_in_embedded_rfork): Ditto (stream2). + +Fixes Debian bug #487101. + +Index: freetype-2.3.7/src/base/ftobjs.c +=== +--- freetype-2.3.7.orig/src/base/ftobjs.c freetype-2.3.7/src/base/ftobjs.c +@@ -128,13 +128,14 @@ + FT_Stream stream; + + ++*astream = 0; ++ + if ( !library ) + return FT_Err_Invalid_Library_Handle; + + if ( !args ) + return FT_Err_Invalid_Argument; + +-*astream = 0; + memory = library-memory; + + if ( FT_NEW( stream ) ) +@@ -1600,7 +1601,7 @@ + FT_Error errors[FT_RACCESS_N_RULES]; + + FT_Open_Args args2; +-FT_Stream stream2; ++FT_Stream stream2 = 0; + + + FT_Raccess_Guess( library, stream, +@@ -1713,7 +1714,7 @@ + FT_Error error; + FT_Driverdriver; + FT_Memorymemory; +-FT_Streamstream; ++FT_Streamstream = 0; + FT_Face face = 0; + FT_ListNode node = 0; + FT_Bool external_stream;
