Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Fedora Development (http://www.linux-archive.org/fedora-development/)
-   -   major boost breakage (http://www.linux-archive.org/fedora-development/141634-major-boost-breakage.html)

Alex Lancaster 08-12-2008 10:50 AM

major boost breakage
 
>>>>> "PM" == Petr Machata writes:

PM> On Tue, Aug 12, 2008 at 03:32:39AM -0700, Alex Lancaster wrote:

>> > boost-1.36.0-0.1.beta1.fc10 --------------------------- * Mon Aug

[...]

>> Created a ton of broken deps (below). Are we supposed to rebuild
>> everything or is this a packaging error?

PM> Yes, I've bumped a soname. In general, with boost updates there
PM> is no guarantee of backwards compatibility.

If the list of broken packages is anything to go by this could be a
major deal and we might need to consider a rollback or a compat-boost3
package or somesuch e.g. a fairly major package Miro won't rebuild
(see below) and I'm sure it won't be the only one.

>> If a rebuild is required, I wish people could get into the habit of
>> pre-announcing these kind of soname bumps, especially one's that
>> impact a huge number of packages. Maintainers need to be aware of
>> the impact that their package might have on other dependent
>> packages...

PM> My mistake, I should have done that. I'll remember to do it next
PM> time.

It doesn't seem seem like a good idea to update a package that can
cause some major ABI/API breakage only 2 weeks before the Beta freeze,
without evaluating the fallout from potential broken deps. This
really should have been not only announced, but discussed before doing
the soname bump.

Miro failure:

http://koji.fedoraproject.org/koji/getfile?taskID=773495&name=build.log

/builddir/build/BUILD/Miro-1.2.4/portable/libtorrent/include/libtorrent/asio/detail/pipe_select_interrupter.hpp:
In member function 'void
asio::detail::pipe_select_interrupter::interrupt() ':
/builddir/build/BUILD/Miro-1.2.4/portable/libtorrent/include/libtorrent/asio/detail/pipe_select_interrupter.hpp:64:
warning: ignoring return value of 'ssize_t write(int, const void*,
size_t)', declared with attribute warn_unused_result
/builddir/build/BUILD/Miro-1.2.4/portable/libtorrent/src/torrent_info.cpp:
In member function 'void
libtorrent::torrent_info::parse_info_section(const
libtorrent::entry&)':
/builddir/build/BUILD/Miro-1.2.4/portable/libtorrent/src/torrent_info.cpp:355:
error: 'struct boost::filesystem::path' has no member named
'has_branch_path'
/builddir/build/BUILD/Miro-1.2.4/portable/libtorrent/src/torrent_info.cpp:
In member function 'void
libtorrent::torrent_info::add_file(boost::filesyst em::path,
libtorrent::size_type)':
/builddir/build/BUILD/Miro-1.2.4/portable/libtorrent/src/torrent_info.cpp:559:
error: 'struct boost::filesystem::path' has no member named
'has_branch_path'
error: command 'gcc' failed with exit status 1
error: Bad exit status from /var/tmp/rpm-tmp.h6aLpo (%build)

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Jesse Keating 08-12-2008 12:01 PM

major boost breakage
 
On Tue, 2008-08-12 at 03:50 -0700, Alex Lancaster wrote:
> It doesn't seem seem like a good idea to update a package that can
> cause some major ABI/API breakage only 2 weeks before the Beta freeze,

One week. This is exactly the sort of change I asked people to avoid
making just yesterday.

--
Jesse Keating
Fedora -- Freedomē is a feature!
identi.ca: http://identi.ca/jkeating
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Petr Machata 08-12-2008 12:03 PM

major boost breakage
 
On Tue, Aug 12, 2008 at 03:50:27AM -0700, Alex Lancaster wrote:
> It doesn't seem seem like a good idea to update a package that can
> cause some major ABI/API breakage only 2 weeks before the Beta freeze,
> without evaluating the fallout from potential broken deps. This
> really should have been not only announced, but discussed before doing
> the soname bump.

Ok, I can see I've screwed on several levels here (underestimating how
many packages depend on boost, not realizing how far into release
cycle Fedora is). So I can have boost un-tagged by releng right away,
and break the next rawhide to come.

Still, while I see some big packages (abiword, inkscape), I suspect
that most incompatibilities can be fixed simply (i.e. mostly sed-style
fixes), and I can help people with fixing their build failures
(attaching Miro patch right away).

PM
diff -urp Miro-1.2.4/portable/libtorrent/include/libtorrent/disk_io_thread.hpp Miro-1.2.4-pm/portable/libtorrent/include/libtorrent/disk_io_thread.hpp
--- Miro-1.2.4/portable/libtorrent/include/libtorrent/disk_io_thread.hpp 2008-05-28 16:05:15.000000000 +0200
+++ Miro-1.2.4-pm/portable/libtorrent/include/libtorrent/disk_io_thread.hpp 2008-08-12 13:24:32.000000000 +0200
@@ -41,6 +41,7 @@ POSSIBILITY OF SUCH DAMAGE.
#include <boost/bind.hpp>
#include <boost/pool/pool.hpp>
#include <boost/noncopyable.hpp>
+#include <boost/thread/condition.hpp>
#include "libtorrent/config.hpp"

