Please hint gpe-mininet and gpe-conf

[Neil Williams]

Please hint gpe-mininet and gpe-conf to go into testing together (this
should be the last hint needed for this transition).

Thanks.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




signature.asc
Description: OpenPGP digital signature

Re: Please hint gpe-mininet and gpe-conf

[Adeodato Simó]

* Neil Williams [Sun, 16 Dec 2007 11:31:14 +]:

> Please hint gpe-mininet and gpe-conf to go into testing together (this
> should be the last hint needed for this transition).

Hinted, we'll see how it goes.

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
Military justice is to justice what military music is to music.
-- Groucho Marx


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

[VAC] now - undefined (was Re: ICU transition status)

[Domenico Andreoli]

Hi,

On Fri, Dec 14, 2007 at 09:17:06PM -0500, Jay Berkenbilt wrote:
> 
> At this point, all but one of ICU's reverse build dependencies have
> been uploaded with dependencies on the new versions.  The only
> exception is boost, and an RC bug was already reported 8 days ago.  I
> guess at this point, it's just a question of getting boost uploaded
> and then waiting for everything to be ready to transition.  I'm going
> to be leaving town soon and will not be monitoring this at all while
> I'm gone, but I think it probably doesn't need any more of my focus.
> (Actually, parrot has also not been uploaded, but it's not in testing,
> so it doesn't have any impact on the transition.)

Unfortunately I am having connectivity problems, I am changing DSL
provider and (almost) anybody in Italy knows how much painful is such
a change.

Please take care of boost wrt ICU and any other important issue it
might have.

Best regards,
Domenico

-[ Domenico Andreoli, aka cavok
 --[ http://www.dandreoli.com/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50


signature.asc
Description: Digital signature

Intent to begin clamav library transition

[Stephen Gran]

Hi all,

Clamav upstream is releasing the new version tomorrow, which will
include a soname change.  This means, unhappily, a small library
transition.  The affected packages are (source package names):

avscan
clamcour
claws-mail
dansguardian
gurlchecker
havp
klamav
php-clamavlib
python-clamav
sylpheed-claws

Hopefully, most of these are fixable with a binNMU.  I remember from the
last library transition that some of them muck about with private
structures and functions, though, and those will need sourceful uploads.

My plan is to upload to unstable tomorrow, and while it's making it's way
through NEW, I'll start tracking the issues for the redepends.

Thanks, and if this is bad time, please let me know.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-


signature.asc
Description: Digital signature

Clamav license issue affecting etch

[Stephen Gran]

Hi all,

It has recently come to my attention that clamav in etch contains code
that is effectively a port of the unrar-nonfree code base.  This code is
obviously not GPL compatible, and so it looks to me like we are
currently distributing something that we don't have permission to
distribute.  

While it was probably foolish of upstream to do this port and bundle,
and definitely foolish of me not to catch this earlier, I'd rather focus
this discussion on where to go now.

The code is not easily cuttable, as it's intermixed with the rest of the
library.  If someone wants to try removing it all in a clean way,
that's probably the simplest solution, but my first tries have just
gotten me to FTBFS rather quickly.  Probably this could be solved by
replacing all the rar functions with 'return CL_UNKNOWN;' or some other
hack, but I'm not sure I love that solution either.

Other options I see are:
a) removal from the archive 
   not a great solution, since other packages rdepend on it
b) pushing a new version in 
   also not a great solution, since the new release of clamav that does 
   allow for easy cutting of the unrar code also comes with a soname
   transition.  I doubt anyone will be happy with a library transition
   in a stable release.

Suggestions?  Help?
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: [VAC] now - undefined (was Re: ICU transition status)

[Jay Berkenbilt]

Domenico Andreoli <[EMAIL PROTECTED]> wrote:

> Unfortunately I am having connectivity problems, I am changing DSL
> provider and (almost) anybody in Italy knows how much painful is such
> a change.
>
> Please take care of boost wrt ICU and any other important issue it
> might have.
>
> Best regards,
> Domenico

If I have time before my vacation and no one from the debian boost
team responds, I can NMU this.  I would just take 1.34.1-3 (currently
in experimental) and update the changelog and control as needed.  I've
done this locally and am building in pbuilder.

I seem to recall an earlier discussion that the only reason 1.34.1-3
was uploaded to experimental instead of unstable was to avoid
lengthening the boost 1.33 to 1.34 transition, so that's why I'd base
the NMU off of 1.34.1-3 rather than 1.34.1-2.

I'm getting ready to go offline for three weeks myself, so it's not
the best time to do an NMU, but this one is sufficiently trivial that
it should be pretty safe.

If someone else would like to take care of it, please say so.  Thanks!

--Jay


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

apt transition - please bump urgency of libept

[Frans Pop]

Hi,

apt looks almost ready to transition with all that's related to it.

Current blockers are (AFAICT):
- python-apt: 9 of 10 days old
- synaptic: 9 of 10 days old
- libept: 1 of 10 days old + missing on 4 arches

libept was uploaded yesterday with a minor (shlib deps) change to fix a bug 
in the previous upload. If not for that, it would now be 7 days old.
The new version has been built for all arches, just needs uploading for the 
remaining 4.

IMO libept could be bumped to at least urgency high, or maybe even critical, 
so apt and friends get to testing (and we can finally upload a new 
apt-setup for D-I which needs the updated apt in testing).

CC'ing libept maintainer (hi Enrico) to get his take on this.

TIA,
FJP


signature.asc
Description: This is a digitally signed message part.

Re: [VAC] now - undefined (was Re: ICU transition status)

[Luk Claes]

Jay Berkenbilt wrote:
> Domenico Andreoli <[EMAIL PROTECTED]> wrote:
> 
>> Unfortunately I am having connectivity problems, I am changing DSL
>> provider and (almost) anybody in Italy knows how much painful is such
>> a change.
>>
>> Please take care of boost wrt ICU and any other important issue it
>> might have.
>>
>> Best regards,
>> Domenico
> 
> If I have time before my vacation and no one from the debian boost
> team responds, I can NMU this.  I would just take 1.34.1-3 (currently
> in experimental) and update the changelog and control as needed.  I've
> done this locally and am building in pbuilder.
> 
> I seem to recall an earlier discussion that the only reason 1.34.1-3
> was uploaded to experimental instead of unstable was to avoid
> lengthening the boost 1.33 to 1.34 transition, so that's why I'd base
> the NMU off of 1.34.1-3 rather than 1.34.1-2.

Well, you may recall correctly, though things have changed in the
meantime... There is not supposed to be an upload of boost that isn't
backwards compatible!

> I'm getting ready to go offline for three weeks myself, so it's not
> the best time to do an NMU, but this one is sufficiently trivial that
> it should be pretty safe.

It's not as trivial as you seem to think, so please refrain from
uploading it.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: apt transition - please bump urgency of libept

[Luk Claes]

Frans Pop wrote:
> Hi,
> 
> apt looks almost ready to transition with all that's related to it.
> 
> Current blockers are (AFAICT):
> - python-apt: 9 of 10 days old
> - synaptic: 9 of 10 days old
> - libept: 1 of 10 days old + missing on 4 arches
> 
> libept was uploaded yesterday with a minor (shlib deps) change to fix a bug 
> in the previous upload. If not for that, it would now be 7 days old.
> The new version has been built for all arches, just needs uploading for the 
> remaining 4.
> 
> IMO libept could be bumped to at least urgency high, or maybe even critical, 
> so apt and friends get to testing (and we can finally upload a new 
> apt-setup for D-I which needs the updated apt in testing).

It's already bumped with urgency (2 days) by Steve ...

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [VAC] now - undefined (was Re: ICU transition status)

[Jay Berkenbilt]

Luk Claes <[EMAIL PROTECTED]> wrote:

> Jay Berkenbilt wrote:
>> Domenico Andreoli <[EMAIL PROTECTED]> wrote:
>> 
>>> Unfortunately I am having connectivity problems, I am changing DSL
>>> provider and (almost) anybody in Italy knows how much painful is such
>>> a change.
>>>
>>> Please take care of boost wrt ICU and any other important issue it
>>> might have.
>>>
>>> Best regards,
>>> Domenico
>> 
>> If I have time before my vacation and no one from the debian boost
>> team responds, I can NMU this.  I would just take 1.34.1-3 (currently
>> in experimental) and update the changelog and control as needed.  I've
>> done this locally and am building in pbuilder.
>> 
>> I seem to recall an earlier discussion that the only reason 1.34.1-3
>> was uploaded to experimental instead of unstable was to avoid
>> lengthening the boost 1.33 to 1.34 transition, so that's why I'd base
>> the NMU off of 1.34.1-3 rather than 1.34.1-2.
>
> Well, you may recall correctly, though things have changed in the
> meantime... There is not supposed to be an upload of boost that isn't
> backwards compatible!

I hadn't looked carefully at the packages yet.  Now that I am looking
at it, I see clearly from the changelog that 1.34.1-3 was an ABI
change, so you're right -- I definitely don't want to upload it.
(Though I'm surprised that going from gcc 4.1 to 4.2 is really an ABI
change.)

>> I'm getting ready to go offline for three weeks myself, so it's not
>> the best time to do an NMU, but this one is sufficiently trivial that
>> it should be pretty safe.
>
> It's not as trivial as you seem to think, so please refrain from
> uploading it.

Point taken.  I would feel the same way if someone were going to NMU
tiff or ICU.

In any case, I wouldn't have uploaded without testing carefully.  I
have software that uses some of the boost libraries.  I would at least
have locally installed boost and checked my software, openoffice, and
perhaps some other reverse dependencies.  My initial comments were
based on my memory of earlier conversations, not a careful analysis.
But you're right, this is not to be taken lightly.

In any case, I can either do an NMU based on 1.34.1-2 (which really
should be safe since 1.34.1-2 is already in testing), or I can just
drop it and let someone else take care of it.  Unless someone says to
go ahead with 1.34.1-2.1, I'll just leave it alone.  If it is not
resolved by the time I'm back from vacation, I probably will upload
1.34.1-2.1 though.  Given that this fixes a 10-day-old RC bug, anyone
could do an NMU at this point anyway.

--Jay


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: apt transition - please bump urgency of libept

[Otavio Salvador]

Luk Claes <[EMAIL PROTECTED]> writes:

> It's already bumped with urgency (2 days) by Steve ...

After APT moves to testing, we'll break ABI of it again on sid :(
We've pending things fixed for uploading and some other Ubuntu changes
for merging too.

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
-
"Microsoft sells you Windows ... Linux gives
 you the whole house."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

please bin-NMU openoffice.org-voikko

[Rene Engelhard]

Hi,

please requeue bin-NMUs of openoffice.org-voikko on all archs to rebuild
it against OOo 2.3.1.

TIA.

Regards,

Rene


signature.asc
Description: Digital signature

Re: [VAC] now - undefined (was Re: ICU transition status)

[Steve Langasek]

tags 454605 patch
thanks

On Sun, Dec 16, 2007 at 01:45:45PM -0500, Jay Berkenbilt wrote:
> I hadn't looked carefully at the packages yet.  Now that I am looking
> at it, I see clearly from the changelog that 1.34.1-3 was an ABI
> change, so you're right -- I definitely don't want to upload it.
> (Though I'm surprised that going from gcc 4.1 to 4.2 is really an ABI
> change.)

It's not, except that the boost Debian packages are encoding the gcc version
in the soname by hand.  This is wrong, but needs to be addressed in order to
get icu through in a timely fashion.

The attached patch looks to me like it does the necessary handling of
switching to gcc-4.2 without breaking the ABI.  I'm still going through the
QA on it, but so far it looks sane; if anyone notices a problem with it,
please let me know, otherwise I'll plan to NMU once I have a good build and
am happy that I haven't broken anything.

In the future, it might be a good idea to switch away from "g++-4.2" to just
"g++"; the -3 upload in experimental actually has a latent RC bug, because
it invokes g++-4.2 but doesn't build-depend on it, so that package will
break suddenly the next time the default g++ version changes.

> In any case, I wouldn't have uploaded without testing carefully.  I
> have software that uses some of the boost libraries.  I would at least
> have locally installed boost and checked my software, openoffice, and
> perhaps some other reverse dependencies.  My initial comments were
> based on my memory of earlier conversations, not a careful analysis.
> But you're right, this is not to be taken lightly.

> In any case, I can either do an NMU based on 1.34.1-2 (which really
> should be safe since 1.34.1-2 is already in testing), or I can just
> drop it and let someone else take care of it.  Unless someone says to
> go ahead with 1.34.1-2.1, I'll just leave it alone.  If it is not
> resolved by the time I'm back from vacation, I probably will upload
> 1.34.1-2.1 though.  Given that this fixes a 10-day-old RC bug, anyone
> could do an NMU at this point anyway.

Jay, if you have time to check on your side that this patch gives a useful
set of packages, that would certainly be helpful; I don't have anything than
uses boost, so I'm really checking that the packages look right on paper
after the change, not confirming that the libs still work the same at
runtime.  This /shouldn't/ be an issue given that there's no magic in -3 to
make the packages work, but the extra assurance wouldn't hurt either.

And maybe you'd have a working package sooner than I at the rate I'm
currently going, and could feel free to upload it before 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]
diff -u boost-1.34.1/debian/control boost-1.34.1/debian/control
--- boost-1.34.1/debian/control
+++ boost-1.34.1/debian/control
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian Boost Team <[EMAIL PROTECTED]>
 Uploaders: Steve M. Robbins <[EMAIL PROTECTED]>, Domenico Andreoli <[EMAIL PROTECTED]>, Christophe Prud'homme <[EMAIL PROTECTED]>
