rawhide report: 20121213 changes
Compose started at Thu Dec 13 08:15:11 UTC 2012 Broken deps for x86_64 -- [Agda] Agda-2.3.0.1-4.fc19.x86_64 requires ghc(Agda-2.3.0.1-ad754944fc95f11aa3b4710387ff959a) [ansible] ansible-fireball-0.9-1.fc19.noarch requires python-keyczar ansible-node-fireball-0.9-1.fc19.noarch requires python-keyczar [cp2k] cp2k-mpich2-2.3-1.fc19.x86_64 requires libmpichf90.so.3()(64bit) cp2k-mpich2-2.3-1.fc19.x86_64 requires libmpich.so.3()(64bit) [dogtag-pki] dogtag-pki-10.0.0-0.16.b3.fc19.noarch requires dogtag-pki-server-theme = 0:10.0.0 [ember] ember-0.6.3-3.fc19.x86_64 requires libOgreMain.so.1.7.4()(64bit) [epiphany-extensions] epiphany-extensions-3.6.0-1.fc19.x86_64 requires epiphany(abi) = 0:3.6 [freeipa] freeipa-server-3.1.0-1.fc19.x86_64 requires dogtag-pki-server-theme [gcc-python-plugin] gcc-python2-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python2-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 [ghc-wai-extra] ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSzlib-conduit-0.4.0.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSzlib-bindings-0.1.0.1-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSzlib-0.5.3.3-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSwai-1.2.0.3-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSvoid-0.5.6-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSvault-0.2.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSunordered-containers-0.2.1.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSunix-2.5.1.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHStransformers-base-0.4.1-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHStransformers-0.3.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHStime-1.4-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHStext-0.11.2.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSsemigroups-0.8.3.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSresourcet-0.3.2.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSparsec-3.1.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSold-time-1.1.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSold-locale-1.0.0.4-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSnetwork-2.3.0.13-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSmtl-2.1.1-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSmonad-control-0.3.1.3-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSlifted-base-0.1.1-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSinteger-gmp-0.4.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHShttp-types-0.6.11-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHShashable-1.1.2.3-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSghc-prim-0.2.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSfilepath-1.3.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSfast-logger-0.0.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSdlist-0.5-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSdirectory-1.1.0.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSdeepseq-1.3.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSdata-default-0.4.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHScontainers-0.4.2.1-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSconduit-0.4.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHScase-insensitive-0.4.0.1-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSbytestring-0.9.2.1-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSblaze-builder-conduit-0.4.0.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSblaze-builder-0.3.1.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSbase-unicode-symbols-0.2.2.3-ghc7.4.1.so()(64bit)
F-18 Branched report: 20121213 changes
Compose started at Thu Dec 13 09:15:48 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 Removed package: kde-printer-applet-4.9.3-1.fc18 Summary: Added Packages: 0 Removed Packages: 1 Upgraded Packages: 0 Compose finished at Thu Dec 13 13:24:04 UTC 2012 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
What is the difficult on adding a file to yum.repo.d ? It is designed for that. Each initial page for an aditional repo would have instructions on how to activate it and provide a repo file to copy from. - Original Message - From: Richard W.M. Jones rjo...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Tuesday, December 11, 2012 4:42:39 PM Subject: Re: What would it take to make Software Collections work in Fedora? On Tue, Dec 11, 2012 at 03:18:42PM -0500, Fernando Nasser wrote: From: Richard W.M. Jones rjo...@redhat.com So let's say the user has to add the OCaml repo themselves. That's difficult for the user because lots of tools like yum search no longer work well. Really? If I add several yum repos in my tum.repo.d the yum subcommands operate over all those repos, son't they? I am surprised by this statement. Obviously I mean that yum search and many other commands don't work until and unless the user knows (how?) what repo to add. That means that you have to add the external repos for the user, or advertise them, which are incompatible as I explained. Did I overlook anything here? Lots. 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Tue, Dec 11, 2012 at 07:33:13PM +, Richard W.M. Jones wrote: What I'm confused about is how this would work in terms of Fedora policy (not in terms of the software). Yes, that's important to cover too. Let's say that we decided that OCaml was non-core. It would be in a collection, and there'd be an OCaml repo, OCaml maintainer team, OCaml packaging policy and so on. I think that there are significant advantages into having these teams be under the Fedora umbrella, even if their collection is not part of core. In order to be included, collections would agree to certain rules, including an overall packaging policy. It may be that we'd have a menu of options for maintenance lifetime and etc., or we might leave that up to each SIG as long as they make it clear. If a particular group wanted to go beyond what we set as the rules for software collections in the distribution as a whole, they'd do it as an indpeendent project. Should Fedora add this repo automatically to make it easier to pull in packages? If it does that, then OCaml is really part of Fedora as far as I can see, pretty much the same as now but a bit more awkward. Maybe more awkward, but hopefully the tools could be improved so that's not the case. If it's pretty much the same but offers the advantages of decoupling the base from stack versions, that sounds great to me. What happens if the OCaml team goes rogue and starts adding non-free packages? Could Fedora be accused of contributory infringement for The same as now. If the group wants to be part of Fedora, they follow the Fedora rules. even pointing to the location of this repo? Again, if Fedora accepts detailed oversight over what goes into these external repos, then AFAICS they might as well just be in Fedora in the first place. Yes. What happens if a core program needs an OCaml program to build? Or needs to Require on one? Or (in Debian terms) could be enhanced by one? I guess this means that everything in Fedora New Core would need to be written in C and perhaps Python, and can only depend on a handful of features, and that's rather limiting for everyone. We can have system ocaml. I see this as particularly useful for, say, increased dependence on ruby-based config systems like Puppet. The system stack would be the version needed to make that work, and we wouldn't need to worry about the implications for users of the same software stack for non-system programs -- that is, developers and users building on Fedora. Same applies to Python and whatever else. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
anaconda and btrfs
I have submitted an RFE bugzilla report asking for improvements in how anaconda deals with btrfs: https://bugzilla.redhat.com/show_bug.cgi?id=886691 There have been promises (threats?) to make btrfs the default starting with (IIRC) Fedora 16, then 17, and again 18. In each case it did not happen and I believe that was good. Nevertheless, btrfs has a great deal of promise and should become the default for Fedora ... just not yet. However, if btrfs is ever going to be the default, there needs to be a lot more experience and testing of it. Currently, is a start out with a blank slate and allocate a btrfs subvolume for root and perhaps /home, that works. Similarly, in kickstart, if I use a freshly formatted btrfs volume and define the pool plus some subvolumes with mount points (again / and /home), this works. What does not work is to try and use a new subvolume allocated into an predefined btrfs volume/storage-pool. This also does not work in kickstart (or, at least, I have not figured out how to do it). The major problem is the subvolume for root (/) which needs to be in the equivalent state that a reformatted standard partition or LV work be ... and this is reasonable. Now, I can reuse a previously defined /home and I suspect I could fake it for anaconda by defining an bunch of subvolumes for /usr, /var/ /etc, etc. and put / in a small standard partition but the purpose is not to fake things but to get things done. What I want: 1. In the gui, be able to allocate a new subvolume for root in an existing btrfs storage pool. 2. In kickstart, I want to be able to create a new subvolume for root in an existing btrfs storage pool. Note, I said nothing about making btrfs the default. I just want the capability to use it and I would expect it to be used in the future. I believe that the above two things must be done sooner rather than later if there is any future for btrfs in Fedora. Whether you believe I am right or wrong, please chime in with your comments here and in bugzilla. If you have other suggestions, these are welcome also. Maybe if there is enough interest, something will happen. Gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: For Fedora vs. In Fedora [Was: What would it take to make Software Collections work in Fedora?]
Good. Then we should use this model more frequently. And in these third party repos, Software Collections could be used by them to avoid conflicts with base, allow installations of multiple of their versions etc. So, SC _for_ Fedora as opposed as _in_ Fedora. --Fernando - Original Message - From: Emmanuel Seyman emman...@seyman.fr To: devel@lists.fedoraproject.org Sent: Tuesday, December 11, 2012 6:23:36 PM Subject: Re: For Fedora vs. In Fedora [Was: What would it take to make Software Collections work in Fedora?] * Fernando Nasser [11/12/2012 23:05] : As we have EPEL _for_ RHEL we can have things _for_ Fedora as opposed to _in_ Fedora. It is how several VARs do with their software _for_ RHEL in the Red Hat world. We already have third party repositories for Fedora. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 884354] perl: possible arbitrary code execution via Locale::Maketext
Product: Security Response https://bugzilla.redhat.com/show_bug.cgi?id=884354 Stefan Cornelius scorn...@redhat.com changed: What|Removed |Added Flags|needinfo?(vda...@redhat.com | |) | -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=oUW1pMHU7Ya=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
OCaml 4.00.1 for Fedora 18
Unfortunately we found a bug in the code generator: https://bugzilla.redhat.com/show_bug.cgi?id=877128 It seems likely (comment 20) that a patch which already went into OCaml 4.00.1 upstream some months ago fixes this. However it requires that every OCaml package be rebuilt in Fedora 18 (since all of them potentially are using the invalid register). This isn't ideal, but I can't see any other way around it. I'm going to start this process, where possible just merging commits from Rawhide to keep the git history nice and clean. 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: MariaDB: Packagers needed
On 10/29/2012 04:36 AM, Sven Lankes wrote: On Sun, Oct 28, 2012 at 11:31:25PM +0100, Kevin Kofler wrote: Uh, conflicting with MySQL is really a no go (just look at how many things require mysql-libs, and even mysql-server is required for Akonadi, and mysql-embedded or Amarok), why isn't the fork renaming its stuff? If the idea is to be a 100% compatible drop-in replacement, then Fedora needs to make a choice whether to ship Oracle's MySQL or MariaDB and then stick to it. That may be the outcome of all of this. But that still means that we need MariaDB packaged first. On the one hand we could first prepare mariadb package (package review is frozen for a while, but I'll try to push that forward soon), but on the other hand we should know how we want to ship it -- and package it according to that. This is why I'd like to refresh this topic, which froze too in a state with no resolution (at least I haven't noticed any). What I'd like to achieve is to collect real risks (or pros cons) of all possible solutions. Right now I see these options: 1. continue shipping only mysql 2. ship mysql + mariadb, that would conflict 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 6. is there any other? The following are notes I tried to summarized mainly from the thread started at http://lists.fedoraproject.org/pipermail/devel/2012-October/173089.html (+ some of my POVs) ad 1. continue shipping only mysql: PROS: * Admins would be happy (unless they care about early security updates, fixes and regression tests -- so probably not happy that much) CONS: * No early (not only) security fixes * No new regression tests * It doesn't seem to me mysql upstream will ever become more open, the opposite is much more probable. NOTE: Considering just changes made by Oracle during the last year made on mysql project I'd say we should only think about *how* and *when* switching to an alternative, not *if* anymore. ad 2. ship mysql + mariadb, that would conflict: PROS: * Probably the easiest way to do at least in the beginning. CONS: * It would require twice much work to maintain two packages. * What message would we send to users - that we don't know what we want? * In a long term it doesn't look sustainable. NOTE: It could be used in a transient period, e.g. during one release. ad 3. ship mysql + mariadb with adjusted file-names and using alternatives PROS: * To give an option to admins? I'm not really sure if this is even good. CONS: * cons from 2. apply here * I don't think this is actually possible. Alternatives work fine with commands, but I haven't seen a usage of this tool for libraries and directories. * That would also require 100% API/ABI compatibility of libraries, which we can't depend on. 4. ship mysql + mariadb with adjusted file-names but not using alternatives PROS: * We could provide both packages at the same time without conflicts CONS: * cons from 2. apply here * We don't want to differ from upstream * What package depended packages would be built against? ad 5: drop mysql and ship only mariadb PROS: * We'll provide a package with active and open upstream, that cares about (not only) security bugs... * Some enhancements in comparison to mysql CONS: * Transition could be harder, we would have to take this like a rebase (we probably can't depend on 100% API/ABI compatibility). * Admins would have to migrate. NOTES: Similar will happen soon or later (at a time of rebasing to mysql-5.6). Right now my favorite one. So what have I said wrong/omitted? Regards, Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Heads up: glew 1.9.0 coming to F19
This, like all GLEW updates, is a soname break. I'll kick rebuilds for
dependent packages, which are:
% repoquery --whatrequires --qf=%{sourcerpm} libGLEW libGLEWmx | sort -u
amanith-0.3-22.fc18.src.rpm
avogadro-1.0.3-12.fc18.1.src.rpm
bino-1.4.1-2.fc18.src.rpm
blender-2.64a-3.fc18.src.rpm
bzflag-2.4.2-1.fc18.src.rpm
calligra-2.5.3-1.fc18.src.rpm
cegui06-0.6.2-12.fc18.src.rpm
cegui-0.7.6-8.fc18.src.rpm
enblend-4.0-15.fc18.src.rpm
FlightGear-Atlas-0.4.9-0.4.cvs20120911.fc18.src.rpm
freewrl-1.22.13.1-3.fc18.src.rpm
frogatto-1.2-4.fc18.src.rpm
gambas3-3.3.3-1.fc18.src.rpm
gambas3-3.3.4-2.fc18.src.rpm
glew-1.7.0-3.fc18.src.rpm
gource-0.38-1.fc18.src.rpm
hugin-2012.0.0-1.fc18.src.rpm
kalzium-4.9.4-1.fc18.src.rpm
libprojectM-2.0.1-17.fc18.src.rpm
lightspark-0.7.0-1.fc18.1.src.rpm
maniadrive-1.2-49.fc18.src.rpm
megaglest-3.7.1-1.fc18.src.rpm
mesa-demos-7.10-8.20101028.fc18.src.rpm
meshlab-1.3.1-7.fc18.src.rpm
opencsg-1.3.2-6.fc18.src.rpm
OpenImageIO-1.0.9-1.fc18.src.rpm
openmsx-0.9.0-1.fc18.src.rpm
openscad-2012.10.31-5.fc18.src.rpm
pymol-1.5.0.2-5.20120218svn3982.fc18.src.rpm
quesoglc-0.7.2-5.fc18.src.rpm
root-5.34.02-1.fc18.src.rpm
rss-glx-0.9.1.p-13.fc18.src.rpm
scorched3d-43.3d-3.fc18.src.rpm
sdljava-0.9.1-19.fc18.src.rpm
SFML-1.6-7.fc18.src.rpm
spring-91.0-1.fc18.src.rpm
supertux-0.3.3-9.fc18.src.rpm
toped-0.9.81-1.svn2211.fc18.src.rpm
vdrift-20120722-1.fc18.src.rpm
warzone2100-3.1-0.10.rc3.fc18.src.rpm
widelands-0-0.33.build17.fc18.src.rpm
wxmacmolplt-7.4.1-7.fc18.src.rpm
xbmc-12.0-0.2.Frodo_alpha6.fc18.src.rpm
- ajax
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OCaml 4.00.1 for Fedora 18
On Thu, 13 Dec 2012 16:16:12 + Richard W.M. Jones rjo...@redhat.com wrote: Unfortunately we found a bug in the code generator: https://bugzilla.redhat.com/show_bug.cgi?id=877128 It seems likely (comment 20) that a patch which already went into OCaml 4.00.1 upstream some months ago fixes this. However it requires that every OCaml package be rebuilt in Fedora 18 (since all of them potentially are using the invalid register). This isn't ideal, but I can't see any other way around it. I'm going to start this process, where possible just merging commits from Rawhide to keep the git history nice and clean. Nasty. ;( Would it be possible for you (or someone) to coordinate and put all these builds into one update? That way we could see about pulling them all in as a NTH before release. If they are a bunch of scattered updates it could be much harder to make sure we don't miss any. Also, someone would need to nominate this bug for that process: http://fedoraproject.org/wiki/QA:SOP_nth_bug_process#Proposing_nice-to-have_bugs kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MariaDB: Packagers needed
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? Remi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Thu, Dec 13, 2012 at 10:06 AM, Fernando Nasser fnas...@redhat.comwrote: What is the difficult on adding a file to yum.repo.d ? It is designed for that. Each initial page for an aditional repo would have instructions on how to activate it and provide a repo file to copy from. The difficulty is that, currently, in Fedora and indeed most other modern distributions, if I want to install a piece of software, I don't want to have to Google the software, find the Fedora repository for that software, add the repo file, and then use yum to install it. I want to be able to use yum to install the software directly. Of course if this fails I'll look around on the internet for unofficial RPMs or repositories, but the point is that it's a huge inconvenience to the user to make them have to do this when, at present, they don't need to. It's not a difficulty so much as a bad or annoying design decision from an end-user standpoint. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: glew 1.9.0 coming to F19
Hi,
I am new to this, so now I really don't know, what steps should I make.
After the rebuild, openscad package is no longer working, it seems it
requires libGLEW.so.1.7 as it was builded agains this version, but
nothing provides it, is that right?
http://koji.fedoraproject.org/koji/taskinfo?taskID=4787523
Error: Package: opencsg-1.3.2-6.fc19.i686 (build)
Requires: libGLEW.so.1.7
Is that something I should fix?
Thanks,
Miro Hrončok
Jabber: m...@hroncok.cz
Telefon: +420777974800
2012/12/13 Adam Jackson a...@redhat.com:
This, like all GLEW updates, is a soname break. I'll kick rebuilds for
dependent packages, which are:
% repoquery --whatrequires --qf=%{sourcerpm} libGLEW libGLEWmx | sort -u
amanith-0.3-22.fc18.src.rpm
avogadro-1.0.3-12.fc18.1.src.rpm
bino-1.4.1-2.fc18.src.rpm
blender-2.64a-3.fc18.src.rpm
bzflag-2.4.2-1.fc18.src.rpm
calligra-2.5.3-1.fc18.src.rpm
cegui06-0.6.2-12.fc18.src.rpm
cegui-0.7.6-8.fc18.src.rpm
enblend-4.0-15.fc18.src.rpm
FlightGear-Atlas-0.4.9-0.4.cvs20120911.fc18.src.rpm
freewrl-1.22.13.1-3.fc18.src.rpm
frogatto-1.2-4.fc18.src.rpm
gambas3-3.3.3-1.fc18.src.rpm
gambas3-3.3.4-2.fc18.src.rpm
glew-1.7.0-3.fc18.src.rpm
gource-0.38-1.fc18.src.rpm
hugin-2012.0.0-1.fc18.src.rpm
kalzium-4.9.4-1.fc18.src.rpm
libprojectM-2.0.1-17.fc18.src.rpm
lightspark-0.7.0-1.fc18.1.src.rpm
maniadrive-1.2-49.fc18.src.rpm
megaglest-3.7.1-1.fc18.src.rpm
mesa-demos-7.10-8.20101028.fc18.src.rpm
meshlab-1.3.1-7.fc18.src.rpm
opencsg-1.3.2-6.fc18.src.rpm
OpenImageIO-1.0.9-1.fc18.src.rpm
openmsx-0.9.0-1.fc18.src.rpm
openscad-2012.10.31-5.fc18.src.rpm
pymol-1.5.0.2-5.20120218svn3982.fc18.src.rpm
quesoglc-0.7.2-5.fc18.src.rpm
root-5.34.02-1.fc18.src.rpm
rss-glx-0.9.1.p-13.fc18.src.rpm
scorched3d-43.3d-3.fc18.src.rpm
sdljava-0.9.1-19.fc18.src.rpm
SFML-1.6-7.fc18.src.rpm
spring-91.0-1.fc18.src.rpm
supertux-0.3.3-9.fc18.src.rpm
toped-0.9.81-1.svn2211.fc18.src.rpm
vdrift-20120722-1.fc18.src.rpm
warzone2100-3.1-0.10.rc3.fc18.src.rpm
widelands-0-0.33.build17.fc18.src.rpm
wxmacmolplt-7.4.1-7.fc18.src.rpm
xbmc-12.0-0.2.Frodo_alpha6.fc18.src.rpm
- ajax
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Dealing with static code analysis in Fedora
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 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) 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)? 3) As I said already, IMHO, this thread is the most practically important topic in Fedora. What about SIG/Team? I think base of 8-10 high experienced part-time contributors will be enough for your spec and 1)-like enhancements. Kind Regards, Alek P.S. Fedora infrastructure resources are mandatory for the final Fedora repos cooking, but I think that the community is able to provide less secure, but much more in volume resources for the analysis workers (Fedora can just supply small enslaving script for the dedicated VM) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: glew 1.9.0 coming to F19
On Thu, Dec 13, 2012 at 08:19:57PM +0100, Miro Hrončok wrote: After the rebuild, openscad package is no longer working, it seems it requires libGLEW.so.1.7 as it was builded agains this version, but nothing provides it, is that right? http://koji.fedoraproject.org/koji/taskinfo?taskID=4787523 Error: Package: opencsg-1.3.2-6.fc19.i686 (build) Requires: libGLEW.so.1.7 If you are a provenpackage, you may rebuidl the opencsg package to fix this issue. If not you should contact the owner of this package for rebuild. Best Regards: Jochen Schmitt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: glew 1.9.0 coming to F19
On Thu, Dec 13, 2012 at 08:19:57PM +0100, Miro Hrončok wrote Hi, I am new to this, so now I really don't know, what steps should I make. After the rebuild, openscad package is no longer working, it seems it requires libGLEW.so.1.7 as it was builded agains this version, but nothing provides it, is that right? http://koji.fedoraproject.org/koji/taskinfo?taskID=4787523 Error: Package: opencsg-1.3.2-6.fc19.i686 (build) Requires: libGLEW.so.1.7 you can simply resubmit the build request. the issue was, that the last build has fetch opencsq-1.3.2-6 which was bult agains glew-devel-1.7.0. But now opencsq-1.3.2-7 which is built agains the new glew-devel-1.9.0 is visible on koji. Best Regards: Jochen Schmitt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg-turbo API/ABI bump in F19 (transition from jpeg6 to jpeg8 API/ABI)
On 10/18/2012 07:13 AM, Adam Tkac wrote: Hello all, I've just created https://fedoraproject.org/wiki/Features/libjpeg-turbo-jpeg8-ABI page which contains plan how to successfully move from current jpeg6 API/ABI to more recent jpeg8 API/ABI for Fedora 19. All packages which depends on libjpeg.so will have to be rebuilt. Since I have provenpackager privileges, I will cook some script which will rebuild all pkgs automatically so no action will be required from maintainers. If there are no objections against this approach, I will start with this task next week. Regards, Adam BR of libjpeg-devel now pulls in libjpeg-turbo-compat-devel, but this doesn't really work as a drop in replacement because those headers are in /usr/include/libjpeg-turbo-compat/. Shouldn't libjpeb-turbo-devel provide libjpeg-devel and not libjpeg-turbo-compat-devel? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- 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 11:20:33AM -0700, Kevin Fenzi wrote: On Thu, 13 Dec 2012 16:16:12 + Richard W.M. Jones rjo...@redhat.com wrote: Unfortunately we found a bug in the code generator: https://bugzilla.redhat.com/show_bug.cgi?id=877128 It seems likely (comment 20) that a patch which already went into OCaml 4.00.1 upstream some months ago fixes this. However it requires that every OCaml package be rebuilt in Fedora 18 (since all of them potentially are using the invalid register). This isn't ideal, but I can't see any other way around it. I'm going to start this process, where possible just merging commits from Rawhide to keep the git history nice and clean. Nasty. ;( Would it be possible for you (or someone) to coordinate and put all these builds into one update? Yes, I'll add them all to this update: https://admin.fedoraproject.org/updates/ocaml-findlib-1.3.3-3.fc18,ocaml-4.00.1-1.fc18 (that link will probably go stale unfortunately ...) There will probably be about 70-80 packages in all. I'm planning to do the others tomorrow. That way we could see about pulling them all in as a NTH before release. If they are a bunch of scattered updates it could be much harder to make sure we don't miss any. Also, someone would need to nominate this bug for that process: http://fedoraproject.org/wiki/QA:SOP_nth_bug_process#Proposing_nice-to-have_bugs I think I've done it right? https://bugzilla.redhat.com/show_bug.cgi?id=877128 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg-turbo API/ABI bump in F19 (transition from jpeg6 to jpeg8 API/ABI)
On Thu, Dec 13, 2012 at 2:08 PM, Orion Poplawski or...@cora.nwra.com wrote: BR of libjpeg-devel now pulls in libjpeg-turbo-compat-devel, but this doesn't really work as a drop in replacement because those headers are in /usr/include/libjpeg-turbo-compat/. Shouldn't libjpeb-turbo-devel provide libjpeg-devel and not libjpeg-turbo-compat-devel? For xbmc I ended up switching the BR to libjpeg-turbo-devel. This works on all supported Fedora releases, and I conditionalized it with a disttag for EPEL. - Ken -- 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 09:19:54PM +, Richard W.M. Jones wrote: https://admin.fedoraproject.org/updates/ocaml-findlib-1.3.3-3.fc18,ocaml-4.00.1-1.fc18 (that link will probably go stale unfortunately ...) Indeed. For now it is: https://admin.fedoraproject.org/updates/ocaml-camlidl-1.05-17.fc18,ocaml-findlib-1.3.3-3.fc18,ocaml-4.00.1-1.fc18 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: [rawhide] (was Re: Where are we going? (Not a rant))
On Sun, Dec 9, 2012 at 6:21 PM, M. Edward (Ed) Borasky zn...@znmeb.net wrote: On Sun, Dec 9, 2012 at 4:16 PM, Michael Scherer m...@zarb.org wrote: Le dimanche 09 décembre 2012 à 15:18 -0800, M. Edward (Ed) Borasky a écrit : There's no way I can run my laptop on Rawhide - it's dual-booted with Windows 8 Pro and Fedora 18. But I do have an ancient crash-and-burn workstation I can run Rawhide on. It's currently dual-booted Fedora 18 and Linux Mint 14, but I rarely run the Mint part and I could easily convert that partition to Rawhide or even blow away Fedora 18 and Mint in favor of Rawhide. What about doing a triple boot, if you share swap and /home, you can get enough space to install a 3rd distro, no ? It's not worth the effort - the machine is the first dual-core Athlon ever built, the USB ports are either dead or 1.1, the NVidia card is mucked up and it only has 4 GB of RAM. I do most of my testing in VMs on the 8 GB laptop under virt-manager on Fedora or VirtualBox and VMware Workstation on Windows. I've also got the Client Hyper-V feature of Windows 8 Pro on the laptop but it needs a wired network to function coherently. I'll probably haul the workstation down to FreeGeek and just make the laptop my workstation. Rawhide's fine in a VM. ;-) -- Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/ How the Hell can the lion sleep with all those people singing A weem oh way! at the top of their lungs? Update - I have said ancient creaky workstation dual-booted Fedora 18 Beta and Rawhide and the Rawhide partition is now stable. There were two show-stoppers on the Rawhide piece - some kind of bizarre X.org / nouveau issue that was locking the machine up when I opened Firefox, and a missing dependency for LibreOffice. Those have gone away and I can now use the machine in Rawhide. I'll probably switch to Firefox beta and put in the Chrome beta as well, since I spend a lot of time in the browser. Might as well live on the edge. ;-) -- Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/ How the Hell can the lion sleep with all those people singing A weem oh way! at the top of their lungs? -- 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 09:19:54PM +, Richard W.M. Jones wrote: There will probably be about 70-80 packages in all. I'm planning to do the others tomorrow. Assuming my repoquery command is correct, the full package list is below: $ repoquery -s --alldeps --recursive --whatrequires ocaml '*.src' | sort -u alt-ergo-0.94-6.fc18.src.rpm apron-0.9.10-8.fc18.src.rpm brltty-4.3-7.fc18.src.rpm cduce-0.5.5-2.fc18.src.rpm coccinelle-1.0.0-0.rc14.5.fc18.src.rpm coq-8.4-1.fc18.src.rpm emacs-common-tuareg-2.0.4-3.fc18.src.rpm flocq-2.1.0-2.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 guestfs-browser-0.2.1-5.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 ocaml-4.00.0-1.fc18.src.rpm # done 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 # done 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 # done 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 plplot-5.9.9-10.svn12202.fc18.src.rpm syntastic-2.3.0-8.20120917git72856e6.fc18.src.rpm whenjobs-0.7.3-1.fc18.src.rpm why-2.31-3.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 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
Compiling my suggestions made in this list
Hi, 1 - Here: https://fedoraproject.org/wiki/Input_device_configuration#system-setup-keyboard we need update this because: Command system-setup-keyboard is not present in F18, now we got localectl set-x11-keymap. And need review system-config-keyboard ? 2 - as wrote and suggest in other email, that I agree is overwrite /etc/sysconfig/keyboard with following content: # This file is obsolete and may be removed, its settings # were migrated on date by running: # localectl set-x11-keymap 3 - 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. I remembered that Fedora also could make system-config-synaptics like others system-configs to configure enable and disable Tap of synaptics and create/manage /etc/X11/xorg.conf.d/01-touchpad.conf 4 -The wiki page Upgrading_Fedora_using_yum have instructions that we should know and do, in every type of upgrade . https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#3._Clean_Stuff we should do this in any case . 5 - https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#6._Preparing_for_reboot this link in others method of upgrades should be mention in case of boot fails. Also misses (I think), how prepare a bootable rescue mode in case of grub install fails. I wrote sometime ago : http://www.serjux.com/freedos_boot/Create-a-bootable-rescue.txt 6 - Other thing, that could be not ready for F18 release date, but is important, in my point of view, is Fedup be able to upgrade F16 to F18 . 7 - Fedup correctly writes: package foo needs 100M etc But at the end don't explain that transaction fails because need more free space on disk before upgrade Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OCaml 4.00.1 for Fedora 18
On Thu, 13 Dec 2012 21:38:26 + Richard W.M. Jones rjo...@redhat.com wrote: On Thu, Dec 13, 2012 at 09:19:54PM +, Richard W.M. Jones wrote: There will probably be about 70-80 packages in all. I'm planning to do the others tomorrow. Assuming my repoquery command is correct, the full package list is below: $ repoquery -s --alldeps --recursive --whatrequires ocaml '*.src' | .. Well, you're missing e.g. Unison, which lead to the discovery of the whole bug. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Can systemd/PrivateTmp bug 851970 be fixed for F17?
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: 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. Ok, so, Lennart? Our current Fedora has a borken systemd. Can you please help fix it? If not, I'd propose removing PrivateTmp=true from all F17 services as a workaround, and/or ignoring it in systemd so this doesn't crop up again. Thanks, -Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg-turbo API/ABI bump in F19 (transition from jpeg6 to jpeg8 API/ABI)
Orion Poplawski or...@cora.nwra.com writes: BR of libjpeg-devel now pulls in libjpeg-turbo-compat-devel, but this doesn't really work as a drop in replacement because those headers are in /usr/include/libjpeg-turbo-compat/. Yeah, I just whinged about that at bz #887013. Shouldn't libjpeb-turbo-devel provide libjpeg-devel and not libjpeg-turbo-compat-devel? Only if jpeg8 is a drop-in (source code compatible) replacement. Otherwise you're only moving the point at which failures will occur. 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 Thu, 2012-12-13 at 16:16 +, Richard W.M. Jones wrote: Unfortunately we found a bug in the code generator: https://bugzilla.redhat.com/show_bug.cgi?id=877128 It seems likely (comment 20) that a patch which already went into OCaml 4.00.1 upstream some months ago fixes this. However it requires that every OCaml package be rebuilt in Fedora 18 (since all of them potentially are using the invalid register). This isn't ideal, but I can't see any other way around it. I'm going to start this process, where possible just merging commits from Rawhide to keep the git history nice and clean. Please, in doing rebuilds, go for the *minimal possible* change from the package currently in *stable* for F18. If any of the packages have bumped significantly in updates-testing - especially critpath packages - this could be a problem and we might want to look at rolling back somehow. Please don't merge down any changes that don't absolutely need to be in F18. We're past freeze at this point and should be aiming for minimal change. If we need to rebuild we need to rebuild, but I'll be checking certainly all the 'sensitive' packages in this set to ensure they have absolute minimal possible changes. Please co-ordinate with QA and releng if you see any packages where we may need to do some special handling. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- 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 11:50:21PM +0200, Susi Lehtola wrote: On Thu, 13 Dec 2012 21:38:26 + Richard W.M. Jones rjo...@redhat.com wrote: On Thu, Dec 13, 2012 at 09:19:54PM +, Richard W.M. Jones wrote: There will probably be about 70-80 packages in all. I'm planning to do the others tomorrow. Assuming my repoquery command is correct, the full package list is below: $ repoquery -s --alldeps --recursive --whatrequires ocaml '*.src' | .. Well, you're missing e.g. Unison, which lead to the discovery of the whole bug. Also libguestfs is missing, even though it directly BuildRequires: ocaml So the repoquery command is wrong. The version in the man page gives no output at all. Other variants that I found online list a mysterious selection of about 10 packages. The one above was the result of me messing around until I got something that looked about right at the time. 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: OCaml 4.00.1 for Fedora 18
On Thu, Dec 13, 2012 at 01:58:41PM -0800, Adam Williamson wrote: On Thu, 2012-12-13 at 16:16 +, Richard W.M. Jones wrote: Unfortunately we found a bug in the code generator: https://bugzilla.redhat.com/show_bug.cgi?id=877128 It seems likely (comment 20) that a patch which already went into OCaml 4.00.1 upstream some months ago fixes this. However it requires that every OCaml package be rebuilt in Fedora 18 (since all of them potentially are using the invalid register). This isn't ideal, but I can't see any other way around it. I'm going to start this process, where possible just merging commits from Rawhide to keep the git history nice and clean. Please, in doing rebuilds, go for the *minimal possible* change from the package currently in *stable* for F18. If any of the packages have bumped significantly in updates-testing - especially critpath packages - this could be a problem and we might want to look at rolling back somehow. Please don't merge down any changes that don't absolutely need to be in F18. We're past freeze at this point and should be aiming for minimal change. If we need to rebuild we need to rebuild, but I'll be checking certainly all the 'sensitive' packages in this set to ensure they have absolute minimal possible changes. Please co-ordinate with QA and releng if you see any packages where we may need to do some special handling. Thanks! I don't think any of the packages are going to be an issue. None of them are critical path packages or anything especially important, except possible llvm. I did initially look at backporting just the single compiler patch[1]. However since it quickly became obvious that it was a change to the register allocator, it was clear that everything that had been built from that needed to be recompiled. Oh well .. Rich. [1] https://bugzilla.redhat.com/attachment.cgi?id=663037 -- 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: OCaml 4.00.1 for Fedora 18
On Thu, 2012-12-13 at 22:03 +, Richard W.M. Jones wrote: I don't think any of the packages are going to be an issue. None of them are critical path packages or anything especially important, except possible llvm. Also xen. We have a release criterion relating to it. Maybe not critpath by the critpath definition, but it does have the potential to affect our release-ability. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: glew 1.9.0 coming to F19
I see, thanks. Miro Hrončok Jabber: m...@hroncok.cz Telefon: +420777974800 2012/12/13 Jochen Schmitt joc...@herr-schmitt.de: On Thu, Dec 13, 2012 at 08:19:57PM +0100, Miro Hrončok wrote Hi, I am new to this, so now I really don't know, what steps should I make. After the rebuild, openscad package is no longer working, it seems it requires libGLEW.so.1.7 as it was builded agains this version, but nothing provides it, is that right? http://koji.fedoraproject.org/koji/taskinfo?taskID=4787523 Error: Package: opencsg-1.3.2-6.fc19.i686 (build) Requires: libGLEW.so.1.7 you can simply resubmit the build request. the issue was, that the last build has fetch opencsq-1.3.2-6 which was bult agains glew-devel-1.7.0. But now opencsq-1.3.2-7 which is built agains the new glew-devel-1.9.0 is visible on koji. Best Regards: Jochen Schmitt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- 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?
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. I remembered that Fedora also could make system-config-synaptics like others system-configs . touchpad settings are generally quite user-specific. while IMO it's reasonable to have a system-wide default keyboard layout that is non-US we don't need the same for synaptics. the driver will come up with defaults and the touchpad will be usable. for real configuration (e.g. scroll methods) the desktop environment should provide a way to configure it on a per-user basis. and command system-setup-keyboard is not present in F18, we got localectl set-x11-keymap [1]. https://fedoraproject.org/wiki/Input_device_configuration . updated, thanks. And system-config-keyboard ? [1] as wrote in other email: 3. Overwrite /etc/sysconfig/keyboard with following content: # This file is obsolete and may be removed, its settings # were migrated on date by running: # localectl set-x11-keymap this is something you should probably file a systemd bug for. Cheers, Peter Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- 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 02:43:23PM -0800, Adam Williamson wrote: On Thu, 2012-12-13 at 22:03 +, Richard W.M. Jones wrote: I don't think any of the packages are going to be an issue. None of them are critical path packages or anything especially important, except possible llvm. Also xen. We have a release criterion relating to it. Maybe not critpath by the critpath definition, but it does have the potential to affect our release-ability. Ah yes, Xen. I have just done a bumpspec, merging the same commit back to F18, and building only in F18. Apart from the changed 'Release' tag in the spec file, it's just a rebuild ... http://koji.fedoraproject.org/koji/taskinfo?taskID=4788176 Update will be added to the growing list at: https://admin.fedoraproject.org/updates/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 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub2-tools and UEFI/GPT
It sounds like your entry in your UEFI boot manager was erased. Did you perform a UEFI update or clear it? To fix it in the future run efibootmgr -c to reinsert the entry. Aaaah. Thanks for pointing me at efibootmgr. -benjamin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: glew 1.9.0 coming to F19
Current state: freewrl-1.22.13.1-3.fc18.src.rpm Failed to rebuild, but not my fault: world_script/JScript.c: In function 'JSCreateScriptContext': world_script/JScript.c:407:3: warning: implicit declaration of function 'JS_NewCompartmentAndGlobalObject' [-Wimplicit-function-declaration] world_script/JScript.c:407:14: warning: assignment makes pointer from integer without a cast [enabled by default] world_script/JScript.c:410:3: error: too few arguments to function 'JS_NewGlobalObject' spring-91.0-1.fc18.src.rpm Failed to build, but not my fault: /lib64/libIrrXML.so.1: undefined reference to `irr::core::LOCALE_DECIMAL_POINTS' collect2: error: ld returned 1 exit status make[2]: *** [spring-multithreaded] Error 1 make[2]: Leaving directory `/builddir/build/BUILD/spring_91.0' make[1]: *** [rts/builds/multithreaded/CMakeFiles/engine-multithreaded.dir/all] Error 2 make[1]: Leaving directory `/builddir/build/BUILD/spring_91.0' make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.B4jcdz (%build) RPM build errors: bogus date in %changelog: Sat Aug 12 2012 Gilboa Davara gilboad [AT] gmail [DOT] com - 90.0-1 bogus date in %changelog: Sat Aug 12 2012 Gilboa Davara gilboad [AT] gmail [DOT] com - 89.0-5 bogus date in %changelog: Mon Mar 07 2012 Gilboa Davara gilboad [AT] gmail [DOT] com - 87.0-1 bogus date in %changelog: Tue Dec 24 2011 Gilboa Davara gilboad [AT] gmail [DOT] com - 85.0-1 bogus date in %changelog: Tue Nov 7 2011 Gilboa Davara gilboad [AT] gmail [DOT] com - 83.0-1 bogus date in %changelog: Tue Aug 22 2011 Gilboa Davara gilboad [AT] gmail [DOT] com - 0.82.7.1-6 bogus date in %changelog: Tue Nov 18 2010 Gilboa Davara gilboad [at] gmail [dot] com -0.82.6.1-1 Bad exit status from /var/tmp/rpm-tmp.B4jcdz (%build) Everything else rebuilt fine. - ajax -- 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 2:38 PM, Richard W.M. Jones rjo...@redhat.com 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 mostly just did a git merge with Rawhide and rebuilt. A couple of packages FTBFS due to texlive-2012, so I fixed those in Rawhide first, then built them in F-18. (Side note: I have rebuilt slightly over a dozen LaTeX-using packages since TeXLive 2012 hit the repos. Of those, only 1 did not need to have additional BRs. I suspect we have a lot of undetected FTBFS errors in the Rawhide F-18 repositories right now due to this.) I also rebuilt this, which was not on the list: csisat-1.2-10.fc18 I will do these tomorrow if nobody beats me to them: frama-c-1.7-9.fc18.src.rpm why-2.31-3.fc18.src.rpm why3-0.73-2.fc18.src.rpm This one was on the list, but doesn't contain any actual ocaml code, so does not need a rebuild: flocq-2.1.0-2.fc18.src.rpm 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. Regards, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Fedora 18 Final Test Compose 2 (TC2) Available Now!
As per the Fedora 18 schedule [1], Fedora 18 Final Test Compose 2 (TC2) is now available for testing. Content information, including changes, can be found at https://fedorahosted.org/rel-eng/ticket/5406#comment:4 . Please see the following pages for download links (including delta ISOs) and testing instructions. Normally dl.fedoraproject.org should provide the fastest download, but download-ib01.fedoraproject.org is available as a mirror (with an approximately 1 hour lag) in case of trouble. To use it, just replace dl with download-ib01 in the download URL. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Base: https://fedoraproject.org/wiki/Test_Results:Current_Base_Test Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Security Lab: https://fedoraproject.org/wiki/Test_Results:Current_Security_Lab_Test Ideally, all Alpha, Beta, and Final priority test cases for Installation [2], Base [3], Desktop [4], and Security Lab [5] should pass in order to meet the Final Release Criteria [6]. Help is available on #fedora-qa on irc.freenode.net [7], or on the test list [8]. Create Fedora 18 test compose (TC) and release candidate (RC) https://fedorahosted.org/rel-eng/ticket/5406 Current Blocker and NTH bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://jreznik.fedorapeople.org/schedules/f-18/f-18-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Installation_validation_testing [3] https://fedoraproject.org/wiki/QA:Base_validation_testing [4] https://fedoraproject.org/wiki/QA:Desktop_validation_testing [5] https://fedoraproject.org/wiki/QA:Security_Lab_validation_testing [6] https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria [7] irc://irc.freenode.net/fedora-qa [8] https://admin.fedoraproject.org/mailman/listinfo/test signature.asc Description: OpenPGP digital signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Data-ICal/f16] (6 commits) ...Merge cleanup.
Summary of changes: 4a01525... - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass (*) b596dfa... Perl 5.16 rebuild (*) cc15cfb... - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass (*) 77acfca... Upstream update. (*) 50a9915... Merge cleanup. (*) 875743a... Merge cleanup. (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Data-ICal/f16: 6/6] Merge cleanup.
commit 875743a913617d780b1ec28145c9d793475a84a2 Author: Ralf Corsépius corse...@fedoraproject.org Date: Thu Dec 13 09:00:43 2012 +0100 Merge cleanup. perl-Data-ICal.spec |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) --- diff --git a/perl-Data-ICal.spec b/perl-Data-ICal.spec index a5491f6..b9c79c6 100644 --- a/perl-Data-ICal.spec +++ b/perl-Data-ICal.spec @@ -63,9 +63,6 @@ make test - Modernize spec. - Drop Data-ICal-0.16.diff. -* Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.18-3 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild - * Thu Dec 15 2011 Ralf Corsépius corse...@fedoraproject.org - 0.18-2 - Spec file cleanup. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 886801] New: perl-XML-Rules-1.15 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=886801 Bug ID: 886801 Summary: perl-XML-Rules-1.15 is available Product: Fedora Version: rawhide Component: perl-XML-Rules Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Reporter: upstream-release-monitor...@fedoraproject.org Latest upstream release: 1.15 Current version in Fedora Rawhide: 1.14 URL: http://search.cpan.org/dist/XML-Rules/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=fPHpx28Odha=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 877015] CVE-2012-5526 perl-CGI: Newline injection due to improper CRLF escaping in Set-Cookie and P3P headers
Product: Security Response https://bugzilla.redhat.com/show_bug.cgi?id=877015 Bug 877015 depends on bug 876974, which changed state. Bug 876974 Summary: CVE-2012-5526 perl-CGI: Newline injection due to improper CRLF escaping in Set-Cookie and P3P headers [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=876974 What|Removed |Added Status|CLOSED |ASSIGNED Resolution|CURRENTRELEASE |--- -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=JNmqtyYrGLa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 876974] CVE-2012-5526 perl-CGI: Newline injection due to improper CRLF escaping in Set-Cookie and P3P headers [fedora-all]
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=876974 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|CLOSED |ASSIGNED Resolution|CURRENTRELEASE |--- -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=HclwOxAblZa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 876974] CVE-2012-5526 perl-CGI: Newline injection due to improper CRLF escaping in Set-Cookie and P3P headers [fedora-all]
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=876974 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|ON_QA --- Comment #18 from Petr Pisar ppi...@redhat.com --- Bug in bodhi. F16 is still in testing phase. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=htxDQOmsjUa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 886829] New: RFE: Support vendor plugin directory
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=886829 Bug ID: 886829 Summary: RFE: Support vendor plugin directory Product: Fedora Version: 18 Component: rt3 Severity: unspecified Priority: unspecified Reporter: mchap...@redhat.com Created attachment 662823 -- https://bugzilla.redhat.com/attachment.cgi?id=662823action=edit Patch With the latest versions of RTFM it's necessary to use RT's plugin mechanism. In order to package this properly (and not have to use /usr/local) it would be nice if the rt3 package would add plugindir to the fedora layout. This would also make it possible to package rt3-RTFM for Fedora/EPEL. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=xJvoCdRxl9a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Net-SSLeay-1.50.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Net-SSLeay: 5e239c5aae70dece79fcd6a4307fc53e Net-SSLeay-1.50.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-SSLeay] Update to 1.50
commit 690893433ee9d6acb7f689c3810deb88f4413237
Author: Paul Howarth p...@city-fan.org
Date: Thu Dec 13 12:16:05 2012 +
Update to 1.50
- New upstream release 1.50
- fixed a problem where t/handle/external/50_external.t would crash if
any of
the test sites were not contactable
- now builds on VMS, added README.VMS
- fixed a few compiler warnings in SSLeay.xs; most of them are just
signed/unsigned pointer mismatches but there is one that actually fixes
returning what would be an arbitrary value off the stack from
get_my_thread_id if it happened to be called in a non-threaded build
- added SSL_set_tlsext_host_name, SSL_get_servername,
SSL_get_servername_type,
SSL_CTX_set_tlsext_servername_callback for server side Server Name
Indication (SNI) support
- fixed a problem with C++ comments preventing builds on AIX and HPUX
- perdition.org not available for tests, changed to www.open.com.au
- added SSL_FIPS_mode_set
- improvements to test suite so it succeeds with and without FIPS mode
enabled
- added documentation, warning not to pass UTF-8 data in the content
argument to post_https
perl-Net-SSLeay.spec | 22 +-
sources |2 +-
2 files changed, 22 insertions(+), 2 deletions(-)
---
diff --git a/perl-Net-SSLeay.spec b/perl-Net-SSLeay.spec
index 430e363..7fa23ac 100644
--- a/perl-Net-SSLeay.spec
+++ b/perl-Net-SSLeay.spec
@@ -1,5 +1,5 @@
Name: perl-Net-SSLeay
-Version: 1.49
+Version: 1.50
Release: 1%{?dist}
Summary: Perl extension for using OpenSSL
Group: Development/Libraries
@@ -92,6 +92,26 @@ rm -rf %{buildroot}
%{_mandir}/man3/Net::SSLeay::Handle.3pm*
%changelog
+* Thu Dec 13 2012 Paul Howarth p...@city-fan.org - 1.50-1
+- update to 1.50
+ - fixed a problem where t/handle/external/50_external.t would crash if any of
+the test sites were not contactable
+ - now builds on VMS, added README.VMS
+ - fixed a few compiler warnings in SSLeay.xs; most of them are just
+signed/unsigned pointer mismatches but there is one that actually fixes
+returning what would be an arbitrary value off the stack from
+get_my_thread_id if it happened to be called in a non-threaded build
+ - added SSL_set_tlsext_host_name, SSL_get_servername,
SSL_get_servername_type,
+SSL_CTX_set_tlsext_servername_callback for server side Server Name
+Indication (SNI) support
+ - fixed a problem with C++ comments preventing builds on AIX and HPUX
+ - perdition.org not available for tests, changed to www.open.com.au
+ - added SSL_FIPS_mode_set
+ - improvements to test suite so it succeeds with and without FIPS mode
+enabled
+ - added documentation, warning not to pass UTF-8 data in the content
+argument to post_https
+
* Tue Sep 25 2012 Paul Howarth p...@city-fan.org - 1.49-1
- update to 1.49
- fixed problem where on some platforms test t/local/07_tcpecho.t would bail
diff --git a/sources b/sources
index b250aef..f337302 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-9e05acd6773ff5e94c5a1dcd7c0ec4a7 Net-SSLeay-1.49.tar.gz
+5e239c5aae70dece79fcd6a4307fc53e Net-SSLeay-1.50.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-SSLeay] Created tag perl-Net-SSLeay-1.50-1.fc19
The lightweight tag 'perl-Net-SSLeay-1.50-1.fc19' was created pointing to: 6908934... Update to 1.50 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File XML-Rules-1.15.tar.gz uploaded to lookaside cache by wfp
A file has been added to the lookaside cache for perl-XML-Rules: ced3fb6923d4fbf59feb409d6771831f XML-Rules-1.15.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-XML-Rules] update to version 1.15
commit 88de783e0cfacc50bf1e0898cd5c4cb759102ff5
Author: Bill Pemberton wf...@virginia.edu
Date: Thu Dec 13 08:41:10 2012 -0500
update to version 1.15
.gitignore |1 +
perl-XML-Rules.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 59a439e..7e6de84 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
/XML-Rules-1.10.tar.gz
/XML-Rules-1.13.tar.gz
/XML-Rules-1.14.tar.gz
+/XML-Rules-1.15.tar.gz
diff --git a/perl-XML-Rules.spec b/perl-XML-Rules.spec
index 30cee9c..e312447 100644
--- a/perl-XML-Rules.spec
+++ b/perl-XML-Rules.spec
@@ -1,5 +1,5 @@
Name: perl-XML-Rules
-Version: 1.14
+Version: 1.15
Release: 1%{?dist}
Summary: Parse XML and specify what and how to keep/process for
individual tags
License: GPL+ or Artistic
@@ -72,6 +72,9 @@ rm -rf $RPM_BUILD_ROOT
%{_bindir}/xml2XMLRules.pl
%changelog
+* Thu Dec 13 2012 Bill Pemberton wf...@virginia.edu - 1.15-1
+- update to version 1.15
+
* Mon Oct 22 2012 Bill Pemberton wf...@virginia.edu - 1.14-1
- update to version 1.14
diff --git a/sources b/sources
index bec9eba..83a1546 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-2de5337a35a261b75c61cbd244315bd6 XML-Rules-1.14.tar.gz
+ced3fb6923d4fbf59feb409d6771831f XML-Rules-1.15.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-XML-Rules/f18] update to version 1.15
Summary of changes: 88de783... update to version 1.15 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 886801] perl-XML-Rules-1.15 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=886801 --- Comment #1 from Fedora Update System upda...@fedoraproject.org --- perl-XML-Rules-1.15-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/perl-XML-Rules-1.15-1.fc18 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=rs37mjSB0ka=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-XML-Rules/f17] (5 commits) ...update to version 1.15
Summary of changes: 719e0b1... Perl 5.16 rebuild (*) 3587074... - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass (*) 5fabe35... Update to upstream version 1.13 (*) 03ce46d... Update to version 1.14 (*) 88de783... update to version 1.15 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 886801] perl-XML-Rules-1.15 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=886801 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- perl-XML-Rules-1.15-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/perl-XML-Rules-1.15-1.fc17 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=G2WygSK0YOa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 886339] defined(@array) is deprecated at /usr/share/perl5/vendor_perl/Mail/Sender.pm
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=886339 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- Package perl-Mail-Sender-0.8.21-1.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 perl-Mail-Sender-0.8.21-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-20315/perl-Mail-Sender-0.8.21-1.fc18 then log in and leave karma (feedback). -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=vcDYDTOYrKa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 886801] perl-XML-Rules-1.15 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=886801 --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- Package perl-XML-Rules-1.15-1.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 perl-XML-Rules-1.15-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-20351/perl-XML-Rules-1.15-1.fc18 then log in and leave karma (feedback). -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=FXmlaOU6Q4a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
