Re: hdf5 transition
On Mon, Mar 20, 2006 at 08:31:11AM +0100, Rafael Laboissiere wrote: > * Thomas Weber <[EMAIL PROTECTED]> [2006-03-20 07:58]: > > both 2.1 and 2.9 packages of Octave have been semi-automatically been > > updated to a new hdf5 library. > > changelog: > > = > > octave2.1 (1:2.1.72-12+b1) unstable; urgency=low > > > > * Binary-only non-maintainer upload for i386; no source changes. > > * Rebuild against libhdf5 1.6.5 > > > > -- Debian/i386 Build Daemon Fri, 17 Mar 2006 > > 21:31:52 -0800 > > = > > I don't have a clue, why a transition to 1.6.5 is so urgent (it hit > > unstable 3 days ago). Does anybody have an idea about this? Er, it's not urgent at all, but neither is there a reason to delay it AFAICT? Since octave2.1 was uploaded at about the same time that hdf5 cleared the NEW queue, there was certainly no way that octave2.1 was going to reach testing ahead of hdf5 itself, since at least one of the (non-binNMUed) builds of octave2.1 1:2.1.72-12 built against libhdf5-1.6.5-0 instead of libhdf5-1.6.4-0c2. Likewise, the octave2.9 builds on alpha, mips, mipsel, and powerpc are all linked against hdf 1.6.5; since britney isn't going to keep libhdf5-1.6.4-0c2 around when pushing libhdf5-1.6.5 into testing, the only way these packages get into testing now is if they're updated on all architectures to use 1.6.5 instead of 1.6.4. > I think that once hdf_1.6.5 will enter testing, the transition package > hdf5_1.6.4-0c2 will be removed from the archive. This will stale all the > packages in testing depending on the 1.6.4-0c2 version. Rather, the update in testing is not possible at all until all related packages are in sync. > The release team is apparently taking care of this. However, since I am > not subscribed to the debian-release mailing list, I only discovered the > post above today. My understanding is that we should not upload new > versions of octave2.1 and octave2.9 until the aging period is finished. It would be appreciated if you didn't upload new versions of those packages without an important reason that would justify delaying the hdf5 transition, yes. > I am hence Cc:ing this message to the debian-release mailing list, along > with the following request to whoever did the upload of the new > binary-compatible packages: the next time such uploads are done, could > you please keep the maintainers informed? Do you mind if I ask why you feel such notification is important? Part of the value of binNMUs is that it lets rebuild-only library transitions be completed without the need to involve maintainers (as well as without any need to add backport-disrupting versioned build-dependencies). If I'm going to have to negotiate binNMUs for each package individually with the maintainer, I might as well not try, and just file RC bugs against all the packages instead. Given that these are not sourceful changes, I think it's better to trust the release team and the porters to know when a binNMU is needed. As I noted above, it's not as if the binNMUs in question were actually disruptive; octave2.1 and octave2.9 were already going to be left uninstallable in unstable, and owing to the timing of the uploads neither package was going to be able to migrate to testing ahead of hdf5. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: binNMUs for tagcoll, debtags and libapt-front
On Mon, Mar 20, 2006 at 01:42:29AM +0200, Guillem Jover wrote: > Please do bin-NMUs for tagcoll, debtags and libapt-front on i386. > They are linked against gcc 4.1. BinNMUs queued. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: [Pkg-octave-devel] Re: hdf5 transition
* Steve Langasek <[EMAIL PROTECTED]> [2006-03-20 01:04]: > Do you mind if I ask why you feel such notification is important? Because I, for instance, was not aware of the bin-NMU until Thomas sent his message this morning and after I have browsed the debian-release archive. I would then happily upload new versions of octave2.1 and octave2.9 and unintentionally delay the hdf5 transition. Notice that it is not a matter of distrust on the release team and the porters. BTW, you guys are doing a great job and we are thankful for it. -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-octave-devel] Re: hdf5 transition
On 2006-03-20 Rafael Laboissiere wrote: > > Do you mind if I ask why you feel such notification is important? > > Because I, for instance, was not aware of the bin-NMU until Thomas sent Steve, you probably should create a little "transitions FAQ" entry in the developers reference to not always have to answer to the same wrong proposals of developers who only do a transition once every couple of years :) bye, -christian- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
hdf5 transition
Hi > Steve, you probably should create a little "transitions FAQ" entry > in the developers reference to not always have to answer to the same > wrong proposals of developers who only do a transition once every couple > of years :) I fail to see what's so wrong about an (automated) email stating that a package is currently undergoing a transition. Octave's upstream will probably release a new version during this week. We would have delayed the transition without actually intending to do so just because we wouldn't have known that there was one in the first place. While I don't have any first hand experience with transitions, I'm quite sure that "the faster, the better" applies to them. Regards Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New libmysqlclient transition necessary
Hello On 2006-03-16 Steve Langasek wrote: > > > > During the last month I have build my libmysqlclient15 with > > > > shared symbols that looked in "objdump -T" like: > > > > 0013a154 gDO .bss 0004 MYSQL_5.0 my_dont_interrupt > > > > 00026d70 gDF .text 02fa MYSQL_5.0 my_strntoll_8bit > > > > 00015730 gDF .text 0025 MYSQL_5.0 my_no_flags_free > > > > > Now MySQL finally closed my bug report to them and provides symbols > > > > in their upstream source. Sadly they look like: > > > > f280 gDF .text 000b libmysqlclient_15 mysql_row_tell > > > > f4d0 gDF .text 0043 libmysqlclient_15 > > > > mysql_escape_string da30 gDF .text 00e1 > > > > libmysqlclient_15 mysql_slave_send_query > > ... > > > Yes, this is a backwards-incompatible ABI change. If libmysqlclient15 > > > had been present in sarge, such a change without a rename of the > > > library package would be a release-critical bug for etch; since it > > > wasn't, it's only severity: important, but either way all packages > > > built against the previous symbol versions would have a > > > release-critical bug requiring a rebuild. The source package mysql-dfsg-5.0 5.0.19-2 is now in unstable and build on all archs except m68k. It's now your turn to schedule the binNMU mechanism, right? The resulting binaries should end up linked against "libmysqlclient15off". bye, -christian- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New libmysqlclient transition necessary
On Mon, Mar 20, 2006 at 09:22:33PM +0100, Christian Hammers wrote: > On 2006-03-16 Steve Langasek wrote: > > > > > During the last month I have build my libmysqlclient15 with > > > > > shared symbols that looked in "objdump -T" like: > > > > > 0013a154 gDO .bss 0004 MYSQL_5.0 my_dont_interrupt > > > > > 00026d70 gDF .text 02fa MYSQL_5.0 my_strntoll_8bit > > > > > 00015730 gDF .text 0025 MYSQL_5.0 my_no_flags_free > > > > > Now MySQL finally closed my bug report to them and provides symbols > > > > > in their upstream source. Sadly they look like: > > > > > f280 gDF .text 000b libmysqlclient_15 mysql_row_tell > > > > > f4d0 gDF .text 0043 libmysqlclient_15 > > > > > mysql_escape_string da30 gDF .text 00e1 > > > > > libmysqlclient_15 mysql_slave_send_query > > > ... > > > > Yes, this is a backwards-incompatible ABI change. If libmysqlclient15 > > > > had been present in sarge, such a change without a rename of the > > > > library package would be a release-critical bug for etch; since it > > > > wasn't, it's only severity: important, but either way all packages > > > > built against the previous symbol versions would have a > > > > release-critical bug requiring a rebuild. > The source package mysql-dfsg-5.0 5.0.19-2 is now in unstable and build on > all archs except m68k. It's now your turn to schedule the binNMU mechanism, > right? Yep, it's already mostly done. mipsel is lagging a bit behind because of its buildd situation right now, but the other release archs have already build the majority of the necessary binNMUs. There are some package builds that will have to be given back, due to gtk libraries being broken in unstable at the time :P, plus a few other random failures that will warrant bug reports; but you should see most of the mysql5-using packages installable again already on i386 with the next mirror pulse. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: amd64 glibc update for sarge
Hello, On Thu, Mar 16, 2006 at 09:08:25PM +0100, Goswin von Brederlow wrote: > The bug prevents NPTL threads from functioning correctly which is a > big issue on amd64. Most notably mysql hangs due to this. I second the request to include this patch, and strongly recommend to do so. For a discussion of this issue concerning mysql, please have a look at http://bugs.mysql.com/bug.php?id=8555 Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: [Pkg-octave-devel] Re: hdf5 transition
On Mon, Mar 20, 2006 at 12:51:40PM +0100, Rafael Laboissiere wrote: > * Steve Langasek <[EMAIL PROTECTED]> [2006-03-20 01:04]: > > Do you mind if I ask why you feel such notification is important? > Because I, for instance, was not aware of the bin-NMU until Thomas sent > his message this morning and after I have browsed the debian-release > archive. I would then happily upload new versions of octave2.1 and > octave2.9 and unintentionally delay the hdf5 transition. Well, as noted, the hdf5 transition shouldn't really be regarded as urgent. From my POV, if you had uploaded new versions and delayed the transition, that wouldn't have been a problem. :) On Mon, Mar 20, 2006 at 08:23:12PM +0100, Thomas Weber wrote: > > Steve, you probably should create a little "transitions FAQ" entry > > in the developers reference to not always have to answer to the same > > wrong proposals of developers who only do a transition once every couple > > of years :) > I fail to see what's so wrong about an (automated) email stating that a > package is currently undergoing a transition. Probably nothing, but no such automation is in place today, and to me it doesn't seem worth the effort to try to automate it. When we get into transitions that are critical, or where there's a known danger of transitions getting tangled together, I certainly make a point to send out mails. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
missingh
libghc6-missingh-dev is uninstallable in testing: it Depends: ghc6 (<< 6.2.2-999), ghc6 (>= 6.2.2) while ghc6 is 6.4.1-2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Antique RC bugs (many about licensing)
On Wed, Mar 15, 2006 at 05:43:38PM +0100, Goswin von Brederlow wrote:
> Nathanael Nerode <[EMAIL PROTECTED]> writes:
> > I went through the RC bugs which apply to etch and are older than one year.
> > This is a rather disturbing list, as you would expect from the age of the
> > bugs.
> > In most cases I don't think you can expect the maintainers to deal with
> > these
> > bugs on their own.
> > What are the release managers planning to do about these?
> > First the easy bugs:
> > ---
> > Package: libuclibc0 (optional; David Schleef) [uclibc/0.9.27-1 ; =]
> > [add/edit comment]
> > 261725 [ ] libuclibc0 - violates FHS
> > This deserves a long-term exception because the FHS has no reasonable
> > alternative
> > placement, and tools expect the placement used here.
> The multiarch path is different from the cross-tools paths used in
> libuclibc0. The only argument for the multiarch dirs (over cross-tool
> dirs) is that it does not pollute toplevel dirs.
> cross-tools multiarch
> - /lib/$(gcc -dumpmachine)
> /usr/$(gcc -dumpmachine)/lib/usr/lib/$(gcc -dumpmachine)
> /usr/$(gcc -dumpmachine)/include/usr/include/$(gcc -dumpmachine)
> /usr/bin/$(gcc -dumpmachine)-gcc-
> A decision about which to use has to be made NOW if you want any say
> in the matter. Otherwise the multiarch dirs will be added to gcc,
> binutils and glibc any day now.
> libuclibc0 should then just follow their example.
The current multiarch proposal overlooks paths such as
/usr/$(gcc -dumpmachine)/bin/{nm,ld,ar}, which are the paths referenced
internally by the cross-compiler and refer to binaries for the build
architecture used to generate code for the host architecture. These can't
be made to conform to multiarch paths, because there's no spec for
/usr/lib/$(gcc -dumpmachine)/bin or /usr/bin/$(gcc -dumpmachine), and even
if there were it would be the wrong location for native binaries. This
isn't a deficiency in multiarch, it just shows that multiarch isn't a
complete solution for cross-compilers.
So assuming the multiarch-style paths are the preferred solution (because
of, e.g., the ability to create subdirs of /lib), there would still be a
need for /usr/$(gcc -dumpmachine) directories for cross-compilers -- unless
someone "fixes" gcc to be able to use /usr/bin/$(gcc -dumpmachine)-foo
directly. It just wouldn't be the appropriate path for headers and
libraries.
Anyway, I do think that the multiarch-style directories are the right way
forward, but it doesn't make sense to require uclibc to conform to them
before any other packages are doing so. As such, I agree with the idea of
granting uclibc an exception here *if* multiarch doesn't happen for etch;
but in the meantime, I think this bug should be kept on the radar.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