-Build-Depends: debhelper (>= 4), bison, flex, docbook-to-man, xsltproc, doxygen, zlib1g-dev, libbz2-dev, libicu36-dev, python-dev | python-all-dev, python2.4-dev, python-support (>= 0.3), g++-4.1
+Build-Depends: debhelper (>= 4), bison, flex, docbook-to-man, xsltproc, doxygen, zlib1g-dev, libbz2-dev, libicu-dev, python-dev | python-all-dev, python2.4-dev, python-support (>= 0.3), g++-4.2
 Standards-Version: 3.7.2
 
 Package: bcp
diff -u boost-1.34.1/debian/changelog boost-1.34.1/debian/changelog
--- boost-1.34.1/debian/changelog
+++ boost-1.34.1/debian/changelog
@@ -1,3 +1,15 @@
+boost (1.34.1-2.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Build-depend on libicu-dev instead of libicu36-dev for the icu library
+transition.  Closes: #454605.
+  * Drop the gcc version out of the library soname since it's no longer part
+of what determines the ABI, and add backwards-compatibility "-gcc41"
+symlinks for all libraries to avoid gratuitous ABI breakage when
+rebuilding with gcc 4.2.  Bump the shlibs to match.
+
+ -- Steve Langasek <[EMAIL PROTECTED]>  Sun, 16 Dec 2007 13:59:29 -0800
+
 boost (1.34.1-2) unstable; urgency=low
 
   [ Steve Robbins ]
diff -u boost-1.34.1/debian/rules boost-1.34.1/debian/rules
--- boost-1.34.1/debian/rules
+++ boost-1.34.1/debian/rules
@@ -10,12 +10,12 @@
 
 # Boost does not guarantee any ABI, it uses the full version in SONAME
 SOVERSION = 1.34.1
-SHLIBS_VERSION =
+SHLIBS_VERSION = (>= 1.34.1-2.1)
 DEBIAN_SUFFIX =
 
 # tags for library name decoration
 boost_version = $(subst .,_,$(SOVERSION))
-gcc_version = gcc41
+gcc_version = gcc42
 
 # Boost libraries for which we want separate packages
 boost_libs := date-time filesystem 

Re: [VAC] now - undefined (was Re: ICU transition status)

[Bernd Zeimetz]

> The attached patch looks to me like it does the necessary handling of
> switching to gcc-4.2 without breaking the ABI.  I'm still going through the
> QA on it, but so far it looks sane; if anyone notices a problem with it,
> please let me know, otherwise I'll plan to NMU once I have a good build and
> am happy that I haven't broken anything.

A but offtopic now, but I jumped into my mind while looking at your
diff As we want to move to python2.5 at some point

I think the line

PYTHON_CONFIG="using python : 2.4 : /usr ;"

could be replaced by

PYTHON_CONFIG="using python : $(shell pyversions -dv) : /usr ;"

Which would allow to drop the build-dependency on python2.4-dev -
assuming that boost builds fine with python2.5.


Cheers,

Bernd

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: apt transition - please bump urgency of libept

[Luk Claes]

Otavio Salvador wrote:
> Luk Claes <[EMAIL PROTECTED]> writes:
> 
>> It's already bumped with urgency (2 days) by Steve ...
> 
> After APT moves to testing, we'll break ABI of it again on sid :(
> We've pending things fixed for uploading and some other Ubuntu changes
> for merging too.

Unfortunately is not going to happen as soon as we wanted due to a new
aptitude upload...

Cheers

Luk



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: apt transition - please bump urgency of libept

[Enrico Zini]

On Mon, Dec 17, 2007 at 12:51:35AM +0100, Luk Claes wrote:

> Unfortunately is not going to happen as soon as we wanted due to a new
> aptitude upload...

This kind of scenario made me think... would it make sense to publish in
a fixed location a machine-readable scenario of current ongoing
transitions, then have dput fetch it and print a warning in case one is
going to upload a package that would step in someone's feet?


Ciao,

Enrico

-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: apt transition - please bump urgency of libept

[Otavio Salvador]

Dear Daniel,

I'd like to ask you to postpone any other aptitude upload, for sid,
until we're moved current APT to testing since we do want to move
forward with APT on sid but d-i and other things need this (0.7.9)
version to be available ASAP.

Cheers,

Luk Claes <[EMAIL PROTECTED]> writes:

> Otavio Salvador wrote:
>> Luk Claes <[EMAIL PROTECTED]> writes:
>> 
>>> It's already bumped with urgency (2 days) by Steve ...
>> 
>> After APT moves to testing, we'll break ABI of it again on sid :(
>> We've pending things fixed for uploading and some other Ubuntu changes
>> for merging too.
>
> Unfortunately is not going to happen as soon as we wanted due to a new
> aptitude upload...
>
> Cheers
>
> Luk
>
>

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
-
"Microsoft sells you Windows ... Linux gives
 you the whole house."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: apt transition - please bump urgency of libept

[Steve Langasek]

On Mon, Dec 17, 2007 at 01:02:09AM +0100, Enrico Zini wrote:
> On Mon, Dec 17, 2007 at 12:51:35AM +0100, Luk Claes wrote:

> > Unfortunately is not going to happen as soon as we wanted due to a new
> > aptitude upload...

> This kind of scenario made me think... would it make sense to publish in
> a fixed location a machine-readable scenario of current ongoing
> transitions, then have dput fetch it and print a warning in case one is
> going to upload a package that would step in someone's feet?

http://ftp-master.debian.org/testing/update_output.txt.gz is already
published; it's possible to parse this to get a list of both packages that
are currently hinted, and packages that are currently accepted only as part
of an ongoing hint run.

I don't think I agree that dput should attempt to pull this information
prior to any upload.  How is dput to know the difference between an upload
to an "official" repo, and a local repo?  I think maintainers need to be
cognizant of their packages' involvement in transitions, but I'm not sure
that's the right way to accomplish it.

Ideally, maintainers would be aware of whether their packages aren't
up-to-date in testing (something they should be interested in for their own
sakes), and be aware of when this indicates a library transition.  This is
harder now that binNMUs are widely used, but certainly in the case of
aptitude this was a sourceful upload on the part of the maintainer and just
a look at his qa page would have shown it wasn't up-to-date in testing.  But
evidently this isn't how (some) maintainers work today.

-- 
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: [VAC] now - undefined (was Re: ICU transition status)

[Steve Langasek]

On Mon, Dec 17, 2007 at 12:39:20AM +0100, Bernd Zeimetz wrote:

> > The attached patch looks to me like it does the necessary handling of
> > switching to gcc-4.2 without breaking the ABI.  I'm still going through the
> > QA on it, but so far it looks sane; if anyone notices a problem with it,
> > please let me know, otherwise I'll plan to NMU once I have a good build and
> > am happy that I haven't broken anything.

> A but offtopic now, but I jumped into my mind while looking at your
> diff As we want to move to python2.5 at some point

> I think the line

> PYTHON_CONFIG="using python : 2.4 : /usr ;"

> could be replaced by

> PYTHON_CONFIG="using python : $(shell pyversions -dv) : /usr ;"

> Which would allow to drop the build-dependency on python2.4-dev -
> assuming that boost builds fine with python2.5.

Yes, that would be nice.  The package currently build-depends on
python2.4-dev, *and* an python-dev | python-all-dev; simplifying that can
only be a win.

BTW, the previous patch didn't work, I made the mistake of thinking that the
sonames were being set from within debian/rules when the complex logic in
debian/rules was apparently just there to keep pace with upstream.  So
that's a factor in not dropping the explicit "g++-4.2" build-dep for now.

The attached patch works quite a bit better, and is what I'll upload if it
finishes checking out here.

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]
diff -u boost-1.34.1/debian/control boost-1.34.1/debian/control
--- boost-1.34.1/debian/control
+++ boost-1.34.1/debian/control
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian Boost Team <[EMAIL PROTECTED]>
 Uploaders: Steve M. Robbins <[EMAIL PROTECTED]>, Domenico Andreoli <[EMAIL PROTECTED]>, Christophe Prud'homme <[EMAIL PROTECTED]>
