Arches. please test and mark stable =sys-kernel/openvz-sources-2.6.32.68.8 on amd64. Before build please double read openvz ebuild warning's and messages. Yes, this require gcc-4.4 and custom config from openvz.org site. This bug assigned to arch team since pva is unavailable for a long time. Thanks.
Assigning this bug properly, adding x86 arch team to CC
It fails with error like this: CC fs/nfs/dns_resolve.o CC fs/quota/quota_v2.o CC fs/ramfs/file-mmu.o fs/nfs/dns_resolve.c:12:32: fatal error: linux/dns_resolver.h: No such file or directory compilation terminated. Someone can reproduce?
(In reply to comment #2) > > Someone can reproduce? I can't reproduce that error, I get the following in my box: CC kernel/sched.o In file included from kernel/sched.c:2120:0: kernel/sched_autogroup.c: In function 'autogroup_move_group': kernel/sched_autogroup.c:145:4: error: expected 'while' before 'while_each_thread' In file included from kernel/sched.c:2122:0: kernel/sched_debug.c: In function 'print_cfs_rq': kernel/sched_debug.c:175:2: error: implicit declaration of function 'task_group_path' kernel/sched_debug.c:175:2: warning: format '%s' expects type 'char *', but argument 4 has type 'int' kernel/sched_debug.c:175:2: warning: format '%s' expects type 'char *', but argument 3 has type 'int' kernel/sched_debug.c: In function 'print_rt_rq': kernel/sched_debug.c:231:2: warning: format '%s' expects type 'char *', but argument 4 has type 'int' kernel/sched_debug.c:231:2: warning: format '%s' expects type 'char *', but argument 3 has type 'int' kernel/sched.c: In function 'sched_init': kernel/sched.c:10547:5: warning: passing argument 5 of 'init_tg_cfs_entry' makes pointer from integer without a cast kernel/sched.c:10341:13: note: expected 'struct sched_entity *' but argument is of type 'int' kernel/sched.c:10547:5: error: too many arguments to function 'init_tg_cfs_entry' kernel/sched.c:10341:13: note: declared here kernel/sched.c: In function 'cpuacct_stats_show': kernel/sched.c:12475:16: error: 'cpuacct_stat_desc' undeclared (first use in this function) kernel/sched.c:12475:16: note: each undeclared identifier is reported only once for each function it appears in make[1]: *** [kernel/sched.o] Error 1 make: *** [kernel] Error 2
(In reply to comment #3) > I can't reproduce that error, I get the following in my box: In some cases appears broken, may we close this bug?
(In reply to comment #4) > (In reply to comment #3) > > I can't reproduce that error, I get the following in my box: > > In some cases appears broken, may we close this bug? did you use gcc 4.4 for compiling this? It can be broken with newer versions, as upstream says
(In reply to comment #5) > did you use gcc 4.4 for compiling this? It can be broken with newer > versions, as upstream says why we should stabilize a broken package?
(In reply to comment #6) > why we should stabilize a broken package? This package used in many enterprise, but upstream did not want to support compilation and work under new gcc(upstream is RHEL-orientied). We are already have stable versions of openvz-sources 2.6.32-branch that hits just the same problem with gcc, so it's NOT a regression
(In reply to comment #7) > (In reply to comment #6) > > why we should stabilize a broken package? > > This package used in many enterprise, but upstream did not want to support > compilation and work under new gcc(upstream is RHEL-orientied). We are > already have stable versions of openvz-sources 2.6.32-branch that hits just > the same problem with gcc, so it's NOT a regression I'd suggest to drop stable keywords if fails to compile
first - https://bugs.gentoo.org/show_bug.cgi?id=452078#c0 second - you use the requested kernel config or not? thrid - please look at the history of the ebuild in cvs and see https://bugs.gentoo.org/show_bug.cgi?id=198632#c2 P.S You propose to remove the stable keywords in all versions? If so, then does your suggestion that if the PVA will not come back to us, to everyone who uses openvz not think about migrating to other distributions? That would be a very bad ending .
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > why we should stabilize a broken package? > > > > This package used in many enterprise, but upstream did not want to support > > compilation and work under new gcc(upstream is RHEL-orientied). We are > > already have stable versions of openvz-sources 2.6.32-branch that hits just > > the same problem with gcc, so it's NOT a regression > > I'd suggest to drop stable keywords if fails to compile since it is not a regression i'd say to proceed with the stabilization
(In reply to comment #9) > first - https://bugs.gentoo.org/show_bug.cgi?id=452078#c0 Says do this, this and this, does not mean the package is ok from the qa side. > second - you use the requested kernel config or not? We are talking about the failure with the stable gcc. > thrid - please look at the history of the ebuild in cvs and see > https://bugs.gentoo.org/show_bug.cgi?id=198632#c2 I don't like to have a stable keyword on package that fails to compile with latest gcc > P.S You propose to remove the stable keywords in all versions? > If so, then does your suggestion that if the PVA will not come back to us, > to everyone who uses openvz not think about migrating to other distributions? > That would be a very bad ending . People can use their package.keywords, but is silly give a package as stable which does not compile with gcc:4.6
(In reply to comment #11) > (In reply to comment #9) > > first - https://bugs.gentoo.org/show_bug.cgi?id=452078#c0 > Says do this, this and this, does not mean the package is ok from the qa > side. > > > second - you use the requested kernel config or not? > We are talking about the failure with the stable gcc. > > > thrid - please look at the history of the ebuild in cvs and see > > https://bugs.gentoo.org/show_bug.cgi?id=198632#c2 > I don't like to have a stable keyword on package that fails to compile with > latest gcc > People are not supposed to use the latest gcc with this package.
(In reply to comment #9) > second - you use the requested kernel config or not? Is this? http://download.openvz.org/kernel/branches/2.6.32/current/configs/kernel-2.6.32-x86_64.config.ovz
(In reply to comment #13) > (In reply to comment #9) > > second - you use the requested kernel config or not? > Is this? > http://download.openvz.org/kernel/branches/2.6.32/current/configs/kernel-2.6. > 32-x86_64.config.ovz http://download.openvz.org/kernel/branches/rhel6-2.6.32/042stab068.8/configs/
K_EXTRAEINFO="This openvz kernel uses RHEL6 patchset instead of vanilla kernel. This patchset considered to be more stable and security supported by upstream, but for us RHEL6 patchset is very fragile and fails to build in many configurations so if you have problems use config files from openvz team http://wiki.openvz.org/Download/kernel/rhel6/042stab${OVZ_KV} For info in next paragraph, see http://bugzilla.openvz.org/show_bug.cgi?id=2012#1 In general, RHEL kernels are very sensitive to compiler version and therefore should be compiled by RHEL compiler, otherwise there might be stability issues, sometimes as bad as this case." K_EXTRAEWARN="This kernel is stable only when built with gcc-4.4.x and is known to oops in random places if built with newer compilers."
Tell me if I did something wrong in bug 453660
CC back when 453660 is resolved
Readding arches, due to closing bug #453660. Please proceed with stabilization...
amd64 stable
