Orphaning schroot package
I'm orphaning the schroot package, since I no longer use it or work with it: https://src.fedoraproject.org/rpms/schroot There is currently a serious (crash) bug affecting the package in F28: https://bugzilla.redhat.com/show_bug.cgi?id=1573253 Upstream: https://packages.debian.org/search?keywords=schroot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F-18 Branched report: 20120829 changes
Ok, thanks Kevin, Good to know, I just wanted to make sure I wasn't dropping the ball on anything -Zach On 08/29/2012 03:06 PM, Kevin Fenzi wrote: On Wed, 29 Aug 2012 15:01:52 -0700 Zach Carter wrote: Hi, I have rebuilt this package and requested it to be pushed to stable. Is there anything else I need to do to get it through and stop the nag emails? Am I missing some update procedure? We are currently in Alpha Change freeze. http://fedoraproject.org/wiki/Change_deadlines So, only packages which fix a accepted blocker (or depending, NTH) of Alpha will be pushed to stable. Sorry for the extra delay, since Alpha has already slipped one week... kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-18 Branched report: 20120829 changes
Hi, I have rebuilt this package and requested it to be pushed to stable. Is there anything else I need to do to get it through and stop the nag emails? Am I missing some update procedure? thanks, -Zach On 08/29/2012 04:36 AM, Fedora Branched Report wrote: [schroot] dchroot-1.4.25-9.fc18.x86_64 requires libboost_system.so.1.48.0()(64bit) dchroot-1.4.25-9.fc18.x86_64 requires libboost_regex.so.1.48.0()(64bit) dchroot-1.4.25-9.fc18.x86_64 requires libboost_program_options.so.1.48.0()(64bit) dchroot-1.4.25-9.fc18.x86_64 requires libboost_filesystem.so.1.48.0()(64bit) schroot-1.4.25-9.fc18.x86_64 requires libboost_system.so.1.48.0()(64bit) schroot-1.4.25-9.fc18.x86_64 requires libboost_regex.so.1.48.0()(64bit) schroot-1.4.25-9.fc18.x86_64 requires libboost_program_options.so.1.48.0()(64bit) schroot-1.4.25-9.fc18.x86_64 requires libboost_filesystem.so.1.48.0()(64bit) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost 1.46.0
On Tuesday, February 08, 2011 04:43:37 am Petr Machata wrote: > Actually I found the above in 1.37 (not 47) changelog. The ticket #1972 > has been closed for years. See: > http://www.boost.org/doc/libs/1_45_0/libs/filesystem/v2/doc/index.htm > Oops, my bad for substituting s/4/3/ somehow in my head, thanks for correcting me. > > From http://koji.fedoraproject.org/koji/getfile?taskID=2765676&name=build.log: > > sbuild-chroot-config.cc: In member function 'void > > sbuild::chroot_config::add_config_directory(const string&, const > > string&)': sbuild-chroot-config.cc:170:32: error: 'class > > boost::filesystem3::directory_entry' has no member named 'leaf' > > If there's a lot of problems like this, compile with > -DBOOST_FILESYSTEM_VERSION=2 and have upstream decide what to do > long-term. In this particular case, you should be able to replace > leaf() with path().filename().string(). This worked perfectly, thanks! -Zach -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost 1.46.0
On Friday, February 04, 2011 05:33:24 am Petr Machata wrote: > Hi, > > beta of boost-1.46.0 was released recently and packaged yesterday. It's > now in the git, and a scratch build[2] was done. This is in preparation > for final release that should be out on 7th, just before the feature > freeze. Providing boost-1.46.0 is one of features of F15[1]. > > I'm in the process of test-driving a couple packages locally to make > sure that the new boost works. If that turns out well, I'll do a > non-scratch build of boost-1.46.0-0.beta1 later today. > > PM > > References: > [1] http://fedoraproject.org/wiki/Features/F15Boost146 > [2] http://koji.fedoraproject.org/koji/taskinfo?taskID=2760766 I believe my package schroot may have been hit by a 1.46 issue that is fixed in 1.47 Is there a plan to update to 1.47 or backport the fixes? >From the 1.47 changelog: Doc fixes: Update release history, add tables of macros and deprecated names. Bug fix: convenience.hpp didn't fully apply BOOST_FILESYSTEM_NO_DEPRECATED to name changes. Bug fix: Ticket #1972 'remove' fixes. Bug fix: Restore deprecated basic_directory_entry names inadvertently removed. Bug fix: Provide deprecated functions has_branch_path and has_leaf, inadvertently omitted from 1.36.0 Add workarounds for Codegear/Borland C++ Builder 2009. >From http://koji.fedoraproject.org/koji/getfile?taskID=2765676&name=build.log: sbuild-chroot-config.cc: In member function 'void sbuild::chroot_config::add_config_directory(const string&, const string&)': sbuild-chroot-config.cc:170:32: error: 'class boost::filesystem3::directory_entry' has no member named 'leaf' -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: trouble locally reproducing koji build error
On Monday 19 July 2010 01:15:43 Andreas Schwab wrote: > John5342 writes: > > Well the problem is obvious. > > Very obvious, indeed. > > > The line in the test program should be: > > > > boost::program_options::variables_map dummy() > > > > and not: > > > > boost::program_options::variables_map::variables_map dummy() > > > > I however know very little about autotools (and don't intend on ever > > learning either) so how to actually fix it is another matter. > > A trivial grep. > > define([testprog], [AC_LANG_PROGRAM([#include ], > > [boost::program_options::variables_map::variables_map dummy()])]) > > Andreas. Thanks guys for the help. I'll get a patch in this morning. Howeverthe question remains, why did it build just fine with the function header as-is on a rawhide machine and in my local mockbuild, but not when the build was run on the koji server? Some difference in the autotools, g++ compiler, boost? Any theories? It doesn't seem good at all to have unknown differences in behavior between the developer build environment and and official build environment. -Zach -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: trouble locally reproducing koji build error
On Friday 16 July 2010 00:36:31 Andreas Schwab wrote:
> > Any insight, tips or pointers would be much appreciated.
>
> You could modify the spec file to cat the config.log file on error,
> which should give you more clues.
Thanks for the suggestion. I did that and got a more verbose and detailed
log.[1] Unfortunately I'm not a big enough c++/boost guru to know what it
means. I'll keep banging away at it though.
And I still don't know why it can't be reproduced outside of koji. I even
tried the build on one of Kevin's public machines (rawhide was natively
installed there), and the error did not reproduce.
-Zach
[1] http://koji.fedoraproject.org/koji/getfile?taskID=2324390&name=build.log
"...
| include
| int
| main ()
| {
| boost::program_options::variables_map::variables_map dummy()
| ;
| return 0;
| }
configure:18263: g++ -o conftest -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -
fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
conftest.cpp -lboost_program_options -lboost_system -lboost_regex -
lboost_program_options-mt >&5
conftest.cpp: In function 'int main()':
conftest.cpp:58:1: error:
'boost::program_options::variables_map::variables_map' names the constructor,
not the type
conftest.cpp:58:54: error: expected ';' before 'dummy'
conftest.cpp:59:3: error: statement cannot resolve address of overloaded
function
configure:18263: $? = 1
configure: failed program was:
...
"
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
trouble locally reproducing koji build error
Hi: I've got this build error: http://koji.fedoraproject.org/koji/taskinfo?taskID=2322203 However, on my local machine "make mockbuild" does not seem to reproduce it. What's a good set of steps for me to reproduce an environment that is the same as koji is using? I'd like to avoid doing a full install of rawhide if possible. Shouldn't a mockbuild generally be good enough to reproduce things? Any insight, tips or pointers would be much appreciated. thanks! -Zach -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