-Build-Depends: debhelper (>= 4), bison, flex, docbook-to-man, xsltproc, doxygen, zlib1g-dev, libbz2-dev, libicu36-dev, python-dev | python-all-dev, python2.4-dev, python-support (>= 0.3), g++-4.1
+Build-Depends: debhelper (>= 4), bison, flex, docbook-to-man, xsltproc, doxygen, zlib1g-dev, libbz2-dev, libicu-dev, python-dev | python-all-dev, python2.4-dev, python-support (>= 0.3), g++-4.2
 Standards-Version: 3.7.2
 
 Package: bcp
diff -u boost-1.34.1/debian/changelog boost-1.34.1/debian/changelog
--- boost-1.34.1/debian/changelog
+++ boost-1.34.1/debian/changelog
@@ -1,3 +1,16 @@
+boost (1.34.1-2.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Build-depend on libicu-dev instead of libicu36-dev for the icu library
+transition.  Closes: #454605.
+  * Bump the Build-Depends from g++-4.1 to g++-4.2, and add
+backwards-compatibility "-gcc41" symlinks for all libraries to avoid
+gratuitous ABI breakage for the rebuild since the gcc version
+doesn't change the ABI, contrary to upstream assertion.  Bump the
+shlibs to match.
+
+ -- Steve Langasek <[EMAIL PROTECTED]>  Sun, 16 Dec 2007 13:59:29 -0800
+
 boost (1.34.1-2) unstable; urgency=low
 
   [ Steve Robbins ]
diff -u boost-1.34.1/debian/rules boost-1.34.1/debian/rules
--- boost-1.34.1/debian/rules
+++ boost-1.34.1/debian/rules
@@ -10,12 +10,12 @@
 
 # Boost does not guarantee any ABI, it uses the full version in SONAME
 SOVERSION = 1.34.1
-SHLIBS_VERSION =
+SHLIBS_VERSION = (>= 1.34.1-2.1)
 DEBIAN_SUFFIX =
 
 # tags for library name decoration
 boost_version = $(subst .,_,$(SOVERSION))
-gcc_version = gcc41
+gcc_version = gcc42
 
 # Boost libraries for which we want separate packages
 boost_libs := date-time filesystem graph iostreams program-options python regex serialization signals test thread wave
@@ -36,6 +36,7 @@
 # helpers to make basic and decorated library names
 mk_base_name = usr/lib/libboost_$(subst -,_,$(1))$(2)
 mk_full_name = usr/lib/libboost_$(subst -,_,$(1))-$(gcc_version)$(2)-$(boost_version)
+mk_compat_name = usr/lib/libboost_$(subst -,_,$(1))-gcc41$(2)-$(boost_version)
 
 # helpers to make proper release/debug package names
 mk_pkg_lib = libboost-$(if $(findstring -d,$(2)),dbg,$(1)$(SOVERSION)$(DEBIAN_SUFFIX))
@@ -49,7 +50,8 @@
 mk_ln_files = $(shell echo $(call mk_full_name,$(2),$(3)).so.$(SOVERSION) $(call mk_full_name,$(2),$(3)).so >> $(call mk_deb_dev,$(1),$(3)).links)
 mk_ln2_files = $(shell echo $(call mk_full_name,$(2),$(3)).so $(call mk_base_name,$(2),$(3)).so >> $(call mk_deb_dev,$(1),$(3)).links)
 mk_ln3_files = $(shell echo $(call mk_full_name,$(2),$(3)).a $(call mk_base_name,$(2),$(3)).a >> $(call mk_deb_dev,$(1),$(3)).links)
-mk_files = $(foreach fn,a so ln ln2 ln3,$(call mk_$(fn)_files,$(1),$(2),$(3)))
+mk_ln4_files = $(shell echo $(call mk_full_name,$(2),$(3)).so.$(SOVERSION) $(call mk_compat_name,$(2),$(3)).so >> $(call mk_deb_lib,$(1),$(3)).links)
+mk_files = $(foreach fn,a so ln ln2 ln3 ln4,$(cal

Re: Please binNMU apache2-mpm-itk

[Steve Langasek]

On Tue, Dec 11, 2007 at 08:46:22PM +0100, Stefan Fritsch wrote:

> please binNMU apache2-mpm-itk to build against apache2 2.2.6-3, which 
> is already installed for all architectures.

Scheduled.

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: apt transition - please bump urgency of libept

[Daniel Burrows]

  (this is an expansion of a reply I dashed off earlier to Otavio on my
   way to dinner)

On Sun, Dec 16, 2007 at 10:42:41PM -0200, Otavio Salvador <[EMAIL PROTECTED]> 
was heard to say:
> I'd like to ask you to postpone any other aptitude upload, for sid,
> until we're moved current APT to testing since we do want to move
> forward with APT on sid but d-i and other things need this (0.7.9)
> version to be available ASAP.

  Hi, Otavio.  Thanks for bringing this to my attention.

  Sorry about the trouble.  I wasn't aware that there was an apt
transition going on, but I certainly won't upload any new versions until
that goes through.  I've subscribed to -release so that I can keep an
eye on what sorts of transitions are going on in the future.  Hopefully
I can avoid future badly-timed uploads that way.

  I wonder if it would be a good idea to announce apt transitions on
[EMAIL PROTECTED]  aptitude is not special in its dependency structure; any
upload of an apt-related package will do the same thing, and I think
maintainers of those packages are more likely to be subscribed to deity
than to -release.  I could be totally mistaken in this belief, of
course.

  Daniel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]