namespace libtorrent
diff -urp Miro-1.2.4/portable/libtorrent/src/torrent_info.cpp Miro-1.2.4-pm/portable/libtorrent/src/torrent_info.cpp
--- Miro-1.2.4/portable/libtorrent/src/torrent_info.cpp 2008-05-28 16:05:16.000000000 +0200
+++ Miro-1.2.4-pm/portable/libtorrent/src/torrent_info.cpp 2008-08-12 13:29:02.000000000 +0200
@@ -352,7 +352,7 @@ namespace libtorrent
fs::path tmp = m_name;
if (tmp.is_complete()) throw std::runtime_error("torrent contains "
"a file with an absolute path: '" + m_name + "'");
- if (tmp.has_branch_path()) throw std::runtime_error(
+ if (!tmp.branch_path().empty()) throw std::runtime_error(
"torrent contains name with directories: '" + m_name + "'");

// extract file list
@@ -556,7 +556,7 @@ namespace libtorrent
{
// TORRENT_ASSERT(file.begin() != file.end());

- if (!file.has_branch_path())
+ if (file.branch_path().empty())
{
// you have already added at least one file with a
// path to the file (branch_path), which means that
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Petr Machata 08-12-2008 12:13 PM

major boost breakage
 
On Tue, Aug 12, 2008 at 08:01:18AM -0400, Jesse Keating wrote:
> On Tue, 2008-08-12 at 03:50 -0700, Alex Lancaster wrote:
> > It doesn't seem seem like a good idea to update a package that can
> > cause some major ABI/API breakage only 2 weeks before the Beta freeze,
>
> One week. This is exactly the sort of change I asked people to avoid
> making just yesterday.

Hmm, so one week is not enough. I have untagged the package.

PM
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Jesse Keating 08-12-2008 12:17 PM

major boost breakage
 
On Tue, 2008-08-12 at 14:03 +0200, Petr Machata wrote:
>
> Ok, I can see I've screwed on several levels here (underestimating how
> many packages depend on boost, not realizing how far into release
> cycle Fedora is). So I can have boost un-tagged by releng right away,
> and break the next rawhide to come.

Unfortunately FESCo passed a policy that doesn't allow one to untag
builds that have gone out to rawhide. You can ask FESCo for an email
vote to override this rule for this case, otherwise you'd have to do a
build of the older boost with an epoch so that upgrade path continues.

> Still, while I see some big packages (abiword, inkscape), I suspect
> that most incompatibilities can be fixed simply (i.e. mostly sed-style
> fixes), and I can help people with fixing their build failures
> (attaching Miro patch right away).

When bumping something like boost, it is wise to do a local build, then
use it in a mock chroot to try rebuilding all the things that require
it. Anything that fails you should file bugs and attach patches to fix
the issue. Then a coordinated effort can happen to get boost and all
it's dependents rebuilt in one fell swoop. This is where open package
ACLs would help.

--
Jesse Keating
Fedora -- Freedomē is a feature!
identi.ca: http://identi.ca/jkeating
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

"David Nielsen" 08-12-2008 01:38 PM

major boost breakage
 
Den 12. aug. 2008 14.17 skrev Jesse Keating <jkeating@redhat.com>:




When bumping something like boost, it is wise to do a local build, then

use it in a mock chroot to try rebuilding all the things that require

it. *Anything that fails you should file bugs and attach patches to fix

the issue. *Then a coordinated effort can happen to get boost and all

it's dependents rebuilt in one fell swoop. *This is where open package

ACLs would help.


*Do we have documentation on the wiki on how to do this?

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

"Jon Ciesla" 08-12-2008 02:26 PM

major boost breakage
 
> On Tue, Aug 12, 2008 at 03:50:27AM -0700, Alex Lancaster wrote:
>> It doesn't seem seem like a good idea to update a package that can
>> cause some major ABI/API breakage only 2 weeks before the Beta freeze,
>> without evaluating the fallout from potential broken deps. This
>> really should have been not only announced, but discussed before doing
>> the soname bump.
>
> Ok, I can see I've screwed on several levels here (underestimating how
> many packages depend on boost, not realizing how far into release
> cycle Fedora is). So I can have boost un-tagged by releng right away,
> and break the next rawhide to come.

So no need for purely boost-related rebuilds at this time?

> Still, while I see some big packages (abiword, inkscape), I suspect
> that most incompatibilities can be fixed simply (i.e. mostly sed-style
> fixes), and I can help people with fixing their build failures
> (attaching Miro patch right away).
>
> PM
> --
> fedora-devel-list mailing list
> fedora-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list


--
novus ordo absurdum

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Jesse Keating 08-12-2008 02:30 PM

major boost breakage
 
On Tue, 2008-08-12 at 15:38 +0200, David Nielsen wrote:
> Do we have documentation on the wiki on how to do this?

A) Define "this"

B) probably not as there are many variables each time it's done, for
each package. This is currently one of those "tribal knowledge" things
for people who maintain a package that is consumed by numerous other
packages.

--
Jesse Keating
Fedora -- Freedomē is a feature!
identi.ca: http://identi.ca/jkeating
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

"David Nielsen" 08-12-2008 03:03 PM

major boost breakage
 
Den 12. aug. 2008 16.30 skrev Jesse Keating <jkeating@redhat.com>:

On Tue, 2008-08-12 at 15:38 +0200, David Nielsen wrote:

> *Do we have documentation on the wiki on how to do this?



A) Define "this"



B) probably not as there are many variables each time it's done, for

each package. *This is currently one of those "tribal knowledge" things

for people who maintain a package that is consumed by numerous other

packages.


*
sometimes it comes in handy to be able to queue up a mock build where you insert packages to test rebuilding in a clean environment. Say in this case, first we build a clean libboost, then we insert it into subsequent mock builds to test what breaks. I was wondering if mock which is generally magical could do that and if so if it was documented.


- David

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Petr Machata 08-12-2008 03:06 PM

major boost breakage
 
On Tue, Aug 12, 2008 at 09:26:30AM -0500, Jon Ciesla wrote:
> So no need for purely boost-related rebuilds at this time?

Nope. I'll do proper rawhide breaking after F10.

PM
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list


All times are GMT. The time now is 01:10 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.