Re: Minimal install diff from F16 to F19 (TC6)
On Mon, Jun 24, 2013 at 11:15:11AM +0930, Glen Turner wrote: On 22/06/2013, at 7:23 PM, Richard W.M. Jones wrote: (2) Write a shell script that contains the ifconfig/route add (or ip ...) commands they need and have it run at boot. Most simple static network configs are 2 or 3 commands at most. If you have a server in the tradition of UNIX workstations sure. But such simple networking isn't the case for some servers today, and it's hard to see that it will be the case in the future. [complicated network stuff] Then use NetworkManager for the complicated stuff! The whole point here is we're *not* talking about complicated network configuration. 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#) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
On 06/24/2013 03:27 AM, Bruno Wolff III wrote: On Sun, Jun 23, 2013 at 18:04:55 -0400, Matthias Clasen mcla...@redhat.com wrote: rpm db 82M I vaguely remember a discussion about dropping this for live images because it gets rebuilt every boot when needed. My memory is that we ended up removing this data while building live images, but haven't looked at it in a long time. Well you can't create the rpmdb out of nothing on reboot. There are three different types of data in the rpmdb: - the main Packages database which holds the package headers - indexes like Name, Requirename etc which can always be recreated from the main Packages db - host-specific __db.* files (BDB internal cache, locks etc) which must NOT be included in live images, and which get created as needed The __db.* files hopefully are not included on live images to begin with. It might be possible to drop the indexes too: current rpm versions will automatically generate missing indexes on access, but obviously it needs to run as root for that to work. So if indexes are dropped, non-root queries would be very broken until root does a query or runs an explicit 'rpmdb --rebuilddb' (which could be arranged to happen on boot) - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: A need for build triggers automatic rebuilds
- Original Message - From: Florian Weimer fwei...@redhat.com To: devel@lists.fedoraproject.org Sent: Friday, June 21, 2013 3:00:36 PM Subject: Re: A need for build triggers automatic rebuilds On 06/21/2013 08:28 AM, Krzysztof Daniel wrote: OSGI records that there is a file org.eclipse.jetty.http_9.0.3.v20130506.jar that holds a plugin with version 9.0.3.v20130506. That version goes at the build time in a couple of places (including metabundle). Such exact dependencies are fundamentally broken and do not scale. We cannot rebuild the whole world just for minor (say, security) updates. Lying about the version number (so that the new version looks like the old one to OSGi) doesn't strike me as a good idea, either, because it will confuse developers and other tools. I tried to bring this up on the Project Jigsaw mailing list a couple of years ago, but I'm not sure if I brought across this point. From my point of view, these Java module frameworks refuse to acknowledge that there is extensive experience with distro-level release engineering. (Basically, exact dependencies and multiple versions of the same code might be convenient now, but will seriously hurt you down the road.) Exact match can't be used at all, because if jetty is updated, then it will be impossible to install Eclipse. Well, if it doesn't work with the old version, that's the right thing to do. I believe Debian relaxes the OSGi-generated dependencies on system libraries. Fedora should do the same thing in its Eclipse packaging. Just to clarify a bit - this is not a limitation of OSGi. It's the Eclipse implementation being faulty of this. And when I say Eclipse implementation I mean Eclipse platform because the actual OSGi runtime in Eclipse (called Equinox) works perfectly with version ranges and doesn't suffer from this problem at all. It's the Eclipse IDE that suffers from this due to legacy reasons. This shows another problem though: expressing version range in a spec file e.g there is no easy way to say I want a package that provides osgi(smth) [1.0.0, 1.5.0). If you try to express it with RPM requires as two statements: Requires: osgi(smth) = 1.0.0 Requires: osgi(smth) 1.5.0 it's not exactly the same as having packages providing osgi(0.9) and osgi(1.6.0) will satisfy this requirements too. I know this is hypothetical but it shows the inability to require version range in RPM terms reliably. And the way to get that but not fail-proof is too verbose now. Alexander Kurtakov Red Hat Eclipse team -- Florian Weimer / Red Hat Product Security Team -- 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: A need for build triggers automatic rebuilds
Krzysztof, unrelated to this thread, but I've noticed the Face header in your email, which exceeds the maximum size of such headers. As such, it breaks the hard limits of some servers as well as clients, such as Claws Mail. http://quimby.gnus.org/circus/face/ -- Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.6-301.fc19.x86_64 loadavg: 0.05 0.11 0.11 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: A need for build triggers automatic rebuilds
Le Lun 24 juin 2013 11:59, Aleksandar Kurtakov a écrit : This shows another problem though: expressing version range in a spec file e.g there is no easy way to say I want a package that provides osgi(smth) [1.0.0, 1.5.0). If you try to express it with RPM requires as two statements: Requires: osgi(smth) = 1.0.0 Requires: osgi(smth) 1.5.0 it's not exactly the same as having packages providing osgi(0.9) and osgi(1.6.0) will satisfy this requirements too. I know this is hypothetical but it shows the inability to require version range in RPM terms reliably. And the way to get that but not fail-proof is too verbose now. You can express it reliably : Requires: osgi(smth) = 1.0.0 Conflicts: osgi(smth) = 1.5.0 The drawback being you can not have two generations of osgi(smth) on-system (but having two generations will confuse lots of apps anyway) -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: A need for build triggers automatic rebuilds
On 06/24/2013 11:59 AM, Aleksandar Kurtakov wrote: I believe Debian relaxes the OSGi-generated dependencies on system libraries. Fedora should do the same thing in its Eclipse packaging. Just to clarify a bit - this is not a limitation of OSGi. It's the Eclipse implementation being faulty of this. And when I say Eclipse implementation I mean Eclipse platform because the actual OSGi runtime in Eclipse (called Equinox) works perfectly with version ranges and doesn't suffer from this problem at all. It's the Eclipse IDE that suffers from this due to legacy reasons. Yes, thanks for the clarification. As I said, I believe that Debian patches the generated dependencies to be more lenient. At least they did some time ago—this particular feature might have been lost along with Eclipse build system changes. This shows another problem though: expressing version range in a spec file e.g there is no easy way to say I want a package that provides osgi(smth) [1.0.0, 1.5.0). If you try to express it with RPM requires as two statements: Requires: osgi(smth) = 1.0.0 Requires: osgi(smth) 1.5.0 it's not exactly the same as having packages providing osgi(0.9) and osgi(1.6.0) will satisfy this requirements too. I know this is hypothetical but it shows the inability to require version range in RPM terms reliably. And the way to get that but not fail-proof is too verbose now. Conflicts with future versions which do not exist yet are a bit questionable, IMHO. In most cases, you don't know that 1.6.0 will actually be incompatible with your code because it hasn't been released yet. -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Minimal install diff from F16 to F19 (TC6)
On Mon, Jun 24, 2013 at 11:15:11AM +0930, Glen Turner wrote: Sun's tagline of the network is the computer was true. But for servers these days the computer is the network is also the case. It's nothing for a server today to statically NAT or bridge IPv4 to VMs. Even in that case it's best if the guest VM picks up its IPv4 addressing using DHCP. But in the future we'll want to do better than that: to move network routing onto the server itself. These new data centre ethernet protocols are not entirely implemented in kernel space. Some run quite complex BGP and MPLS control planes; others run IS-IS control planes. So, the converse is that as actual workloads move to VMs (let alone cloud), the host systems become a special case, and the normal case for a server tends to become much more simple: either a single interface probably with fixed-address DHCP, or in most complicated cases several interfaces on specific networks known by convention. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
- Original Message - On Sat, 2013-06-22 at 22:17 -0700, Adam Williamson wrote: On Sat, 2013-06-22 at 11:00 -0400, Matthias Clasen wrote: On Fri, 2013-06-21 at 14:14 -0700, Adam Williamson wrote: https://bugzilla.redhat.com/show_bug.cgi?id=958426 - 19 Final TC1 x86_64 Desktop Live is oversized (larger than 1 GB) - desktop team (I know you're working on it) I've filed an update with some 20 packages, only removing excess baggage from /usr/share/doc (duplicate docs, large ChangeLog files, etc). It touches nothing outside /usr/share/doc, so should be fairly safe to let in. That will probably only get us part of the way, so I've also cut some more things from the package set in the .ks file (gnome-system-log, deja-dup). If that is not enough, next step will probably be removing some of the big font packages. So Matthias forgot to link to his update, but here it is: https://admin.fedoraproject.org/updates/FEDORA-2013-11471/PackageKit-0.8.9-6.fc19,gtk2-2.24.19-2.fc19,evolution-3.8.3-2.fc19,gedit-3.8.2-2.fc19,gnome-session-3.8.2.1-2.fc19,gdm-3.8.3-2.fc19,eog-3.8.2-2.fc19,telepathy-mission-control-5.14.1-2.fc19,yelp-3.8.1-5.fc19,libchamplain-0.12.4-2.fc19,dbus-glib-0.100-4.fc19,libisofs-1.2.8-2.fc19,libxslt-1.1.28-3.fc19,gnome-contacts-3.8.2-2.fc19,gtkmm24-2.24.2-6.fc19,glibmm24-2.36.2-2.fc19,folks-0.9.2-3.fc19,harfbuzz-0.9.18-3.fc19,tracker-0.16.1-3.fc19,libmx-1.4.7-7.fc19 It contains changes to some packages not entirely GNOME-y in nature, inc. dbus-glib and gtk2, so other people might want to give it the once-over just to make sure there are no inadvertent errors, and upkarma it assuming it's all good. I am about to test a live compose with the update to see the impact on image size. So here's some results. f2e707287dd82cccb05a3fef6b75cb356744ca58 (Jun 14), no update: 1019215872 f2e707287dd82cccb05a3fef6b75cb356744ca58 (Jun 14), update: 1017118720 1a0c28fdf638796bda60ed2785f95eac16a85b65 (Jun 22), update: 1005584384 that is, with the old spin-kickstarts and without the above update, we're 19215872 bytes oversize; with the update but old spin-kickstarts, we're 17118720 bytes oversize (the update saves ~2.1MB); and with the update and latest spin-kickstarts, we're 5584384 bytes oversize (the kickstart changes save ~11.5MB). We still need to find another 5.6MB from somewhere. Do we have to be byte strict here? For physical medium sizes, we had to be, this 1 GB is more we set it as we think it's a good idea. Or maybe 1 GB sticks (what's the real size one can use + overlay?) but it's not as strict, as you could pick up bigger one. R. Thanks folks! -- 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
- Original Message - - Original Message - On Sat, 2013-06-22 at 22:17 -0700, Adam Williamson wrote: On Sat, 2013-06-22 at 11:00 -0400, Matthias Clasen wrote: On Fri, 2013-06-21 at 14:14 -0700, Adam Williamson wrote: https://bugzilla.redhat.com/show_bug.cgi?id=958426 - 19 Final TC1 x86_64 Desktop Live is oversized (larger than 1 GB) - desktop team (I know you're working on it) I've filed an update with some 20 packages, only removing excess baggage from /usr/share/doc (duplicate docs, large ChangeLog files, etc). It touches nothing outside /usr/share/doc, so should be fairly safe to let in. That will probably only get us part of the way, so I've also cut some more things from the package set in the .ks file (gnome-system-log, deja-dup). If that is not enough, next step will probably be removing some of the big font packages. So Matthias forgot to link to his update, but here it is: https://admin.fedoraproject.org/updates/FEDORA-2013-11471/PackageKit-0.8.9-6.fc19,gtk2-2.24.19-2.fc19,evolution-3.8.3-2.fc19,gedit-3.8.2-2.fc19,gnome-session-3.8.2.1-2.fc19,gdm-3.8.3-2.fc19,eog-3.8.2-2.fc19,telepathy-mission-control-5.14.1-2.fc19,yelp-3.8.1-5.fc19,libchamplain-0.12.4-2.fc19,dbus-glib-0.100-4.fc19,libisofs-1.2.8-2.fc19,libxslt-1.1.28-3.fc19,gnome-contacts-3.8.2-2.fc19,gtkmm24-2.24.2-6.fc19,glibmm24-2.36.2-2.fc19,folks-0.9.2-3.fc19,harfbuzz-0.9.18-3.fc19,tracker-0.16.1-3.fc19,libmx-1.4.7-7.fc19 It contains changes to some packages not entirely GNOME-y in nature, inc. dbus-glib and gtk2, so other people might want to give it the once-over just to make sure there are no inadvertent errors, and upkarma it assuming it's all good. I am about to test a live compose with the update to see the impact on image size. So here's some results. f2e707287dd82cccb05a3fef6b75cb356744ca58 (Jun 14), no update: 1019215872 f2e707287dd82cccb05a3fef6b75cb356744ca58 (Jun 14), update: 1017118720 1a0c28fdf638796bda60ed2785f95eac16a85b65 (Jun 22), update: 1005584384 that is, with the old spin-kickstarts and without the above update, we're 19215872 bytes oversize; with the update but old spin-kickstarts, we're 17118720 bytes oversize (the update saves ~2.1MB); and with the update and latest spin-kickstarts, we're 5584384 bytes oversize (the kickstart changes save ~11.5MB). We still need to find another 5.6MB from somewhere. Do we have to be byte strict here? For physical medium sizes, we had to be, this 1 GB is more we set it as we think it's a good idea. Or maybe 1 GB sticks (what's the real size one can use + overlay?) but it's not as strict, as you could pick up bigger one. And I'm aware of multi desktop medias - not sure 5 megs means a huge difference there (and it still makes sense to have some limit +/-). R. R. Thanks folks! -- 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 -- 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: Minimal install diff from F16 to F19 (TC6)
Once upon a time, Glen Turner g...@gdt.id.au said: What we don't want is a scenario where configuring these protocols on servers has to be done by network engineers. We want them configured from a GUI and supervised by a master daemon. Let's call that NetworkManager. You think hundreds of servers (with untold numbers of VMs), or any complicated networking setups, are going to each have their network configuration managed by a GUI? -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Minimal install diff from F16 to F19 (TC6)
* Chris Adams [24/06/2013 06:30] : You think hundreds of servers (with untold numbers of VMs), or any complicated networking setups, are going to each have their network configuration managed by a GUI? I believe Glen meant that in the sense an admin is running a GUI app on his workstation and the configuration get farmed out to the servers. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Minimal install diff from F16 to F19 (TC6)
Le Lun 24 juin 2013 13:08, Matthew Miller a écrit : So, the converse is that as actual workloads move to VMs (let alone cloud), the host systems become a special case, and the normal case for a server tends to become much more simple: either a single interface probably with fixed-address DHCP, or in most complicated cases several interfaces on specific networks known by convention. That's a big assumption, just because the hypervisor is more complex does not mean vms get simpler (this is the same faulty reasoning that vmware made a few years past when it told everyone that esxi would replace bioses and systems would be reduced to their simplest expression — read give us your money, not to Microsoft or Red Hat). In fact I am quite certain vm complexity is a direct factor of management tools maturity, and people will continue to deploy the most complex configurations they can, as long as the tools let them. No one wants to delegate anything when the problem can be solved without delegation. Regards, -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20130624 changes
Compose started at Mon Jun 24 08:15:03 UTC 2013 Broken deps for x86_64 -- [aries-blueprint] aries-blueprint-0.3.1-5.fc19.noarch requires asm2 [chmsee] chmsee-2.0-5.git0acc572a.fc20.x86_64 requires libxpcom.so()(64bit) [cxf] 1:cxf-rt-2.6.6-1.fc19.noarch requires asm2 [ekiga] ekiga-4.0.1-1.fc19.x86_64 requires libedata-book-1.2.so.17()(64bit) [evolution-rss] 1:evolution-rss-0.3.93-3.fc20.x86_64 requires libeutil.so()(64bit) 1:evolution-rss-0.3.93-3.fc20.x86_64 requires libeshell.so()(64bit) [firefox] firefox-20.0-5.fc20.x86_64 requires libxpcom.so()(64bit) [gdb-heap] gdb-heap-0.5-12.fc19.x86_64 requires glibc(x86-64) = 0:2.17 [ghc-Agda] ghc-Agda-2.3.0.1-12.fc20.x86_64 requires libHSzlib-0.5.4.0-ghc7.4.2.so()(64bit) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires libHSxhtml-3000.2.1-ghc7.4.2.so()(64bit) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires libHSvector-0.10.0.1-ghc7.4.2.so()(64bit) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires libHSunix-2.5.1.1-ghc7.4.2.so()(64bit) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires libHStransformers-0.3.0.0-ghc7.4.2.so()(64bit) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires libHStime-1.4-ghc7.4.2.so()(64bit) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires libHStext-0.11.2.3-ghc7.4.2.so()(64bit) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires libHSterminfo-0.3.2.5-ghc7.4.2.so()(64bit) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires libHStemplate-haskell-2.7.0.0-ghc7.4.2.so()(64bit) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires libHSsyb-0.3.7-ghc7.4.2.so()(64bit) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires libHSrandom-1.0.1.1-ghc7.4.2.so()(64bit) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires libHSprocess-1.1.0.1-ghc7.4.2.so()(64bit) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires libHSprimitive-0.5.0.1-ghc7.4.2.so()(64bit) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires libHSpretty-1.1.1.0-ghc7.4.2.so()(64bit) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires libHSold-time-1.1.0.0-ghc7.4.2.so()(64bit) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires libHSold-locale-1.0.0.4-ghc7.4.2.so()(64bit) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires libHSmtl-2.1.2-ghc7.4.2.so()(64bit) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires libHSinteger-gmp-0.4.0.0-ghc7.4.2.so()(64bit) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires libHShaskell-src-exts-1.13.5-ghc7.4.2.so()(64bit) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires libHShaskeline-0.7.0.3-ghc7.4.2.so()(64bit) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires libHShashtables-1.0.1.8-ghc7.4.2.so()(64bit) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires libHShashable-1.1.2.5-ghc7.4.2.so()(64bit) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires libHSghc-prim-0.2.0.0-ghc7.4.2.so()(64bit) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires libHSfilepath-1.3.0.0-ghc7.4.2.so()(64bit) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires libHSdirectory-1.1.0.2-ghc7.4.2.so()(64bit) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires libHSdeepseq-1.3.0.0-ghc7.4.2.so()(64bit) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires libHScpphs-1.16-ghc7.4.2.so()(64bit) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires libHScontainers-0.4.2.1-ghc7.4.2.so()(64bit) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires libHSbytestring-0.9.2.1-ghc7.4.2.so()(64bit) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires libHSbinary-0.5.1.0-ghc7.4.2.so()(64bit) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires libHSbase-4.5.1.0-ghc7.4.2.so()(64bit) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires libHSarray-0.4.0.0-ghc7.4.2.so()(64bit) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires libHSQuickCheck-2.5.1.1-ghc7.4.2.so()(64bit) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires ghc(zlib-0.5.4.0-f9a7b27d857d3e506b8524567650abc8) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires ghc(xhtml-3000.2.1-290aa859a8b955ebda95b5ca3b1b69f3) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires ghc(syb-0.3.7-60af41a2377e93620710d393692aff24) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires ghc(process-1.1.0.1-608c248c1528f46eb960a08cead77291) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires ghc(pretty-1.1.1.0-91ed62f0481a81d292d550eec35ee75b) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires ghc(old-time-1.1.0.0-703543375fafbcbe67bc51a758e84f10) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires ghc(mtl-2.1.2-02e701f9b1590ee88a0b5b0bd5d93a29) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires ghc(haskell-src-exts-1.13.5-bdba692764e11c662d7ce456e9b0) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires ghc(haskeline-0.7.0.3-d7f3ccf9e91c534c80a7d7d408a958c4) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires ghc(hashtables-1.0.1.8-83bb853aa7f012eaa447f17f929e2fad) ghc-Agda-2.3.0.1-12.fc20.x86_64 requires ghc(hashable-1.1.2.5-14291f3b4e96b5599759ce7daa2bd37c) ghc-Agda-2.3.0.1-12.fc20.x86_64
Re: Minimal install diff from F16 to F19 (TC6)
On Mon, Jun 24, 2013 at 01:22:03PM +0200, Reindl Harald wrote: yes, and all these setups are more than satisfied with network.service and do not need more complexity with a running daemon like NM If you'd be interested in packaging and maintaining a network.service that handles static addressing and DHCP using the configuration in /etc/system-config/network-scripts, I'd be happy to take a look at it. -- Matthew Miller mat...@mattdm.org http://mattdm.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Minimal install diff from F16 to F19 (TC6)
On Mon, Jun 24, 2013 at 01:41:16PM +0200, Nicolas Mailhot wrote: So, the converse is that as actual workloads move to VMs (let alone cloud), the host systems become a special case, and the normal case for a server tends to become much more simple: either a single interface probably with fixed-address DHCP, or in most complicated cases several interfaces on specific networks known by convention. That's a big assumption, just because the hypervisor is more complex does not mean vms get simpler (this is the same faulty reasoning that vmware made a few years past when it told everyone that esxi would replace bioses and systems would be reduced to their simplest expression — read give us your money, not to Microsoft or Red Hat). In fact I am quite certain vm complexity is a direct factor of management tools maturity, and people will continue to deploy the most complex configurations they can, as long as the tools let them. No one wants to delegate anything when the problem can be solved without delegation. I'm not sure it's the same reasoning because I have no idea how what I said relates to replacing the BIOS wiith ESXi, but it's certainly the case that VMware has been hugely successful. And part of that success is because addressing the _problem_ of increased complexity on the individual servers. The situation I described above is a feature, not a side-effect. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Fedora 19 Go/No-Go Meeting, Thursday, June 27 @ 17:00 UTC
Join us on irc.freenode.net in #fedora-meeting-2 for this important meeting, wherein we shall determine the readiness of the Fedora 19. Thursday, June 27, 2013 17:00 UTC (1 PM EDT, 10 AM PDT, 19:00 CEST) Before each public release Development, QA and Release Engineering meet to determine if the release criteria are met for a particular release. This meeting is called the Go/No-Go Meeting. Verifying that the Release criteria are met is the responsibility of the QA Team. For more details about this meeting see: https://fedoraproject.org/wiki/Go_No_Go_Meeting In the meantime, keep an eye on the Fedora 19 Blocker list: http://qa.fedoraproject.org/blockerbugs/milestone/19/final/buglist There are currently three unresolved accepted blockers, for full status see mail [1] by adamw. Please help with the release of Fedora 19, take a look on bugs assigned to you! Reminder: the Readiness meeting follows up the Go/No-Go meeting two hours later. [1] https://lists.fedoraproject.org/pipermail/devel/2013-June/184345.html Jaroslav ___ 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
F-19 Branched report: 20130624 changes
Compose started at Mon Jun 24 09:15:02 UTC 2013 Broken deps for x86_64 -- [avgtime] avgtime-0-0.5.git20120724.fc19.x86_64 requires libphobos-ldc.so.60()(64bit) [derelict] derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires ogg derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires OGG derelict-ogg-3-13.20130516gitd8aa11d.fc19.x86_64 requires ogg derelict-ogg-3-13.20130516gitd8aa11d.fc19.x86_64 requires OGG derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires ogg derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires OGG derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires ogg derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires OGG derelict-pq-3-13.20130516gitd8aa11d.fc19.i686 requires pq derelict-pq-3-13.20130516gitd8aa11d.fc19.i686 requires PQ derelict-pq-3-13.20130516gitd8aa11d.fc19.x86_64 requires pq derelict-pq-3-13.20130516gitd8aa11d.fc19.x86_64 requires PQ derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.i686 requires pq derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.i686 requires PQ derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires pq derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires PQ derelict-tcod-3-13.20130516gitd8aa11d.fc19.i686 requires tcod derelict-tcod-3-13.20130516gitd8aa11d.fc19.i686 requires TCOD derelict-tcod-3-13.20130516gitd8aa11d.fc19.x86_64 requires tcod derelict-tcod-3-13.20130516gitd8aa11d.fc19.x86_64 requires TCOD derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.i686 requires tcod derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.i686 requires TCOD derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires tcod derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires TCOD [dragonegg] dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19 [dsqlite] dsqlite-1.0-4.fc19.i686 requires libphobos-ldc.so.60 dsqlite-1.0-4.fc19.x86_64 requires libphobos-ldc.so.60()(64bit) [dustmite] dustmite-1-8.20121031git1fb3ac4.fc18.x86_64 requires libphobos-ldc.so.60()(64bit) [freeipa] freeipa-server-strict-3.2.1-1.fc19.x86_64 requires pki-ca = 0:10.0.2 freeipa-server-strict-3.2.1-1.fc19.x86_64 requires 389-ds-base = 0:1.3.1.0 [gl3n] gl3n-0.20120813-4.fc19.i686 requires libphobos-ldc.so.60 gl3n-0.20120813-4.fc19.x86_64 requires libphobos-ldc.so.60()(64bit) [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [kawa] 1:kawa-1.11-5.fc19.x86_64 requires servlet25 [koji] koji-vm-1.8.0-1.fc19.noarch requires python-virtinst [libkolab] php-kolab-0.4.1-3.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-kolab-0.4.1-3.fc19.x86_64 requires php(api) = 0:20100412-x86-64 [nodejs-tilelive] nodejs-tilelive-4.4.3-2.fc19.noarch requires npm(optimist) 0:0.4 [openbox] gdm-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel gnome-panel-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel [ovirt-engine] ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires classpathx-mail [ovirt-guest-agent] ovirt-guest-agent-gdm-plugin-1.0.6-6.fc19.x86_64 requires libgdmsimplegreeter.so.1()(64bit) [perl-Bio-ASN1-EntrezGene] perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) [perl-Bio-SamTools] perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) [python-TraitsBackendQt] python-TraitsBackendQt-3.5.0-5.fc19.noarch requires python-TraitsGUI [scala] scala-2.9.2-2.fc19.noarch requires osgi(org.scala-ide.scala.library) [spacewalk-web] spacewalk-dobby-1.9.22-2.fc19.noarch requires perl(Spacewalk::Setup) [tango] tango-2-12.20120821git7b92443.fc19.i686 requires libphobos-ldc.so.60 tango-2-12.20120821git7b92443.fc19.x86_64 requires libphobos-ldc.so.60()(64bit) [zarafa] php-mapi-7.0.13-1.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-mapi-7.0.13-1.fc19.x86_64 requires php(api) = 0:20100412-x86-64 Broken deps for i386 -- [avgtime] avgtime-0-0.5.git20120724.fc19.i686 requires libphobos-ldc.so.60 [derelict] derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires ogg derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires OGG derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires ogg derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires OGG derelict-pq-3-13.20130516gitd8aa11d.fc19.i686 requires pq derelict-pq-3-13.20130516gitd8aa11d.fc19.i686 requires PQ
Re: Fedora 19 Final blocker status: fix and karma requests
- We have both js and mozjs17. js is still used by gjs, libpeas, libproxy-mozjs and gnome-shell. Possible savings: 7M I thought Colin was fixing everything to use mosjz17. Is that a F-20 thing? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
Bruno Wolff III (br...@wolff.to) said: On Sun, Jun 23, 2013 at 18:04:55 -0400, Matthias Clasen mcla...@redhat.com wrote: rpm db 82M I vaguely remember a discussion about dropping this for live images because it gets rebuilt every boot when needed. My memory is that we ended up removing this data while building live images, but haven't looked at it in a long time. It's useful in terms of having a RPM-based manifest of what's on the image, and if you're installing the image to disk, you're going to need it on the installed system... Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
On Mon, Jun 24, 2013 at 3:15 PM, Bill Nottingham nott...@redhat.com wrote: Bruno Wolff III (br...@wolff.to) said: On Sun, Jun 23, 2013 at 18:04:55 -0400, Matthias Clasen mcla...@redhat.com wrote: rpm db 82M I vaguely remember a discussion about dropping this for live images because it gets rebuilt every boot when needed. My memory is that we ended up removing this data while building live images, but haven't looked at it in a long time. It's useful in terms of having a RPM-based manifest of what's on the image, and if you're installing the image to disk, you're going to need it on the installed system... And it allows stuff like yum install foo to work in the live environment. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[dnf] dnf-0.3.8
Hello, a new DNF build has been built and pushed to updates-testing for F19 today[1]. It includes the latest upstream libsolv, hawkey, librepo and DNF with bugfixes, see the DNF 0.3.8 release notes[2]. Ales [1] http://bit.ly/19vfFeu [2] http://akozumpl.github.io/dnf/release_notes.html#id7 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
On Mon, 2013-06-24 at 09:14 -0400, Bill Nottingham wrote: - We have both js and mozjs17. js is still used by gjs, libpeas, libproxy-mozjs and gnome-shell. Possible savings: 7M I thought Colin was fixing everything to use mosjz17. Is that a F-20 thing? It missed f19, yes. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
On Mon, 2013-06-24 at 09:15 -0400, Bill Nottingham wrote: Bruno Wolff III (br...@wolff.to) said: On Sun, Jun 23, 2013 at 18:04:55 -0400, Matthias Clasen mcla...@redhat.com wrote: rpm db 82M I vaguely remember a discussion about dropping this for live images because it gets rebuilt every boot when needed. My memory is that we ended up removing this data while building live images, but haven't looked at it in a long time. It's useful in terms of having a RPM-based manifest of what's on the image, and if you're installing the image to disk, you're going to need it on the installed system... I don't really want to propose dropping the rpm db. I merely stated those numbers to give some perspective on what takes up how much space on the live image. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
On Mon, Jun 24, 2013 at 12:53:14 +0300, Panu Matilainen pmati...@laiskiainen.org wrote: On 06/24/2013 03:27 AM, Bruno Wolff III wrote: The __db.* files hopefully are not included on live images to begin with. It might be possible to drop the indexes too: current rpm Those are the files I was referring to and my memory is that they are removed from live images. I don't know if they were included in the quoted size for rpmdb. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Minimal install diff from F16 to F19 (TC6)
Le Lun 24 juin 2013 14:40, Matthew Miller a écrit : I'm not sure it's the same reasoning because I have no idea how what I said relates to replacing the BIOS wiith ESXi, but it's certainly the case that VMware has been hugely successful. And part of that success is because addressing the _problem_ of increased complexity on the individual servers. The situation I described above is a feature, not a side-effect. It's a feature for the cloud infra provider. It's an antifeature for everyone else. There is value in providing more features infra-side. There is no value in restricting functionnalities vm-side to favor the infra. The 'everything is a dumb system' vm view is nice on slideware but it does not describe reality (let alone because some complex network scenarii are the result of app needs, and there is zero value in shorting the system layer to make apps talk to the hypervisor directly. If only because the system layer is also an access control layer). -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: media capacity and Fedora 19
On 06/24/2013, Jaroslav Reznik wrote: Do we have to be byte strict here? For physical medium sizes, we had to be, this 1 GB is more we set it as we think it's a good idea. Or maybe 1 GB sticks (what's the real size one can use + overlay?) but it's not as strict, as you could pick up bigger one. Device sizes vary according to manufacturer and model. 3% is not uncommon. Here's one actual 1GB USB2.0 flash memory device that I use [from syslog, /var/log/messages]: usb 1-9: New USB device found, idVendor=154b, idProduct=0005 sd 9:0:0:0: [sdc] 2015232 512-byte logical blocks: (1.03 GB/984 MiB) That's 30MB (3%) more capacity than labeled. Here's a 4GB device: usb 1-9: New USB device found, idVendor=154b, idProduct=000f sd 13:0:0:0: [sdc] 8060928 512-byte logical blocks: (4.12 GB/3.84 GiB) That's 127MB (3.2%) more capacity than labeled. Here's a 8GB device: usb 1-9: New USB device found, idVendor=13fe, idProduct=5100 sd 11:0:0:0: [sdc] 15466496 512-byte logical blocks: (7.91 GB/7.37 GiB) That's 81MB (1%) less capacity than labeled. Here's a 16GB device: usb 1-10: New USB device found, idVendor=13fe, idProduct=5200 sd 10:0:0:0: [sdc] 30283008 512-byte logical blocks: (15.5 GB/14.4 GiB) That's 495MB (3.1%) less capacity than labeled. [Almost illegal.] -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fatal PCIe error 928 on KVM GPU Passthrough
On 06/20/2013 04:53 PM, Mario Ceresa wrote: Thanks Don, for your answer. How can I follow progress in this area? Is there a mailing list, or a wiki page for that? upstream qemu list primarily; potentiall lkml /or pci-list if vfio gets modified for it. @Lars: I'll try the preview repo nonetheless and report the result tomorrow. With best regards, Mario On 20 June 2013 16:39, Don Dutile ddut...@redhat.com mailto:ddut...@redhat.com wrote: On 06/20/2013 03:27 AM, Mario Ceresa wrote: Thanks Lars, I'll do as you suggest! Best, Mario On 19 June 2013 23:35, Lars Seipel lars.sei...@gmail.com mailto:lars.sei...@gmail.com mailto:lars.sei...@gmail.com mailto:lars.sei...@gmail.com__ wrote: On Wed, Jun 19, 2013 at 04:42:30PM +0200, Mario Ceresa wrote: does anybody know if it is currently possible to do GPU passthrough in kvm? No. it's being worked upstream by Alex Williamson. You might want to ask that on the Fedora virt list[1] or on upstream libvirt's users list[2]. The chances for getting good answers should be much higher there. [1] https://admin.fedoraproject.__org/mailman/listinfo/virt https://admin.fedoraproject.org/mailman/listinfo/virt [2] http://libvirt.org/contact.__html http://libvirt.org/contact.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Minimal install diff from F16 to F19 (TC6)
Am 24.06.2013 13:08, schrieb Matthew Miller: On Mon, Jun 24, 2013 at 11:15:11AM +0930, Glen Turner wrote: Sun's tagline of the network is the computer was true. But for servers these days the computer is the network is also the case. It's nothing for a server today to statically NAT or bridge IPv4 to VMs. Even in that case it's best if the guest VM picks up its IPv4 addressing using DHCP. But in the future we'll want to do better than that: to move network routing onto the server itself. These new data centre ethernet protocols are not entirely implemented in kernel space. Some run quite complex BGP and MPLS control planes; others run IS-IS control planes. So, the converse is that as actual workloads move to VMs (let alone cloud), the host systems become a special case, and the normal case for a server tends to become much more simple: either a single interface probably with fixed-address DHCP, or in most complicated cases several interfaces on specific networks known by convention yes, and all these setups are more than satisfied with network.service and do not need more complexity with a running daemon like NM they are also not affected from the interface-renamings and race-conditions which are the reson for biosdevname and the new systemd-replacement because typically in a VM you have even with multiple interfaces the same NIC type and driver signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Minimal install diff from F16 to F19 (TC6)
On Mon, Jun 24, 2013 at 04:05:35PM +0200, Nicolas Mailhot wrote: The situation I described above is a feature, not a side-effect. It's a feature for the cloud infra provider. It's an antifeature for everyone else. There is value in providing more features infra-side. There is no value in restricting functionnalities vm-side to favor the infra. Having managed reasonably large and complicated server infrastructures in reasonably large and complicated network environments, running on both real hardware and in virtual machines, I very much disagree. Sure, there are corner cases where you want more flexibility, but for the majority, the encapsulation of complexity is absolutely a good thing. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: media capacity and Fedora 19
On 06/24/2013 07:22 AM, John Reiser wrote: Device sizes vary according to manufacturer and model. 3% is not uncommon. [snip examples] Flash drives, like RAM, (technically, they are non-volatile RAM) always come in binary units. The difference between the nominal and actual capacity is space used for bookkeeping and replacement of faulty blocks. Perhaps the manufacturer of your last example expects the flash chips to be not very reliable. :-) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Minimal install diff from F16 to F19 (TC6)
On 24/06/2013, at 9:00 PM, Chris Adams wrote: Once upon a time, Glen Turner said: What we don't want is a scenario where configuring these protocols on servers has to be done by network engineers. We want them configured from a GUI and supervised by a master daemon. Let's call that NetworkManager. You think hundreds of servers (with untold numbers of VMs), or any complicated networking setups, are going to each have their network configuration managed by a GUI? In that case I think the sysadmin will do what they do now. Run the GUI on their development box, look at the underlying NetworkManager configuration files it created, generalise them, and then farm them out using puppet. What I am arguing against is the current situation where a server administrator has to configure each element of a network configuration, in one configuration file per protocol. It's bad enough as it is now, without data centre networking exploding the number of protocols seen by a VM host. The router experience has been that per-protocol configuration is a dead end. The lesson appears to be that it is better to deploy software which directly addresses use-cases (thus explaining some of the hype around OpenFlow). I see NetworkManager as the best tool to do that job on Linux. To deploy a new network service you deploy the NetworkManager plugin, its dependencies, and a lightweight configuration file written by the NM GUI. I'd hope for a plugin ecosystem, since the number of use cases, and the variations on those, is pretty large. With a use-case approach rather than a protocol configuration approach junior sysadmins don't also need to be network engineers in order to deploy networking features -- ranging from a protocol nightmare like MPLS-based data centre networking; to anycast networking for DNS; to IPVS and HA failover. This sort of mechanism also gives the opportunity to promote good practices which aren't done because they are too hard: such as placing management traffic in a preferenced tc class which will allow device management connectivity during a DoS, or running LLDP on physical interfaces to allow simple discovery of cabling mistakes; from the sysadmins point of view they just enable those plugins. Note that these are runtime plugins -- not configuration-time wizards -- if you have multiple plugins requiring the services of the BGP protocol then they should both succeed. -glen -- Glen Turner http://www.gdt.id.au/~gdt/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
_hardened_build not affecting libtool-compiled libraries
Here's the problem (found by Björn Esser): https://bugzilla.redhat.com/show_bug.cgi?id=977446#c10 and then later on: https://bugzilla.redhat.com/show_bug.cgi?id=977446#c14 So it seems as if _hardened_build for some reason doesn't work for libtool-compiled libraries. It does look as if the correct CFLAGS and LDFLAGS are getting to the build. See for example: http://koji.fedoraproject.org/koji/buildinfo?buildID=429062 http://kojipkgs.fedoraproject.org//packages/nbdkit/1.0.0/4.fc20/data/logs/x86_64/build.log but the plugins from that build are not hardened fully: $ hardening-check ./usr/lib64/nbdkit/plugins/nbdkit-example1-plugin.so ./usr/lib64/nbdkit/plugins/nbdkit-example1-plugin.so: Position Independent Executable: no, regular shared library (ignored) Stack protected: no, not found! Fortify Source functions: no, only unprotected functions found! Read-only relocations: yes Immediate binding: yes Also we had to add an LDFLAGS hack into the %build section to even get this far. Any ideas? Is this a bug or how it should be? 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
/usr/lib64/udev/rules.d/ actually processed?
Does udev/systemd actually process files in rhis directory? I found a couple of files in that directory, from the isdn4k-utils package and from libwacom-0.6.1-1.fc17.x86_64. The lib64 directory isn't mentioned in udev(7), and I can't find it in the /usr/lib/systemd/systemd-udevd binary. -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/lib64/udev/rules.d/ actually processed?
Florian Weimer (fwei...@redhat.com) said: Does udev/systemd actually process files in rhis directory? I found a couple of files in that directory, from the isdn4k-utils package and from libwacom-0.6.1-1.fc17.x86_64. The lib64 directory isn't mentioned in udev(7), and I can't find it in the /usr/lib/systemd/systemd-udevd binary. No. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/lib64/udev/rules.d/ actually processed?
2013/6/24 Florian Weimer fwei...@redhat.com Does udev/systemd actually process files in rhis directory? I found a couple of files in that directory, from the isdn4k-utils package and from libwacom-0.6.1-1.fc17.x86_64. The lib64 directory isn't mentioned in udev(7), and I can't find it in the /usr/lib/systemd/systemd-udevd binary. -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel Also, you can verify with: udevadm test $SYSPATH for example: udevadm test /sys/class/net/wlan0 HTH -- -- Sergio Belkin http://www.sergiobelkin.com Watch More TV http://sebelk.blogspot.com LPIC-2 Certified - http://www.lpi.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: _hardened_build not affecting libtool-compiled libraries
On Mon, Jun 24, 2013 at 8:46 PM, Richard W.M. Jones rjo...@redhat.com wrote: but the plugins from that build are not hardened fully: Isn't it possible that the plugins are just so trivial that there were no opportunities for hardening? $ hardening-check ./usr/lib64/nbdkit/plugins/nbdkit-example1-plugin.so ./usr/lib64/nbdkit/plugins/nbdkit-example1-plugin.so: Position Independent Executable: no, regular shared library (ignored) Stack protected: no, not found! No on-stack arrays that I can find. Fortify Source functions: no, only unprotected functions found! I can see libc calls with compile-time-known destination sizes except for example1_load () where it can be statically proven the call is safe. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/lib64/udev/rules.d/ actually processed?
Reindl Harald (h.rei...@thelounge.net) said: Am 24.06.2013 20:57, schrieb Bill Nottingham: Florian Weimer (fwei...@redhat.com) said: Does udev/systemd actually process files in rhis directory? I found a couple of files in that directory, from the isdn4k-utils package and from libwacom-0.6.1-1.fc17.x86_64. The lib64 directory isn't mentioned in udev(7), and I can't find it in the /usr/lib/systemd/systemd-udevd binary. No what means No in this context? The two questions in the mail were... /usr/lib64/udev/rules.d/ actually processed? Does udev/systemd actually process files in this directory? The answer is ... no. udev/systemd only looks in /usr/lib, /etc, and /run. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/lib64/udev/rules.d/ actually processed?
On 06/24/2013 08:57 PM, Bill Nottingham wrote: Florian Weimer (fwei...@redhat.com) said: Does udev/systemd actually process files in rhis directory? I found a couple of files in that directory, from the isdn4k-utils package and from libwacom-0.6.1-1.fc17.x86_64. The lib64 directory isn't mentioned in udev(7), and I can't find it in the /usr/lib/systemd/systemd-udevd binary. No. Thanks! Bugs filed. -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/lib64/udev/rules.d/ actually processed?
Am 24.06.2013 20:57, schrieb Bill Nottingham: Florian Weimer (fwei...@redhat.com) said: Does udev/systemd actually process files in rhis directory? I found a couple of files in that directory, from the isdn4k-utils package and from libwacom-0.6.1-1.fc17.x86_64. The lib64 directory isn't mentioned in udev(7), and I can't find it in the /usr/lib/systemd/systemd-udevd binary. No what means No in this context? [] /usr/lib64/udev/rules.d/ is ignored because lib64 is wrong [] /usr/lib/udev/rules.d/ is also ignored [] /etc/udev/rules.d/ which is used like below will also not work in F18+ however, only No is not a very good response [root@proxy:~]$ cat /etc/udev/rules.d/50-ats.rules # /etc/udev/rules.d/50-ats.rules # Apache Traffic Server owns disk for RAW access KERNEL==sdc, OWNER=ats signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: _hardened_build not affecting libtool-compiled libraries
On Mon, Jun 24, 2013 at 09:13:29PM +0200, Miloslav Trmač wrote: On Mon, Jun 24, 2013 at 8:46 PM, Richard W.M. Jones rjo...@redhat.com wrote: but the plugins from that build are not hardened fully: Isn't it possible that the plugins are just so trivial that there were no opportunities for hardening? $ hardening-check ./usr/lib64/nbdkit/plugins/nbdkit-example1-plugin.so ./usr/lib64/nbdkit/plugins/nbdkit-example1-plugin.so: Position Independent Executable: no, regular shared library (ignored) Stack protected: no, not found! No on-stack arrays that I can find. Fortify Source functions: no, only unprotected functions found! I can see libc calls with compile-time-known destination sizes except for example1_load () where it can be statically proven the call is safe. Yes, I think you're right. I only checked the simple example* plugins. The xz plugin which is rather more complicated does seem to be protected: $ hardening-check ./usr/lib64/nbdkit/plugins/nbdkit-xz-plugin.so ./usr/lib64/nbdkit/plugins/nbdkit-xz-plugin.so: Position Independent Executable: no, regular shared library (ignored) Stack protected: yes Fortify Source functions: yes (some protected functions found) Read-only relocations: yes Immediate binding: yes 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#) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: _hardened_build not affecting libtool-compiled libraries
On Mon, Jun 24, 2013 at 08:46:51PM +0100, Richard W.M. Jones wrote: On Mon, Jun 24, 2013 at 09:13:29PM +0200, Miloslav Trmač wrote: On Mon, Jun 24, 2013 at 8:46 PM, Richard W.M. Jones rjo...@redhat.com wrote: but the plugins from that build are not hardened fully: Isn't it possible that the plugins are just so trivial that there were no opportunities for hardening? $ hardening-check ./usr/lib64/nbdkit/plugins/nbdkit-example1-plugin.so ./usr/lib64/nbdkit/plugins/nbdkit-example1-plugin.so: Position Independent Executable: no, regular shared library (ignored) Stack protected: no, not found! No on-stack arrays that I can find. Fortify Source functions: no, only unprotected functions found! I can see libc calls with compile-time-known destination sizes except for example1_load () where it can be statically proven the call is safe. Yes, I think you're right. I only checked the simple example* plugins. The xz plugin which is rather more complicated does seem to be protected: $ hardening-check ./usr/lib64/nbdkit/plugins/nbdkit-xz-plugin.so ./usr/lib64/nbdkit/plugins/nbdkit-xz-plugin.so: Position Independent Executable: no, regular shared library (ignored) Stack protected: yes Fortify Source functions: yes (some protected functions found) Read-only relocations: yes Immediate binding: yes Note there is still a problem that an LDFLAGS hack was needed in the spec file, otherwise libtool (or something) eats the hardening LDFLAGS. 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: Fedora 19 Final blocker status: fix and karma requests
On Mon, 2013-06-24 at 15:21 +0200, drago01 wrote: On Mon, Jun 24, 2013 at 3:15 PM, Bill Nottingham nott...@redhat.com wrote: Bruno Wolff III (br...@wolff.to) said: On Sun, Jun 23, 2013 at 18:04:55 -0400, Matthias Clasen mcla...@redhat.com wrote: rpm db 82M I vaguely remember a discussion about dropping this for live images because it gets rebuilt every boot when needed. My memory is that we ended up removing this data while building live images, but haven't looked at it in a long time. It's useful in terms of having a RPM-based manifest of what's on the image, and if you're installing the image to disk, you're going to need it on the installed system... And it allows stuff like yum install foo to work in the live environment. which is *extremely* useful both for normal use and for testing (I do 'yum update anaconda' for a quick test run all the time, fr'instance). Let's not lose that :) -- 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: Fedora 19 Final blocker status: fix and karma requests
On Mon, 2013-06-24 at 07:22 -0400, Jaroslav Reznik wrote: that is, with the old spin-kickstarts and without the above update, we're 19215872 bytes oversize; with the update but old spin-kickstarts, we're 17118720 bytes oversize (the update saves ~2.1MB); and with the update and latest spin-kickstarts, we're 5584384 bytes oversize (the kickstart changes save ~11.5MB). We still need to find another 5.6MB from somewhere. Do we have to be byte strict here? For physical medium sizes, we had to be, this 1 GB is more we set it as we think it's a good idea. Or maybe 1 GB sticks (what's the real size one can use + overlay?) but it's not as strict, as you could pick up bigger one. So my take on that is: * As long as we have a size limit we should be byte-strict. This is just for practical reasons: it's excessively difficult to enforce a 'fuzzy' size cap. It's much easier if it's just Thou Shalt Not. * There is nothing magical about 100 (whatever the zero count is) bytes. We picked the power-of-10 GB as a pessimistic number for the USB stick case: we haven't actually sent anyone to Staples to buy a bunch of USB sticks and figure out exactly how many bytes you can write to one with a given stated capacity, we just figured that was the safe pessimistic number to use. Personally I'm not in any way wedded to that specific size limit for the desktop live image; if the desktop team wants to change it, fine. As I wrote earlier in the thread, I'd just like to make sure the spin doesn't get so large people consider it bloated, and doesn't start interfering with our ability to do the four-desktop live DVD. -- 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
Media Sizes SRPMS DVD
Freemedia Hat on. Seeing the other thread where size limits have been spoken about: https://lists.fedoraproject.org/pipermail/devel/2013-June/184345.html Looking at: http://torrent.fedoraproject.org/ Fedora-18-source-DVD.torrent 8.8GB Hazard a guess F19 will be similar. It's pushed the limit of single-side dual-layer DVD 8.5GB app, there is a cost involved for many to send\give away 16gb Sticks. Could it be split over two std. 4.7 gb DVD, either officially, or give us in Freemedia a green light to split ourselves. -- Regards, Frank When in doubt PANIC! I check for new mail app. 20min www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Media Sizes SRPMS DVD
On Tue, Jun 25, 2013 at 12:13 AM, Frank Murphy frankl...@gmail.com wrote: Freemedia Hat on. Seeing the other thread where size limits have been spoken about: https://lists.fedoraproject.org/pipermail/devel/2013-June/184345.html Looking at: http://torrent.fedoraproject.org/ Fedora-18-source-DVD.torrent 8.8GB Hazard a guess F19 will be similar. It's pushed the limit of single-side dual-layer DVD 8.5GB app, there is a cost involved for many to send\give away 16gb Sticks. Could it be split over two std. 4.7 gb DVD, either officially, or give us in Freemedia a green light to split ourselves. Do people download / use the SRPM DVDs rather then just download the ones they are interested in? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Media Sizes SRPMS DVD
On Tue, 2013-06-25 at 00:45 +0200, drago01 wrote: On Tue, Jun 25, 2013 at 12:13 AM, Frank Murphy frankl...@gmail.com wrote: Freemedia Hat on. Seeing the other thread where size limits have been spoken about: https://lists.fedoraproject.org/pipermail/devel/2013-June/184345.html Looking at: http://torrent.fedoraproject.org/ Fedora-18-source-DVD.torrent 8.8GB Hazard a guess F19 will be similar. It's pushed the limit of single-side dual-layer DVD 8.5GB app, there is a cost involved for many to send\give away 16gb Sticks. Could it be split over two std. 4.7 gb DVD, either officially, or give us in Freemedia a green light to split ourselves. Do people download / use the SRPM DVDs rather then just download the ones they are interested in? It does seem a tad...vestigial. -- 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: Media Sizes SRPMS DVD
Do people download / use the SRPM DVDs rather then just download the ones they are interested in? It does seem a tad...vestigial. If you want to give away copies of the DVD with binaries, then under GPL you must offer the source similarly, or promise to maintain for 3 years a download site with the *CORRESPONDING* source. Your obligation ends three years sooner if you _offer_ the source on DVD at the same time as the binary. As soon as someone declines the source DVD, then you're off the hook. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: _hardened_build not affecting libtool-compiled libraries
On Mon, 24 Jun 2013, Richard W.M. Jones wrote: Note there is still a problem that an LDFLAGS hack was needed in the spec file, otherwise libtool (or something) eats the hardening LDFLAGS. Too often Makefiles contain CFLAGS= / LDFLAGS=, instead of CFLAGS?= / LDFLAGS?= Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Media Sizes SRPMS DVD
On Mon, 2013-06-24 at 16:37 -0700, John Reiser wrote: Do people download / use the SRPM DVDs rather then just download the ones they are interested in? It does seem a tad...vestigial. If you want to give away copies of the DVD with binaries, then under GPL you must offer the source similarly, or promise to maintain for 3 years a download site with the *CORRESPONDING* source. Your obligation ends three years sooner if you _offer_ the source on DVD at the same time as the binary. As soon as someone declines the source DVD, then you're off the hook. Yes. I know that. But that's a boring legal technicality. We can perfectly well satisfy that by providing a 600GB image if we want to. This thread is about the case of someone who for some weird reason *actually wants to burn the stupid image to an actual form of media*. What I'm suggesting is that no-one has any good reason to do that any more. (Our legal obligations may be discharged simply by the fact we keep the entire frozen tree, including SRPMs, for each release on the mirror, but that's an entirely different bikeshed and IANAL). -- 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
File HTTP-Tiny-0.033.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-HTTP-Tiny: c0811f2422da288dae4fd3545599e4e5 HTTP-Tiny-0.033.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
[Bug 977266] New: perl-ExtUtils-Typemaps-Default-1.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=977266 Bug ID: 977266 Summary: perl-ExtUtils-Typemaps-Default-1.04 is available Product: Fedora Version: rawhide Component: perl-ExtUtils-Typemaps-Default Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Assignee: mhron...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mhron...@redhat.com, perl-devel@lists.fedoraproject.org Latest upstream release: 1.04 Current version/release in Fedora Rawhide: 1.01-4.fc19 URL: http://search.cpan.org/dist/ExtUtils-Typemaps-Default/ 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=0AUQyV0QmLa=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-HTTP-Tiny] 0.033 bump
commit b1c794663a966ca5fb44d36aa3e13ad9ac55c906
Author: Petr Písař ppi...@redhat.com
Date: Mon Jun 24 09:53:07 2013 +0200
0.033 bump
perl-HTTP-Tiny.spec |5 -
sources |1 -
2 files changed, 4 insertions(+), 2 deletions(-)
---
diff --git a/perl-HTTP-Tiny.spec b/perl-HTTP-Tiny.spec
index 440908e..9229438 100644
--- a/perl-HTTP-Tiny.spec
+++ b/perl-HTTP-Tiny.spec
@@ -1,5 +1,5 @@
Name: perl-HTTP-Tiny
-Version:0.032
+Version:0.033
Release:1%{?dist}
Summary:Small, simple, correct HTTP/1.1 client
License:GPL+ or Artistic
@@ -69,6 +69,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Mon Jun 24 2013 Petr Pisar ppi...@redhat.com - 0.033-1
+- 0.033 bump
+
* Fri Jun 21 2013 Petr Pisar ppi...@redhat.com - 0.032-1
- 0.032 bump
diff --git a/sources b/sources
index 53d64c0..e69de29 100644
--- a/sources
+++ b/sources
@@ -1 +0,0 @@
-83ff086a9c2c0d373db941a5b27763de HTTP-Tiny-0.032.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-HTTP-Tiny] Cache sources
commit 7d5765658582460ebf5384839dbb4a819de5d38e Author: Petr Písař ppi...@redhat.com Date: Mon Jun 24 09:54:15 2013 +0200 Cache sources -- 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-HTTP-Tiny] Cache sources really
commit 0135c9dba8f110b81a170a0a0c468b211ced9592 Author: Petr Písař ppi...@redhat.com Date: Mon Jun 24 09:57:09 2013 +0200 Cache sources really .gitignore |1 + sources|1 + 2 files changed, 2 insertions(+), 0 deletions(-) --- diff --git a/.gitignore b/.gitignore index ca77665..af02100 100644 --- a/.gitignore +++ b/.gitignore @@ -3,3 +3,4 @@ /HTTP-Tiny-0.030.tar.gz /HTTP-Tiny-0.031.tar.gz /HTTP-Tiny-0.032.tar.gz +/HTTP-Tiny-0.033.tar.gz diff --git a/sources b/sources index e69de29..7b4359e 100644 --- a/sources +++ b/sources @@ -0,0 +1 @@ +c0811f2422da288dae4fd3545599e4e5 HTTP-Tiny-0.033.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
[Bug 976985] perl-HTTP-Tiny-0.033 is available
https://bugzilla.redhat.com/show_bug.cgi?id=976985 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-HTTP-Tiny-0.033-1.fc20 Resolution|--- |RAWHIDE Last Closed||2013-06-24 04:04:15 -- 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=rIK6EbBMola=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 963123] perl-ExtUtils-Typemaps-Default-1.03 is available
https://bugzilla.redhat.com/show_bug.cgi?id=963123 Miro Hrončok mhron...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Resolution|--- |DUPLICATE Last Closed||2013-06-24 07:54:41 --- Comment #4 from Miro Hrončok mhron...@redhat.com --- *** This bug has been marked as a duplicate of bug 977266 *** -- 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=lXcxTDj6q6a=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 977266] perl-ExtUtils-Typemaps-Default-1.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=977266 --- Comment #1 from Miro Hrončok mhron...@redhat.com --- *** Bug 963123 has been marked as a duplicate of this bug. *** -- 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=30RVfdJWsOa=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-Clone] Update dependencies
commit 774cb0c229eea4dd83c4925124f875b9e9630c24
Author: Jitka Plesnikova jples...@redhat.com
Date: Mon Jun 24 14:07:23 2013 +0200
Update dependencies
perl-Clone.spec | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
---
diff --git a/perl-Clone.spec b/perl-Clone.spec
index 65b1112..ab80dab 100644
--- a/perl-Clone.spec
+++ b/perl-Clone.spec
@@ -1,11 +1,12 @@
Name: perl-Clone
Version:0.34
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Recursively copy perl data types
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/Clone
Source:
http://search.cpan.org/CPAN/authors/id/G/GA/GARU/Clone-%{version}.tar.gz
+BuildRequires: perl
BuildRequires: perl(AutoLoader)
BuildRequires: perl(Carp)
BuildRequires: perl(Data::Dumper)
@@ -13,8 +14,12 @@ BuildRequires: perl(DynaLoader)
BuildRequires: perl(Exporter)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Scalar::Util)
+BuildRequires: perl(strict)
BuildRequires: perl(Taint::Runtime)
BuildRequires: perl(Test::More)
+BuildRequires: perl(utf8)
+BuildRequires: perl(vars)
+BuildRequires: perl(warnings)
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
%{?perl_default_filter}
@@ -52,6 +57,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Mon Jun 24 2013 Jitka Plesnikova jples...@redhat.com - 0.34-3
+- Update dependencies
+
* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.34-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
--
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
Broken dependencies: perl-PDL
perl-PDL has broken dependencies in the rawhide tree: On x86_64: perl-PDL-2.4.10-6.fc19.x86_64 requires libgd.so.2()(64bit) On i386: perl-PDL-2.4.10-6.fc19.i686 requires libgd.so.2 Please resolve this as soon as possible. -- 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
Broken dependencies: perl-Bio-SamTools
perl-Bio-SamTools has broken dependencies in the rawhide tree: On x86_64: perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) On i386: perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::PrimarySeq) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-Bio-ASN1-EntrezGene
perl-Bio-ASN1-EntrezGene has broken dependencies in the rawhide tree: On x86_64: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) On i386: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) Please resolve this as soon as possible. -- 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-Boost-Geometry-Utils] New upstream release
commit 8d7943cd3ff890d4f99e200c5ffa7b38c791825c
Author: Miro Hrončok m...@hroncok.cz
Date: Mon Jun 24 14:34:37 2013 +0200
New upstream release
.gitignore |1 +
perl-Boost-Geometry-Utils.spec |5 -
sources|2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 0e269dd..5d3cd97 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
/Boost-Geometry-Utils-0.05.tar.gz
/Boost-Geometry-Utils-0.06.tar.gz
+/Boost-Geometry-Utils-0.15.tar.gz
diff --git a/perl-Boost-Geometry-Utils.spec b/perl-Boost-Geometry-Utils.spec
index 4f5f311..33c7253 100644
--- a/perl-Boost-Geometry-Utils.spec
+++ b/perl-Boost-Geometry-Utils.spec
@@ -1,5 +1,5 @@
Name: perl-Boost-Geometry-Utils
-Version:0.06
+Version:0.15
Release:1%{?dist}
Summary:Boost::Geometry::Utils Perl module
License:GPL+ or Artistic
@@ -43,6 +43,9 @@ find %{buildroot} -type f -name '*.bs' -size 0 -exec rm -f {}
\;
%{_mandir}/man3/*
%changelog
+* Mon Jun 24 2013 Miro Hrončok mhron...@redhat.com - 0.15-1
+- New upstream release
+
* Wed Apr 03 2013 Miro Hrončok mhron...@redhat.com - 0.06-1
- New upstream release
diff --git a/sources b/sources
index 5a97962..6cbaf8e 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-e73373480a3861c3f0cd061079241eab Boost-Geometry-Utils-0.06.tar.gz
+14d705f8efda8db81e118aa8c8a21bed Boost-Geometry-Utils-0.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
File Boost-Geometry-Utils-0.15.tar.gz uploaded to lookaside cache by churchyard
A file has been added to the lookaside cache for perl-Boost-Geometry-Utils: 14d705f8efda8db81e118aa8c8a21bed Boost-Geometry-Utils-0.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
Broken dependencies: perl-Bio-ASN1-EntrezGene
perl-Bio-ASN1-EntrezGene has broken dependencies in the F-19 tree: On x86_64: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) On i386: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-Bio-SamTools
perl-Bio-SamTools has broken dependencies in the F-19 tree: On x86_64: perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) On i386: perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::PrimarySeq) Please resolve this as soon as possible. -- 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 Math-Clipper-1.22.tar.gz uploaded to lookaside cache by churchyard
A file has been added to the lookaside cache for perl-Math-Clipper: b3ab7976e0248cf92ddda7546ad75771 Math-Clipper-1.22.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-Math-Clipper] New upstream release
commit e0ec2e5f28296d5096e88f34ce9e44e014656d51
Author: Miro Hrončok m...@hroncok.cz
Date: Mon Jun 24 14:43:33 2013 +0200
New upstream release
.gitignore |1 +
perl-Math-Clipper.spec |5 -
sources|2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 24302c0..46da2c4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
/Math-Clipper-1.17.tar.gz
/Math-Clipper-1.19.tar.gz
+/Math-Clipper-1.22.tar.gz
diff --git a/perl-Math-Clipper.spec b/perl-Math-Clipper.spec
index b0f199d..e53f1d1 100644
--- a/perl-Math-Clipper.spec
+++ b/perl-Math-Clipper.spec
@@ -1,5 +1,5 @@
Name: perl-Math-Clipper
-Version:1.19
+Version:1.22
Release:1%{?dist}
Summary:Perl wrapper around Clipper library
License:Boost
@@ -51,6 +51,9 @@ find %{buildroot} -type f -name '*.bs' -size 0 -exec rm -f {}
\;
%{_mandir}/man3/*
%changelog
+* Mon Jun 24 2013 Miro Hrončok mhron...@redhat.com - 1.22-1
+- New upstream release
+
* Mon Apr 22 2013 Miro Hrončok mhron...@redhat.com - 1.19-1
- New version compatible with polyclipping 5.1.x
- Patch to don't use bundled C sources updated and renamed
diff --git a/sources b/sources
index a9c5a7c..23e6f7a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-a2533e57ac6ad7e2e154c00e8db0ce36 Math-Clipper-1.19.tar.gz
+b3ab7976e0248cf92ddda7546ad75771 Math-Clipper-1.22.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-Boost-Geometry-Utils/f19] New upstream release
Summary of changes: 8d7943c... New upstream release (*) (*) 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-Math-Clipper/f19] New upstream release
Summary of changes: e0ec2e5... New upstream release (*) (*) 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-CGI] Update dependencies and license
commit d16320fff2cc91841986412414a71ec44f402078
Author: Jitka Plesnikova jples...@redhat.com
Date: Mon Jun 24 16:19:44 2013 +0200
Update dependencies and license
perl-CGI.spec | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
---
diff --git a/perl-CGI.spec b/perl-CGI.spec
index e906357..1c656c6 100644
--- a/perl-CGI.spec
+++ b/perl-CGI.spec
@@ -1,12 +1,13 @@
Name: perl-CGI
Summary:Handle Common Gateway Interface requests and responses
Version:3.63
-Release:2%{?dist}
-License:GPL+ or Artistic
+Release:3%{?dist}
+License:(GPL+ or Artistic) and Artistic 2.0
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/M/MA/MARKSTOS/CGI.pm-%{version}.tar.gz
URL:http://search.cpan.org/dist/CGI
BuildArch: noarch
+BuildRequires: perl
BuildRequires: perl(ExtUtils::MakeMaker)
# Run-requires:
BuildRequires: perl(base)
@@ -15,13 +16,20 @@ BuildRequires: perl(constant)
BuildRequires: perl(Exporter)
BuildRequires: perl(FCGI) = 0.67
BuildRequires: perl(File::Spec) = 0.82
+BuildRequires: perl(overload)
+BuildRequires: perl(strict)
+BuildRequires: perl(vars)
+BuildRequires: perl(warnings)
# Apache modules are optional
# Tests:
+BuildRequires: perl(Config)
BuildRequires: perl(Encode)
+BuildRequires: perl(FileHandle)
BuildRequires: perl(IO::File)
BuildRequires: perl(IO::Handle)
BuildRequires: perl(lib)
BuildRequires: perl(Test::More) = 0.98
+BuildRequires: perl(utf8)
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
Requires: perl(FCGI) = 0.67
Requires: perl(File::Spec) = 0.82
@@ -67,6 +75,10 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Mon Jun 24 2013 Jitka Plesnikova jples...@redhat.com - 3.63-3
+- Specify all dependencies
+- Update License - CGI.pm is distributed under GPL and Artistic 2.0
+
* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 3.63-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
--
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 slic3r-0.9.10b-f13c611.tar.gz uploaded to lookaside cache by churchyard
A file has been added to the lookaside cache for slic3r: 5c7b9271685ea4c537ad411075126439 slic3r-0.9.10b-f13c611.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
[slic3r] New upstream release
commit 2cba691fe1bef215038bfe811831dbda96b4ac39
Author: Miro Hrončok m...@hroncok.cz
Date: Mon Jun 24 16:36:39 2013 +0200
New upstream release
.gitignore |1 +
slic3r.spec | 24 +---
sources |2 +-
3 files changed, 11 insertions(+), 16 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index cb87c0a..06fe978 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
/slic3r-0.9.8-7105243.tar.gz
/slic3r-0.9.9-01e86c2.tar.gz
+/slic3r-0.9.10b-f13c611.tar.gz
diff --git a/slic3r.spec b/slic3r.spec
index cab3380..07f017e 100644
--- a/slic3r.spec
+++ b/slic3r.spec
@@ -1,12 +1,12 @@
Name: slic3r
-Version:0.9.9
-Release:5%{?dist}
+Version:0.9.10b
+Release:1%{?dist}
Summary:G-code generator for 3D printers (RepRap, Makerbot, Ultimaker
etc.)
License:AGPLv3 and CC-BY
# Images are CC-BY, code is AGPLv3
Group: Applications/Engineering
URL:http://slic3r.org/
-%global commit 01e86c26159c5ff0570613831b82f638daf74450
+%global commit f13c611f95059a2530bd30fc3c83362c2d95bf7e
%global shortcommit %(c=%{commit}; echo ${c:0:7})
Source0:
https://github.com/alexrj/Slic3r/archive/%{commit}/%{name}-%{version}-%{shortcommit}.tar.gz
@@ -17,23 +17,16 @@ Patch0: %{name}-datadir.patch
# Reasons are a bit complicated and are described in the patch
Patch1: %{name}-english-locale.patch
-# https://github.com/alexrj/Slic3r/issues/1077
-Patch2: %{name}-config-wizard-crash-fix.patch
-Patch3: %{name}-config-wizard-crash-fix2.patch
-
-# Removed (optional) Net::DBus usage, that causes crashes
-Patch4: %{name}-remove-net-dbus.patch
-
Source1:%{name}.desktop
BuildArch: noarch
-BuildRequires: perl(Boost::Geometry::Utils) = 0.06
+BuildRequires: perl(Boost::Geometry::Utils) = 0.12
BuildRequires: perl(Class::XSAccessor)
BuildRequires: perl(Encode::Locale)
BuildRequires: perl(File::Spec)
BuildRequires: perl(Growl::GNTP)
BuildRequires: perl(IO::Scalar)
BuildRequires: perl(List::Util)
-BuildRequires: perl(Math::Clipper) = 1.17
+BuildRequires: perl(Math::Clipper) = 1.22
BuildRequires: perl(Math::ConvexHull::MonotoneChain)
BuildRequires: perl(Math::ConvexHull) = 1.0.4
BuildRequires: perl(Math::Geometry::Voronoi)
@@ -69,9 +62,6 @@ for more information.
%setup -qn Slic3r-%{commit}
%patch0 -p1
%patch1 -p1
-%patch2 -p1
-%patch3 -p1
-%patch4 -p1
%build
perl Build.PL installdirs=vendor optimize=$RPM_OPT_FLAGS
@@ -104,6 +94,10 @@ desktop-file-install
--dir=%{buildroot}%{_datadir}/applications %{SOURCE1}
%{_mandir}/man3/*
%changelog
+* Mon Jun 24 2013 Miro Hrončok mhron...@redhat.com - 0.9.10b-1
+- New upstream release
+- Removed some already merged patches
+
* Tue Apr 23 2013 Miro Hrončok mhron...@redhat.com - 0.9.9-5
- Added BR perl(Encode::Locale)
diff --git a/sources b/sources
index 1101ced..09bfbb8 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-5fbe7a813e12fdc37cc1d4b913240556 slic3r-0.9.9-01e86c2.tar.gz
+5c7b9271685ea4c537ad411075126439 slic3r-0.9.10b-f13c611.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
File Math-PlanePath-105.tar.gz uploaded to lookaside cache by churchyard
A file has been added to the lookaside cache for perl-Math-PlanePath: 24cb8fb383762a9391be607181d933ce Math-PlanePath-105.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-Math-PlanePath] New upstream release
commit dcf548c9e0ef81b080c575c9800aa921883da3f3
Author: Miro Hrončok m...@hroncok.cz
Date: Mon Jun 24 18:35:32 2013 +0200
New upstream release
.gitignore |1 +
perl-Math-PlanePath.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 27b8a84..6fce229 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
/Math-PlanePath-98.tar.gz
+/Math-PlanePath-105.tar.gz
diff --git a/perl-Math-PlanePath.spec b/perl-Math-PlanePath.spec
index 508397c..487d17f 100644
--- a/perl-Math-PlanePath.spec
+++ b/perl-Math-PlanePath.spec
@@ -1,6 +1,6 @@
Name: perl-Math-PlanePath
-Version:98
-Release:2%{?dist}
+Version:105
+Release:1%{?dist}
Summary:Mathematical paths through the 2-D plane
License:GPLv3+
Group: Development/Libraries
@@ -59,6 +59,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Mon Jun 24 2013 Miro Hrončok mhron...@redhat.com - 105-1
+- New upstream release
+
* Sat Feb 09 2013 Miro Hrončok mhron...@redhat.com - 98-2
- Using original homepage for URL
- Updated summary and description to suit whole package
diff --git a/sources b/sources
index a41954b..8f10f08 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-21fc008e59c5a28ef16a46d62a044fa3 Math-PlanePath-98.tar.gz
+24cb8fb383762a9391be607181d933ce Math-PlanePath-105.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-Math-PlanePath/f19] New upstream release
Summary of changes: dcf548c... New upstream release (*) (*) 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 971096] CVE-2013-2145 perl-Module-Signature: arbitrary code execution when verifying SIGNATURE
https://bugzilla.redhat.com/show_bug.cgi?id=971096 --- Comment #8 from Fedora Update System upda...@fedoraproject.org --- perl-Module-Signature-0.73-1.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report. -- 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=Bv87iSN4jja=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 977592] New: svk throws perl errors while syncing and fails to update properly
https://bugzilla.redhat.com/show_bug.cgi?id=977592 Bug ID: 977592 Summary: svk throws perl errors while syncing and fails to update properly Product: Fedora Version: 18 Component: perl-SVK Severity: high Priority: unspecified Assignee: ppi...@redhat.com Reporter: warl...@mit.edu QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Description of problem: I just upgraded my laptop from F15 to F18 and now SVK throws perl errors when trying to sync and fails to complete an update properly. Version-Release number of selected component (if applicable): perl-SVK-2.2.3-9.fc18.noarch How reproducible: It is 100% reproducible in my case, but that's because I had an existing mirror and checkout from F15 (and earlier). I have not tried blowing away all my data, but I shouldn't have to. Steps to Reproduce: 1. svk sync //mirrors/gnucash(choose your own local mirror) 2. svk update(from a WC checkout) 3. Actual results: The SYNC: svk sync //mirrors/gnucash Use of qw(...) as parentheses is deprecated at /usr/share/perl5/vendor_perl/SVK/Mirror.pm line 455. Syncing svn+ssh://svn.gnucash.org/repo/gnucash Use of uninitialized value in pattern match (m//) at /usr/share/perl5/vendor_perl/Data/Hierarchy.pm line 215. The Update: svk up Use of qw(...) as parentheses is deprecated at /usr/share/perl5/vendor_perl/SVK/Mirror.pm line 455. Use of uninitialized value $ARGV[0] in ucfirst at /usr/share/perl5/vendor_perl/App/CLI/Command.pm line 116. Syncing //mirrors/gnucash/branches/2.4(/mirrors/gnucash/branches/2.4) in /home/warlord/src/gnucash/gnucash-2.4/src to 20426. ChangeLog.2011 - skipped ChangeLog.2012 - skipped g accounts/ru/acctchrt_common.gnucash-xea ChangeLog - skipped g configure.ac g Makefile.am g NEWS g po/en_GB.po g po/nl.po g po/da.po g po/de.po g packaging/win32/install-impl.sh g packaging/win32/defaults.sh g packaging/win32/gnucash.iss.in g macros/ac_python_devel.m4 g src/report/standard-reports/budget-flow.scm g src/report/standard-reports/register.scm g src/engine/gnc-commodity.c g src/import-export/import-main-matcher.c g doc/README-nl.win32-bin.txt Use of uninitialized value in pattern match (m//) at /usr/share/perl5/vendor_perl/Data/Hierarchy.pm line 215. ... And if I run it again I get the exact same output. The first time I ran it all the g's were G's (capitals), because it did pull down the changes. However it clearly never marked that those changes took, and isn't recognizing them. Expected results: No perl warnings, and an update that actually succeeds. Additional info: I realize I could be using git, but I have some svn packages that I've been using for a long time in SVK so I'd like to be able to continue using SVK. Downloading into git-svn would take a long time for some of these repositories. -- 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=7qFJok6fmpa=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 914316] perl-Net-Twitter-4.00006 is available
https://bugzilla.redhat.com/show_bug.cgi?id=914316 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Net-Twitter-4.6-1. ||fc17 Resolution|--- |ERRATA Last Closed||2013-06-24 23:24:13 --- Comment #10 from Fedora Update System upda...@fedoraproject.org --- perl-Net-Twitter-4.6-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. -- 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=lrMfLRMYYqa=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 914316] perl-Net-Twitter-4.00006 is available
https://bugzilla.redhat.com/show_bug.cgi?id=914316 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Fixed In Version|perl-Net-Twitter-4.6-1. |perl-Net-Twitter-4.6-1. |fc17|fc18 --- Comment #11 from Fedora Update System upda...@fedoraproject.org --- perl-Net-Twitter-4.6-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report. -- 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=S5kaTzkWRBa=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
[389-devel] Please review: ticket 512 (cont') - improve performance of vattr code
This review reimplements the virtual attribute cache (per entry) within a linked list. https://fedorahosted.org/389/ticket/512 https://fedorahosted.org/389/attachment/ticket/512/0004-Ticket-512-improve-performance-of-vattr-code.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Build failed in Jenkins: 389-ds-base #52
See http://jenkins.cloud.fedoraproject.org/job/389-ds-base/52/changes Changes: [Noriko Hosoi] Ticket 123 - Enhancement request:whoami extended operation -- Started by an SCM change Building remotely on Fedora18 in workspace http://jenkins.cloud.fedoraproject.org/job/389-ds-base/ws/ Checkout:389-ds-base / http://jenkins.cloud.fedoraproject.org/job/389-ds-base/ws/ - hudson.remoting.Channel@7f0a0a9a:Fedora18 Using strategy: Default Last Built Revision: Revision beaad2ce018235fa5bf4ae135d36e7b8bba8b909 (origin/master) Wiping out workspace first. Cloning the remote Git repository Cloning repository http://git.fedorahosted.org/cgit/389/ds.git/ git --version git version 1.8.1.4 Fetching upstream changes from http://git.fedorahosted.org/cgit/389/ds.git/ Commencing build of Revision 465fa850af4658d18235f26f6e05c5a386e70e3d (origin/master) Checking out Revision 465fa850af4658d18235f26f6e05c5a386e70e3d (origin/master) [389-ds-base] $ /bin/sh -xe /tmp/hudson7578353487074993089.sh ++ date +%s + ts=1372118997 + baseurl=http://jenkins.cloud.fedoraproject.org/job/389-ds-base/ws + buildlog=build.1372118997.txt + buildwarns=build-warns.1372118997.txt + url=http://jenkins.cloud.fedoraproject.org/job/389-ds-base/ws/build.1372118997.txt + urlwarn=http://jenkins.cloud.fedoraproject.org/job/389-ds-base/ws/build-warns.1372118997.txt ++ rpm --eval %optflags + CFLAGS='-O2 -g -Wall' + CXXFLAGS='-O2 -g -Wall' + ./configure --with-tmpfiles-d=/etc/tmpfiles.d --with-openldap --enable-autobind --with-selinux --with-systemdsystemunitdir=/lib/systemd/system --with-systemdsystemconfdir=/etc/systemd/system --enable-debug + make + cat + awk -f parse_build.awk build.1372118997.txt + '[' -s build-warns.1372118997.txt ']' + echo Build http://jenkins.cloud.fedoraproject.org/job/389-ds-base/52/ failed Build http://jenkins.cloud.fedoraproject.org/job/389-ds-base/52/ failed + echo There are build warnings There are build warnings + echo Build warnings: http://jenkins.cloud.fedoraproject.org/job/389-ds-base/ws/build-warns.1372118997.txt Build warnings: http://jenkins.cloud.fedoraproject.org/job/389-ds-base/ws/build-warns.1372118997.txt + exit 1 Build step 'Execute shell' marked build as failure -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
