Re: Looking for dnssec-triggerd alpha testers!
On 09/17/2011 08:00 PM, Paul Wouters wrote: Hi developers of NM and Fedora, We are trying to get DNSSEC validation on the end nodes. One way of doing that is to run a caching resolver on every host, but that strains the DNS infrastructure because all DNS caches would be circumvented. Since DNSSEC data is signed, you can obtain it via insecure channels and then validate it. So we want to try and use the DHCP obtained DNS caches as much as possible. However, there are many networks out there that mess with DNS, and sometimes we have to accept fake DNS to get past hotspot/login pages. Sometimes the DNS proxies are broken for DNSSEC and we would prefer to run the queries ourselves to the authoritative nameservers without using the broken caching middle layer. This is where dnssec-trigger comes in. Users run a local validating resolver with DNSSEC support (unbound) that can be dynamically reconfigured to use different forwarders. dnssec-triggerd checks the DNS path by sending a query to a root name server (via the caching resolver or directly) and determines if the DHCP obtained DNS servers can be used, or if unbound should attempt it directly. Or in the worst case, if DNS should be disabled completely because it is proven untrusted. dnssec-trigger consists of NetworkManager hooks, a daemon that rewrites resolv.conf and signals unbound, and a gnome applet to show the user the DNSSEC status and to warn the user if the network is (too?) unsafe to use. We'd love to hear from Fedora people how well this integrates and works in various hotspot scenarios. We'd love to hear from NM developers to see if the hooking have all been done in proper ways. Hello Paul, this is a great idea and work. We talked (inside Red Hat) about similar approach how to secure the clients but this proposal is better, ready for use, and I like it. The only one question for discussion is if we should disable DNSSEC when it is proven untrusted. Previously, I tended to use similar approach but after discussion with security guys I think we shouldn't go this way. The main problem is how to differ between misconfigured ISP's proxy/server which strips DNSSEC data (good example is bind 9.3, still widely used, and it's default dnssec-enable no; setting) and MITM attack which strips DNSSEC data. Due this I think we should always enforce DNSSEC, user should explicitly modify unbound or riggerd configuration to disable DNSSEC. Otherwise we can end with same situation as with X.509 certs on the Internet - when cert is bad, everyone automatically accept it and there is no security benefit. Another argument for enforcing DNSSEC is that in future (well, I believe :) ) DNS will be used as storage for X.509 certs, SSHFP records and other stuff. If we adopt leisure approach (automatic disabling of DNSSEC or ability to click somewhere on the applet to disable DNSSEC) then we can end in the same situation as we are currently with X.509 certs. Everyone will simply click on disable DNSSEC button or, when MITM attack will be in progress, DNSSEC will be automatically disabled. This will degrade DNSSEC benefits. When we enforce DNSSEC there will be definitely some users which will end with broken DNS but this is a great opportunity how to really secure end nodes. Comments are welcomed. Regards, Adam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for dnssec-triggerd alpha testers!
On 09/20/2011 05:19 PM, Dan Williams wrote: On Sat, 2011-09-17 at 14:00 -0400, Paul Wouters wrote: Hi developers of NM and Fedora, We are trying to get DNSSEC validation on the end nodes. One way of doing that is to run a caching resolver on every host, but that strains the DNS infrastructure because all DNS caches would be circumvented. Since DNSSEC data is signed, you can obtain it via insecure channels and then validate it. So we want to try and use the DHCP obtained DNS caches as much as possible. However, there are many networks out there that mess with DNS, and sometimes we have to accept fake DNS to get past hotspot/login pages. Sometimes the DNS proxies are broken for DNSSEC and we would prefer to run the queries ourselves to the authoritative nameservers without using the broken caching middle layer. This is where dnssec-trigger comes in. Users run a local validating resolver with DNSSEC support (unbound) that can be dynamically reconfigured to use different forwarders. dnssec-triggerd checks the DNS path by sending a query to a root name server (via the caching resolver or directly) and determines if the DHCP obtained DNS servers can be used, or if unbound should attempt it directly. Or in the worst case, if DNS should be disabled completely because it is proven untrusted. dnssec-trigger consists of NetworkManager hooks, a daemon that rewrites resolv.conf and signals unbound, and a gnome applet to show the user the DNSSEC status and to warn the user if the network is (too?) unsafe to use. We can do a much better job of NM integration here. We've already got a DNS local-caching plugin for dnsmasq, but that doesn't do IPv6 as well. We can easily create one for unbound. I tried to do one for bind, but bind's config format is arcane enough that I gave up trying to get it to do what I needed (local caching nameserver). NM handles rewriting resolv.conf too, so that would no longer be required here. Another way is to use unbound/bind default configuration files and don't pass NM-generated configs. This way you (and other NM developers) doesn't have to know unbound/bind configuration details. Next advantage is that enthusiastic users and admins can modify unbound/bind configuration without touching NM. By default, both bind and unbound are installed as DNSSEC-validating local resolvers so NM can only spawn unbound/bind. Also, I saw mention of DHCP obtained DNS caches at the top of the mail; can somebody provide a pointer to how that works? It's something we should also expose via NM. NM already lets clients access all the DHCP-provided options via the D-Bus interface, but if this requires the DHCP client to request specific options from the server, that's something NM would want to know as well. With DHCP obtained DNS caches Paul probably meant the nameservers which you got via DHCP (aka ISP's nameservers). Those servers perform caching so local unbound/bind will use them and there won't be increased DNS traffic over the Internet due bypassing those caches. We'd love to hear from Fedora people how well this integrates and works in various hotspot scenarios. We'd love to hear from NM developers to see if the hooking have all been done in proper ways. Yeah, a DNS plugin would be the best way to go here. I've already implemented a local caching DNS plugin for dnsmasq, including reverse resolution for IPv4 addresses so that stuff like VPN IP lookups work correctly when they are in-use. I can provide pointers on how to set up a new DNS plugin, but the existing ones are here: http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/dns-manager I just checked the NetworkManager/src/dns-manager/nm-dns-bind.c and this plugin already does nearly everything what we need (it spawns named and catches important info from DHCP). With little hacking I'm sure we can modify it to serve us as we need. Regards, Adam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
GDBM upgrade in F17
Jan Horak (hhorak) is going to upgrade GDBM to version with new SONAME in F17. Because rel-engs refused to provide dedicated build root, the upgrade will be performed in F17 directly. That means Perl, Pyhon and other default-build-root packages will disable support for GDBM temporarily. So if your package needs GDBM support in those languages, please wait until new GDMB and other packages (Perl, Python and similar) get recompiled again against this new GDBM. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
On Tue, 2011-09-20 at 12:21 -0400, Adam Jackson wrote: On 9/20/11 11:43 AM, Nils Philippsen wrote: On Tue, 2011-09-20 at 11:33 -0400, Adam Jackson wrote: Of course, the accounts system _still_ doesn't have groups, five years later, so provenpackager is the big hammer we have. We could get groups any day now, that'd be just fine. Do you mean groups of groups, like in provenpackager-kde, provenpackager-gnome, and provenpackager means all of these? I don't see any real reason to do that instead of just unix-style groups, but either one would be an improvement. Hmm, it seems I don't quite get what you mean with the accounts system _still_ doesn't have groups -- while provenpackager among others is a group. Would you please elaborate? TIA, Nils -- Nils Philippsen Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: perl-Test-Version
perl-Test-Version has broken dependencies in the F-16 tree: On x86_64: perl-Test-Version-1.0.0-3.fc15.noarch requires perl(:MODULE_COMPAT_5.12.4) On i386: perl-Test-Version-1.0.0-3.fc15.noarch requires perl(:MODULE_COMPAT_5.12.4) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: GDBM upgrade in F17
On Wed, 2011-09-21 at 10:59 +, Petr Pisar wrote: Jan Horak (hhorak) is going to upgrade GDBM to version with new SONAME in F17. Because rel-engs refused to provide dedicated build root, the upgrade will be performed in F17 directly. That means Perl, Pyhon and other default-build-root packages will disable support for GDBM temporarily. So if your package needs GDBM support in those languages, please wait until new GDMB and other packages (Perl, Python and similar) get recompiled again against this new GDBM. Have you tried building gdbm, creating the buildroot in bodhi, then untagging gdbm from f17 instead? Nils -- Nils Philippsen Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
On Tue, 2011-09-20 at 22:25 +0200, Ralf Corsepius wrote: On 09/20/2011 05:52 PM, Nils Philippsen wrote: On Tue, 2011-09-20 at 15:19 +0200, Ralf Corsepius wrote: When you have a closer look, you'll notice that such mass rebuilts were being delayed by QA's delay queue and now are stuck. I didn't want to (re)start that particular discussion ;-). We need some guidelines who should drive rebuilds in such a situation, regardless of whether it happens in Rawhide or Branched or wherever. a) These situation can only happen in release branches. Uhm, no. A library SONAME bump can happen in Rawhide as well as in branches and if dependent packages don't get built with the new version, things are broken. Waiting for dependent components to be built at their maintainers leisure or whenever a mass rebuild comes around isn't a solution, not if we want to have a more stable Rawhide. Nils -- Nils Philippsen Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GDBM upgrade in F17
On Wed, 2011-09-21 at 11:29 +, Petr Pisar wrote: On 2011-09-21, Nils Philippsen n...@redhat.com wrote: On Wed, 2011-09-21 at 10:59 +, Petr Pisar wrote: Jan Horak (hhorak) is going to upgrade GDBM to version with new SONAME in F17. Because rel-engs refused to provide dedicated build root, the upgrade will be performed in F17 directly. That means Perl, Pyhon and other default-build-root packages will disable support for GDBM temporarily. So if your package needs GDBM support in those languages, please wait until new GDMB and other packages (Perl, Python and similar) get recompiled again against this new GDBM. Have you tried building gdbm, creating the buildroot in bodhi, then untagging gdbm from f17 instead? Bodhi and F17? Why not, you're not trying to submit an update, are you ;-)? As of buildroot overrides, bodhi isn't used solely for updates anymore (even though the URL ends in /updates/). The buildroot override document[1] doesn't mention that this would be limited to branches. Nils [1]: http://fedoraproject.org/wiki/Bodhi/BuildRootOverrides -- Nils Philippsen Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GDBM upgrade in F17
On 09/21/2011 01:14 PM, Nils Philippsen wrote: On Wed, 2011-09-21 at 10:59 +, Petr Pisar wrote: Jan Horak (hhorak) is going to upgrade GDBM to version with new SONAME in F17. Because rel-engs refused to provide dedicated build root, the upgrade will be performed in F17 directly. That means Perl, Pyhon and other default-build-root packages will disable support for GDBM temporarily. So if your package needs GDBM support in those languages, please wait until new GDMB and other packages (Perl, Python and similar) get recompiled again against this new GDBM. Have you tried building gdbm, creating the buildroot in bodhi, then untagging gdbm from f17 instead? Nils I understand that buildroot override in bodhi works for f16 and lower only, am I wrong? I wanted to create a new target to make it safe, but after a discussion with rel-engs it appears to be too big hammer for such a few of packages. A temporary perl built without gdbm seems to be fine enough for this purpose. Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GDBM upgrade in F17
Dne 21.9.2011 13:45, Honza Horak napsal(a): On 09/21/2011 01:14 PM, Nils Philippsen wrote: On Wed, 2011-09-21 at 10:59 +, Petr Pisar wrote: Jan Horak (hhorak) is going to upgrade GDBM to version with new SONAME in F17. Because rel-engs refused to provide dedicated build root, the upgrade will be performed in F17 directly. That means Perl, Pyhon and other default-build-root packages will disable support for GDBM temporarily. So if your package needs GDBM support in those languages, please wait until new GDMB and other packages (Perl, Python and similar) get recompiled again against this new GDBM. Have you tried building gdbm, creating the buildroot in bodhi, then untagging gdbm from f17 instead? Nils I understand that buildroot override in bodhi works for f16 and lower only, am I wrong? I wanted to create a new target to make it safe, but after a discussion with rel-engs it appears to be too big hammer for such a few of packages. A temporary perl built without gdbm seems to be fine enough for this purpose. Honza Its strange to me. There are concerns to have Rawhide usable but at the end, if somebody wants to prevents problems using dedicated build root, it is denied by Rel-Engs, because it is probably to much work. This is disappointing. Vit -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Buildroot overrides in Rawhide, was: GDBM upgrade in F17
On Wed, Sep 21, 2011 at 14:01:10 +0200, Nils Philippsen n...@redhat.com wrote: It's unclear to me why this would need to be the case. Creating a build root for what we perceive as Rawhide should be just the same as Chain building is allowed for rawhide to help get groups of packages built. What I have personally done is asked to co-maintain dependent packages so that I can handle soname bumps myself. While this probably isn't practical for packages with huge numbers of dependent packages, it seems reasonable for something on the order of a dozen. It shouldn't really involve rel-eng at all, Bodhi buildroot overrides should just do this as it does with branched releases. Note that in rawhide, all successful builds end up in the build root. The real difference is that with bodhi you can delay the updates going out to users until all the related updates are available. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for dnssec-triggerd alpha testers!
On Wed, 2011-09-21 at 12:45 +, Jóhann B. Guðmundsson wrote: On 09/21/2011 10:21 AM, Adam Tkac wrote: Another argument for enforcing DNSSEC is that in future (well, I believe :) ) DNS will be used as storage for X.509 certs, SSHFP records and other stuff. If we adopt leisure approach (automatic disabling of DNSSEC or ability to click somewhere on the applet to disable DNSSEC) then we can end in the same situation as we are currently with X.509 certs. Everyone will simply click on disable DNSSEC button or, when MITM attack will be in progress, DNSSEC will be automatically disabled. This will degrade DNSSEC benefits. Beside the obvious design flaws in dnssec and in the long run they only solve a part of the problem how can you even consider removing the ability for disabling dnssec when implementing and deploying and running dnssec increases the complexity times hundred and people and isp's alike cant even implement and properly run a simple dns server as it is now? You probably did not understand the meaning of removing the ability for disabling dnssec in the Adam's e-mail. It is not meant to disable the ability to not use of dnssec completely but that it should not be possible to simply click away any failures to verify dnssec for domains that are marked as that they should be validated by dnssec. Simply if a domain is marked as dnssec enabled in the parent record then it must have correct dnssec entries or it should not be accepted. Domains that are not marked as dnssec enabled (that should be the default for admins that are unable or unwilling to use dnssec on their domains) are not affected in any way. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for dnssec-triggerd alpha testers!
On 09/21/2011 01:00 PM, Tomas Mraz wrote: You probably did not understand the meaning of removing the ability for disabling dnssec in the Adam's e-mail. It is not meant to disable the ability to not use of dnssec completely but that it should not be possible to simply click away any failures to verify dnssec for domains that are marked as that they should be validated by dnssec. Simply if a domain is marked as dnssec enabled in the parent record then it must have correct dnssec entries or it should not be accepted. Domains that are not marked as dnssec enabled (that should be the default for admins that are unable or unwilling to use dnssec on their domains) are not affected in any way. You are right I misunderstood him. By all means remove the users availability to simply click them selves away from that. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: perl-BerkeleyDB
perl-BerkeleyDB has broken dependencies in the rawhide tree: On x86_64: perl-BerkeleyDB-0.49-1.fc17.x86_64 requires libdb = 0:5.2.28 On i386: perl-BerkeleyDB-0.49-1.fc17.i686 requires libdb = 0:5.2.28 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Buildroot overrides in Rawhide, was: GDBM upgrade in F17
On 2011-09-21, Bruno Wolff III br...@wolff.to wrote: On Wed, Sep 21, 2011 at 14:01:10 +0200, Nils Philippsen n...@redhat.com wrote: It's unclear to me why this would need to be the case. Creating a build root for what we perceive as Rawhide should be just the same as Chain building is allowed for rawhide to help get groups of packages built. Chain building helps but does not solve this problem. In gdbm---perl scenario both packages are in set of default build environment, so once you upgrade gdbm, you cannot install perl resulting in mock failure in root preparation stage. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20110921 changes
On Wed, Sep 21, 2011 at 01:43:16PM +, Rawhide Report wrote: cduce-0.5.3-8.fc15.x86_64 requires ocaml(Unixqueue) = 0:5f2882e466b57c733efe14816d08229e All these ocaml broken deps are because of the update to ocamlnet noted on this list a couple of days ago. I will attempt to push new builds for all the broken packages today. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
On 09/21/2011 01:25 PM, Nils Philippsen wrote: On Tue, 2011-09-20 at 22:25 +0200, Ralf Corsepius wrote: On 09/20/2011 05:52 PM, Nils Philippsen wrote: On Tue, 2011-09-20 at 15:19 +0200, Ralf Corsepius wrote: When you have a closer look, you'll notice that such mass rebuilts were being delayed by QA's delay queue and now are stuck. I didn't want to (re)start that particular discussion ;-). We need some guidelines who should drive rebuilds in such a situation, regardless of whether it happens in Rawhide or Branched or wherever. a) These situation can only happen in release branches. Uhm, no. A library SONAME bump can happen in Rawhide as well as in branches and if dependent packages don't get built with the new version, things are broken. Right. They break in rawhide, where issues are inevitable and can be addressed within short terms because maintainers are not being forced to play 10 days per package update you wait for me/I wait for you delay ping-pong. Or am I misunderstanding? Are you referring to points in time when stable fedoras are being sync'ed and inherit broken deps during this fork? If this happens, something would be very defective with Fedora's rel-eng's procedures. The situation currently to be found in f16 is longer dep chains being in inconsistent build-state (showing as broken deps), because fixed packages in *-testing did not make it into stable in time because of these QA delays and because Fedora policies _forbit_ fixing these at this point in time. Waiting for dependent components to be built at their maintainers leisure or whenever a mass rebuild comes around isn't a solution, not if we want to have a more stable Rawhide. To we want this? I don't. To me, rawhide is the big package dumping ground for the bleading edge. Certainly, it should be as little broken as possible, but its brokenness is part of its working principle and inevitable to me. That said, I find a stable rawhide to be nonrealisting and inapplicable. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GDBM upgrade in F17
On 2011-09-21, Petr Pisar ppi...@redhat.com wrote: That means Perl, Pyhon and other default-build-root packages will disable support for GDBM temporarily. So if your package needs GDBM support in those languages, please wait until new GDMB and other packages (Perl, Python and similar) get recompiled again against this new GDBM. State info: Because bug in glibc-2.14.90-9.x86_64 (https://bugzilla.redhat.com/show_bug.cgi?id=740235), perl cannot be recompiled now, so you can still enjoy GDBM-featured Perl. I will send another notification once pruned Perl reaches F17 build root. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for dnssec-triggerd alpha testers!
On Wed, 21 Sep 2011, Adam Tkac wrote: this is a great idea and work. We talked (inside Red Hat) about similar approach how to secure the clients but this proposal is better, ready for use, and I like it. Great. Please test and give us feedback :) The only one question for discussion is if we should disable DNSSEC when it is proven untrusted. Previously, I tended to use similar approach but after discussion with security guys I think we shouldn't go this way. The main problem is how to differ between misconfigured ISP's proxy/server which strips DNSSEC data (good example is bind 9.3, still widely used, and it's default dnssec-enable no; setting) and MITM attack which strips DNSSEC data. Due this I think we should always enforce DNSSEC, user should explicitly modify unbound or riggerd configuration to disable DNSSEC. Otherwise we can end with same situation as with X.509 certs on the Internet - when cert is bad, everyone automatically accept it and there is no security benefit. Currently, a big warning comes that tells you you can either continue from your current cache (with causes new lookups to fail) or to go insecure. We're trying to gain more hotspot experiences to see how well this works. If we can do auth dns ourselves in the majority of causes, we might be better of then we think. Networks with bind 9.3 tend to not firewall port 53, so moving in such a network should be mostly transparent. Another argument for enforcing DNSSEC is that in future (well, I believe :) ) DNS will be used as storage for X.509 certs, SSHFP records and other stuff. If we adopt leisure approach (automatic disabling of DNSSEC or ability to click somewhere on the applet to disable DNSSEC) then we can end in the same situation as we are currently with X.509 certs. There is a difference still. Applications can still see the difference between the localhost resolver returning the AD bit or not. So going insecure will render the sshfp/dane records uselesss, they will not be trusted. Note also that with dnssec chains via TLS, either as a TLS extension or as part of a certificate blob, the non-attack case will be able to work in the browser even if fetching DNS via the network is broken/misconfigured. Everyone will simply click on disable DNSSEC button or, when MITM attack will be in progress, DNSSEC will be automatically disabled. This will degrade DNSSEC benefits. When we enforce DNSSEC there will be definitely some users which will end with broken DNS but this is a great opportunity how to really secure end nodes. One of the reasons we are trying this, is to gain experience in how bad DNS at the endnode really is. So I agree, we're not yet ready to inflict it on mortals, just on developers :) Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Buildroot overrides in Rawhide, was: GDBM upgrade in F17
On Wed, 21 Sep 2011 14:01:10 +0200 Nils Philippsen n...@redhat.com wrote: On Wed, 2011-09-21 at 13:53 +0200, Vít Ondruch wrote: Dne 21.9.2011 13:45, Honza Horak napsal(a): I understand that buildroot override in bodhi works for f16 and lower only, am I wrong? I wanted to create a new target to make it safe, but after a discussion with rel-engs it appears to be too big hammer for such a few of packages. A temporary perl built without gdbm seems to be fine enough for this purpose. Honza It seems that you're right, I got this when I tried to submit a buildroot override for the current Rawhide dcraw package: Error: Could not determine release for dcraw-9.10-1.fc17 with tags ['f17'] It's unclear to me why this would need to be the case. Creating a build root for what we perceive as Rawhide should be just the same as Bodhi doesn't create buildroots. It just allows you to override the process on non rawhide branches and get a package into the koji buildroot before it normally would be. There's only one buildroot for each build target... ie, rawhide, f16, f15, f14, f15-gnome, etc. Its strange to me. There are concerns to have Rawhide usable but at the end, if somebody wants to prevents problems using dedicated build root, it is denied by Rel-Engs, because it is probably to much work. This is disappointing. Every target added that has a buildroot that must be generated means more overhead for koji. It has to populate and createrepo the buildroots a lot. Doing more means that other ones have to wait. It shouldn't really involve rel-eng at all, Bodhi buildroot overrides should just do this as it does with branched releases. I don't understand how they could here. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Buildroot overrides in Rawhide, was: GDBM upgrade in F17
On Wed, Sep 21, 2011 at 6:50 AM, Bruno Wolff III br...@wolff.to wrote: Chain building is allowed for rawhide to help get groups of packages built. The chain-build facility is very useful. But when you've got a chain of 3 packages to build, and the build of the second one fails, then you're done for the day. You can't restart the chain-build, because the first package has already been built. You can't restart the chain-build from the second package, because the already-built first package won't be available to build against until the next repo compose. Is there any way of addressing this that isn't prohibitively expensive? That is, can we either: - make chain-build atomic, so the failure of any build causes all builds in the chain to be marked as failed (allows restarting the chain-build); or - have a buildroot-override kind of functionality, where we can ask that the newly built packages be added to the Rawhide buildroot temporarily, so that the chain-build can be restarted at the failed build? Regards, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for dnssec-triggerd alpha testers!
On Wed, 21 Sep 2011, Tomas Mraz wrote: solve a part of the problem how can you even consider removing the ability for disabling dnssec when implementing and deploying and running dnssec increases the complexity times hundred and people and isp's alike cant even implement and properly run a simple dns server as it is now? Let's not try and turn this into a dnssec bashing thread please. Fedora has been shipping with turn on dnssec aware servers that do a pretty decent job. ISPs can simple install bind or unbound in Fedora or RHEL and dnssec just works. (especially on ISP networks that have no broken cheap consumer hardware issues) You probably did not understand the meaning of removing the ability for disabling dnssec in the Adam's e-mail. It is not meant to disable the ability to not use of dnssec completely but that it should not be possible to simply click away any failures to verify dnssec for domains that are marked as that they should be validated by dnssec. right. the big problem is not working around a broken network or a network with an attacker. The problem is false positives due to the pletora of hotspot mangling techniques out there. Ideally, NetworkManager would deal with the whole hotspot detection and lift any blocking done by the hotspot pre-login, and then dnssec-triggerd in some way or shape can deal with the DNS investigation and caching resolver reconfiguration. For example, the Apple iOS hotspot detection consists of simple trying to fetch: http://www.apple.com/library/test/success.html Once NM detects something like this, it can: 1) use dnssec-triggerd to put unbound in readonly cache mode to avoid insecure/bad DNS 2) fire of a webrequest that triggers the user into portal authentication 3) detect with above test the access has opened (or will never get better) 4) signal dnssec-triggerd to see if it can go to either use ISP DNS server or auth mode. Simply if a domain is marked as dnssec enabled in the parent record then it must have correct dnssec entries or it should not be accepted. If you never contacted that domain before, you cannot always perform that check on a pre-login hotspot. Even if they do not mangle DNS but grab you at the IP layer, then you run into the DNSSEC DANE record telling you about a TLS cert that is mismatching due to the portal. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 process change proposal
On Tue, Sep 20, 2011 at 21:55, Tom Lane t...@redhat.com wrote: Bruno Wolff III br...@wolff.to writes: On Wed, Sep 21, 2011 at 01:08:56 +0300, Kalev Lember kalevlem...@gmail.com wrote: With my proposal, Branched and rawhide would have exactly the same package set during the Alpha Freeze - Beta Freeze time frame. That way, we'd have a month to let users choose whether they want to stay on the Branched or on the rawhide track. I'd still like to be able to play with new stuff that might not be ready by beta, in rawhide during that time. Yeah. This proposal seems like it breaks one of the fundamental process improvements we already made, namely No Frozen Rawhide. I don't have a problem with Kalev's goal of reducing the amount of overhead for maintainers who only want to update rawhide and branched together, but I do object to doing that by preventing maintainers who want to push rawhide forward from doing so. It is only an improvement if it works consistently. The problem is that all it takes is some critical package getting a 'broken' update in rawhide and the developer getting pulled into concentrating on release issues that a de-facto freeze occurs anyway. The perception from living on rawhide for a while is that this happens enough during the alpha/beta/rc stage that we might as well freeze because critpath items that upgraded but don't work aren't going to get focus until after Fedora N is out the door. -- Stephen J Smoogen. The core skill of innovators is error recovery, not failure avoidance. Randy Nelson, President of Pixar University. Let us be kind, one to another, for most of us are fighting a hard battle. -- Ian MacLaren -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
On Wed, Sep 21, 2011 at 04:43:38PM +0200, Nils Philippsen wrote: And that's always fine and dandy if these issues are resolved in a reasonable amount of time. Right now Rawhide has packages with dependencies broken since pre-F15. This isn't acceptable. If you notice this, ask FESCo to ask FES to perform a rebuild to fix the dependency: https://fedoraproject.org/wiki/Fedora_Engineering_Services Probably any member of the provenpackager group can help you here. Regards Till pgpze8fJ76uSR.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Buildroot overrides in Rawhide, was: GDBM upgrade in F17
On Wed, 21 Sep 2011 09:23:52 -0600 Jerry James loganje...@gmail.com wrote: On Wed, Sep 21, 2011 at 6:50 AM, Bruno Wolff III br...@wolff.to wrote: Chain building is allowed for rawhide to help get groups of packages built. The chain-build facility is very useful. But when you've got a chain of 3 packages to build, and the build of the second one fails, then you're done for the day. You can't restart the chain-build, because the first package has already been built. You can't restart the chain-build from the second package, because the already-built first package won't be available to build against until the next repo compose. Incorrect. The first package is already in the build root. All chain build does is the waiting for you. build A; wait until A is in the buildroot; build B If B fails, then you can fix it and resume from B and it will work fine. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Proventester meetup today at 19:00 UTC
Greetings. Just a reminder that I am going to try and run a meetup of proventesters in #fedora-meeting at 19:00 UTC today on irc.freenode.net. If you are a proventester I hope you can drop by. If you are not, but are interested in whats involved in becoming one and helping test, also please drop by. Rough agenda: * What's required of proventesters? http://fedoraproject.org/wiki/Proven_tester * How do you become one? http://fedoraproject.org/wiki/Proven_tester#Joining_the_proven_testers * Resources - fedora-easy-karma - bodhi rss feeds - bodhi command line - updates reports/lists. * Focus on fedora 14 security and critpath updates. How can we move them along. * Is there enough interest to keep meeting? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Self Introduction - Chuck Rolke as user 'chug'
Greetings all.
I'm working toward becoming a package maintainer for project vios-proxy.
Currently I'm working at Red Hat in the Enterprise MRG Messaging team where I
support the Windows .NET messaging client binding. I am a committer for the
Apache Qpid project where most of my work resides.
I've had a long career in computing since my professional coding practice began
in the minicomputer era. My first pc was a PDP-8/M with 8k words of core (no
stack and no bytes) and a paper tape operating system. A few of my
lifetime-favorite software/hardware projects were based on the Signetics 8X305
microcontroller, a Harvard architecture device
http://www.lansdale.com/datasheets/sl8x305_rev0.pdf In 1985 my 8X305 receiver
could process 192,000 messages per second indefinitely!
Anyhow, the upcoming Fedora vios-proxy project uses a virtioserial channel to
proxy a network connection between a server in a QEMU host and a client in a
QEMU guest. This scheme allows guest-host 'network' connections in the absence
of actual network connections. You can read more about it in the project /doc
pages. I intend to make this work for Fedora and I hope it proves useful.
Regards,
Chuck
main(i){putchar(251139(i-1)*531|!!(i5)6) main(++i);}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GDBM upgrade in F17
On Wed, 2011-09-21 at 10:59 +, Petr Pisar wrote: Jan Horak (hhorak) is going to upgrade GDBM to version with new SONAME in F17. Because rel-engs refused to provide dedicated build root, the upgrade will be performed in F17 directly. That means Perl, Pyhon and other default-build-root packages will disable support for GDBM temporarily. So if your package needs GDBM support in those languages, please wait until new GDMB and other packages (Perl, Python and similar) get recompiled again against this new GDBM. FWIW I added a with_gdbm boolean to the specfile for both python and python3 and set it to 0, building them into rawhide as: python-2.7.2-12.fc17 and python3-3.2.2-4.fc17 (fwiw, this was a week ago, on 2011-09-13) Let me know when the new gdbm is in the buildroot for f17, and we can set those booleans to 1 and rebuild python/python3 (or some other python maintainer/proven packager can do it). Hope this is helpful Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
On 09/21/2011 04:43 PM, Nils Philippsen wrote: On Wed, 2011-09-21 at 15:51 +0200, Ralf Corsepius wrote: On 09/21/2011 01:25 PM, Nils Philippsen wrote: On Tue, 2011-09-20 at 22:25 +0200, Ralf Corsepius wrote: On 09/20/2011 05:52 PM, Nils Philippsen wrote: On Tue, 2011-09-20 at 15:19 +0200, Ralf Corsepius wrote: When you have a closer look, you'll notice that such mass rebuilts were being delayed by QA's delay queue and now are stuck. I didn't want to (re)start that particular discussion ;-). We need some guidelines who should drive rebuilds in such a situation, regardless of whether it happens in Rawhide or Branched or wherever. a) These situation can only happen in release branches. Uhm, no. A library SONAME bump can happen in Rawhide as well as in branches and if dependent packages don't get built with the new version, things are broken. Right. They break in rawhide, where issues are inevitable and can be addressed within short terms because maintainers are not being forced to play 10 days per package update you wait for me/I wait for you delay ping-pong. And that's always fine and dandy if these issues are resolved in a reasonable amount of time. Right now Rawhide has packages with dependencies broken since pre-F15. This isn't acceptable. Agreed - If so, these need to be addressed. IMO, if packagers and/or proven packagers are not able to fix these in reasonable time, I'd consider it to be QA's job to take care about these. As experience as a proven packager, who did try to address such cases in the past tells, such cases typically originate from a) packagers not being sufficently skilled to fix such breakages and them not asking for assitance. b) packagers having gone AWOL or being unreachable c) packages being sufficiently incompatible to an upgrade that they better should be removed/retired. Wrt. a) experience tells, some packagers are hesitant to ask for assitance and prefer to sit out the issue, until some proven packager or upstream takes action. Wrt. the packages I had stepped in, case b) was fairly common. IMO the cause is Fedora lacking a spirit of teaming up. Wrt. c), here the issue seems to be packagers being hesitant to draw a cut and to retire a package. Surprisingly, when directly contacting maintainers of such packages, they often agree to such retirement. Waiting for dependent components to be built at their maintainers leisure or whenever a mass rebuild comes around isn't a solution, not if we want to have a more stable Rawhide. To we want this? I don't. To me, rawhide is the big package dumping ground for the bleading edge. Certainly, it should be as little broken as possible, but its brokenness is part of its working principle and inevitable to me. That said, I find a stable rawhide to be nonrealisting and inapplicable. You're twisting my words a bit. I wasn't opting for a stable, but a more stable release. If somebody wants to test something in Rawhide they shouldn't have to debug other parts of the distribution. This means that changes should be done with enough circumspection that breakage is reduced to a minimum. People who actually run Rawhide (and I know their number is low) would thank us for that. Well, what am I supposed to say? Anybody would be grateful for less bugs and breakage, but ... on rawhide breakage is simply inevitable. Right now this is not the case: a substantial number of components is broken due to unsatisfied dependencies alone, meaning that everybody who wants to test Rawhide in conjunction with anything on that list is simply out of luck right now. That's one view. From a packager's view, whenever something changes incompatibly, no matter how careful and speedy the packager tries to be, there always be situations when something breaks. Typical case are: The packager who is pushing an incompatible upgrade misses a to be rebuild package, the packager doesn't have sufficient privileges to rebuild a package in need of a rebuilt or the upgrade renders a package unbuildable ... IMO, the last on this list is the critical case, which is causing rawhide users to complain. I admit that the impact of being broken is not the same for every component in the distribution: some stuff more on the fringe is sufficiently isolated that it will only affect few testers if it doesn't work (ideally the ones fixing the breakage), so it won't hurt many if these are broken for a longer time, but other components are central enough that they can't afford that luxury. No disagreement. It would certainly help here if buildroots could be created for Rawhide so that breakage can be resolved in isolation there. I am using local mock environments which inherit from upstream (== Fedora), as a band-aid to identify potential breakage and to keep impact of incompatible upgrades low. This often works, but not always. In this case they'd need to be created before the first package is built however, so
Re: grub / grub2 conflicts
On Wed, Sep 21, 2011 at 08:39:24PM +0100, Mark McLoughlin wrote: On Wed, 2011-09-21 at 18:48 +0100, Matthew Garrett wrote: Remember that the incompatibility isn't between libguestfs and the guest, it's between the host grub and the guest grub. Both of those can change without libguestfs's knowledge. Sounds like we need a 'Conflicts: libguestfs' in both grub and grub2 then? I don't think so. Nothing they do or install conflicts with libguestfs. libguestfs is simply trying to use them inappropriately. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub / grub2 conflicts
On 09/21/2011 03:39 PM, Mark McLoughlin wrote: On Wed, 2011-09-21 at 18:48 +0100, Matthew Garrett wrote: On Wed, Sep 21, 2011 at 06:30:58PM +0100, Mark McLoughlin wrote: On Mon, 2011-09-19 at 20:11 +0100, Matthew Garrett wrote: The grub package (as provided in Fedora) is not designed for that. This would be a much easier discussion to have if you stopped describing things that are manifestly true as not true. And while it is the case that grub *is* binary compatible between every version we've ever released, it is *not* guaranteed that that remains true, or even that it's true between us and any distribution that may be installed in a guest. If libguestfs had code to detect that the guest version was incompatible and failed gracefully with a nice explanation for the user, then there's no problem right? To be reliable you'd need to support disassembling the binaries installed and working out what the arguments are meant to look like. This doesn't seem like a great way to spend time. Not your problem how libguestfs authors spend their time. Nor whether they actually do this or choose to just warn their users about potential incompatibility. Remember that the incompatibility isn't between libguestfs and the guest, it's between the host grub and the guest grub. Both of those can change without libguestfs's knowledge. Sounds like we need a 'Conflicts: libguestfs' in both grub and grub2 then? Yes, but this will hardly help the situation, which right now is that the distro pulls in grub 2, because that's what we've collectively chosen to do, and libguestfs pulls in grub on the host, even though it isn't really using it there. So effectively your solution is to keep the problem we've got right now. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub / grub2 conflicts
On Wed, Sep 21, 2011 at 03:54:28PM -0400, Peter Jones wrote: Yes, but this will hardly help the situation, which right now is that the distro pulls in grub 2, because that's what we've collectively chosen to do, and libguestfs pulls in grub on the host, even though it isn't really using it there. So effectively your solution is to keep the problem we've got right now. Tools on the host are often useful in guest situations. If I created a filesystem using mke2fs: lvcreate /dev/vg/foo mke2fs /dev/vg/foo and attached this to a guest, is that an inappropriate use of host tools for a guest? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub / grub2 conflicts
On Wed, Sep 21, 2011 at 09:10:06PM +0100, Richard W.M. Jones wrote: On Wed, Sep 21, 2011 at 03:54:28PM -0400, Peter Jones wrote: Yes, but this will hardly help the situation, which right now is that the distro pulls in grub 2, because that's what we've collectively chosen to do, and libguestfs pulls in grub on the host, even though it isn't really using it there. So effectively your solution is to keep the problem we've got right now. Tools on the host are often useful in guest situations. If I created a filesystem using mke2fs: lvcreate /dev/vg/foo mke2fs /dev/vg/foo and attached this to a guest, is that an inappropriate use of host tools for a guest? Yes, if the guest is running a sufficiently old kernel. But mke2fs is designed to allow you to create filesystems that will work with arbitrary kernels, so it's possible to use it in appropriate ways. grub is not designed to be compatible across arbitrary versions, and so using it with that expectation is inappropriate. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Input Methods Test Day
Hello all! Just a reminder that today is input methods support test day. This test day will focus on a new feature [1] that will debut in Fedora 16 and will improve the usage of input methods in the overall desktop. Please join us in #fedora-test-day at freenode and post your results on the wiki page [2]. [1] http://fedoraproject.org/wiki/Features/GnomeInputIntegration [2] http://fedoraproject.org/wiki/Test_Day:2011-09-22_I18n_Desktop Regards, -- Igor Pires Soares Fedora Ambassador (Brazil) - Member of FAmSCo Fedora I18N/L10N QA https://fedoraproject.org/wiki/User:Igor ___ 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
grub1 support in grubby
Given the grub1/grub2 discussion that is going on, I could use some info about the state of grubby's support for grub1. The virtual machine images that the Cloud SIG publishes on Amazon EC2 do not require bootloaders, but they do require valid grub1 *configuration files* to start. So while these images will survive grub1's eventual retirement, they will still need grubby to support grub1 configuration files for the foreseeable future so kernel updates can continue to work correctly. Is that realistic? Are there currently any plans to kill off grubby's grub1 support at some point? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Buildroot overrides in Rawhide, was: GDBM upgrade in F17
Dne 21.9.2011 16:52, Kevin Fenzi napsal(a): Its strange to me. There are concerns to have Rawhide usable but at the end, if somebody wants to prevents problems using dedicated build root, it is denied by Rel-Engs, because it is probably to much work. This is disappointing. Every target added that has a buildroot that must be generated means more overhead for koji. It has to populate and createrepo the buildroots a lot. Doing more means that other ones have to wait. Yes, Koji might have more work, but in opposite case, Rawhide is going to be broken and it might be broken for indefinite period of time if something goes wrong. So should be Rawhide usable even though it would mean that Koji has more work and somebody might wait longer for his task or should Rawhide be broken? I would opt for slower Koji, but apparently the broken Rawhide is preferred. Vit -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Socket-Netlink/el6] Do not build on ppc64.
commit f45c59a4f4f24385f60ce7a3d78ec7d49e0622c5
Author: Mathieu Bridon boche...@fedoraproject.org
Date: Wed Sep 21 15:11:02 2011 +0800
Do not build on ppc64.
perl-Socket-Netlink.spec |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
---
diff --git a/perl-Socket-Netlink.spec b/perl-Socket-Netlink.spec
index c050fbc..3254615 100644
--- a/perl-Socket-Netlink.spec
+++ b/perl-Socket-Netlink.spec
@@ -1,6 +1,6 @@
Name: perl-Socket-Netlink
Version:0.03
-Release:3%{?dist}
+Release:4%{?dist}
Summary:Interface to Linux's PF_NETLINK socket family
# License file contains the old FSF address:
@@ -11,6 +11,10 @@ Group: Development/Libraries
URL:http://search.cpan.org/dist/Socket-Netlink/
Source0:
http://www.cpan.org/authors/id/P/PE/PEVANS/Socket-Netlink-%{version}.tar.gz
+# Unit tests fail on ppc64:
+# https://rt.cpan.org/Public/Bug/Display.html?id=71112
+ExcludeArch:ppc64
+
BuildRequires: perl(ExtUtils::CBuilder)
BuildRequires: perl(ExtUtils::CChecker)
BuildRequires: perl(ExtUtils::H2PM) = 0.03
@@ -74,6 +78,9 @@ find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null \;
%changelog
+* Wed Sep 21 2011 Mathieu Bridon boche...@fedoraproject.org - 0.03-4
+- Do not build on ppc64.
+
* Mon Sep 19 2011 Mathieu Bridon boche...@fedoraproject.org - 0.03-3
- Fixes based on Remi's review feedback.
--
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 740223] New: perl-Classic-Perl-0.03 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Classic-Perl-0.03 is available https://bugzilla.redhat.com/show_bug.cgi?id=740223 Summary: perl-Classic-Perl-0.03 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-Classic-Perl AssignedTo: ppi...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com, ppi...@redhat.com Classification: Fedora Story Points: --- Type: --- Latest upstream release: 0.03 Current version in Fedora Rawhide: 0.02 URL: http://search.cpan.org/dist/Classic-Perl/ 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 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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 740223] perl-Classic-Perl-0.03 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=740223 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Resolution||RAWHIDE Fixed In Version||perl-Classic-Perl-0.03-1.fc ||17 Last Closed||2011-09-21 06:48:23 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Net-SSLeay-1.39.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Net-SSLeay: d0a0b92d4ca2d8e7c50a4b232d5861a7 Net-SSLeay-1.39.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-SSLeay] Created tag perl-Net-SSLeay-1.39-1.fc17
The lightweight tag 'perl-Net-SSLeay-1.39-1.fc17' was created pointing to: e9fab83... Update to 1.39 -- 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-BerkeleyDB] Rebuild for libdb 5.2.36 in Rawhide
commit d7b856f82f4cfc1d32d937f062397afa37881831
Author: Paul Howarth p...@city-fan.org
Date: Wed Sep 21 15:20:21 2011 +0100
Rebuild for libdb 5.2.36 in Rawhide
perl-BerkeleyDB.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-BerkeleyDB.spec b/perl-BerkeleyDB.spec
index 213efa2..21649e9 100644
--- a/perl-BerkeleyDB.spec
+++ b/perl-BerkeleyDB.spec
@@ -10,7 +10,7 @@
Name: perl-BerkeleyDB
Version:0.49
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Interface to Berkeley DB
License:GPL+ or Artistic
Group: Development/Libraries
@@ -80,6 +80,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/BerkeleyDB.3pm*
%changelog
+* Wed Sep 21 2011 Paul Howarth p...@city-fan.org - 0.49-2
+- Rebuild for libdb 5.2.36 in Rawhide
+
* Sun Sep 18 2011 Steven Pritchard st...@kspei.com 0.49-1
- Update to 0.49.
- BR Cwd (not in core now).
--
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-BerkeleyDB/f16] (2 commits) ...Rebuild for libdb 5.2.36 in Rawhide
Summary of changes: a51705d... Update to 0.49. BR Cwd (not in core now). (*) d7b856f... Rebuild for libdb 5.2.36 in Rawhide (*) (*) 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-BerkeleyDB] Created tag perl-BerkeleyDB-0.49-2.fc16
The lightweight tag 'perl-BerkeleyDB-0.49-2.fc16' was created pointing to: d7b856f... Rebuild for libdb 5.2.36 in Rawhide -- 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 739881] perl-DateTime-TimeZone-1.38 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=739881 Iain Arnell iarn...@gmail.com changed: What|Removed |Added Status|NEW |CLOSED Resolution||WONTFIX Last Closed||2011-09-22 01:08:54 --- Comment #1 from Iain Arnell iarn...@gmail.com 2011-09-22 01:08:54 EDT --- This is not an interesting update - only a minor change to avoid confusing the metacpan indexer. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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
