library package needs to be renamed (libstdc++ allocator change)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
pcre3 (Debian) |
Fix Released
|
Unknown
|
|||
pcre3 (Ubuntu) |
Fix Released
|
High
|
Matthias Klose |
Bug Description
Automatically imported from Debian bug report #339250 http://
In Debian Bug tracker #339250, Matthias Klose (doko-cs) wrote : | #1 |
In Debian Bug tracker #339250, Matthias Klose (doko-cs) wrote : raise severity of bug reports filed for libstdc++ allocator changes | #2 |
severity 339142 serious
severity 339143 serious
severity 339144 serious
severity 339145 serious
severity 339146 serious
severity 339147 serious
severity 339148 serious
severity 339149 serious
severity 339150 serious
severity 339151 serious
severity 339152 serious
severity 339153 serious
severity 339154 serious
severity 339155 serious
severity 339156 serious
severity 339157 serious
severity 339158 serious
severity 339159 serious
severity 339160 serious
severity 339161 serious
severity 339162 serious
severity 339163 serious
severity 339164 serious
severity 339165 serious
severity 339166 serious
severity 339167 serious
severity 339168 serious
severity 339169 serious
severity 339170 serious
severity 339171 serious
severity 339172 serious
severity 339173 serious
severity 339174 serious
severity 339175 serious
severity 339176 serious
severity 339177 serious
severity 339178 serious
severity 339179 serious
severity 339180 serious
severity 339181 serious
severity 339182 serious
severity 339183 serious
severity 339184 serious
severity 339185 serious
severity 339186 serious
severity 339187 serious
severity 339188 serious
severity 339189 serious
severity 339190 serious
severity 339191 serious
severity 339192 serious
severity 339193 serious
severity 339194 serious
severity 339195 serious
severity 339196 serious
severity 339197 serious
severity 339198 serious
severity 339199 serious
severity 339200 serious
severity 339201 serious
severity 339202 serious
severity 339203 serious
severity 339204 serious
severity 339205 serious
severity 339206 serious
severity 339207 serious
severity 339208 serious
severity 339209 serious
severity 339210 serious
severity 339211 serious
severity 339212 serious
severity 339213 serious
severity 339214 serious
severity 339215 serious
severity 339216 serious
severity 339217 serious
severity 339218 serious
severity 339219 serious
severity 339220 serious
severity 339221 serious
severity 339222 serious
severity 339223 serious
severity 339224 serious
severity 339225 serious
severity 339226 serious
severity 339227 serious
severity 339228 serious
severity 339229 serious
severity 339230 serious
severity 339231 serious
severity 339232 serious
severity 339233 serious
severity 339234 serious
severity 339235 serious
severity 339236 serious
severity 339237 serious
severity 339238 serious
severity 339239 serious
severity 339240 serious
severity 339241 serious
severity 339242 serious
severity 339243 serious
severity 339244 serious
severity 339245 serious
severity 339246 serious
severity 339247 serious
severity 339248 serious
severity 339249 serious
severity 339250 serious
severity 339251 serious
severity 339252 serious
severity 339253 serious
severity 339254 serious
severity 339255 serious
severity 339256 serious
severity 339257 serious
severity 339258 serious
severity 339259 serious
severity 339260 serious
severity 339261 serious
severity 339262 serious
severity 339263 serious
severity 339264 serious
severity 339265 serious
severity 339266 serious
severity 339267 serious
severity 339268 serious
severity 339269 serious
severity 339270 serious
severity 339271 serious
severity 339272 serious
severity 339273 serious
severity 339274 serious
severity...
Debian Bug Importer (debzilla) wrote : | #3 |
Automatically imported from Debian bug report #339250 http://
Debian Bug Importer (debzilla) wrote : | #4 |
Message-Id: <email address hidden>
Date: Tue, 15 Nov 2005 07:57:03 +0100 (MET)
From: Matthias Klose <email address hidden>
To: <email address hidden>
Subject: library package needs to be renamed (libstdc++ allocator change)
Package: pcre3
Severity: important
Please do not take any action before reading
http://
This bug report is filed against the source package which builds
a library depending on libstdc++6 and defining or referencing
*mt_alloc* symbols. The package has to be rebuilt with either
g++-4.0_4.0.2-4 or g++-3.4_3.4.4-10 (or newer). Please rename the
library package to a name with a "c2a" suffix, and adjust the build
dependencies if dependencies on another renamed library do exist.
Do *not* yet upload the package, but wait for a followup mail to this
bug report.
If this bug report is for some reason invalid, please close it with
a short reasoning.
Debian Bug Importer (debzilla) wrote : | #5 |
Message-Id: <email address hidden>
Date: Thu, 17 Nov 2005 03:22:36 +0100 (MET)
From: Matthias Klose <email address hidden>
To: <email address hidden>
Subject: Re: library package needs to be renamed (libstdc++ allocator change)
Compiler versions g++-4.0_4.0.2-4 and g++-3.4_3.4.4-10 are now in the
archive. The renaming of the library packages can now start. You can
upload the packages even before the toolchain is built for all architectures
because the packages with the new binary packages will be hold in the NEW
queue until the required toolchain changes are installed on the buildd's.
Debian Bug Importer (debzilla) wrote : | #6 |
Message-ID: <email address hidden>
Date: Thu, 17 Nov 2005 03:25:34 +0100
From: Matthias Klose <email address hidden>
To: <email address hidden>
Subject: raise severity of bug reports filed for libstdc++ allocator changes
severity 339142 serious
severity 339143 serious
severity 339144 serious
severity 339145 serious
severity 339146 serious
severity 339147 serious
severity 339148 serious
severity 339149 serious
severity 339150 serious
severity 339151 serious
severity 339152 serious
severity 339153 serious
severity 339154 serious
severity 339155 serious
severity 339156 serious
severity 339157 serious
severity 339158 serious
severity 339159 serious
severity 339160 serious
severity 339161 serious
severity 339162 serious
severity 339163 serious
severity 339164 serious
severity 339165 serious
severity 339166 serious
severity 339167 serious
severity 339168 serious
severity 339169 serious
severity 339170 serious
severity 339171 serious
severity 339172 serious
severity 339173 serious
severity 339174 serious
severity 339175 serious
severity 339176 serious
severity 339177 serious
severity 339178 serious
severity 339179 serious
severity 339180 serious
severity 339181 serious
severity 339182 serious
severity 339183 serious
severity 339184 serious
severity 339185 serious
severity 339186 serious
severity 339187 serious
severity 339188 serious
severity 339189 serious
severity 339190 serious
severity 339191 serious
severity 339192 serious
severity 339193 serious
severity 339194 serious
severity 339195 serious
severity 339196 serious
severity 339197 serious
severity 339198 serious
severity 339199 serious
severity 339200 serious
severity 339201 serious
severity 339202 serious
severity 339203 serious
severity 339204 serious
severity 339205 serious
severity 339206 serious
severity 339207 serious
severity 339208 serious
severity 339209 serious
severity 339210 serious
severity 339211 serious
severity 339212 serious
severity 339213 serious
severity 339214 serious
severity 339215 serious
severity 339216 serious
severity 339217 serious
severity 339218 serious
severity 339219 serious
severity 339220 serious
severity 339221 serious
severity 339222 serious
severity 339223 serious
severity 339224 serious
severity 339225 serious
severity 339226 serious
severity 339227 serious
severity 339228 serious
severity 339229 serious
severity 339230 serious
severity 339231 serious
severity 339232 serious
severity 339233 serious
severity 339234 serious
severity 339235 serious
severity 339236 serious
severity 339237 serious
severity 339238 serious
severity 339239 serious
severity 339240 serious
severity 339241 serious
severity 339242 serious
severity 339243 serious
severity 339244 serious
severity 339245 serious
severity 339246 serious
severity 339247 serious
severity 339248 serious
severity 339249 serious
severity 339250 serious
severity 339251 serious
severity 339252 serious
severity 339253 serious
severity 339254 serious
severity 339255 serious
severity 339256 serious
severity 339257 serious
severity 339258 serious
severity 339259 serious
severity 339260 serious
severity 339261 serious
severity 339262 serious
severity 339263 serious
severity 339264 serious
se...
Matthias Klose (doko) wrote : | #7 |
fixed in pcre3_6.4-1ubuntu1
In Debian Bug tracker #339250, Matthias Klose (doko-cs) wrote : libstdc++ allocator change | #8 |
tags 339250 + patch
thanks
please find a patch at http://
as a side note: the package doesn't clean:
dpkg-source -b pcre3-6.4
dpkg-source: building pcre3 using existing pcre3_6.
dpkg-source: building pcre3 in pcre3_6.
dpkg-source: cannot represent change to testsavedregex: binary file
contents changed
dpkg-source: building pcre3 in pcre3_6.
dpkg-source: unrepresentable changes to source
Debian Bug Importer (debzilla) wrote : | #9 |
Message-ID: <email address hidden>
Date: Wed, 23 Nov 2005 21:46:39 +0100
From: Matthias Klose <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: libstdc++ allocator change
tags 339250 + patch
thanks
please find a patch at http://
as a side note: the package doesn't clean:
dpkg-source -b pcre3-6.4
dpkg-source: building pcre3 using existing pcre3_6.
dpkg-source: building pcre3 in pcre3_6.
dpkg-source: cannot represent change to testsavedregex: binary file
contents changed
dpkg-source: building pcre3 in pcre3_6.
dpkg-source: unrepresentable changes to source
In Debian Bug tracker #339250, Dato Simó (dato) wrote : bugs blocking the kdelibs4c2a upload | #10 |
# openexr
block 339190 by 339241
# pcre3
block 339190 by 339250
thanks
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
It is impossible to make anything foolproof because fools are so ingenious.
Debian Bug Importer (debzilla) wrote : | #11 |
Message-ID: <email address hidden>
Date: Thu, 24 Nov 2005 12:25:00 +0100
From: Adeodato =?utf-8?
To: <email address hidden>
Subject: bugs blocking the kdelibs4c2a upload
# openexr
block 339190 by 339241
# pcre3
block 339190 by 339250
thanks
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
It is impossible to make anything foolproof because fools are so ingenious.
In Debian Bug tracker #339250, Dato Simó (dato) wrote : Re: libstdc++ allocator change | #12 |
# doko, see explanation below
tag 339250 - patch
thanks
* Matthias Klose [Wed, 23 Nov 2005 21:46:39 +0100]:
> tags 339250 + patch
> thanks
> please find a patch at http://
Mark, please don't use that patch. The libpcre3 package ships both a C
library and a C++ library, and only the C++ one is affected by this
libstdc++ change. Given the high number of libpcre3 reverse
dependencies (116), it's very unadvisable to rename the whole package.
The right course of action would be to ship the C++ library in a
separate package, so that in can be independently renamed in further
transitions.
Mark, please let us know if you'll be able to fix this bug yourself in
the next days, so that other libraries depending on libpcre3 can
transition themselves. If not, I'll prepare a patch an upload unless
you indicate otherwise.
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
In Debian Bug tracker #339250, Matthias Klose (doko-cs) wrote : | #13 |
Adeodato =?utf-8?
> # doko, see explanation below
> tag 339250 - patch
> thanks
>
> * Matthias Klose [Wed, 23 Nov 2005 21:46:39 +0100]:
>
> > tags 339250 + patch
> > thanks
>
> > please find a patch at http://
>
> Mark, please don't use that patch. The libpcre3 package ships both a C
> library and a C++ library, and only the C++ one is affected by this
> libstdc++ change. Given the high number of libpcre3 reverse
> dependencies (116), it's very unadvisable to rename the whole package.
> The right course of action would be to ship the C++ library in a
> separate package, so that in can be independently renamed in further
> transitions.
right, that approach looks better, although currently you have to
rename both the package.
Matthias
In Debian Bug tracker #339250, Mark Baker (mark-mnb) wrote : | #14 |
Adeodato Simó wrote:
> > please find a patch at http://
>
> Mark, please don't use that patch. The libpcre3 package ships both a C
> library and a C++ library, and only the C++ one is affected by this
> libstdc++ change.
That's why I haven't done anything about this yet.
> Given the high number of libpcre3 reverse
> dependencies (116),
Very few of which use the C++ library, of course.
> it's very unadvisable to rename the whole package.
> The right course of action would be to ship the C++ library in a
> separate package, so that in can be independently renamed in further
> transitions.
>
So I should put the C++ library in a new package, and no longer include
it in the libpcre3 package. What should I do about dependencies to get a
smooth upgrade path? Obviously people installing new versions of things
that use the C++ library will get the new package; until they do isn't
there a danger that they will install the new libpcre3 and things will
stop working?
> Mark, please let us know if you'll be able to fix this bug yourself in
> the next days, so that other libraries depending on libpcre3 can
> transition themselves.
I should have some time at the weekend.
In Debian Bug tracker #339250, Dato Simó (dato) wrote : | #15 |
* Matthias Klose [Thu, 24 Nov 2005 22:29:15 +0100]:
> right, that approach looks better, although currently you have to
> rename both the package.
I discussed it with vorlon, and we were going with the "make libpcre3
conflict with everything that used libpcrecpp.so, which we expect will
be very little" option. Do you see some sort of problem with this
approach? (If I'm not mistaken, has been used for at least one package
in the previous ABI transition).
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
In Debian Bug tracker #339250, Dato Simó (dato) wrote : | #16 |
* Mark Baker [Thu, 24 Nov 2005 21:32:44 +0000]:
> So I should put the C++ library in a new package, and no longer include
> it in the libpcre3 package. What should I do about dependencies to get a
> smooth upgrade path? Obviously people installing new versions of things
> that use the C++ library will get the new package; until they do isn't
> there a danger that they will install the new libpcre3 and things will
> stop working?
Yes, see my other message: you make libpcre3 conflict with does
packages, as in Conflicts: package (<= current-
believe there'll be ver few.
So you have to examine all the reverse dependencies, and check which
of them actually link to libpcrecpp.so. Let me know if you'd like
assistance with this.
> > Mark, please let us know if you'll be able to fix this bug yourself in
> > the next days, so that other libraries depending on libpcre3 can
> > transition themselves.
> I should have some time at the weekend.
Nice, thanks.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
In Debian Bug tracker #339250, Matthias Klose (doko-cs) wrote : | #17 |
Adeodato =?utf-8?
> * Matthias Klose [Thu, 24 Nov 2005 22:29:15 +0100]:
>
> > right, that approach looks better, although currently you have to
> > rename both the package.
>
> I discussed it with vorlon, and we were going with the "make libpcre3
> conflict with everything that used libpcrecpp.so, which we expect will
> be very little" option. Do you see some sort of problem with this
> approach? (If I'm not mistaken, has been used for at least one package
> in the previous ABI transition).
well, I disagree, because that leaves out any 3rd party package, which
you don't know. and vorlon did agree on that? *cough*
let's take the ways we did go incompletely for libgmp3:
- split libpcre3 into libpcre3c2a and libpcre3++c2a
- libpcre3c2a depends on libpcre3++c2a
- libpcre3c2a's shlibs file reads:
libpcre 3 libpcre3c2a | libpcre3 (>= 4.5)
libpcreposix 3 libpcre3c2a | libpcre3 (>= 4.5)
This way, packages depending on the renamed package can move to
testing before pcre3 moves to testing.
the shlibs file can be reduced once the new pcre3 is in testing.
Matthias
Debian Bug Importer (debzilla) wrote : | #18 |
Message-ID: <email address hidden>
Date: Thu, 24 Nov 2005 22:22:18 +0100
From: Adeodato =?utf-8?
To: Mark Baker <email address hidden>, <email address hidden>
Cc: Matthias Klose <email address hidden>, <email address hidden>
Subject: Re: libstdc++ allocator change
# doko, see explanation below
tag 339250 - patch
thanks
* Matthias Klose [Wed, 23 Nov 2005 21:46:39 +0100]:
> tags 339250 + patch
> thanks
> please find a patch at http://
Mark, please don't use that patch. The libpcre3 package ships both a C
library and a C++ library, and only the C++ one is affected by this
libstdc++ change. Given the high number of libpcre3 reverse
dependencies (116), it's very unadvisable to rename the whole package.
The right course of action would be to ship the C++ library in a
separate package, so that in can be independently renamed in further
transitions.
Mark, please let us know if you'll be able to fix this bug yourself in
the next days, so that other libraries depending on libpcre3 can
transition themselves. If not, I'll prepare a patch an upload unless
you indicate otherwise.
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Debian Bug Importer (debzilla) wrote : | #19 |
Message-ID: <email address hidden>
Date: Thu, 24 Nov 2005 22:29:15 +0100
From: Matthias Klose <email address hidden>
To: <email address hidden>,
Adeodato =?utf-8?
Subject: Re: libstdc++ allocator change
Adeodato =?utf-8?
> # doko, see explanation below
> tag 339250 - patch
> thanks
>
> * Matthias Klose [Wed, 23 Nov 2005 21:46:39 +0100]:
>
> > tags 339250 + patch
> > thanks
>
> > please find a patch at http://
>
> Mark, please don't use that patch. The libpcre3 package ships both a C
> library and a C++ library, and only the C++ one is affected by this
> libstdc++ change. Given the high number of libpcre3 reverse
> dependencies (116), it's very unadvisable to rename the whole package.
> The right course of action would be to ship the C++ library in a
> separate package, so that in can be independently renamed in further
> transitions.
right, that approach looks better, although currently you have to
rename both the package.
Matthias
Debian Bug Importer (debzilla) wrote : | #20 |
Message-ID: <email address hidden>
Date: Thu, 24 Nov 2005 21:32:44 +0000
From: Mark Baker <email address hidden>
To: <email address hidden>, =?UTF-8?
<email address hidden>
Subject: Re: libstdc++ allocator change
Adeodato Simó wrote:
> > please find a patch at http://
>
> Mark, please don't use that patch. The libpcre3 package ships both a C
> library and a C++ library, and only the C++ one is affected by this
> libstdc++ change.
That's why I haven't done anything about this yet.
> Given the high number of libpcre3 reverse
> dependencies (116),
Very few of which use the C++ library, of course.
> it's very unadvisable to rename the whole package.
> The right course of action would be to ship the C++ library in a
> separate package, so that in can be independently renamed in further
> transitions.
>
So I should put the C++ library in a new package, and no longer include
it in the libpcre3 package. What should I do about dependencies to get a
smooth upgrade path? Obviously people installing new versions of things
that use the C++ library will get the new package; until they do isn't
there a danger that they will install the new libpcre3 and things will
stop working?
> Mark, please let us know if you'll be able to fix this bug yourself in
> the next days, so that other libraries depending on libpcre3 can
> transition themselves.
I should have some time at the weekend.
Debian Bug Importer (debzilla) wrote : | #21 |
Message-ID: <email address hidden>
Date: Thu, 24 Nov 2005 22:33:01 +0100
From: Adeodato =?utf-8?
To: Matthias Klose <email address hidden>
Cc: <email address hidden>
Subject: Re: libstdc++ allocator change
* Matthias Klose [Thu, 24 Nov 2005 22:29:15 +0100]:
> right, that approach looks better, although currently you have to
> rename both the package.
I discussed it with vorlon, and we were going with the "make libpcre3
conflict with everything that used libpcrecpp.so, which we expect will
be very little" option. Do you see some sort of problem with this
approach? (If I'm not mistaken, has been used for at least one package
in the previous ABI transition).
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Debian Bug Importer (debzilla) wrote : | #22 |
Message-ID: <email address hidden>
Date: Thu, 24 Nov 2005 22:35:31 +0100
From: Adeodato =?utf-8?
To: Mark Baker <email address hidden>
Cc: <email address hidden>
Subject: Re: libstdc++ allocator change
* Mark Baker [Thu, 24 Nov 2005 21:32:44 +0000]:
> So I should put the C++ library in a new package, and no longer include
> it in the libpcre3 package. What should I do about dependencies to get a
> smooth upgrade path? Obviously people installing new versions of things
> that use the C++ library will get the new package; until they do isn't
> there a danger that they will install the new libpcre3 and things will
> stop working?
Yes, see my other message: you make libpcre3 conflict with does
packages, as in Conflicts: package (<= current-
believe there'll be ver few.
So you have to examine all the reverse dependencies, and check which
of them actually link to libpcrecpp.so. Let me know if you'd like
assistance with this.
> > Mark, please let us know if you'll be able to fix this bug yourself in
> > the next days, so that other libraries depending on libpcre3 can
> > transition themselves.
> I should have some time at the weekend.
Nice, thanks.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Debian Bug Importer (debzilla) wrote : | #23 |
Message-ID: <email address hidden>
Date: Thu, 24 Nov 2005 22:49:57 +0100
From: Matthias Klose <email address hidden>
To: "<email address hidden> Adeodato =?utf-8?
Cc: <email address hidden>
Subject: Re: libstdc++ allocator change
Adeodato =?utf-8?
> * Matthias Klose [Thu, 24 Nov 2005 22:29:15 +0100]:
>
> > right, that approach looks better, although currently you have to
> > rename both the package.
>
> I discussed it with vorlon, and we were going with the "make libpcre3
> conflict with everything that used libpcrecpp.so, which we expect will
> be very little" option. Do you see some sort of problem with this
> approach? (If I'm not mistaken, has been used for at least one package
> in the previous ABI transition).
well, I disagree, because that leaves out any 3rd party package, which
you don't know. and vorlon did agree on that? *cough*
let's take the ways we did go incompletely for libgmp3:
- split libpcre3 into libpcre3c2a and libpcre3++c2a
- libpcre3c2a depends on libpcre3++c2a
- libpcre3c2a's shlibs file reads:
libpcre 3 libpcre3c2a | libpcre3 (>= 4.5)
libpcreposix 3 libpcre3c2a | libpcre3 (>= 4.5)
This way, packages depending on the renamed package can move to
testing before pcre3 moves to testing.
the shlibs file can be reduced once the new pcre3 is in testing.
Matthias
In Debian Bug tracker #339250, Matthias Klose (doko-cs) wrote : NMU for pcre3, avoiding renaming of the libpcre3 library package | #24 |
Please find attached the diff for the NMU 6.4-1.1
* Split out the C++ library into it's own package libpcrecpp0, as
discussed in #339250. The C++ library was recently added, no
package references the C++ library yet.
Closes: #339250.
* debian/rules: Remove testsavedregex in clean target.
diff -u pcre3-6.
--- pcre3-6.
+++ pcre3-6.
@@ -17,10 +17,23 @@
.
This package contains the runtime libraries.
+Package: libpcrecpp0
+Section: libs
+Architecture: any
+Priority: optional
+Depends: ${shlibs:Depends}
+Conflicts: libpcre3 (<< 6.4-1.1)
+Replaces: libpcre3 (<< 6.4-1.1)
+Description: Perl 5 Compatible Regular Expression Library - C++ runtime files
+ This is a C++ library of functions to support regular expressions whose syntax
+ and semantics are as close as possible to those of the Perl 5 language.
+ .
+ This package contains the C++ runtime library.
+
Package: libpcre3-dev
Section: libdevel
Architecture: any
-Depends: libc6-dev, libpcre3 (=${Source-
+Depends: libc6-dev, libpcre3 (= ${Source-Version}), libpcrecpp0 (= ${Source-Version})
Conflicts: libpcre1-dev, libpcre2-dev
Description: Perl 5 Compatible Regular Expression Library - development files
This is a library of functions to support regular expressions whose syntax
diff -u pcre3-6.
--- pcre3-6.
+++ pcre3-6.
@@ -62,7 +62,7 @@
### cp -f /usr/share/
- rm -f dftables RunTest
+ rm -f dftables RunTest testsavedregex
dh_clean
install: build
@@ -116,7 +116,8 @@
dh_strip -a
dh_compress -a
dh_fixperms -a
- dh_makeshlibs -a -V 'libpcre3 (>= 4.5)'
+ dh_makeshlibs -plibpcre3 -V 'libpcre3 (>= 4.5)'
+ dh_makeshlibs -plibpcrecpp0 -V 'libpcrecpp0'
dh_installdeb -a
# dh_perl -a
dh_shlibdeps -a -ldebian/
diff -u pcre3-6.
--- pcre3-6.
+++ pcre3-6.
@@ -1,3 +1,13 @@
+pcre3 (6.4-1.1) unstable; urgency=low
+
+ * Split out the C++ library into it's own package libpcrecpp0, as
+ discussed in #339250. The C++ library was recently added, no
+ package references the C++ library yet.
+ Closes: #339250.
+ * debian/rules: Remove testsavedregex in clean target.
+
+ -- Matthias Klose <email address hidden> Fri, 25 Nov 2005 07:59:14 +0100
+
pcre3 (6.4-1) unstable; urgency=low
* New upstream release (Closes: 333191)
diff -u pcre3-6.
--- pcre3-6.
+++ pcre3-6.
@@ -1,4 +1,5 @@
-usr/lib/lib*.so.*
+usr/lib/
+usr/lib/
usr/bin/pcretest
usr/share/
usr/share/
diff -u pcre3-6.
--- pcre3-6.
+++ pcre3-6.
@@ -50,0 +51,4 @@
+
+
+On Debian GNU/Linux systems, the complete text of the GNU General
+Public License can be found in `/usr/share/
only in patch2:
unchanged:
--- pcre3-6.
+++ pcre3-6.
Debian Bug Importer (debzilla) wrote : | #25 |
Message-ID: <email address hidden>
Date: Fri, 25 Nov 2005 10:23:26 +0100
From: Matthias Klose <email address hidden>
To: <email address hidden>
Subject: NMU for pcre3, avoiding renaming of the libpcre3 library package
Please find attached the diff for the NMU 6.4-1.1
* Split out the C++ library into it's own package libpcrecpp0, as
discussed in #339250. The C++ library was recently added, no
package references the C++ library yet.
Closes: #339250.
* debian/rules: Remove testsavedregex in clean target.
diff -u pcre3-6.
--- pcre3-6.
+++ pcre3-6.
@@ -17,10 +17,23 @@
.
This package contains the runtime libraries.
+Package: libpcrecpp0
+Section: libs
+Architecture: any
+Priority: optional
+Depends: ${shlibs:Depends}
+Conflicts: libpcre3 (<< 6.4-1.1)
+Replaces: libpcre3 (<< 6.4-1.1)
+Description: Perl 5 Compatible Regular Expression Library - C++ runtime files
+ This is a C++ library of functions to support regular expressions whose syntax
+ and semantics are as close as possible to those of the Perl 5 language.
+ .
+ This package contains the C++ runtime library.
+
Package: libpcre3-dev
Section: libdevel
Architecture: any
-Depends: libc6-dev, libpcre3 (=${Source-
+Depends: libc6-dev, libpcre3 (= ${Source-Version}), libpcrecpp0 (= ${Source-Version})
Conflicts: libpcre1-dev, libpcre2-dev
Description: Perl 5 Compatible Regular Expression Library - development files
This is a library of functions to support regular expressions whose syntax
diff -u pcre3-6.
--- pcre3-6.
+++ pcre3-6.
@@ -62,7 +62,7 @@
### cp -f /usr/share/
- rm -f dftables RunTest
+ rm -f dftables RunTest testsavedregex
dh_clean
install: build
@@ -116,7 +116,8 @@
dh_strip -a
dh_compress -a
dh_fixperms -a
- dh_makeshlibs -a -V 'libpcre3 (>= 4.5)'
+ dh_makeshlibs -plibpcre3 -V 'libpcre3 (>= 4.5)'
+ dh_makeshlibs -plibpcrecpp0 -V 'libpcrecpp0'
dh_installdeb -a
# dh_perl -a
dh_shlibdeps -a -ldebian/
diff -u pcre3-6.
--- pcre3-6.
+++ pcre3-6.
@@ -1,3 +1,13 @@
+pcre3 (6.4-1.1) unstable; urgency=low
+
+ * Split out the C++ library into it's own package libpcrecpp0, as
+ discussed in #339250. The C++ library was recently added, no
+ package references the C++ library yet.
+ Closes: #339250.
+ * debian/rules: Remove testsavedregex in clean target.
+
+ -- Matthias Klose <email address hidden> Fri, 25 Nov 2005 07:59:14 +0100
+
pcre3 (6.4-1) unstable; urgency=low
* New upstream release (Closes: 333191)
diff -u pcre3-6.
--- pcre3-6.
+++ pcre3-6.
@@ -1,4 +1,5 @@
-usr/lib/lib*.so.*
+usr/lib/
+usr/lib/
usr/bin/pcretest
usr/share/
usr/share/
diff -u pcre3-6.
--- pcre3-6.
+++ pcre3-6.
@@ -50,0...
In Debian Bug tracker #339250, Matthias Klose (doko) wrote : Fixed in NMU of pcre3 6.4-1.1 | #26 |
tag 339250 + fixed
quit
This message was generated automatically in response to a
non-maintainer upload. The .changes file follows.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.7
Date: Fri, 25 Nov 2005 07:59:14 +0100
Source: pcre3
Binary: pcregrep libpcre3 pgrep libpcrecpp0 libpcre3-dev
Architecture: source i386 all
Version: 6.4-1.1
Distribution: unstable
Urgency: low
Maintainer: Mark Baker <email address hidden>
Changed-By: Matthias Klose <email address hidden>
Description:
libpcre3 - Perl 5 Compatible Regular Expression Library - runtime files
libpcre3-dev - Perl 5 Compatible Regular Expression Library - development files
libpcrecpp0 - Perl 5 Compatible Regular Expression Library - C++ runtime files
pcregrep - grep utility that uses perl 5 compatible regexes.
pgrep - Dummy package for transition to pcregrep
Closes: 339250
Changes:
pcre3 (6.4-1.1) unstable; urgency=low
.
* Split out the C++ library into it's own package libpcrecpp0, as
discussed in #339250. The C++ library was recently added, no
package references the C++ library yet.
Closes: #339250.
* debian/rules: Remove testsavedregex in clean target.
Files:
4e7c1065714222
cd2c7ca7075d36
312d7f450c01cc
8dd946b0343edd
6834202757634a
a5209bcd37c274
65416cfbaf678a
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDhteaStl
yMbWjpFOy6Myba6
=Howx
-----END PGP SIGNATURE-----
Debian Bug Importer (debzilla) wrote : | #27 |
Message-Id: <email address hidden>
Date: Sun, 27 Nov 2005 11:13:30 -0800
From: Matthias Klose <email address hidden>
To: <email address hidden>
Cc: Matthias Klose <email address hidden>, Mark Baker <email address hidden>
Subject: Fixed in NMU of pcre3 6.4-1.1
tag 339250 + fixed
quit
This message was generated automatically in response to a
non-maintainer upload. The .changes file follows.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.7
Date: Fri, 25 Nov 2005 07:59:14 +0100
Source: pcre3
Binary: pcregrep libpcre3 pgrep libpcrecpp0 libpcre3-dev
Architecture: source i386 all
Version: 6.4-1.1
Distribution: unstable
Urgency: low
Maintainer: Mark Baker <email address hidden>
Changed-By: Matthias Klose <email address hidden>
Description:
libpcre3 - Perl 5 Compatible Regular Expression Library - runtime files
libpcre3-dev - Perl 5 Compatible Regular Expression Library - development files
libpcrecpp0 - Perl 5 Compatible Regular Expression Library - C++ runtime files
pcregrep - grep utility that uses perl 5 compatible regexes.
pgrep - Dummy package for transition to pcregrep
Closes: 339250
Changes:
pcre3 (6.4-1.1) unstable; urgency=low
.
* Split out the C++ library into it's own package libpcrecpp0, as
discussed in #339250. The C++ library was recently added, no
package references the C++ library yet.
Closes: #339250.
* debian/rules: Remove testsavedregex in clean target.
Files:
4e7c1065714222
cd2c7ca7075d36
312d7f450c01cc
8dd946b0343edd
6834202757634a
a5209bcd37c274
65416cfbaf678a
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDhteaStl
yMbWjpFOy6Myba6
=Howx
-----END PGP SIGNATURE-----
In Debian Bug tracker #339250, Adam D. Barratt (debian-bts-adam-barratt) wrote : Bugs fixed in NMU, documenting versions | #28 |
# Hi,
#
# These bugs were fixed in an NMU, but have not been acknowledged by the
# maintainers. With version tracking in the Debian BTS, it is important
# to know which version of a package fixes each bug so that they can be
# tracked for release status, so I'm closing these bugs with the
#relevant version information now
close 331601 0.11.3-1.3
close 331607 0.11.3-1.3
close 332216 2005.08.R1-1.1
close 332237 0.11.3-1.4
close 332389 3.1.2-0.1
close 332424 2.6.1-6sarge1
close 325490 0.7.1-1.1
close 332451 0.7.1-1.1
close 332507 0.4.5+cvs200308
close 332702 1.5-2.1
close 332703 2.1.19-1.7
close 332808 2.0.12-1.5
close 332896 2.6.2.pre2-1.1
close 333035 0.12-8.1
close 342420 0.12-8.1
close 333046 2.2-5.1
close 333460 1.0-23.2
close 333857 1.0-23.2
close 333885 1.0.20040603-1.1
close 340743 1.0.20040603-1.1
close 334252 20031130-2.1
close 334320 1.4.2-5.1
close 334651 3.0-4.1
close 335126 0.5.3-1.1
close 335144 3.1.1-4.1
close 335146 0.2-1.1
close 335252 0.4.0-1.1
close 335274 0.13-3.2
close 335567 0.4.5+cvs200308
close 335719 3.0.cvs20050714-1.1
close 335842 3.10-1.1
close 336168 1.4-2.1
close 336312 0.2.4-4.1
close 336485 2.1.19.dfsg1-0.3
close 379846 2.1.19.dfsg1-0.3
close 336535 2005.08.R1-1.2
close 336710 1:3.2.6-2.1
close 337246 1.0.1-6.1
close 337453 0.9b3-2.1
close 337495 2.09-2sarge1
close 337576 20.0-1.1
close 337593 1.1.3-5.1
close 339192 1.1.3-5.1
close 346695 1.1.3-5.1
close 347154 1.1.3-5.1
close 337708 1.20-2.1
close 337711 0.5-0.2
close 338327 1.9-11.1
close 340076 1.9-11.1
close 345223 1.9-11.1
close 338370 1.35-4.1
close 338432 2.3.3-6.2
close 338483 0.95-1.3
close 338537 1.6-1.1
close 338920 46-2.1
close 339024 4.2.24-1.1
close 341234 4.2.24-1.1
close 339073 1.5.19-20+sarge1
close 339103 0.5.0-1.1
close 339187 6:6.2.4.5-0.3
close 339220 0.6.5-2
close 339225 1.0.4-1.2
close 339226 2.6.1-2.2
close 339236 2.6.2.pre2-1.2
close 339241 1.2.2-4.1
close 339250 6.4-1.1
close 339267 4.2.0-8.1
close 339268 0.7.2-1.1
close 339280 0.1.5.9+
close 339711 2.0pl5-19.4
close 339806 0.8pre1-6.1
close 339835 2.11b-1.4
close 340010 1.3-2.2
close 340084 1:1.2.3-9.1
close 340163 0.2.9-5.1
close 340174 0.99.44-0.1
close 340516 1.1.6-2.1
close 340577 1.1.0.20050815-2.1
close 341011 1.8-1.1
close 341975 0.70.1-1.1
close 342035 0.70.1-1.1
close 342322 9.4.2-2.5
close 346188 9.4.2-2.5
close 347153 9.4.2-2.5
close 343035 0.3b.19990815-3.1
close 343771 4.3.9-2.1
close 343782 1.3.13.1-4.1
close 343795 0.5.8-0.1
close 343804 0.3.7-4.1
close 343912 0.0.4-2.1
close 343989 8.4.11-1.1
close 344029 2.1-5.1
close 344254 2.0.9-3.2
close 344447 0.79-3.1
close 344503 9.4.2-2.7
close 345737 2.1.19-1.8
close 345880 2.1.19-1.8
close 344742 0.1.14-1.1
Changed in pcre3: | |
status: | Fix Committed → Fix Released |
Compiler versions g++-4.0_4.0.2-4 and g++-3.4_3.4.4-10 are now in the
archive. The renaming of the library packages can now start. You can
upload the packages even before the toolchain is built for all architectures
because the packages with the new binary packages will be hold in the NEW
queue until the required toolchain changes are installed on the buildd's.