Looks like the old memory allocation bug in Ocaml is back on Fedora 18 x86_64. Running the F18 x86_64 build of Unison http://koji.fedoraproject.org/koji/taskinfo?taskID=4692447 ends up with $ unison Fatal error: out of memory. Strace reveals mmap(NULL, 259407338535944192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory) so there is something seriously wrong in the compiler. The same RPM compiled on F17 works fine in F18.
Re the last sentence: *unison* compiled with OCaml < 4.00.0 works OK? I don't see anything in the changelog of 4.00.1 which would address this bug. Can you get a stack trace of the unison binary at the point where it crashes? Also I will ask on the upstream mailing lits.
Yup, the F17 build of unison used ocaml-3.12.1-12.fc17.x86_64 whereas the F18 build is with ocaml-4.00.0-1.fc18.x86_64. The F17 build works but the F18 build doesn't.
Created attachment 645910 [details] strace of the F18 binary
Created attachment 645911 [details] strace of the F17 binary
I really mean a stack trace, not system call trace: https://fedoraproject.org/wiki/StackTraces
Right. But not much help there: $ gdb unison-2.40 GNU gdb (GDB) Fedora (7.5.0.20120926-25.fc18) Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/bin/unison-2.40...Reading symbols from /usr/lib/debug/usr/bin/unison-2.40.debug...done. done. (gdb) r Starting program: /usr/bin/unison-2.40 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". warning: "/usr/lib/debug/usr/lib64/libicudata.so.49.1.1.debug": separate debug info file has no debug info Fatal error: out of memory. [Inferior 1 (process 29192) exited with code 02] (gdb)
Created attachment 656039 [details] gdb backtrace of failing brk() I set a breakpoint at the failing brk() call to get a backtrace at the point where things go south. Though all I can see is that its somewhere in the bowels of the ocaml interpreter.
This is the upstream bug report: http://caml.inria.fr/mantis/view.php?id=5717
I am experiencing the same problem in F18 beta - the same version (2.40) on F17 works without problems. What is more, the lesser version of unison (2.27) does work! How can this be if it is built against the same library, or is it not? At the same time, when trying to sync my computers with 2.27 for the time being the comparison process always spits out that both databases are different and that I should compare again. Needless to say, it doesn't work.
btw, why is the platform set to "arm Linux" ?
Seems like only x86_64 is affected, at least thats where all reports on this ticket are from. Somebody with sufficient permissions should change the platform. A workaround for unison is to copy /usr/bin/unison-2.40 from Fedora 17 over to the Fedora 18 install.
I'm having the same problem (out of memory with a ridiculously large allocation attempt) in coqide (package name is coq-coqide). As noted above, this only seems to affect F-18 x86_64. It works fine in Rawhide. See bug 884741.
(In reply to comment #12) > As noted above, > this only seems to affect F-18 x86_64. It works fine in Rawhide. See bug > 884741. When I looked at the list of changes from 4.00.0 -> 4.00.1 (ie. F18 -> Rawhide) I did not see anything that looked like it should fix this bug. Also I've seen this sort of thing before with data-driven changes to the GC causing a bug to appear and disappear seemingly at random. So I'd be very careful about saying that Rawhide (4.00.1) would be a fix for this bug. Not until we understand why precisely the bug happens in F18.
And I'd still like to see a stack trace of the problem when the bug occurs (comment 1).
(In reply to comment #13) > When I looked at the list of changes from 4.00.0 -> 4.00.1 > (ie. F18 -> Rawhide) I did not see anything that looked like > it should fix this bug. Also I've seen this sort of thing > before with data-driven changes to the GC causing a bug to > appear and disappear seemingly at random. So I'd be very > careful about saying that Rawhide (4.00.1) would be a > fix for this bug. Not until we understand why precisely > the bug happens in F18. Sure. Let me try that again. I have tried running coqide on a Fedora 18 x86_64 VM numerous times. In all of those attempts, it never managed to map a window before failing due to this bug. I have tried running coqide on a Fedora Rawhide x86_64 VM several times. On each attempt, coqide mapped its window and let me do some simple proofs without manifesting this bug. (In reply to comment #14) > And I'd still like to see a stack trace of the problem > when the bug occurs (comment 1). An attempt I made just now produced essentially the same backtrace as the one shown in the bug report linked from comment 8. What can I do to get a more informative stack trace for you?
(In reply to comment #15) > I have tried running coqide on a Fedora 18 x86_64 VM numerous times. In all > of those attempts, it never managed to map a window before failing due to > this bug. I have tried running coqide on a Fedora Rawhide x86_64 VM several > times. On each attempt, coqide mapped its window and let me do some simple > proofs without manifesting this bug. I don't doubt you. The problem this could be caused by two things: (1) The Coq codepath just doesn't cause the GC to hit this bug on Rawhide. (2) The bug is fixed -- but if so, what patch in .1 fixed it? I really don't know if it's (1) or (2). > (In reply to comment #14) > > And I'd still like to see a stack trace of the problem > > when the bug occurs (comment 1). > > An attempt I made just now produced essentially the same backtrace as the > one shown in the bug report linked from comment 8. What can I do to get a > more informative stack trace for you? One with ocaml-debuginfo (plus deps) would be a lot more helpful.
> > (In reply to comment #14) > > > And I'd still like to see a stack trace of the problem > > > when the bug occurs (comment 1). > > > > An attempt I made just now produced essentially the same backtrace as the > > one shown in the bug report linked from comment 8. What can I do to get a > > more informative stack trace for you? > > One with ocaml-debuginfo (plus deps) would be a lot more helpful. Installing ocaml-debuginfo doesn't seem to do much good: $ rpm -q ocaml-debuginfo ocaml-debuginfo-4.00.0-1.fc18.x86_64 $ gdb -ex run --args unison Documents -ui text GNU gdb (GDB) Fedora (7.5.1-31.fc18) Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/bin/unison...Reading symbols from /usr/lib/debug/usr/bin/unison-2.40.debug...done. done. Starting program: /usr/bin/unison Documents -ui text [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". warning: "/usr/lib/debug/usr/lib64/libicudata.so.49.1.1.debug": separate debug info file has no debug info Fatal error: out of memory. [Inferior 1 (process 20576) exited with code 02] (gdb) quit Is there anything else we can do? I have a feeling this is one of those issues where something with lower latency than bugzilla might be easier... If you want to meet up on IRC I'd be happy to help get whatever info you need. I'm nemequ on freenode and gimpnet.
Ditto that. After installing ocaml-debuginfo, the stack trace still looks like the one linked from comment 8, up through frame 8 (caml_system__code_begin). So I built my own ocaml binaries from the git sources, and callously overwrote the system versions with binaries and libraries containing debug symbols, then did the same for coq. Ugh. Anyway, try this stack trace: #0 __GI__IO_fputs (str=str@entry=0x6860ec "Fatal error: out of memory.\n", fp= 0x3725fb21a0 <_IO_2_1_stderr_>) at iofputs.c:35 #1 0x000000000066cdc0 in fprintf (__fmt=<optimized out>, __stream=<optimized out>) at /usr/include/bits/stdio2.h:97 #2 caml_fatal_error (msg=msg@entry=0x6860ec "Fatal error: out of memory.\n") at misc.c:54 #3 0x000000000066f874 in caml_alloc_shr (wosize=wosize@entry= 18014398509439783, tag=<optimized out>) at memory.c:416 #4 0x000000000066e9bf in caml_oldify_one (v=140737353766824, p=0x9b2fa0) at minor_gc.c:130 #5 0x000000000066bad7 in caml_oldify_local_roots () at roots.c:168 #6 0x000000000066ebd5 in caml_empty_minor_heap () at minor_gc.c:234 #7 0x000000000066ed1d in caml_minor_collection () at minor_gc.c:277 #8 0x000000000066cc1a in caml_garbage_collection () at signals_asm.c:71 #9 0x000000000067e128 in caml_system__code_begin () #10 0x0000000000615735 in camlMap__add_1082 () at map.ml:114 #11 0x00000000006156d4 in camlMap__add_1082 () at map.ml:114 #12 0x00000000006156d4 in camlMap__add_1082 () at map.ml:114 #13 0x00000000006356ec in camlCamlinternalOO__fun_1593 () at camlinternalOO.ml:219 #14 0x000000000060f232 in camlList__iter2_1106 () at list.ml:112 #15 0x00000000006368f3 in camlCamlinternalOO__narrow_1161 () at camlinternalOO.ml:215 #16 0x000000000063713a in camlCamlinternalOO__inherits_1233 () at camlinternalOO.ml:320 #17 0x00000000005bd85c in camlGButton__tool_item_skel_init_3064 () #18 0x00007ffff7e3af20 in ?? () ... [followed by nonsense stack frames with addresses like 0x25]. In frame 4, sz = 18014398509439783, and all other locals = <optimized out>. Don't you hate that? So let's figure it out for ourselves from the value of v, and these definitions in stdlib/caml/mlvalues.h: #define Tag_hd(hd) ((tag_t) ((hd) & 0xFF)) #define Wosize_hd(hd) ((mlsize_t) ((hd) >> 10)) #define Hd_val(val) (((header_t *) (val)) [-1]) which gives us the following variable values (with a little help from GDB): hd = 18446744073666338135 tag = 87 sz = 18014398509439783 In frame 5, the only local variables that are not <optimized out> are i = 88 and j = 11. The value of glob = caml_globals[i] is 10170184, which means that the failing call was: Oldify (&Field (10170184, 11)); ==> Oldify (&(((value *)(10170184)) [11])); ==> Oldify ((value *) 0x9b2fa0); ==> do { value __oldify__v__ = *(value *)0x9b2fa0; if (Is_block (__oldify__v__) && Is_young (__oldify__v__)){ caml_oldify_one (__oldify__v__, (value *)0x9b2fa0); } } while(0); And *(value *)0x9b2fa0 == 140737353766824, for the record. I don't actually understand much, if any, of this, so tell me what else you want GDB to reveal.
(In reply to comment #13) > (In reply to comment #12) > > As noted above, > > this only seems to affect F-18 x86_64. It works fine in Rawhide. See bug > > 884741. > > When I looked at the list of changes from 4.00.0 -> 4.00.1 > (ie. F18 -> Rawhide) I did not see anything that looked like > it should fix this bug. Also I've seen this sort of thing > before with data-driven changes to the GC causing a bug to > appear and disappear seemingly at random. So I'd be very > careful about saying that Rawhide (4.00.1) would be a > fix for this bug. Not until we understand why precisely > the bug happens in F18. On a side note: the rawhide(fc19) build of unison240 seems to work fine on F-18 x86_64, too.
The OCaml 4.00.0 -> 4.00.1 changelog lists a serious bug fix for the x86_64 code generator: - PR#5707: AMD64 code generator: do not use r10 and r11 for parameter passing, as these registers can be destroyed by the dynamic loader http://caml.inria.fr/pub/distrib/ocaml-4.00/notes/Changes I think its pretty clear that we are being hit by this. This also explains why the rawhide version of OCaml-4.00.1 works.
That is indeed a very serious bug that could cause this sort of error easily. Not sure why I didn't spot that before ... Let me backport just that fix to F18 and see if that improves the situation.
Created attachment 663037 [details] ocaml r12907 (In reply to comment #21) > That is indeed a very serious bug that could cause this > sort of error easily. Not sure why I didn't spot that before ... > > Let me backport just that fix to F18 and see if that improves the > situation. Dammit, unfortunately this makes the calling convention incompatible, so all packages would have to be recompiled anyway. In which case we might as well just update to 4.00.1 from Rawhide. This is a huge chunk of work. Attached is the patch which would fix the register problem.
For better or worse, I started to rebuild the F18 packages. This is going to take a while.
If you'll let us know when the new ocaml package is available as a buildroot override, I'll rebuild the ocaml packages that I rebuilt for the Rawhide update (packages I maintain, plus a few dependencies).
*** Bug 884741 has been marked as a duplicate of this bug. ***
ocaml-4.00.1-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/ocaml-4.00.1-1.fc18
(In reply to comment #24) > If you'll let us know when the new ocaml package is available as a buildroot > override, I'll rebuild the ocaml packages that I rebuilt for the Rawhide > update (packages I maintain, plus a few dependencies). ocaml-4.00.1-1.fc18 and ocaml-findlib-1.3.3-3.fc18 are now available as buildroot overrides to build against.
Package ocaml-4.00.1-1.fc18, ocaml-findlib-1.3.3-3.fc18, ocaml-camlidl-1.05-17.fc18, ocaml-camlp5-6.07-1.fc18, ocaml-lablgl-20120306-4.fc18, ocaml-lablgtk-2.16.0-1.fc18, xen-4.2.0-7.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing ocaml-4.00.1-1.fc18 ocaml-findlib-1.3.3-3.fc18 ocaml-camlidl-1.05-17.fc18 ocaml-camlp5-6.07-1.fc18 ocaml-lablgl-20120306-4.fc18 ocaml-lablgtk-2.16.0-1.fc18 xen-4.2.0-7.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-20337/xen-4.2.0-7.fc18,ocaml-lablgtk-2.16.0-1.fc18,ocaml-lablgl-20120306-4.fc18,ocaml-camlp5-6.07-1.fc18,ocaml-camlidl-1.05-17.fc18,ocaml-findlib-1.3.3-3.fc18,ocaml-4.00.1-1.fc18 then log in and leave karma (feedback).
*** Bug 876765 has been marked as a duplicate of this bug. ***
Package ocaml-4.00.1-1.fc18, ocaml-findlib-1.3.3-3.fc18, ocaml-camlidl-1.05-17.fc18, ocaml-camlp5-6.07-1.fc18, ocaml-lablgl-20120306-4.fc18, ocaml-lablgtk-2.16.0-1.fc18, xen-4.2.0-7.fc18, zenon-0.7.1-3.fc18, ocaml-zarith-1.1-3.fc18, ocaml-ocamlgraph-1.8.2-2.fc18, ocaml-mlgmpidl-1.2.1-0.2.20120830.fc18, ocaml-menhir-20120123-5.fc18, gappalib-coq-0.18.0-5.fc18, coq-8.4-3.fc18, apron-0.9.10-9.fc18, alt-ergo-0.94-7.fc18, ocaml-ancient-0.9.0-10.fc18, ocaml-bisect-1.1-4.fc18, ocaml-augeas-0.5-3.fc18, ocaml-cil-1.4.0-6.fc18, ocaml-camomile-0.8.3-10.fc18, ocaml-extlib-1.5.3-2.fc18, ocaml-camlimages-4.0.1-7.fc18, ocaml-calendar-2.03.2-2.fc18, ocaml-cairo-1.2.0-0.8.git08b40192975.fc18, ocaml-bitstring-2.0.3-5.fc18, ocaml-curl-0.5.3-7.fc18, ocaml-cryptokit-1.6-3.fc18, ocaml-curses-1.0.3-15.fc18, ocaml-deriving-0.1.1a-17.fc18, ocaml-dbus-0.29-6.fc18, ocaml-expat-0.9.1-24.fc18, ocaml-facile-1.1-19.fc18, ocaml-csv-1.2.3-3.fc18, ocaml-libvirt-0.6.1.2-6.fc18, ocaml-newt-0.9-14.fc18, ocaml-mysql-1.1.1-1.fc18, ocaml-gsl-0.6.0-16.fc18, ocaml-lacaml-7.0.3-1.fc18, ocaml-json-static-0.9.8-8.fc18, ocaml-pa-do-0.8.15-1.fc18, ocaml-perl4caml-0.9.5-23.fc18, ocaml-ounit-1.1.2-4.fc18, ocaml-ssl-0.4.6-5.fc18, ocaml-pcre-7.0.2-2.fc18, ocaml-ulex-1.1-15.fc18, ocaml-openin-20070524-16.fc18, ocaml-sqlite-1.6.3-3.fc18, ocaml-xml-light-2.3-0.3.svn234.fc18, ocaml-zip-1.04-10.fc18, ocaml-type-conv-3.0.5-3.fc18, ocaml-p3l-2.03-12.fc18, ocaml-react-0.9.4-1.fc18, ocaml-res-3.2.0-10.fc18, ocaml-pa-monad-6.0-10.fc18, ocaml-postgresql-2.0.2-1.fc18, ocaml-SDL-0.8.0-7.fc18, ocaml-sexplib-7.0.5-4.fc18, ocaml-lwt-2.4.2-1.fc18, ocaml-reins-0.1a-14.fc18, ocaml-bin-prot-2.0.9-3.fc18, ocaml-ocamlnet-3.5.1-4.fc18, ocaml-fileutils-0.4.4-4.fc18, ocaml-pgocaml-1.6-2.fc18, ocaml-gettext-0.3.4-8.fc18, ocaml-xmlrpc-light-0.6.1-11.fc18, ocaml-pxp-1.2.3-5.fc18, ocaml-json-wheel-1.0.6-10.fc18, ocaml-preludeml-0.1-0.22.20100314.fc18, frama-c-1.8-4.fc18, brltty-4.3-10.fc18, hivex-1.3.7-2.fc18, virt-top-1.0.8-3.fc18, virt-dmesg-0.3.0-6.fc18, whenjobs-0.7.3-4.fc18, coccinelle-1.0.0-0.rc14.6.fc18, js-of-ocaml-1.2-2.fc18, llvm-3.1-12.fc18, cduce-0.5.5-3.fc18, why3-0.73-3.fc18, graphviz-2.28.0-24.fc18, unison213-2.13.16-20.fc18, unison227-2.27.57-19.fc18, unison240-2.40.102-2.fc18, why-2.31-4.fc18, kalzium-4.9.4-2.fc18, plplot-5.9.9-12.svn12202.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing ocaml-4.00.1-1.fc18 ocaml-findlib-1.3.3-3.fc18 ocaml-camlidl-1.05-17.fc18 ocaml-camlp5-6.07-1.fc18 ocaml-lablgl-20120306-4.fc18 ocaml-lablgtk-2.16.0-1.fc18 xen-4.2.0-7.fc18 zenon-0.7.1-3.fc18 ocaml-zarith-1.1-3.fc18 ocaml-ocamlgraph-1.8.2-2.fc18 ocaml-mlgmpidl-1.2.1-0.2.20120830.fc18 ocaml-menhir-20120123-5.fc18 gappalib-coq-0.18.0-5.fc18 coq-8.4-3.fc18 apron-0.9.10-9.fc18 alt-ergo-0.94-7.fc18 ocaml-ancient-0.9.0-10.fc18 ocaml-bisect-1.1-4.fc18 ocaml-augeas-0.5-3.fc18 ocaml-cil-1.4.0-6.fc18 ocaml-camomile-0.8.3-10.fc18 ocaml-extlib-1.5.3-2.fc18 ocaml-camlimages-4.0.1-7.fc18 ocaml-calendar-2.03.2-2.fc18 ocaml-cairo-1.2.0-0.8.git08b40192975.fc18 ocaml-bitstring-2.0.3-5.fc18 ocaml-curl-0.5.3-7.fc18 ocaml-cryptokit-1.6-3.fc18 ocaml-curses-1.0.3-15.fc18 ocaml-deriving-0.1.1a-17.fc18 ocaml-dbus-0.29-6.fc18 ocaml-expat-0.9.1-24.fc18 ocaml-facile-1.1-19.fc18 ocaml-csv-1.2.3-3.fc18 ocaml-libvirt-0.6.1.2-6.fc18 ocaml-newt-0.9-14.fc18 ocaml-mysql-1.1.1-1.fc18 ocaml-gsl-0.6.0-16.fc18 ocaml-lacaml-7.0.3-1.fc18 ocaml-json-static-0.9.8-8.fc18 ocaml-pa-do-0.8.15-1.fc18 ocaml-perl4caml-0.9.5-23.fc18 ocaml-ounit-1.1.2-4.fc18 ocaml-ssl-0.4.6-5.fc18 ocaml-pcre-7.0.2-2.fc18 ocaml-ulex-1.1-15.fc18 ocaml-openin-20070524-16.fc18 ocaml-sqlite-1.6.3-3.fc18 ocaml-xml-light-2.3-0.3.svn234.fc18 ocaml-zip-1.04-10.fc18 ocaml-type-conv-3.0.5-3.fc18 ocaml-p3l-2.03-12.fc18 ocaml-react-0.9.4-1.fc18 ocaml-res-3.2.0-10.fc18 ocaml-pa-monad-6.0-10.fc18 ocaml-postgresql-2.0.2-1.fc18 ocaml-SDL-0.8.0-7.fc18 ocaml-sexplib-7.0.5-4.fc18 ocaml-lwt-2.4.2-1.fc18 ocaml-reins-0.1a-14.fc18 ocaml-bin-prot-2.0.9-3.fc18 ocaml-ocamlnet-3.5.1-4.fc18 ocaml-fileutils-0.4.4-4.fc18 ocaml-pgocaml-1.6-2.fc18 ocaml-gettext-0.3.4-8.fc18 ocaml-xmlrpc-light-0.6.1-11.fc18 ocaml-pxp-1.2.3-5.fc18 ocaml-json-wheel-1.0.6-10.fc18 ocaml-preludeml-0.1-0.22.20100314.fc18 frama-c-1.8-4.fc18 brltty-4.3-10.fc18 hivex-1.3.7-2.fc18 virt-top-1.0.8-3.fc18 virt-dmesg-0.3.0-6.fc18 whenjobs-0.7.3-4.fc18 coccinelle-1.0.0-0.rc14.6.fc18 js-of-ocaml-1.2-2.fc18 llvm-3.1-12.fc18 cduce-0.5.5-3.fc18 why3-0.73-3.fc18 graphviz-2.28.0-24.fc18 unison213-2.13.16-20.fc18 unison227-2.27.57-19.fc18 unison240-2.40.102-2.fc18 why-2.31-4.fc18 kalzium-4.9.4-2.fc18 plplot-5.9.9-12.svn12202.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-20337/plplot-5.9.9-12.svn12202.fc18,kalzium-4.9.4-2.fc18,why-2.31-4.fc18,unison213-2.13.16-20.fc18,unison227-2.27.57-19.fc18,unison240-2.40.102-2.fc18,llvm-3.1-12.fc18,cduce-0.5.5-3.fc18,why3-0.73-3.fc18,graphviz-2.28.0-24.fc18,frama-c-1.8-4.fc18,brltty-4.3-10.fc18,hivex-1.3.7-2.fc18,virt-top-1.0.8-3.fc18,virt-dmesg-0.3.0-6.fc18,whenjobs-0.7.3-4.fc18,coccinelle-1.0.0-0.rc14.6.fc18,js-of-ocaml-1.2-2.fc18,ocaml-preludeml-0.1-0.22.20100314.fc18,ocaml-gettext-0.3.4-8.fc18,ocaml-xmlrpc-light-0.6.1-11.fc18,ocaml-pxp-1.2.3-5.fc18,ocaml-json-wheel-1.0.6-10.fc18,ocaml-sexplib-7.0.5-4.fc18,ocaml-lwt-2.4.2-1.fc18,ocaml-reins-0.1a-14.fc18,ocaml-bin-prot-2.0.9-3.fc18,ocaml-ocamlnet-3.5.1-4.fc18,ocaml-fileutils-0.4.4-4.fc18,ocaml-pgocaml-1.6-2.fc18,ocaml-pa-do-0.8.15-1.fc18,ocaml-perl4caml-0.9.5-23.fc18,ocaml-ounit-1.1.2-4.fc18,ocaml-ssl-0.4.6-5.fc18,ocaml-pcre-7.0.2-2.fc18,ocaml-ulex-1.1-15.fc18,ocaml-openin-20070524-16.fc18,ocaml-sqlite-1.6.3-3.fc18,ocaml-xml-light-2.3-0.3.svn234.fc18,ocaml-zip-1.04-10.fc18,ocaml-type-conv-3.0.5-3.fc18,ocaml-p3l-2.03-12.fc18,ocaml-react-0.9.4-1.fc18,ocaml-res-3.2.0-10.fc18,ocaml-pa-monad-6.0-10.fc18,ocaml-postgresql-2.0.2-1.fc18,ocaml-SDL-0.8.0-7.fc18,ocaml-csv-1.2.3-3.fc18,ocaml-libvirt-0.6.1.2-6.fc18,ocaml-newt-0.9-14.fc18,ocaml-mysql-1.1.1-1.fc18,ocaml-gsl-0.6.0-16.fc18,ocaml-lacaml-7.0.3-1.fc18,ocaml-json-static-0.9.8-8.fc18,ocaml-curl-0.5.3-7.fc18,ocaml-cryptokit-1.6-3.fc18,ocaml-curses-1.0.3-15.fc18,ocaml-deriving-0.1.1a-17.fc18,ocaml-dbus-0.29-6.fc18,ocaml-expat-0.9.1-24.fc18,ocaml-facile-1.1-19.fc18,ocaml-cil-1.4.0-6.fc18,ocaml-camomile-0.8.3-10.fc18,ocaml-extlib-1.5.3-2.fc18,ocaml-camlimages-4.0.1-7.fc18,ocaml-calendar-2.03.2-2.fc18,ocaml-cairo-1.2.0-0.8.git08b40192975.fc18,ocaml-bitstring-2.0.3-5.fc18,ocaml-bisect-1.1-4.fc18,ocaml-augeas-0.5-3.fc18,ocaml-ancient-0.9.0-10.fc18,zenon-0.7.1-3.fc18,ocaml-zarith-1.1-3.fc18,ocaml-ocamlgraph-1.8.2-2.fc18,ocaml-mlgmpidl-1.2.1-0.2.20120830.fc18,ocaml-menhir-20120123-5.fc18,gappalib-coq-0.18.0-5.fc18,coq-8.4-3.fc18,apron-0.9.10-9.fc18,alt-ergo-0.94-7.fc18,xen-4.2.0-7.fc18,ocaml-lablgtk-2.16.0-1.fc18,ocaml-lablgl-20120306-4.fc18,ocaml-camlp5-6.07-1.fc18,ocaml-camlidl-1.05-17.fc18,ocaml-findlib-1.3.3-3.fc18,ocaml-4.00.1-1.fc18 then log in and leave karma (feedback).
Proper NTH nomination.
Discussed at 2012-12-17 NTH review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-17/f18final-blocker-review-5.2012-12-17-16.40.log.txt . Though this is a Big Hairy Emergency, on careful examination, we see no reasoning in the bug or ML thread as to why we actually have to break freeze for this. No impact on critical path or release blocking stuff has been demonstrated in this bug report or on the mailing list thread. Does someone have a good reason as to why we have to break freeze and take this major change? Or is it OK for it to go out as a 0-day update?
No reason to break any freeze.
On that basis I'm 'un-nominating' this rather than rejecting it: if rwmj doesn't think it needs to break freeze, no purpose to having it nominated.
ocaml-4.00.1-1.fc18, ocaml-findlib-1.3.3-3.fc18, ocaml-camlidl-1.05-17.fc18, ocaml-camlp5-6.07-1.fc18, ocaml-lablgl-20120306-4.fc18, ocaml-lablgtk-2.16.0-1.fc18, xen-4.2.0-7.fc18, zenon-0.7.1-3.fc18, ocaml-zarith-1.1-3.fc18, ocaml-ocamlgraph-1.8.2-2.fc18, ocaml-mlgmpidl-1.2.1-0.2.20120830.fc18, ocaml-menhir-20120123-5.fc18, gappalib-coq-0.18.0-5.fc18, coq-8.4-3.fc18, apron-0.9.10-9.fc18, alt-ergo-0.94-7.fc18, ocaml-ancient-0.9.0-10.fc18, ocaml-bisect-1.1-4.fc18, ocaml-augeas-0.5-3.fc18, ocaml-cil-1.4.0-6.fc18, ocaml-camomile-0.8.3-10.fc18, ocaml-extlib-1.5.3-2.fc18, ocaml-camlimages-4.0.1-7.fc18, ocaml-calendar-2.03.2-2.fc18, ocaml-cairo-1.2.0-0.8.git08b40192975.fc18, ocaml-bitstring-2.0.3-5.fc18, ocaml-curl-0.5.3-7.fc18, ocaml-cryptokit-1.6-3.fc18, ocaml-curses-1.0.3-15.fc18, ocaml-deriving-0.1.1a-17.fc18, ocaml-dbus-0.29-6.fc18, ocaml-expat-0.9.1-24.fc18, ocaml-facile-1.1-19.fc18, ocaml-csv-1.2.3-3.fc18, ocaml-libvirt-0.6.1.2-6.fc18, ocaml-newt-0.9-14.fc18, ocaml-mysql-1.1.1-1.fc18, ocaml-gsl-0.6.0-16.fc18, ocaml-lacaml-7.0.3-1.fc18, ocaml-json-static-0.9.8-8.fc18, ocaml-pa-do-0.8.15-1.fc18, ocaml-perl4caml-0.9.5-23.fc18, ocaml-ounit-1.1.2-4.fc18, ocaml-ssl-0.4.6-5.fc18, ocaml-pcre-7.0.2-2.fc18, ocaml-ulex-1.1-15.fc18, ocaml-openin-20070524-16.fc18, ocaml-sqlite-1.6.3-3.fc18, ocaml-xml-light-2.3-0.3.svn234.fc18, ocaml-zip-1.04-10.fc18, ocaml-type-conv-3.0.5-3.fc18, ocaml-p3l-2.03-12.fc18, ocaml-react-0.9.4-1.fc18, ocaml-res-3.2.0-10.fc18, ocaml-pa-monad-6.0-10.fc18, ocaml-postgresql-2.0.2-1.fc18, ocaml-SDL-0.8.0-7.fc18, ocaml-sexplib-7.0.5-4.fc18, ocaml-lwt-2.4.2-1.fc18, ocaml-reins-0.1a-14.fc18, ocaml-bin-prot-2.0.9-3.fc18, ocaml-ocamlnet-3.5.1-4.fc18, ocaml-fileutils-0.4.4-4.fc18, ocaml-pgocaml-1.6-2.fc18, ocaml-gettext-0.3.4-8.fc18, ocaml-xmlrpc-light-0.6.1-11.fc18, ocaml-pxp-1.2.3-5.fc18, ocaml-json-wheel-1.0.6-10.fc18, ocaml-preludeml-0.1-0.22.20100314.fc18, frama-c-1.8-4.fc18, brltty-4.3-10.fc18, hivex-1.3.7-2.fc18, virt-top-1.0.8-3.fc18, virt-dmesg-0.3.0-6.fc18, whenjobs-0.7.3-4.fc18, coccinelle-1.0.0-0.rc14.6.fc18, js-of-ocaml-1.2-2.fc18, llvm-3.1-12.fc18, cduce-0.5.5-3.fc18, why3-0.73-3.fc18, graphviz-2.28.0-24.fc18, unison213-2.13.16-20.fc18, unison227-2.27.57-19.fc18, unison240-2.40.102-2.fc18, why-2.31-4.fc18, kalzium-4.9.4-2.fc18, plplot-5.9.9-12.svn12202.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.