Re: OCaml 4.00.1 for Fedora 18
Richard W.M. Jones wrote: > All those packages should be in the buildroot overrides, unless I > missed any. > > Strangely, the command at the end of this email shows only 67 > overrides, which can't be right because there are more packages than > that. > > Yet: > > bodhi --buildroot-override=ocaml-facile-1.1-19.fc18 --duration=50 > '--notes=Override ocaml-findlib package to fix RHBZ#877128' Error: > buildroot override for ocaml-facile-1.1-19.fc18 already exists > > So I guess you (or someone) added this already? You filed it. I don't know why it isn't showing up in bodhi --my-overrides for you. It shows up on the web interface as filed by you, in any case. I rebuilt kalzium and added it to your update a few hours ago, it has been included in the current testing push. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MariaDB: Packagers needed
Kevin Fenzi writes: > I think I am with Remi on the above... shipping both for 1 release > would be potentially helpful in seeing issues, we can ask people to > migrate at that time and file bugs, if the bugs are stoppers they can > go back to mysql until fixed. I guess it depends on the maintainer(s) > involved if they feel this would be worthwhile. There will be very substantial costs to either of the schemes that allow mysql and mariadb to be installed in parallel. I'm pretty disinclined to expend the packaging effort, or the user-education effort, if the road map is that we're expecting to drop mysql altogether soon. I'm OK with a ship-both-for-awhile plan as long as it's done by making the packages simply Conflict:. Otherwise I think we'll be doing too much throwaway work. Personally, though, I lean to the just-do-it approach. Remember that mariadb is in the end a fork of mysql. It seems unlikely to me that there are bugs in it that are (a) not in mysql and (b) so catastrophic as to justify the work of dual-packaging, even in the stripped down form of just-make-them-conflict. So I'd rather just make the switch (early in a devel cycle) and fix any bugs we run into. As an example of the sort of work I'd rather not do, if we want to have two packages then it'll be necessary to change BuildRequires in other packages if we want to build/test them against mariadb. If we go straight for the replacement approach, then we can say mariadb-devel Provides: mysql-devel, and no source changes are needed in other packages. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OCaml 4.00.1 for Fedora 18
On 12/14/2012 11:12 AM, Josh Stone wrote: > On 12/14/2012 07:34 AM, Kevin Kofler wrote: >> Richard W.M. Jones wrote: >>> It's my understanding that when the update goes out, the build >>> overrides are automatically expired, which is why I selected a very >>> long expiry. >> >> AIUI, that's actually not the case. But you can expire the stuff manually >> when it's done. > > It's documented to do so here in the "auto expiration" note: > https://fedoraproject.org/wiki/Bodhi/BuildRootOverrides#Submitting_a_new_override Actually, I might be reading that incorrectly - so if you do specify a duration, then no auto-expiration takes place? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OCaml 4.00.1 for Fedora 18
On 12/14/2012 07:34 AM, Kevin Kofler wrote: > Richard W.M. Jones wrote: >> It's my understanding that when the update goes out, the build >> overrides are automatically expired, which is why I selected a very >> long expiry. > > AIUI, that's actually not the case. But you can expire the stuff manually > when it's done. It's documented to do so here in the "auto expiration" note: https://fedoraproject.org/wiki/Bodhi/BuildRootOverrides#Submitting_a_new_override If not, someone please update that to reflect reality... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MariaDB: Packagers needed
On Thu, 13 Dec 2012 19:52:17 +0100 Remi Collet wrote: > Le 13/12/2012 18:32, Honza Horak a écrit : > > > 1. continue shipping only mysql > > 2. ship mysql + mariadb, that would conflict > > Seems ok for 1 release. > > > 3. ship mysql + mariadb with adjusted file-names and using > > alternatives 4. ship mysql + mariadb with adjusted file-names but > > not using alternatives 5. drop mysql and ship only mariadb > > For me, the good target. > > > 6. is there any other? I think I am with Remi on the above... shipping both for 1 release would be potentially helpful in seeing issues, we can ask people to migrate at that time and file bugs, if the bugs are stoppers they can go back to mysql until fixed. I guess it depends on the maintainer(s) involved if they feel this would be worthwhile. Longer term I don't see too much advantage to continuing to ship both however, we should follow the better choice (as we did in cases like LibreOffice). kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Static Analysis SIG ? (was Re: Dealing with static code analysis in Fedora)
On Thu, 2012-12-13 at 21:45 +0200, Alek Paunov wrote: > On 11.12.2012 23:52, David Malcolm wrote: > > We'd be able to run all of the code in Fedora through static analysis > > tools, and slurp the results into the database > > Dave, I really do not know what to say first :-). The subject is so > important and there are so many aspects and application fields - IMHO, > the topic is the most important one in the devel list lately (and is in > _direct_ relation with the all other _hot_ topics - ABI stability, > upgradeability, collections, reliable/automated migrations, packagers > productivity, rawhide, etc.) I very much agree, of course :) We rely far too much on manual tasks when we build Fedora, and there are plenty that we could be automating. Within the domain of making Fedora more stable, static code analysis should be the partner of the AutoQA effort: the former can detect bugs at compile-time, the latter at run-time (hopefully before it reaches any systems that people care about). The two approaches are of course complementary: programmers tend to overemphasize the value of static code analysis - but both are valuable. > I hope this thread will be long and fruitful discussion with the final > effect to change Fedora to something that all motivated devs in the list > expect it to become. Just few preliminary questions about your insights > in the future: > > 1) What about dumping the GCC structs to the DB during the OS/Repos > processing from the same beginning (means something more powerful than > dxr.mozilla.org, and possibility to engage various static analysis > people to the project, like Masaryk University team as Michal reported, > without the locking to concrete compiler technology/encoding) Yes - we could use that to build a great source cross-referencer for all of Fedora. I can think of plenty of uses for this (e.g. "upstream added a new parameter to this library function; how much is going to break?"). FWIW, I'm trying to focus my efforts on bug detection, though, and I'm not sure how far one can get with a database of the IR of every function. I've been looking at using LTO to do interprocedural analysis across source files via my gcc plugin, and I have that working (not yet released), so I can run analyses at whole libraries at link-time, from within GCC. One drawback of that is that (IIRC) GCC's LTO representation within the .o files is specific to the precise GCC version, and IIRC there aren't any guarantees about forward or backward compatibility, compared to say, LLVM bitcode. It might be possible to patch GCC to use GIMPLE textual dumps (compressed?) as an intermediate format, storing that within the .o files in a similar way to the LTO implementation. But I'm speculating here. > 2) Clang world enrolled the (suspicious) term "Compilation database" as > the safe sequence and arguments of the compiler invocations for a > package build. What is your opinion for abstracting build systems to the > DB in the same way in Fedora (based on the GCC plugin)? I hadn't heard of that; presumably you're referring to: http://clang.llvm.org/docs/JSONCompilationDatabase.html right? That sounds reminiscent of the "fake-make" program that Steve Grubb wrote and mentioned elsewhere in this thread: http://lists.fedoraproject.org/pipermail/devel/2012-December/175259.html http://people.redhat.com/sgrubb/swa/cwe/index.html As for both (2) and the SA part of (1), they seem to me to be coming at this from a slightly different direction to the one I'm interested in: they're approaching the problem of "I have a static analysis tool that finds bugs in, say C++ code, how do I get it to run on all of Fedora without having to dealing with the bazillion different build invocations, Makefiles, autoconf, cmake, custom scripts etc across all of the packages". As described in my other mail, I think it's possible to reliably run a static analysis tool whilst rebuilding an srpm by hacking up mock to inject the analysis payload, and then harvesting report files from the chroot, as described in: http://lists.fedoraproject.org/pipermail/devel/2012-December/175258.html [search for "nasty nasty hack... but it works" within that post :)]. There's still the messy business of actually doing the rebuilds, of course (I believe we can set up some guest VMs within Fedora's infrastructure for big workloads - massively handwaving here, of course). The problem I'm most interested in is "I've run my tool on lots of packages and it generated lots of results. What do we do with all of these results?" - I want to come up with a better answer than "file lots of bugzillas", since that approach would suck: what happens next time you want to run the tool? (newer version of tool, or newer version of srpm). Note that we're already running an analysis tool on all of the C/C++ tool in Fedora: the compiler. How good is everyone at reading all of the compiler warnings from their builds? (or does everyone use -
Spatialindex changes from LGPLv2 to MIT
Dear list readers! The Spatialindex license changes in version 1.8. It used to be LGPLv2 or later and is MIT from now on. Affected packages are: qgis -- is mine, GPVLv3+ python-Rtree -- LGPLv2 Therefore, no legal issues should arise. Greetings, Volker Fröhlich -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OCaml 4.00.1 for Fedora 18
On Fri, Dec 14, 2012 at 04:36:05PM +0100, Kevin Kofler wrote: > Richard W.M. Jones wrote: > > As discussed, this list isn't quite correct, but it's the best > > I've got at the moment. > > We need to rebuild kdeedu too, it links statically against ocaml-facile. > (And ocaml-facile needs to be in the buildroot overrides for that.) All those packages should be in the buildroot overrides, unless I missed any. Strangely, the command at the end of this email shows only 67 overrides, which can't be right because there are more packages than that. Yet: bodhi --buildroot-override=ocaml-facile-1.1-19.fc18 --duration=50 '--notes=Override ocaml-findlib package to fix RHBZ#877128' Error: buildroot override for ocaml-facile-1.1-19.fc18 already exists So I guess you (or someone) added this already? Rich. -- $ bodhi --my-overrides Password for rjones: 67 Buildroot Overrides submitted by rjones == [ llvm-3.1-12.fc18 ] * Notes: Override ocaml-findlib package to fix RHBZ#877128 * Submitter: rjones * Submitted: 2012-12-14 13:25:12 * Expiration: 2013-02-02 00:00:00 [ graphviz-2.28.0-24.fc18 ] * Notes: Override ocaml-findlib package to fix RHBZ#877128 * Submitter: rjones * Submitted: 2012-12-14 13:20:00 * Expiration: 2013-02-02 00:00:00 [ why3-0.73-3.fc18 ] * Notes: Override ocaml-findlib package to fix RHBZ#877128 * Submitter: rjones * Submitted: 2012-12-14 13:19:33 * Expiration: 2013-02-02 00:00:00 [ cduce-0.5.5-3.fc18 ] * Notes: Override ocaml-findlib package to fix RHBZ#877128 * Submitter: rjones * Submitted: 2012-12-14 13:19:12 * Expiration: 2013-02-02 00:00:00 [ frama-c-1.8-4.fc18 ] * Notes: Override ocaml-findlib package to fix RHBZ#877128 * Submitter: rjones * Submitted: 2012-12-14 13:12:54 * Expiration: 2013-02-02 00:00:00 [ virt-dmesg-0.3.0-6.fc18 ] * Notes: Override ocaml-findlib package to fix RHBZ#877128 * Submitter: rjones * Submitted: 2012-12-14 13:05:33 * Expiration: 2013-02-02 00:00:00 [ virt-top-1.0.8-3.fc18 ] * Notes: Override ocaml-findlib package to fix RHBZ#877128 * Submitter: rjones * Submitted: 2012-12-14 13:05:25 * Expiration: 2013-02-02 00:00:00 [ whenjobs-0.7.3-4.fc18 ] * Notes: Override ocaml-findlib package to fix RHBZ#877128 * Submitter: rjones * Submitted: 2012-12-14 12:58:28 * Expiration: 2013-02-02 00:00:00 [ coccinelle-1.0.0-0.rc14.6.fc18 ] * Notes: Override ocaml-findlib package to fix RHBZ#877128 * Submitter: rjones * Submitted: 2012-12-14 12:54:53 * Expiration: 2013-02-02 00:00:00 [ brltty-4.3-10.fc18 ] * Notes: Override ocaml-findlib package to fix RHBZ#877128 * Submitter: rjones * Submitted: 2012-12-14 12:53:33 * Expiration: 2013-02-02 00:00:00 [ js-of-ocaml-1.2-2.fc18 ] * Notes: Override ocaml-findlib package to fix RHBZ#877128 * Submitter: rjones * Submitted: 2012-12-14 12:53:28 * Expiration: 2013-02-02 00:00:00 [ hivex-1.3.7-2.fc18 ] * Notes: Override ocaml-findlib package to fix RHBZ#877128 * Submitter: rjones * Submitted: 2012-12-14 12:53:25 * Expiration: 2013-02-02 00:00:00 [ ocaml-preludeml-0.1-0.22.20100314.fc18 ] * Notes: Override ocaml-findlib package to fix RHBZ#877128 * Submitter: rjones * Submitted: 2012-12-14 12:30:25 * Expiration: 2013-02-02 00:00:00 [ ocaml-gettext-0.3.4-8.fc18 ] * Notes: Override ocaml-findlib package to fix RHBZ#877128 * Submitter: rjones * Submitted: 2012-12-14 12:30:03 * Expiration: 2013-02-02 00:00:00 [ ocaml-xmlrpc-light-0.6.1-11.fc18 ] * Notes: Override ocaml-findlib package to fix RHBZ#877128 * Submitter: rjones * Submitted: 2012-12-14 12:29:52 * Expiration: 2013-02-02 00:00:00 [ ocaml-pxp-1.2.3-5.fc18 ] * Notes: Override ocaml-findlib package to fix RHBZ#877128 * Submitter: rjones * Submitted: 2012-12-14 12:29:32 * Expiration: 2013-02-02 00:00:00 [ ocaml-json-wheel-1.0.6-10.fc18 ] * Notes: Override ocaml-findlib package to fix RHBZ#877128 * Submitter: rjones * Submitted: 2012-12-14 12:29:24 * Expiration: 2013-02-02 00:00:00 [ ocaml-sexplib-7.0.5-4.fc18 ] * Notes: Override ocaml-findlib package to fix RHBZ#877128 * Submitter: rjones * Submitted: 2012-12-14 11:51:13 * Expiration: 2013-02-02 00:00:00 [ ocaml-pgocaml-1.6-2.fc18 ] * Notes: Override ocaml-findlib package to fix RHBZ#877128 * Submitter: rjones * Submitted: 2012-12-14 11:45:17 * Expiration: 2013-02-02 00:00:00 [ ocaml-lwt-2.4.2-1.fc18 ] * Notes: Override ocaml-findlib package to fix RHBZ#877128 * Submitter: rjones * Submitted: 2012-12-14 11:43:09 * Expiration: 2013-02-02 00:00:00 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Can systemd/PrivateTmp bug 851970 be fixed for F17?
Dne 13.12.2012 22:52, Eric Sandeen napsal(a): I just spent too many hours re-triaging and re-discovering bug 851970, in which systemd + PrivateTmp does weird things with namespaces, thereby making it impossible to unmount filesystems under certain circumstances. 851970 was closed NEXTRELEASE, because: Not exactly. The bug was already closed before I added my comment. Michal - is there any reason why the fix mentioned in comment #5 can't be pulled back? The reason is simple. I do not understand well enough how the filesystem namespace stuff works, so I am afraid of backporting the patches that touch it. You quoted only the beginning of my comment. The unquoted part, which begins with "So in order to fix this bug in F17 ...", is the starting point for anyone who is serious about wanting to help with fixing it. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OCaml 4.00.1 for Fedora 18
Kevin Kofler wrote: > We need to rebuild kdeedu too, it links statically against ocaml-facile. > (And ocaml-facile needs to be in the buildroot overrides for that.) Oops, actually, make that kalzium. kdeedu is now a metapackage, the apps are built separately. I'll take care of it. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OCaml 4.00.1 for Fedora 18
Richard W.M. Jones wrote: > As discussed, this list isn't quite correct, but it's the best > I've got at the moment. We need to rebuild kdeedu too, it links statically against ocaml-facile. (And ocaml-facile needs to be in the buildroot overrides for that.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OCaml 4.00.1 for Fedora 18
Richard W.M. Jones wrote: > It's my understanding that when the update goes out, the build > overrides are automatically expired, which is why I selected a very > long expiry. AIUI, that's actually not the case. But you can expire the stuff manually when it's done. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OCaml 4.00.1 for Fedora 18
On Fri, Dec 14, 2012 at 9:11 AM, Richard W.M. Jones wrote: > On Fri, Dec 14, 2012 at 01:25:40PM +, Richard W.M. Jones wrote: >> > None of the Unison* packages. >> > why > > Now I've done these too, so that's all the packages that I'm aware of. > > The mega-update is: > > https://admin.fedoraproject.org/updates/FEDORA-2012-20337 > > It's marked as [CRITPATH] for some reason. Xen? LLVM? llvm. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OCaml 4.00.1 for Fedora 18
On Fri, Dec 14, 2012 at 01:25:40PM +, Richard W.M. Jones wrote: > > None of the Unison* packages. > > why Now I've done these too, so that's all the packages that I'm aware of. The mega-update is: https://admin.fedoraproject.org/updates/FEDORA-2012-20337 It's marked as [CRITPATH] for some reason. Xen? LLVM? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OCaml 4.00.1 for Fedora 18
On 12/14/2012 06:25 AM, Richard W.M. Jones wrote: FTBFS: plplot-5.9.9-10.svn12202.fc18.src.rpm I'll take a look in a bit. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-18 Branched report: 20121214 changes
Compose started at Fri Dec 14 09:16:03 UTC 2012 Broken deps for x86_64 -- [marble] 1:python-marble-4.9.4-1.fc18.x86_64 requires sip-api(8) >= 0:8.1 [python-fedmsg-meta-fedora-infrastructure] python-fedmsg-meta-fedora-infrastructure-0.0.3-1.fc18.noarch requires fedmsg >= 0:0.6.1 Broken deps for i386 -- [marble] 1:python-marble-4.9.4-1.fc18.i686 requires sip-api(8) >= 0:8.1 [python-fedmsg-meta-fedora-infrastructure] python-fedmsg-meta-fedora-infrastructure-0.0.3-1.fc18.noarch requires fedmsg >= 0:0.6.1 Summary: Added Packages: 0 Removed Packages: 0 Upgraded Packages: 0 Compose finished at Fri Dec 14 13:46:50 UTC 2012 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OCaml 4.00.1 for Fedora 18
As discussed, this list isn't quite correct, but it's the best I've got at the moment. I following are DONE: > ocaml-4.00.0-1.fc18.src.rpm > ocaml-ancient-0.9.0-9.fc18.src.rpm > ocaml-augeas-0.5-2.fc18.src.rpm > ocaml-bin-prot-2.0.9-2.fc18.src.rpm > ocaml-bisect-1.1-3.fc18.src.rpm > ocaml-bitstring-2.0.3-4.fc18.src.rpm > ocaml-cairo-1.2.0-0.7.git08b40192975.fc18.src.rpm > ocaml-calendar-2.03.1-5.fc18.src.rpm > ocaml-camlidl-1.05-16.fc18.src.rpm > ocaml-camlimages-4.0.1-6.fc18.src.rpm > ocaml-camlp5-6.06-4.fc18.src.rpm > ocaml-camomile-0.8.3-9.fc18.src.rpm > ocaml-cil-1.4.0-5.fc18.src.rpm > ocaml-cryptokit-1.6-2.fc18.src.rpm > ocaml-csv-1.1.7-12.fc18.src.rpm > ocaml-curl-0.5.3-6.fc18.src.rpm > ocaml-curses-1.0.3-13.fc18.src.rpm > ocaml-dbus-0.29-5.fc18.src.rpm > ocaml-deriving-0.1.1a-16.fc18.src.rpm > ocaml-expat-0.9.1-23.fc18.src.rpm > ocaml-extlib-1.5.2-4.fc18.src.rpm > ocaml-facile-1.1-18.fc18.src.rpm > ocaml-fileutils-0.4.0-10.fc18.src.rpm > ocaml-findlib-1.3.3-1.fc18.src.rpm > ocaml-gettext-0.3.4-5.fc18.src.rpm > ocaml-gsl-0.6.0-15.fc18.src.rpm > ocaml-json-static-0.9.8-7.fc18.src.rpm > ocaml-json-wheel-1.0.6-9.fc18.src.rpm > ocaml-lablgl-20120306-3.fc18.src.rpm > ocaml-lablgtk-2.14.2-12.fc18.src.rpm > ocaml-lacaml-5.5.2-4.fc18.src.rpm > ocaml-libvirt-0.6.1.2-5.fc18.src.rpm > ocaml-lwt-2.3.2-7.fc18.src.rpm > ocaml-menhir-20120123-4.fc18.src.rpm > ocaml-mikmatch-1.0.6-1.fc18.src.rpm > ocaml-mlgmpidl-1.2-0.5.20120508.fc18.src.rpm > ocaml-mysql-1.1.0-3.fc18.src.rpm > ocaml-newt-0.9-13.fc18.src.rpm > ocaml-ocamlgraph-1.8.2-1.fc18.src.rpm > ocaml-ocamlnet-3.5.1-3.fc18.src.rpm > ocaml-openin-20070524-15.fc18.src.rpm > ocaml-ounit-1.1.2-3.fc18.src.rpm > ocaml-p3l-2.03-11.fc18.src.rpm > ocaml-pa-do-0.8.13-3.fc18.src.rpm > ocaml-pa-monad-6.0-9.fc18.src.rpm > ocaml-pcre-6.2.5-4.fc18.src.rpm > ocaml-perl4caml-0.9.5-22.fc18.src.rpm > ocaml-pgocaml-1.5-2.fc18.src.rpm > ocaml-postgresql-1.18.0-3.fc18.src.rpm > ocaml-preludeml-0.1-0.21.20100314.fc18.src.rpm > ocaml-pxp-1.2.3-4.fc18.src.rpm > ocaml-react-0.9.2-5.fc18.src.rpm > ocaml-reins-0.1a-13.fc18.src.rpm > ocaml-res-3.2.0-9.fc18.src.rpm > ocaml-SDL-0.8.0-6.fc18.src.rpm > ocaml-sexplib-7.0.5-3.fc18.src.rpm > ocaml-sqlite-1.6.3-2.fc18.src.rpm > ocaml-ssl-0.4.6-4.fc18.src.rpm > ocaml-type-conv-3.0.5-2.fc18.src.rpm > ocaml-ulex-1.1-14.fc18.src.rpm > ocaml-xml-light-2.3-0.1.svn234.fc18.src.rpm > ocaml-xmlrpc-light-0.6.1-10.fc18.src.rpm > ocaml-zarith-1.1-2.fc18.src.rpm > ocaml-zip-1.04-9.fc18.src.rpm > alt-ergo-0.94-6.fc18.src.rpm > apron-0.9.10-8.fc18.src.rpm > brltty-4.3-7.fc18.src.rpm > coq-8.4-1.fc18.src.rpm > cduce-0.5.5-2.fc18.src.rpm > coccinelle-1.0.0-0.rc14.5.fc18.src.rpm > frama-c-1.7-9.fc18.src.rpm > gappalib-coq-0.18.0-4.fc18.src.rpm > graphviz-2.28.0-23.fc18.src.rpm > hivex-1.3.7-1.fc18.src.rpm > js-of-ocaml-1.2-1.fc18.src.rpm > llvm-3.1-11.fc18.src.rpm > virt-dmesg > virt-top > whenjobs-0.7.3-1.fc18.src.rpm > why3-0.73-2.fc18.src.rpm > xen-4.2.0-6.fc18.src.rpm > zenon-0.7.1-1.fc18.src.rpm The ones below are NOT done. > None of the Unison* packages. > why-2.31-3.fc18.src.rpm -- waiting for a dependency to finish Both owned by me, I'll fix them later: > libguestfs > guestfs-browser FTBFS: > plplot-5.9.9-10.svn12202.fc18.src.rpm Doesn't contain OCaml code: > emacs-common-tuareg-2.0.4-3.fc18.src.rpm > syntastic-2.3.0-8.20120917git72856e6.fc18.src.rpm Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why is not enabled TapButton of touchpad on Fedora by default?
Il giorno ven, 14/12/2012 alle 09.28 +1000, Peter Hutterer ha scritto: > On Tue, Dec 11, 2012 at 11:26:14PM +, Sérgio Basto wrote: > > On Sex, 2012-09-21 at 01:14 +1000, Peter Hutterer wrote: > > > On Fri, Sep 21, 2012 at 12:48:34AM +1000, Peter Hutterer wrote: > > > > On Wed, Sep 12, 2012 at 04:44:48PM +1000, Ankur Sinha wrote: > > > > > On Tue, 2012-09-11 at 23:16 -0700, Adam Williamson wrote: > > > > > > So instead of /usr/share/X11/xorg.conf.d/50-synaptics.conf you > > > > > > should > > > > > > create /etc/X11/xorg.conf.d/50-synaptics.conf . Other than that, I > > > > > > think > > > > > > the advice is good. > > > > > > > > > > Hi, > > > > > > > > > > Thanks Adam, Onuralp, Alvaro. > > > > > > > > > > I've created a page here[1]. Please review it and correct it if > > > > > required. > > > > > > > > > > [1] https://fedoraproject.org/wiki/How_to_enable_touchpad_click > > > > > > > > For xorg.conf.d snippets, use this section instead: > > > > > > > > Section "InputClass" > > > >Identifier "Enable touchpad tapping" > > > >MatchDriver "synaptics" > > > >Option "TapButton" "1" > > > > EndSection > > > > > > I forgot, this is also described here: > > > https://fedoraproject.org/wiki/Input_device_configuration#Example:_Tap-to-click > > > > Seeing > > cat /etc/X11/xorg.conf.d/00-system-setup-keyboard.conf > > # This file is autogenerated by system-setup-keyboard. Any > > # modifications will be lost. > > this file is deprecated and should've been removed in the F17 cycle by > systemd-localed. if it's still there, you can remove it. /etc/X11/xorg.conf.d/00-system-setup-keyboard.conf is still present in F17, in fact: $ rpm -qf /etc/X11/xorg.conf.d/00-system-setup-keyboard.conf system-setup-keyboard-0.8.8-2.fc17.x86_64 $ rpm -qf /usr/lib/systemd/system/systemd-localed.service systemd-44-21.fc17.x86_64 Nicola -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OCaml 4.00.1 for Fedora 18
On Thu, Dec 13, 2012 at 10:28:41PM -0700, Jerry James wrote: > On Thu, Dec 13, 2012 at 2:38 PM, Richard W.M. Jones wrote: > > Assuming my repoquery command is correct, the full package list is > > below: > > I rebuilt the following members of this list today: > > > alt-ergo-0.94-6.fc18.src.rpm > > apron-0.9.10-8.fc18.src.rpm > > coq-8.4-1.fc18.src.rpm > > gappalib-coq-0.18.0-4.fc18.src.rpm > > ocaml-camlidl-1.05-16.fc18.src.rpm > > ocaml-camlp5-6.06-4.fc18.src.rpm > > ocaml-lablgl-20120306-3.fc18.src.rpm > > ocaml-lablgtk-2.14.2-12.fc18.src.rpm > > ocaml-menhir-20120123-4.fc18.src.rpm > > ocaml-mlgmpidl-1.2-0.5.20120508.fc18.src.rpm > > ocaml-ocamlgraph-1.8.2-1.fc18.src.rpm > > ocaml-zarith-1.1-2.fc18.src.rpm > > zenon-0.7.1-1.fc18.src.rpm I added these ^^^ > csisat-1.2-10.fc18 and this one ^^^ to the update which now seems to have a permanent link here: https://admin.fedoraproject.org/updates/FEDORA-2012-20337 > I create buildroot overrides for all of the packages I rebuilt, > copying your practice of making them not expire until Feb. 1, 2013, so > we don't have some expire before others. It's my understanding that when the update goes out, the build overrides are automatically expired, which is why I selected a very long expiry. Thanks for helping out with this, Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
