Re: The new Update Acceptance Criteria are broken (was: Re: Heads Up - New Firefox update)
On Sun, 31 Oct 2010 04:37:38 +0100, Kevin wrote: > Martin Stransky wrote: > > there's a new Firefox update waiting in Bodhi and we can't push it to > > stable because of new rules. We recommend you to update to it ASAP as it > > fixes a public critical 0day vulnerability > > (https://bugzilla.mozilla.org/show_bug.cgi?id=607222). > > Looks like the F13 build got karma quickly enough to land directly in stable > after all, the F12 build, on the other hand, was stuck in testing for 2 days > before finally making it out to stable. Yet another blatant example of > failure of the Update Acceptance Criteria, needlessly exposing our users to > critical vulnerabilities. > > (And no, by giving yet another special exception to Firefox wouldn't be a > solution. ;-) This problem can hit any other app as well.) > > Kevin Kofler Okay, feedback time. Lately, there have been several attempts at urging proventesters (and not just testers in general) to give positive karma for aging critpath updates. It also has been decided by someone (or maybe even a comittee) to spam proventesters daily with "[old_testing_critpath]" messages for all three dist releases, with no day to unsubscribe from that (other than leaving proventesters group, which is what at least one person has threatened with, or filtering those messages). Dunno about other testers (and there aren't many yet), but I have abandoned F-12 long ago due to lack of time when F-13 became the one to use on a daily basis. And some time before F-14 Beta, my desktop has been switched to boot F-14 by default. That's the only opportunity to evaluate F-14 early and possibly find issues prior to its release. On the contrary, most of Fedora's users will wait for the final release, and many users will wait even longer. It's highly likely that bugzilla can confirm that. F-14 is the the only way forward, and don't like to spend time on F-13 and older anymore. That also applies to packagers I maintain or monitor. I simply don't see the user base [target group] anymore. About positive karma in bodhi, I don't feel comfortable signing off arbitrary updates just because they didn't crash for me after five minutes. With some updates, regression has slipped through already. And the more bugs an update addresses with either patches or a version upgrade, the more careful I would like to be when testing something. Also, in my book, an update working on F-14 may still malfunction on an older dist release due to differences in dependences and the core setup. I still don't understand why some non-security updates are rushed out with sometimes not even the package maintainer(s) having tested them at all. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20101031 changes
Compose started at Sun Oct 31 08:15:03 UTC 2010 Broken deps for x86_64 -- 1:anjuta-2.31.90.0-3.fc15.i686 requires libvala-0.10.so.0 1:anjuta-2.31.90.0-3.fc15.x86_64 requires libvala-0.10.so.0()(64bit) apcupsd-3.14.8-3.fc15.x86_64 requires libnetsnmp.so.20()(64bit) banshee-community-extensions-1.8.0-3.fc15.x86_64 requires mono(mscorlib) = 0:1.0.5000.0 banshee-community-extensions-1.8.0-3.fc15.x86_64 requires mono(System) = 0:1.0.5000.0 beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0()(64bit) beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0(VER_1)(64bit) cluster-glue-1.0.6-1.fc14.x86_64 requires libnetsnmp.so.20()(64bit) cluster-snmp-0.18.1-1.fc15.x86_64 requires libnetsnmp.so.20()(64bit) clutter-gst-devel-1.2.0-1.fc15.i686 requires pkgconfig(clutter-1.0) < 0:1.3.0 clutter-gst-devel-1.2.0-1.fc15.x86_64 requires pkgconfig(clutter-1.0) < 0:1.3.0 db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0 dh-make-0.55-2.fc15.noarch requires debhelper eog-plugins-2.30.0-2.fc14.x86_64 requires libgdata.so.7()(64bit) freefem++-3.9-2.1.fc15.x86_64 requires libopen-rte.so.0()(64bit) freefem++-3.9-2.1.fc15.x86_64 requires libmpi.so.0()(64bit) freefem++-3.9-2.1.fc15.x86_64 requires libmpi_cxx.so.0()(64bit) freefem++-3.9-2.1.fc15.x86_64 requires libopen-pal.so.0()(64bit) freefem++-mpi-3.9-2.1.fc15.x86_64 requires libmpi.so.0()(64bit) freefem++-mpi-3.9-2.1.fc15.x86_64 requires libopen-rte.so.0()(64bit) freefem++-mpi-3.9-2.1.fc15.x86_64 requires libmpi_cxx.so.0()(64bit) freefem++-mpi-3.9-2.1.fc15.x86_64 requires libopen-pal.so.0()(64bit) 1:gedit-devel-2.91.0-4.fc15.i686 requires gtksourceview2-devel >= 0:2.91 1:gedit-devel-2.91.0-4.fc15.x86_64 requires gtksourceview2-devel >= 0:2.91 gedit-vala-0.10.2-2.fc15.i686 requires libvala-0.10.so.0 gedit-vala-0.10.2-2.fc15.x86_64 requires libvala-0.10.so.0()(64bit) 1:gnome-games-extra-2.31.91.1-1.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gnome-pilot-eds-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-burn.so.1()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-media.so.1()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevdocument.so.3()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevview.so.3()(64bit) gnome-python2-evolution-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-totem-2.32.0-1.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gnome-rdp-0.2.3-6.fc12.x86_64 requires mono(vte-sharp) = 0:0.16.0.0 gnome-rdp-0.2.3-6.fc12.x86_64 requires mono(Mono.Data.SqliteClient) = 0:2.0.0.0 gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-gtk-0.6.so.0()(64bit) gtksourceview-sharp-2.0.12-12.fc15.x86_64 requires mono(gnome-print-sharp) = 0:2.18.0.0 hornsey-1.5.2-0.3.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) hugin-2010.0.0-5.fc15.x86_64 requires libpano13.so.1()(64bit) hugin-base-2010.0.0-5.fc15.i686 requires libpano13.so.1 hugin-base-2010.0.0-5.fc15.x86_64 requires libpano13.so.1()(64bit) ifstat-1.1-12.fc13.x86_64 requires libnetsnmp.so.20()(64bit) libreoffice-langpack-af-3.2.99.2-3.fc15.x86_64 requires libreoffice-core = 0:3.2.99.1-1 libreoffice-langpack-ar-3.2.99.2-3.fc15.x86_64 requires libreoffice-core = 0:3.2.99.1-1 libreoffice-langpack-as-3.2.99.2-3.fc15.x86_64 requires libreoffice-core = 0:3.2.99.1-1 libreoffice-langpack-bg-3.2.99.2-3.fc15.x86_64 requires libreoffice-core = 0:3.2.99.1-1 libreoffice-langpack-bn-3.2.99.2-3.fc15.x86_64 requires libreoffice-core = 0:3.2.99.1-1 libreoffice-langpack-ca-3.2.99.2-3.fc15.x86_64 requires libreoffice-core = 0:3.2.99.1-1 libreoffice-langpack-cs-3.2.99.2-3.fc15.x86_64 requires libreoffice-core = 0:3.2.99.1-1 libreoffice-langpack-cy-3.2.99.2-3.fc15.x86_64 requires libreoffice-core = 0:3.2.99.1-1 libreoffice-langpack-da-3.2.99.2-3.fc15.x86_64 requires libreoffice-core = 0:3.2.99.1-1 libreoffice-langpack-de-3.2.99.2-3.fc15.x86_64 requires libreoffice-core = 0:3.2.99.1-1 libreoffice-langpack-dz-3.2.99.2-3.fc15.x86_64 requires libreoffice-core = 0:3.2.99.1-1 libreoffice-langpack-el-3.2.99.2-3.fc15.x86_64 requires libreoffice-core = 0:3.2.99.1-1 libreoffice-langpack-en-3.2.99.2-3.fc15.x86_64 requires libreoffice-core = 0:3.2.99.1-1 libreoffice-langpack-es-3.2.99.2-3.fc15.
Re: Is python-libs segfaulting behind mod_python for anyone in F-14?
Hi, mod_python project is officially dead since june, it had no release since february 2007. You should move to mod_wsgi which a community supported alternative for python web applications. http://blog.dscpl.com.au/2010/06/modpython-project-is-now-officially.html http://blog.dscpl.com.au/2010/05/modpython-project-soon-to-be-officially.html Unless anyone wants to revive mod_python, it should be removed from repositories. Best regards, H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fast Light Tool Kit
On Sunday 31 October 2010 02:58:21 Dominic Hopf wrote: > I think it's likely something like a "BuildRequires: fltk" already > should be enough. I'd suggest to just try out that and see what > happens. :) Most probably it should be BuildRequires: fltk-devel -- José Abílio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fast Light Tool Kit
lör 2010-10-30 klockan 17:05 -0400 skrev Eric "Sparks" Christensen: > The source is a single file with no readme and I'm > not exactly sure how to package the software. Probably: cc -o foo foo.c $(fltk-config --cflags --ldflags) /abo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is python-libs segfaulting behind mod_python for anyone in F-14?
Haïkel Guémar gmail.com> writes: > > Hi, > > mod_python project is officially dead since june, it had no release > since february 2007. You should move to mod_wsgi which a community > supported alternative for python web applications. > http://blog.dscpl.com.au/2010/06/modp ython-project-is-now-officially.html > http://blog.dscpl.com.au/2010/05/modp ython-project-soon-to-be-officially.html > > Unless anyone wants to revive mod_python, it should be removed from > repositories. > > Best regards, > H. Thanks for the pointer. According to viewvc INSTALL file, wsgi and fcgi appear to be somewhat second class supported. But, yeah, maybe we should give it a go and see how it pans out. -- Bojan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken
On 10/31/2010 03:18 AM, Michael Schwendt wrote: > On Sun, 31 Oct 2010 04:37:38 +0100, Kevin wrote: > >> Martin Stransky wrote: >>> there's a new Firefox update waiting in Bodhi and we can't push it to >>> stable because of new rules. We recommend you to update to it ASAP as it >>> fixes a public critical 0day vulnerability >>> (https://bugzilla.mozilla.org/show_bug.cgi?id=607222). >> >> Looks like the F13 build got karma quickly enough to land directly in stable >> after all, the F12 build, on the other hand, was stuck in testing for 2 days >> before finally making it out to stable. Yet another blatant example of >> failure of the Update Acceptance Criteria, needlessly exposing our users to >> critical vulnerabilities. >> >> (And no, by giving yet another special exception to Firefox wouldn't be a >> solution. ;-) This problem can hit any other app as well.) >> >> Kevin Kofler > > Okay, feedback time. > > Lately, there have been several attempts at urging proventesters (and not > just testers in general) to give positive karma for aging critpath updates. > It also has been decided by someone (or maybe even a comittee) to spam > proventesters daily with "[old_testing_critpath]" messages for all three > dist releases, with no day to unsubscribe from that (other than leaving > proventesters group, which is what at least one person has threatened with, > or filtering those messages). > > Dunno about other testers (and there aren't many yet), but I have abandoned > F-12 long ago due to lack of time when F-13 became the one to use on a daily > basis. And some time before F-14 Beta, my desktop has been switched to boot > F-14 by default. That's the only opportunity to evaluate F-14 early and > possibly find issues prior to its release. On the contrary, most of Fedora's > users will wait for the final release, and many users will wait even longer. > It's highly likely that bugzilla can confirm that. > > F-14 is the the only way forward, and don't like to spend time on F-13 and > older anymore. That also applies to packagers I maintain or monitor. I simply > don't see the user base [target group] anymore. > > About positive karma in bodhi, I don't feel comfortable signing off > arbitrary updates just because they didn't crash for me after five > minutes. With some updates, regression has slipped through already. > And the more bugs an update addresses with either patches or a version > upgrade, the more careful I would like to be when testing something. > Also, in my book, an update working on F-14 may still malfunction on an > older dist release due to differences in dependences and the core setup. I > still don't understand why some non-security updates are rushed out with > sometimes not even the package maintainer(s) having tested them at all. I am willing to work with the older, still supported, distros, but would really appreciate test cases since most of the critical-path bugs the update addresses are not common and I haven't run into them. That said, if the update remains without karma, the release is within a month of end-of-life, then the update could be left in updates testing and docs changed to provide a warning. I don't think there would be that much impact on storage to keep an updates-testing repo around on the mirrors that choose to provide the release. Most just delete the release anyway. Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fast Light Tool Kit
"Eric \"Sparks\" Christensen" wrote: > The source I downloaded contained a single file so I'm not sure what > needs to happen. Well, since asking upstream for a copy of the license to ship is required for the guidelines, maybe a simple Makefile could be asked for as well. --Ben -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Polyinstantiated /tmp
On Wed, 2010-10-20 at 08:13 -0400, Daniel J Walsh wrote: > I have been trying to get system processes to stop using /tmp for years. > > http://danwalsh.livejournal.com/11467.html > > As some one who lives with polyinstatiated namespace /tmp, The only > problem I know of now is handing of kerberos tickets. Whenever a system > process (root) needs to communicate with a user via /tmp. namespace > /tmp breaks it. sssd can not create kerberos tickets in my /tmp and > gssd can not find my kerberos tickets in /tmp. I believe the solution > to both is to move the tickets to be managed by sssd and leave /tmp to > users. > > BTW, X has solved this problem a couple of years ago by using virtual > namespace for its sockets. In the abstract namespace, don't you have the same problem where if the real X server dies for any reason, other users can create a socket at the same path and mess with your applications? -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Looking for a good Radix tree (Patricia) library in fedora
I'm the CPAN owner of Net::Patricia (perl-Net-Patricia.rpm) and it currently
supports IPv4 and IPv6.
Both are done with specialized data structures.
I'm looking for something that handles a more generic binary data blob... so
that I could have arbitrary searches.
For instance, in Perl, I could seed the tree with:
$key = join('.', reverse(split(/\./, $domain)));
$keylen = length($key) * 8;
and then do rDNS tree searches for hostnames.
One could similarly imagine converting phone numbers into BCD and doing E.164
searches in such a tree.
Net::Patricia currently uses a modified version of libpatricia from the MERIT
Radius or SNMP code (forget which)... but it only handles IPv6 and IPv4 as I
said.
Ideally it would be an external library that I could just link to.
Anyone have a pointer?
Thanks,
-Philip
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken (was: Re: Heads Up - New Firefox update)
On Sun, 2010-10-31 at 04:37 +0100, Kevin Kofler wrote: > Martin Stransky wrote: > > there's a new Firefox update waiting in Bodhi and we can't push it to > > stable because of new rules. We recommend you to update to it ASAP as it > > fixes a public critical 0day vulnerability > > (https://bugzilla.mozilla.org/show_bug.cgi?id=607222). > > Looks like the F13 build got karma quickly enough to land directly in stable > after all, the F12 build, on the other hand, was stuck in testing for 2 days > before finally making it out to stable. Yet another blatant example of > failure of the Update Acceptance Criteria, needlessly exposing our users to > critical vulnerabilities. Kevin, could you *please* not word things like that? There's just no need for it. I already wrote this to -test a couple of days ago: http://lists.fedoraproject.org/pipermail/test/2010-October/095135.html and we're discussing it there. I think the thread demonstrates things tend to go much more constructively if you avoid throwing words like 'blatant' and 'failure' and 'needlessly' around. We designed a policy, put it into effect, now we're observing how well it works and we can modify its implementation on the fly. It doesn't need to be done in an adversarial spirit. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken (was: Re: Heads Up - New Firefox update)
Adam Williamson píše v Ne 31. 10. 2010 v 18:06 -0700: > On Sun, 2010-10-31 at 04:37 +0100, Kevin Kofler wrote: > Yet another blatant example of > > failure of the Update Acceptance Criteria, needlessly exposing our users to > > critical vulnerabilities. > > Kevin, could you *please* not word things like that? There's just no > need for it. > > I already wrote this to -test a couple of days ago: > > http://lists.fedoraproject.org/pipermail/test/2010-October/095135.html > > and we're discussing it there. I think the thread demonstrates things > tend to go much more constructively if you avoid throwing words like > 'blatant' and 'failure' and 'needlessly' around. Did we not fail our users? Was there a real need to fail them? (As a non-native speaker, I won't judge the relative merits of "blatant" vs. "sucks".) > We designed a policy, > put it into effect, now we're observing how well it works and we can > modify its implementation on the fly. It doesn't need to be done in an > adversarial spirit. Given that _this exact scenario_ was repeatedly brought up since the very start of the update acceptance criteria proposals, I think some frustration is quite justified. This situation is not really a surprise, and Fedora did not have to unnecessarily expose users to a vulnerability in order to relearn this lesson. In addition to being constructive about remedying the situation, shouldn't we try to be more constructive about _not introducing such situations_ in the first place? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken (was: Re: Heads Up - New Firefox update)
Adam Williamson wrote: > I already wrote this to -test a couple of days ago: > > http://lists.fedoraproject.org/pipermail/test/2010-October/095135.html > > and we're discussing it there. I think the thread demonstrates things > tend to go much more constructively if you avoid throwing words like > 'blatant' and 'failure' and 'needlessly' around. We designed a policy, > put it into effect, now we're observing how well it works and we can > modify its implementation on the fly. It doesn't need to be done in an > adversarial spirit. There's exactly one constructive thing to do, it's repealing this set of policies (Critical Path and Update Acceptance Criteria) in its entirety. An update should go stable when the maintainer says so, karma should be purely informational feedback for the maintainer. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Fedora-haskell-list] Taking ownership of haddock
- lakshminaras2...@gmail.com wrote: > I intend to take ownership of haddock package. It is required for one other > package (leksah, an IDE for Haskell) that I am planning to submit. Yes, I think that is fine. You will need to submit haddock for package review since it has been retired from Fedora for a while and then after approval - you can make SCM Change Request to take ownership of the retired package. Jens -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
