Re: permission for ICU transition
Hi Jay, On Mon, Sep 04, 2006 at 01:07:05PM -0400, Jay Berkenbilt wrote: ICU version 3.6 has been released. I would like permission to upload it to unstable and cause an ICU library transition. These source packages contain binary packages that depend upon libicu34: boost ibm-3270 openoffice.org parrot xerces27 Only boost and xerces27 above are libraries. Hopefully their dependencies are set up suitably to not themselves build depend upon libicu34-dev. In any case, the ICU source interfaces appear to not have non-compatible API changes, though I haven't rigorously verified this. It seems likely though that this transition will just be a question of updating build dependencies on the dependent packages. If there are no incompatible API changes, wouldn't it be more straightforward to continue building libicu34-dev from the icu source and schedule binNMUs for the reverse-deps instead of renaming it to libicu36-dev and requiring editing of build-deps? I would stay on top of this transition and be willing/able to NMU packages as needed. The biggest and most visible package here is openoffice.org, but that package seems to be well-maintained. Also, I emailed the maintainers of all these packages to alert them to the fact that there may be an ICU transition, and I uploaded a beta version of ICU 3.6 to experimental. openoffice.org currently needs an upload for the libgcj7/libgcj7-0 ABI transition. I would prefer not to have this transition overlap the icu one, but the icu transition is small enough that on its own it shouldn't cause too much pain if they do overlap, so please go ahead with this upload on whatever timetable is most appropriate for you. On Thu, Sep 07, 2006 at 02:43:06PM -0400, Jay Berkenbilt wrote: Several days ago, I asked whether it would be okay to upload a new version of ICU with an soname bump. Other than a message from the boost maintainer that he would be tracking ICU and would upload a new boost as soon as the new ICU appeared, I haven't heard anything. I'm not sure whether I'm supposed to wait for an affirmative response from the release team or whether I'm supposed to just go ahead with the upload after informing the release team. Please pardon me if I'm being impatient by asking again. I was hoping to take care of this during the upcoming weekend. Given that we aren't in a freeze yet that would affect icu, you don't have any obligation to wait for the release team's approval before uploading; if there had been any strong objections those probably would've come sooner rather than later. I do appreciate you letting us know about the transition, though, and I'm sorry for keeping you waiting. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please schedule binNMUs for xine-lib on mipsen
On Sun, Sep 03, 2006 at 03:03:43PM +0200, Reinhard Tartler wrote: Please schedule binNMUs for xine-lib on both mips and mipsel. Background: xine-lib_1.1.2-4 is the first upload to unstable which links to debian's ffmpeg. This works fine for all architectures but mipsen. ffmpeg_0.cvs20060823-2 contains a fix regarding mips/mipsel for correctly linking against libpthread, as suggested by vorlon on irc. Now ffmpeg_0.cvs20060823-2 has been installed for both mipsen, so xine-lib should now be able to build there. Given back. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ABI changes in gnomeVFS 2.16
Le jeudi 07 septembre 2006 à 16:41 -0700, Steve Langasek a écrit : Ah, but libgnomevfs-2.so.0 *also* depends on libbonobo; and if libbonobo has added symbols it should have a shlibs bump; so rebuilding the new libgnomevfs-2.so.0 with the right version of libbonobo will cause it to depend on an appropriate version of libbonobo, providing the symbols that you need. This is true for 2.14, but the new libgnomevfs2-0 package doesn't depend on libbonobo2-0. The point of this symbol move was to remove that dependency. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: Sarge - Etch upgrade issue
* Steve Langasek ([EMAIL PROTECTED]) [060908 01:47]: Yes, I can see that apt Recommends: debian-archive-keyring and Suggests: gnupg. Given that apt should be doing secure archives by default now, the Suggests: seems like the wrong relationship; I think this warrants a bug on apt, no? Agreed. I think we should also note it in the release notes, unless we shift both dependencies to Depends. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ABI changes in gnomeVFS 2.16
On Fri, Sep 08, 2006 at 10:38:28AM +0200, Josselin Mouette wrote: Le jeudi 07 septembre 2006 à 16:41 -0700, Steve Langasek a écrit : Ah, but libgnomevfs-2.so.0 *also* depends on libbonobo; and if libbonobo has added symbols it should have a shlibs bump; so rebuilding the new libgnomevfs-2.so.0 with the right version of libbonobo will cause it to depend on an appropriate version of libbonobo, providing the symbols that you need. This is true for 2.14, but the new libgnomevfs2-0 package doesn't depend on libbonobo2-0. The point of this symbol move was to remove that dependency. Oh well, it was worth a try. A versioned conflict would be an ok solution, then. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sarge - Etch upgrade issue
Hi! * Steve Langasek [EMAIL PROTECTED] [060908 01:46]: 1) sarge: 1.1) apt-get dist-upgrade - upgrading to etch [..] Yes, I can see that apt Recommends: debian-archive-keyring and Suggests: gnupg. Given that apt should be doing secure archives by default now, the Suggests: seems like the wrong relationship; I think this warrants a bug on apt, no? Shouldn't the Recommends: debian-archive-keyring be enought? AFAIK the Release Notes recommend using aptitude instead of apt-get. And aptitude respects recommends should pull in debian-archive-keyring, which depends on gnupg. Yours sincerely, Alexander -- http://learn.to/quote/ http://www.catb.org/~esr/faqs/smart-questions.html signature.asc Description: Digital signature
Re: [Pkg-mailman-hackers] Bug#358575: mailman 2.1.5-8sarge3: screwup between security and maintainer upload
On Thu, Sep 07, 2006 at 08:02:06PM +0200, Florian Weimer wrote: * Martin Schulze: Imho, it's more useful to upload 2.1.5-8sarge4 and only bump the version number to get the new version built for all architectures into the archive. While you are at it, you could also include this patch: Log Message: --- CVE-2006-3636. Fixes for various cross-site scripting issues. Discovery by Moritz Naumann and most of the repair work done by Mark Sapiro (with some additional work by Barry). As far as I understand the policy listed on http://release.debian.org/stable/3.1/3.1r3/, this would require a DSA. Does the security team plan on doing a DSA on this if I prepare a package, or does the stable release team grant me an exception to the policy to prepare -8sarge4 with this patch? If not, I'll prepare a -8sarge4 without any change as authorised by Martin Zobel-Helas. If I get an answer (CCed to [EMAIL PROTECTED], not only to [EMAIL PROTECTED]) within two hours, I'll prepare a package today (Friday 8 September). -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Binary NMU requested for mailman in sarge [was: mailman 2.1.5-8sarge3: screwup between security and maintainer upload]
On Thu, Sep 07, 2006 at 02:44:21AM -0700, Steve Langasek wrote: On Thu, Sep 07, 2006 at 11:21:35AM +0200, Lionel Elie Mamane wrote: Stable release team, please react accordingly; you may for example do a binary sourceless NMU for the architectures that have -8sarge3 the security update so that they all have -8sarge3 the maintainer update. I have now heard about what the security problem addressed in -8sarge3 the security update is. It is believed not to be exploitable. I thus now officially request a binary NMU to replace -8sarge3 the security update by -8sarge3 the maintainer update on the arches that have -8sarge3 the security update. And which archs are those? I sent that mail before reading the mail from Martin Zobel-Helas authorising a -8sarge4 without any changes to force a rebuild (because that mail was not CCed to me personally). I'm now pursuing that route, and I'm taking back my binary NMU request. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Approve openssl for testing.
Hi, Could you please hint openssl 0.9.8b-3 in testing? Note that it contains a udeb, so it's frozen. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#358575: mailman 2.1.5-8sarge3: screwup between security and maintainer upload
On Fri, Sep 08, 2006 at 05:03:06PM +0200, Lionel Elie Mamane wrote: On Thu, Sep 07, 2006 at 08:02:06PM +0200, Florian Weimer wrote: * Martin Schulze: Imho, it's more useful to upload 2.1.5-8sarge4 and only bump the version number to get the new version built for all architectures into the archive. While you are at it, you could also include this patch: CVE-2006-3636. Fixes for various cross-site scripting issues. Discovery by Moritz Naumann and most of the repair work done by Mark Sapiro (with some additional work by Barry). As far as I understand the policy listed on http://release.debian.org/stable/3.1/3.1r3/, this would require a DSA. Does the security team plan on doing a DSA on this if I prepare a package, or does the stable release team grant me an exception to the policy to prepare -8sarge4 with this patch? If I get an answer (CCed to [EMAIL PROTECTED], not only to [EMAIL PROTECTED]) within two hours, I'll prepare a package today (Friday 8 September). I must go away now, but I've prepared packages for a security update; they are at http://people.debian.org/~lmamane/mailman/ . -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Binary NMU requested for mailman in sarge [was: mailman 2.1.5-8sarge3: screwup between security and maintainer upload]
On Fri, Sep 08, 2006 at 05:05:48PM +0200, Lionel Elie Mamane wrote: On Thu, Sep 07, 2006 at 02:44:21AM -0700, Steve Langasek wrote: On Thu, Sep 07, 2006 at 11:21:35AM +0200, Lionel Elie Mamane wrote: Stable release team, please react accordingly; you may for example do a binary sourceless NMU for the architectures that have -8sarge3 the security update so that they all have -8sarge3 the maintainer update. I have now heard about what the security problem addressed in -8sarge3 the security update is. It is believed not to be exploitable. I thus now officially request a binary NMU to replace -8sarge3 the security update by -8sarge3 the maintainer update on the arches that have -8sarge3 the security update. And which archs are those? I sent that mail before reading the mail from Martin Zobel-Helas authorising a -8sarge4 without any changes to force a rebuild (because that mail was not CCed to me personally). I'm now pursuing that route, and I'm taking back my binary NMU request. I have nevertheless checked it out, and only i386 has -8sarge3 the security update, all others have -8sarge3 the maintainer update. Depending on the evolution of the fate of -8sarge4, you may want to do a binary NMU after all or not. Best Regards, -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
vim-vimoutliner to stable-proposed-updates?
Hi, the problem is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=316626 -- it is one of those last minute before freezing stable uploads and it went horribly wrong, resulting that current Debian/stable has non-functional package. I tried to persuade Joey, that vim-vimoutliner should go to stable-proposed-updates, but he rejected me, because VO didn't seem to be important enough for him. However, number of grumbling users of stable Debian is getting higher, so I would like to ask once more -- could the current vim-vimoutliner from testing go to stable-updates? There has not been a big bugs for a long time (currently, there is no open bug (I forgot to close #383694). Best, Matěj -- 23 Marion St. #3, Cambridge, MA 02141, (617) 876-1259 http://matej.ceplovi.cz/blog/, map http://tinyurl.com/r2lfa GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC Just remember, brothers and sisters--their skins may be white, but their souls are just as black as ours! -- a black preacher -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: vim-vimoutliner to stable-proposed-updates?
Hi Matej, Matej Cepl [EMAIL PROTECTED] writes: Hi, the problem is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=316626 -- it is one of those last minute before freezing stable uploads and it went horribly wrong, resulting that current Debian/stable has non-functional package. I tried to persuade Joey, that vim-vimoutliner should go to stable-proposed-updates, but he rejected me, because VO didn't seem to be important enough for him. However, number of grumbling users of stable Debian is getting higher, so I would like to ask once more -- could the current vim-vimoutliner from testing go to stable-updates? There has not been a big bugs for a long time (currently, there is no open bug (I forgot to close #383694). Stable update policy is as follows: 1. The package fixes a security problem. An advisory by our own Security Team is required. Updates need to be approved by the Security Team. 2. The package fixes a critical bug which can lead to data loss, data corruption, or an overly broken system, or the package is broken. 3. The stable version of the package is not installable at all due to broken or unmet dependencies or broken installation scripts. 4. All released architectures have to be in sync. 5. The package gets all released architectures back in sync. I don't see any of above criteria matched here. Okay, one could argue about 2 here (the package is broken), but i don't see a reason ATM to fix a normal bug in the next point release. So no, i don't see this this as a valid candidate. Sorry. Greetings Martin -- Martin Zobel-Helas GPG Key-ID:0x5d64f870 Debian DevelopereMail Privat: [EMAIL PROTECTED] Debian Stable Release Manager eMail Debian: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sarge - Etch upgrade issue
On Fri, Sep 08, 2006 at 05:01:07PM +0200, Alexander Schmehl wrote: * Steve Langasek [EMAIL PROTECTED] [060908 01:46]: 1) sarge: 1.1) apt-get dist-upgrade - upgrading to etch [..] Yes, I can see that apt Recommends: debian-archive-keyring and Suggests: gnupg. Given that apt should be doing secure archives by default now, the Suggests: seems like the wrong relationship; I think this warrants a bug on apt, no? Shouldn't the Recommends: debian-archive-keyring be enought? AFAIK the Release Notes recommend using aptitude instead of apt-get. And aptitude respects recommends should pull in debian-archive-keyring, which depends on gnupg. Ah, good catch. (I wonder why apt has a separate Suggests: gnupg then?) This means that users who dist-upgrade using aptitude, pulling in Recommends, should not have this problem; so the most that should be needed here is release notes documentation. Assuming someone can test that this works as expected? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Debian Naming Suggestion
Title: Debian Naming Suggestion I currently do not subscribe to the mailing lists. So I don't know if this has been considered. I want to offer a suggestion for a new Debian naming convention. I have enjoyed the Toy Story names. But perhaps it has run it's course. We have used 10 toy stoy names over a period of 10 years. That is a good round number and would be a logical place to start anew. If Debain were to name the new testing branch Andy (the owner of all the toys). That would make a good ending point and when it is moved to stable, a new naming convention could be instituted for the testing and unstable branches. I propose that Debian continue along the same vein with characters from a different Pixar movie. IMO, Finding Nemo makes a lot of sense. It has a lot of named characters that will provide years of distro names. The unstable branch could be forgetful dory or undiciplined darla. That is just a simple suggestion that I wanted to submit. Thank you for taking the time to read this and passing it along for consideration. Jeremy
Meeting Minutes from the latest SRM meeting
Hi *,
there was a stable release team meeting on Thursday September, 8th. Here
are the meeting minutes, summerized by zobel, additions by aba.
Meeting Minutes:
- Kernel updates:
Dann reported, that another kernel update with abi change will happen soon
but he will not change the abi number of that kernel, as only one module
is affected. After that a kernel update for only 1-2 archs will happen.
He also reported that he is working on a new set of kernels to fix some
long standing bugs and he would also like to include some drivers for new
NICs and some cciss stuff. This only makes sense if a new d-i version is
built afterwards. Dann will send a more detailed list to
[EMAIL PROTECTED] prior upload.
- Time based release:
We spoke about the idea of a time based release for r4. Anthony and Julien
think it is a too short time frame, but we should try this experiment, and
the speak with cd-vendors after r4, so we get better impression. Release
date of r4 set to ~16th of October.
Shorter release cycles would lower the risk of problems we had with e.g.
sendmail.
- QA related review on r3:
Anthony reported that a couple of things were left out in my mail to
ftpmasters, like e.g. two packages not in the list and the removals of old
kernels. We agreed that with beginning of r4, it should just be
everything in p-u should be pushed into stable + these removals + this
list
of hand-tasks (like e.g. pushing the new d-i in or whatever).
Some packages from security.d.o do not make it to ftp-master. Andi will
rewrite his script which shows missing packages from security.d.o
to work with p-u-new.
ACCEPT/REJECT mails on debian-changes need some work. It is basicly
rewriting the scripts used for p-u-new accepts/rejects. Andi and Anthony
will work on that.
Footnote: We need to handle libcrypt-cbc-perl somehow, as it shouldn't be
accepted.
- New Tool for SRM:
SRM would like to have some small tool to do package checks based on what
is already in stable,
- diffing .dsc,
- running wdiff on .deb.
- compare md5sum of packages, if they come from security.d.o
That tool should also produce output for queue/p-u-new/COMMENTS.
Andi and Julien will work on that.
Also a small enhancement is wanted for
http://ftp-master.d.o/proposed-updates.html:
- report about arch-not-in-sync status if package is not from security.d.o
for packages already in proposed-updates
- Key Management for stable
We require the following to work:
Any of etch rX needs to be able to install:
- all etch rY [2006-12 to 2009-06/2008-06]
- dist-upgrade to (etch+1)rY [2007-06 to 2008-12/2009-12]
- should dist-upgrade to testing/unstable between etch and etch+1's release
[2006-12 to 2007-06]
- security updates for etch from security.debian.org [2006-12 to 2009-06]
For this, we use three keys, apt in etch contains {ftp-master, SRM,
security}-key.
The primary key and secondary keys are:
for testing, unstable, experimental, *proposed: ftp-master key (which is
online);
for security: security-key, with ftp-master key as secondary;
for stable: SRM-key, with ftp-master key as secondary.
After release of etch+1, three new keys {ftp-master', SRM', securiy'} are
added to apt.
The primary key and secondary keys are:
for testing, unstable, experimental, *proposed: ftp-master' key (which is
online), with
ftp-master key for a transition periode as secondary;
for security: security'-key, with ftp-master(') keys as secondary;
for stable: SRM'-key, with SRM-key and ftp-master(') keys as secondary.
(and same as after etch+1 after etch+2)
- Point-Releases for oldstable:
We talked about point releases for oldstable. Martin is willing to do that
with beginning of etch=stable. Anthony stated that this needs to be
implemented on dak side, but is straightforward, though. Details of this
point were skipped for this meeting however.
- Tracking RC bugs for stable on bts.turmzimmer.net
Andi will work on that.
--
Martin Zobel-Helas GPG Key-ID:0x5d64f870
Debian DevelopereMail Privat: [EMAIL PROTECTED]
Debian Stable Release Manager eMail Debian: [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Naming Suggestion
This discussion has been had before and at the moment there aren't any plans to change the naming scheme. On 9/9/06, Jeremy Herndon [EMAIL PROTECTED] wrote: I currently do not subscribe to the mailing lists. So I don't know if this has been considered. I want to offer a suggestion for a new Debian naming convention. I have enjoyed the Toy Story names. But perhaps it has run it's course. We have used 10 toy stoy names over a period of 10 years. That is a good round number and would be a logical place to start anew. If Debain were to name the new testing branch Andy (the owner of all the toys). That would make a good ending point and when it is moved to stable, a new naming convention could be instituted for the testing and unstable branches. I propose that Debian continue along the same vein with characters from a different Pixar movie. IMO, Finding Nemo makes a lot of sense. It has a lot of named characters that will provide years of distro names. The unstable branch could be forgetful dory or undiciplined darla. That is just a simple suggestion that I wanted to submit. Thank you for taking the time to read this and passing it along for consideration. Jeremy -- Andrew Donnellan http://andrewdonnellan.com http://ajdlinux.blogspot.com Jabber - [EMAIL PROTECTED] GPG - hkp://subkeys.pgp.net 0x5D4C0C58 --- Member of Linux Australia - http://linux.org.au Debian user - http://debian.org Get free rewards - http://ezyrewards.com/?id=23484 OpenNIC user - http://www.opennic.unrated.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: vim-vimoutliner to stable-proposed-updates?
Hi, In linux.debian.devel.release, Martin Zobel-Helas wrote: the problem is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=316626 -- it is one of those last minute before freezing stable uploads and it went horribly wrong, resulting that current Debian/stable has non-functional package. I tried to persuade Joey, that vim-vimoutliner should go to stable-proposed-updates, but he rejected me, because VO didn't seem to be important enough for him. However, number of grumbling users of stable Debian is getting higher, so I would like to ask once more -- could the current vim-vimoutliner from testing go to stable-updates? (I'm one of these grumbling users, and I bugged him to push for Sarge r4.) Wouldn't it be better to backport the fix? I'd vote for that as a matter of principle, and it shouldn't be hard to do. Stable update policy is as follows: [...] 2. The package fixes a critical bug which can lead to data loss, data corruption, or an overly broken system, or the package is broken. [...] I don't see any of above criteria matched here. Okay, one could argue about 2 here (the package is broken), but i don't see a reason ATM to fix a normal bug in the next point release. Yes, the bug was filed as normal. In reality, however, it *clearly* is severity grave, because, well, it does render the package completely unusable unless the user fixes the bug himself. IMO this is a no-brainer for proposed-updates: completely unusable package, with a simple fix AFAIUI. It's only that the BTS record got screwed up. So yes, I'd very much like to argue about 2. So no, i don't see this this as a valid candidate. Sorry. Please reconsider that decision. Nikolaus PS. Sorry for breaking the thread, I'm not subscribed to d-release but reading it with a mail-to-news-gateway. Reply-to should be set accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: permission for ICU transition
Steve Langasek [EMAIL PROTECTED] wrote: If there are no incompatible API changes, wouldn't it be more straightforward to continue building libicu34-dev from the icu source and schedule binNMUs for the reverse-deps instead of renaming it to libicu36-dev and requiring editing of build-deps? Well, there are lots of new APIs. Anyway, I feel like it would be better to have the name be neutral (like libicu-dev) if we are going to drop the soname from the -dev package rather than having it be called libicu34-dev which seems somehow misleading. There are also some deprecated interfaces from 3.4, so it is still my inclination to go ahead and rename the -dev package and have the new -dev package conflict with the old one. I would stay on top of this transition and be willing/able to NMU packages as needed. The biggest and most visible package here is openoffice.org, but that package seems to be well-maintained. Also, I emailed the maintainers of all these packages to alert them to the fact that there may be an ICU transition, and I uploaded a beta version of ICU 3.6 to experimental. openoffice.org currently needs an upload for the libgcj7/libgcj7-0 ABI transition. I would prefer not to have this transition overlap the icu one, but the icu transition is small enough that on its own it shouldn't cause too much pain if they do overlap, so please go ahead with this upload on whatever timetable is most appropriate for you. Okay, thanks. I'll upload when ready, though I'll look at the transition you mentioned before doing so. Given that I'm heading into a busy period and the ICU transition is, as you point out, small, I may do the upload anyway. On Thu, Sep 07, 2006 at 02:43:06PM -0400, Jay Berkenbilt wrote: Several days ago, I asked whether it would be okay to upload a new version of ICU with an soname bump. Other than a message from the boost maintainer that he would be tracking ICU and would upload a new boost as soon as the new ICU appeared, I haven't heard anything. I'm not sure whether I'm supposed to wait for an affirmative response from the release team or whether I'm supposed to just go ahead with the upload after informing the release team. Please pardon me if I'm being impatient by asking again. I was hoping to take care of this during the upcoming weekend. Given that we aren't in a freeze yet that would affect icu, you don't have any obligation to wait for the release team's approval before uploading; if there had been any strong objections those probably would've come sooner rather than later. I do appreciate you letting us know about the transition, though, and I'm sorry for keeping you waiting. Thanks, and no problem. :-) --Jay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: permission for ICU transition
On Fri, Sep 08, 2006 at 07:57:56PM -0400, Jay Berkenbilt wrote: If there are no incompatible API changes, wouldn't it be more straightforward to continue building libicu34-dev from the icu source and schedule binNMUs for the reverse-deps instead of renaming it to libicu36-dev and requiring editing of build-deps? Well, there are lots of new APIs. Anyway, I feel like it would be better to have the name be neutral (like libicu-dev) if we are going to drop the soname from the -dev package rather than having it be called libicu34-dev which seems somehow misleading. There are also some deprecated interfaces from 3.4, so it is still my inclination to go ahead and rename the -dev package and have the new -dev package conflict with the old one. Ok. Since the 3.4 interfaces are still present, even if deprecated, perhaps a Provides: libicu34-dev might still be appropriate? Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: permission for ICU transition
Steve Langasek [EMAIL PROTECTED] wrote: On Fri, Sep 08, 2006 at 07:57:56PM -0400, Jay Berkenbilt wrote: If there are no incompatible API changes, wouldn't it be more straightforward to continue building libicu34-dev from the icu source and schedule binNMUs for the reverse-deps instead of renaming it to libicu36-dev and requiring editing of build-deps? Well, there are lots of new APIs. Anyway, I feel like it would be better to have the name be neutral (like libicu-dev) if we are going to drop the soname from the -dev package rather than having it be called libicu34-dev which seems somehow misleading. There are also some deprecated interfaces from 3.4, so it is still my inclination to go ahead and rename the -dev package and have the new -dev package conflict with the old one. Ok. Since the 3.4 interfaces are still present, even if deprecated, perhaps a Provides: libicu34-dev might still be appropriate? Yes, I agree. I'll put it in. Thanks. --Jay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
