Re: How about firefox 3.6 in Fedora 12 ?
So it doesn't have an official one? On Sat, Jan 30, 2010 at 3:34 PM, Kevin Kofler kevin.kof...@chello.atwrote: Liu Yu Fei Eric wrote: I noticed firefox was stuck on 3.5.6 for a rather long time. What about 3.5.7 and the recently 3.6? They are even not in koji. http://blog.famillecollet.com/post/2010/01/22/Firefox-3.6-en Kevin Kofler -- 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: How about firefox 3.6 in Fedora 12 ?
On Sat, Jan 30, 2010 at 1:42 AM, Liu Yu Fei Eric hoveringnowi...@gmail.comwrote: So it doesn't have an official one? I've been running the f13 build out of rawhide for a week now, and it's worked fine for me... not sure about Java though. yum --enablerepo=rawhide update firefox --wes (f12-x86_64) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fast-track Nonresponsive maintainer: Frank Büttner (frankb)
Hi all, Frank Büttner seems reluctant to be responsive. I fixed one FTBFS bug assigned to him in qtiplot. I posted a non responsive maintainer tracker bug, but he closed soon and was reluctant to explain anymore. See https://bugzilla.redhat.com/show_bug.cgi?id=557424 ?And he was total non-responsive in other bug assigned to him The last build submitted by him is from 2009-01-10: http://koji.fedoraproject.org/koji/builds?userID=frankb There are a lot of open Bugs assigned to him(some were closed by me): See https://bugzilla.redhat.com/show_bug.cgi?id=557424 He owns 8 Packages: https://admin.fedoraproject.org/pkgdb/users/packages/frankb Regards Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Draft privilege escalation policy for comments
On Fri, Jan 29, 2010 at 02:27:13PM -0800, Adam Williamson wrote:
Please do provide any and all feedback on the proposed policy. if we can
get it into a shape which most people on the list would find acceptable,
my next step will be to take it back to FESco for them to review.
Thanks.
I don't understand this sentence:
with the exceptions that the 'cause to be performed' provision is waived
in this case
maybe it already covers it, but there are more directories a user can
write to then just ~, /tmp, /var/tmp or /usr/tmp, e.g. /dev/shm and with
certain restrictions /var/spool/{cron,mail,cups,at}.
Regards
Till
pgpKqy5veaWpi.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fast-track Nonresponsive maintainer: Frank Büttner (frankb)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Frank, On 01/30/2010 10:59 AM, Frank Büttner wrote: until bug #479556 is not fixed, I can't build anything. And the maintainer of mock seem don't do anything to fix it. I don't know why. But for my last post I don't get any response. why don't you use `koji build --scratch` builds until the situation gets fixed since it essentially gives you (remote) mock building? - -- Alexander Kahl GNU/Linux Software Developer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAktkCKAACgkQVTRddCFHw10QRgCgqVbCJZK88AObT9p0+sBnQ8Qx F3AAn1Da2u52rwMwjD+ioDS8cDFpRjMX =taqy -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How about firefox 3.6 in Fedora 12 ?
On Sat, 30 Jan 2010, Wes Shull wrote: On Sat, Jan 30, 2010 at 1:42 AM, Liu Yu Fei Eric hoveringnowi...@gmail.com wrote: So it doesn't have an official one? I've been running the f13 build out of rawhide for a week now, and it's worked fine for me... not sure about Java though. yum --enablerepo=rawhide update firefox It looks like some upstream support in OpenJDK + IcedTea http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-January/008120.html went live 3 days ago, but it doesn't look like there have been any Fedora builds based on it yet. I would suggest a slight word of caution about mixing Fedora 12 and rawhide packages. At the moment they still seem fairly compatible, but if something major changes you might find yourself having to update most of your OS to rawhide to satisfy all the dependencies. Michael Young-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fast-track Nonresponsive maintainer: Frank Büttner (frankb)
Am 30.01.2010 11:23, schrieb Alexander Kahl: Hi Frank, On 01/30/2010 10:59 AM, Frank Büttner wrote: until bug #479556 is not fixed, I can't build anything. And the maintainer of mock seem don't do anything to fix it. I don't know why. But for my last post I don't get any response. why don't you use `koji build --scratch` builds until the situation gets fixed since it essentially gives you (remote) mock building? I have done some like at my first package, and then to my was spoken, that I use local mock and not the infrastructure. But after some updates of mock, mock it now dead. The no response from them maintainer. smime.p7s Description: S/MIME Cryptographic Signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re:Re: Fast-track Nonresponsive m aintainer: Frank Büttner (frankb)
Hi Frank, As you said using the test machines was not an option because of low uploads of you ISP, do you need some co-maintainers to help your maintaining packages before you solve mock problem? Most of your packages now need update for bugfix since the lastest build submitted by you is from 2009-01-10. 在2010-01-30?18:51:10，Frank?Büttner?frank-buett...@gmx.net?写道： Am?30.01.2010?11:23,?schrieb?Alexander?Kahl: ?Hi?Frank, ? ?On?01/30/2010?10:59?AM,?Frank?Büttner?wrote: ?until?bug?#479556?is?not?fixed,?I?can't?build?anything. ?And?the?maintainer?of?mock?seem?don't?do?anything?to?fix?it. ?I?don't?know?why.?But?for?my?last?post?I?don't?get?any?response. ?why?don't?you?use?`koji?build?--scratch`?builds?until?the?situation?gets ?fixed?since?it?essentially?gives?you?(remote)?mock?building? ? I?have?done?some?like?at?my?first?package,?and?then?to?my?was?spoken, that?I?use?local?mock?and?not?the?infrastructure.?But?after?some?updates of?mock,?mock?it?now?dead.?The?no?response?from?them?maintainer. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Draft privilege escalation policy for comments
On Sat, 2010-01-30 at 10:52 +0100, Till Maas wrote:
On Fri, Jan 29, 2010 at 02:27:13PM -0800, Adam Williamson wrote:
Please do provide any and all feedback on the proposed policy. if we can
get it into a shape which most people on the list would find acceptable,
my next step will be to take it back to FESco for them to review.
Thanks.
I don't understand this sentence:
with the exceptions that the 'cause to be performed' provision is waived
in this case
It means that it's okay for the user to indirectly cause changes to
happen, because that happens all the time. This particular clause
applies only to direct user actions.
maybe it already covers it, but there are more directories a user can
write to then just ~, /tmp, /var/tmp or /usr/tmp, e.g. /dev/shm and with
certain restrictions /var/spool/{cron,mail,cups,at}.
full list of directories it's okay for an unprivileged user to write to
directly would be good...
--
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: Fast-track Nonresponsive maintainer: Frank Büttner (frankb)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/30/2010 11:51 AM, Frank Büttner wrote: Am 30.01.2010 11:23, schrieb Alexander Kahl: Hi Frank, On 01/30/2010 10:59 AM, Frank Büttner wrote: until bug #479556 is not fixed, I can't build anything. And the maintainer of mock seem don't do anything to fix it. I don't know why. But for my last post I don't get any response. why don't you use `koji build --scratch` builds until the situation gets fixed since it essentially gives you (remote) mock building? I have done some like at my first package, and then to my was spoken, that I use local mock and not the infrastructure. But after some updates of mock, mock it now dead. The no response from them maintainer. Assuming good faith here, whoever told you this wanted to save our infrastructure from unnecessary load but in this case we all do benefit (at the end of the day) from you being able to fix your assigned bug reports. - -- Alexander Kahl GNU/Linux Software Developer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAktkJzsACgkQVTRddCFHw11cAgCcDJPLxYxrSGGhYcbEMkmujH6L kmsAnid1k/xK0prmcJ5g1GRcsVyjyZqs =uicE -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
No mouse + keyb in X in latest rawhide + fix (selinux)
Hi, This might be a dup, and I'm a bit under the weather so in no mood to search BZ. Anyways for other people who might hit this if your mouse and keyb in X in rawhide all of a sudden are gone, this is due to haldaemon not starting, which is caused by some selinux issue. Setting selinux to permissive works around this for me. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Would you use a programming language with missing features?
I always say one should not blame the system (OS, language, whatever) for his/her programming mistakes. Unfortunately, Fedora has presently two programming languages with missing features, and the user maybe completely unaware of this. The first one is python. The GUI provided with python is called tkinter, which is based on tk, which, in turn, is based on tcl. Since threads are disabled in Fedora's tcl, as a consequence, one cannot use python+tkinter+threads. I believe there are hundreds of computer courses, based on python, around the world. But maybe threads are a minor subject, and can be just forgotten ... https://www.redhat.com/archives/fedora-devel-list/2009-August/msg00462.html I am not saying the points raised in the above link are not important, but the solution is pretty obvious to me. The second language is called Lazarus, a clone of the indefectible* *Delphi. Lazarus is based on fpc (Free Pascal), and for a long time, Firebird was the only database which could be used reliably via Lazarus components. In Fedora 10, finally, mysql 5.0 started to work via components, but this is no longer true in Fedora 12, which ships mysql 5.1: Fortunately, the fix is easy: https://bugzilla.redhat.com/show_bug.cgi?id=554984 Database components are the only reason one would like to use an old environment, such as Lazarus, in my opinion. I hope someone can address these issues, which certainly affect a lot of people. Thanks. -- Paulo Roma Cavalcanti LCG - UFRJ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Would you use a programming language with missing features?
Hi. On Sat, 30 Jan 2010 11:29:09 -0200, Paulo Cavalcanti wrote The first one is python. The GUI provided with python is called tkinter, which is based on tk, which, in turn, is based on tcl. Since threads are disabled in Fedora's tcl, as a consequence, one cannot use python+tkinter+threads. Or you could just use pygtk, which does threads just fine. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Would you use a programming language with missing features?
On 30.1.2010 14:29, Paulo Cavalcanti wrote: https://www.redhat.com/archives/fedora-devel-list/2009-August/msg00462.html I am not saying the points raised in the above link are not important, but the solution is pretty obvious to me. Obviously it isn't if you looked at the BZ link in the answer to you in the 2009-August thread: https://bugzilla.redhat.com/show_bug.cgi?id=443246 You can try filing a new bugreport or just get in touch with both the maintainer of tcl/tk and eggdrop (quick googling shows there were some workarounds which could make it working with threaded tcl/tk as well) and try to find out the solution that will make eggdrop working with enabled threads. (...and yes, I was recently doing a comparison of python GUIs and can just recommend switching to PyQt, like I did, or PyGtk -- if you prefer). The second language is called Lazarus, a clone of the indefectible/ /Delphi. Lazarus is based on fpc (Free Pascal), and for a long time, Firebird was the only database which could be used reliably via Lazarus components. In Fedora 10, finally, mysql 5.0 started to work via components, but this is no longer true in Fedora 12, which ships mysql 5.1: Fortunately, the fix is easy: https://bugzilla.redhat.com/show_bug.cgi?id=554984 Agree that this one should be easy to fix (*provided that the patch you are mentioning indeed works*), try to ping the maintainer once more -- it is not there so terribly long (2 weeks). Regards, Milos -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Would you use a programming language with missing features?
Le 30/01/2010 14:29, Paulo Cavalcanti a écrit : The first one is python. The GUI provided with python is called tkinter, which is based on tk, which, in turn, is based on tcl. Since threads are disabled in Fedora's tcl, as a consequence, one cannot use python+tkinter+threads. Tkinter is not thread-safe even if you built tcl with threads support, though there's a thread-safe variant aka mtTkinter. Basically, it doesn't matter from a python/Tkinter user standpoint. You can mix Tkinter and threading modules in the same script but as with most toolkits, you must not (well shouldn't) make GUI calls outside the main thread. That's how Gtk+, Qt, Swing work. If you keep that in mind, you'll have no problem making a python application using threads and Tkinter (the same goes for PyQt4 and PyGtk). Anyway, fixing threaded tcl/tk by itself is a worthy goal. H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Would you use a programming language with missing features?
On Sat, Jan 30, 2010 at 1:16 PM, Milos Jakubicek xja...@fi.muni.cz wrote: On 30.1.2010 14:29, Paulo Cavalcanti wrote: https://www.redhat.com/archives/fedora-devel-list/2009-August/msg00462.html I am not saying the points raised in the above link are not important, but the solution is pretty obvious to me. Obviously it isn't if you looked at the BZ link in the answer to you in the 2009-August thread: https://bugzilla.redhat.com/show_bug.cgi?id=443246 At least, there should have been, since the beginning, two tcl available in Fedora: tcl and tcl-non-threaded You can try filing a new bugreport or just get in touch with both the maintainer of tcl/tk and eggdrop (quick googling shows there were some workarounds which could make it working with threaded tcl/tk as well) and try to find out the solution that will make eggdrop working with enabled threads. There are at least two official ways of using threaded tcl and eggdrop: http://eggwiki.org/Threaded_Tcl (...and yes, I was recently doing a comparison of python GUIs and can just recommend switching to PyQt, like I did, or PyGtk -- if you prefer). I am not talking about developing systems, but learning python. tkinter is part of python, which makes it very easy to write simple programs, and run in Windows, for instance (I know there is PyQt for windows, but one has to go to Riverbank...). It is not a pleasant situation when your code does not work because the programming language does not do what it is supposed to. I am not raising any kind of rant here. I am just pointing that there is a problem that could have been already solved. -- Paulo Roma Cavalcanti LCG - UFRJ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: best practice for packing programs that use strlcpy()?
On 1/29/2010 4:50 AM, Tom spot Callaway wrote: On 01/28/2010 09:32 PM, Eric Smith wrote: What is considered the best practice for packaging a program that uses strlcpy()? Besides patching it to not use strlcpy? :) Is there a reason (from a programming point of view) to avoid strlcpy/strlcat? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100130 changes
Compose started at Sat Jan 30 08:15:05 UTC 2010 Broken deps for i386 -- armstrong-0.2.6-8.fc12.i686 requires libporttime.so.0 doodle-0.6.7-5.fc12.i686 requires libextractor.so.1 easystroke-0.5.2-1.fc13.i686 requires libboost_serialization-mt.so.5 1:fife-devel-0.3.0-1.fc13.i686 requires fife = 0:0.3.0-1.fc13 fusecompress-2.6-3.fc12.i686 requires libboost_serialization-mt.so.5 fusecompress-2.6-3.fc12.i686 requires libboost_system-mt.so.5 fusecompress-2.6-3.fc12.i686 requires libboost_program_options-mt.so.5 fusecompress-2.6-3.fc12.i686 requires libboost_filesystem-mt.so.5 fusecompress-2.6-3.fc12.i686 requires libboost_iostreams-mt.so.5 geglmm-0.1.0-2.fc12.i686 requires libbabl-0.0.so.0 gnome-python2-totem-2.29.1-4.fc13.i686 requires libtotem-plparser.so.12 gnuradio-3.2.2-1.fc12.i686 requires libboost_thread-mt.so.5 k3d-0.7.11.0-1.fc12.i586 requires libboost_program_options-mt.so.5 k3d-0.7.11.0-1.fc12.i586 requires libboost_python-mt.so.5 k3d-0.7.11.0-1.fc12.i586 requires libboost_regex-mt.so.5 k3d-devel-0.7.11.0-1.fc12.i586 requires libboost_program_options-mt.so.5 k3d-devel-0.7.11.0-1.fc12.i586 requires libboost_python-mt.so.5 k3d-devel-0.7.11.0-1.fc12.i586 requires libboost_regex-mt.so.5 kdeedu-4.3.95-1.fc13.i686 requires libqalculate.so.4 kdeplasma-addons-4.3.95-2.fc13.i686 requires libqalculate.so.4 koan-2.0.2-1.fc13.noarch requires mkinitrd kst-fits-1.8.0-3.fc12.i686 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf.so.4 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf_c++.so.4 1:libguestfs-1.0.82-6.fc13.i686 requires /lib/libidn.so.11.5.38 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 netbeans-apisupport1-6.7.1-1.fc12.noarch requires netbeans-platform = 0:6.7.1 netbeans-apisupport1-6.7.1-1.fc12.noarch requires netbeans-platform-harness = 0:6.7.1 openscada-plc-0.6.4.1-6.fc13.i686 requires openscada-DAQ-IcpDas qgis-python-1.0.2-4.fc13.i686 requires sip-api(6) = 0:6.0 qmf-0.5.819819-1.fc13.i686 requires libboost_program_options.so.5 qmf-0.5.819819-1.fc13.i686 requires libboost_filesystem.so.5 qpidc-0.5.819819-1.fc13.i686 requires libboost_program_options.so.5 qpidc-0.5.819819-1.fc13.i686 requires libboost_filesystem.so.5 qpidc-perftest-0.5.819819-1.fc13.i686 requires libboost_program_options.so.5 qpidc-perftest-0.5.819819-1.fc13.i686 requires libboost_filesystem.so.5 qpidc-rdma-0.5.819819-1.fc13.i686 requires libboost_program_options.so.5 qpidc-rdma-0.5.819819-1.fc13.i686 requires libboost_filesystem.so.5 qpidc-ssl-0.5.819819-1.fc13.i686 requires libboost_program_options.so.5 qpidc-ssl-0.5.819819-1.fc13.i686 requires libboost_filesystem.so.5 qpidd-0.5.819819-1.fc13.i686 requires libboost_program_options.so.5 qpidd-0.5.819819-1.fc13.i686 requires libboost_filesystem.so.5 qpidd-acl-0.5.819819-1.fc13.i686 requires libboost_program_options.so.5 qpidd-acl-0.5.819819-1.fc13.i686 requires libboost_filesystem.so.5 qpidd-cluster-0.5.819819-1.fc13.i686 requires libboost_program_options.so.5 qpidd-cluster-0.5.819819-1.fc13.i686 requires libboost_filesystem.so.5 qpidd-rdma-0.5.819819-1.fc13.i686 requires libboost_program_options.so.5 qpidd-rdma-0.5.819819-1.fc13.i686 requires libboost_filesystem.so.5 qpidd-ssl-0.5.819819-1.fc13.i686 requires libboost_program_options.so.5 qpidd-ssl-0.5.819819-1.fc13.i686 requires libboost_filesystem.so.5 qpidd-xml-0.5.819819-1.fc13.i686 requires libboost_program_options.so.5 qpidd-xml-0.5.819819-1.fc13.i686 requires libboost_filesystem.so.5 rhm-cpp-server-store-0.5.819819-1.fc13.i686 requires libboost_program_options.so.5 rhm-cpp-server-store-0.5.819819-1.fc13.i686 requires libboost_filesystem.so.5 ruby-qmf-0.5.819819-1.fc13.i686 requires libboost_program_options.so.5 ruby-qmf-0.5.819819-1.fc13.i686 requires libboost_filesystem.so.5 usrp-3.2.2-1.fc12.i686 requires libboost_thread-mt.so.5 zikula-module-menutree-2.2-1.fc13.noarch requires zikula = 0:1.2 Broken deps for x86_64 -- armstrong-0.2.6-8.fc12.i686 requires libporttime.so.0 armstrong-0.2.6-8.fc12.x86_64 requires libporttime.so.0()(64bit) doodle-0.6.7-5.fc12.i686 requires libextractor.so.1 doodle-0.6.7-5.fc12.x86_64 requires libextractor.so.1()(64bit) easystroke-0.5.2-1.fc13.x86_64 requires libboost_serialization-mt.so.5()(64bit) 1:fife-devel-0.3.0-1.fc13.i686 requires fife = 0:0.3.0-1.fc13 1:fife-devel-0.3.0-1.fc13.x86_64 requires fife = 0:0.3.0-1.fc13
AWOL Maintainer: John T. Guthrie III
Seems like Fred Guthrie is AWOL. He did not respond to bugs since 2009-07-20: https://bugzilla.redhat.com/show_bug.cgi?id=512660 I started the AWOL procedure already back in October, but it slipped of my radar: https://bugzilla.redhat.com/show_bug.cgi?id=514882 John owns 18 packages in total: https://admin.fedoraproject.org/pkgdb/users/packages/guthrie If anybody knows what's up with John or how to contact him, please let us know. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphan ircd-hybrid
I need to orphan ircd-hybrid because i don't use it anymore and i don't have time to correct open bugs. Thanks Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How about firefox 3.6 in Fedora 12 ?
On Sat, 2010-01-30 at 11:36 -0600, Rex Dieter wrote: Braden McDaniel wrote: On Sat, 2010-01-30 at 14:48 +0800, Liu Yu Fei Eric wrote: Hi, I noticed firefox was stuck on 3.5.6 for a rather long time. What about 3.5.7 and the recently 3.6? They are even not in koji. xulrunner-1.9.2 breaks API compatibility with 1.9.1, so downstream packages would need patching for this to happen. Even minor releases generally/often break ABI, requiring lots of dependent package rebuilds... or is this case even worse? I said API, and that's what I meant. At the very least, there have been subtle changes to the plug-in API that can cause compile failures. -- Braden McDaniel bra...@endoframe.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How about firefox 3.6 in Fedora 12 ?
On 30/01/10 08:42, Liu Yu Fei Eric wrote: So it doesn't have an official one? Not in F12, but as has been said. You can update to 3.6 from Rawhide, then disable rawhide again. Which is what I have done, no problems yet. -- Regards, Frank Murphy UTF_8 Encoded -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How about firefox 3.6 in Fedora 12 ?
On 30 January 2010 19:00, Mail Lists li...@sapience.com wrote: On 01/30/2010 01:53 PM, Braden McDaniel wrote: On Sat, 2010-01-30 at 11:36 -0600, Rex Dieter wrote: Braden McDaniel wrote: On Sat, 2010-01-30 at 14:48 +0800, Liu Yu Fei Eric wrote: Hi, I noticed firefox was stuck on 3.5.6 for a rather long time. What about 3.5.7 and the recently 3.6? They are even not in koji. xulrunner-1.9.2 breaks API compatibility with 1.9.1, so downstream packages would need patching for this to happen. Even minor releases generally/often break ABI, requiring lots of dependent package rebuilds... or is this case even worse? I said API, and that's what I meant. At the very least, there have been subtle changes to the plug-in API that can cause compile failures. And how many plugins are packaged by fedora ? Any? I'd guess all the plugin dev's at the moz website state clearly which vers of filrefox is supported - and most want their plugins to work with current release - 3.6. So that seems like a bad reason not to update. Well there's the Java and Totem plugins at least, but there's a whole slew of apps in Fedora that build against xulrunner: repoquery --whatrequires --alldeps xulrunner\* -- Mat Booth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How about firefox 3.6 in Fedora 12 ?
On 01/30/2010 02:54 PM, Mat Booth wrote: Well there's the Java and Totem plugins at least, but there's a whole slew of apps in Fedora that build against xulrunner: I think we need to use sun java as green tea is not yet on new api anyway is it? repoquery --whatrequires --alldeps xulrunner\* Cant both xulrunners be there? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Draft privilege escalation policy for comments
On Sat, 2010-01-30 at 08:33 +0100, Kevin Kofler wrote: Adam Williamson wrote: Please do provide any and all feedback on the proposed policy. if we can get it into a shape which most people on the list would find acceptable, my next step will be to take it back to FESco for them to review. Thanks. From the proposal: Add, remove, upgrade or downgrade any system-wide application or shared resource (packaged or otherwise) The current PackageKit policy in F12 updates still allows upgrading (as opposed to installing or removing, not sure about downgrading, does PackageKit even support that?) packages without root authentication. Is this intended to be changed as part of the proposal or should the proposal be fixed instead (just remove upgrade from the sentence)? That's odd. I made exactly that change in the second draft but it somehow switched back in the third. I'd better review all second draft changes tomorrow and make sure they're in the current draft as intended. New and changed privilege escalation mechanisms Is the bureaucracy in this section really necessary? AFAICT what was missing when the F12 PackageKit change was made was the informative part of the proposal, the maintainer just didn't know what he should be allowing and what not. I don't think the enforcement part is really needed, maintainers should be able to get it right on their own given the detailed list of evil things to avoid which the proposal provides and I haven't seen any evidence as to the contrary (again, the PackageKit example is not applicable because the PackageKit maintainer did NOT have such a list to go by when he made his change; there's no reason to believe he'd have made that change in spite of it). I think it's sensible, yeah. It's not really much bureaucracy; I don't think it would ever be a good idea to introduce a new privilege escalation mechanism without FESco knowing about it... -- 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: How about firefox 3.6 in Fedora 12 ?
On 30 January 2010 20:04, Mail Lists li...@sapience.com wrote: On 01/30/2010 02:54 PM, Mat Booth wrote: Well there's the Java and Totem plugins at least, but there's a whole slew of apps in Fedora that build against xulrunner: I think we need to use sun java as green tea is not yet on new api anyway is it? repoquery --whatrequires --alldeps xulrunner\* Cant both xulrunners be there? Maybe but I agree with Braden: I don't think it's worth it. Seems like a lot of extra work for not a lot of gain. -- Mat Booth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How about firefox 3.6 in Fedora 12 ?
On 01/30/2010 05:37 PM, Mat Booth wrote: Maybe but I agree with Braden: I don't think it's worth it. Seems like a lot of extra work for not a lot of gain. I much prefer chrome and use it preferentially now anyway ... I'd prefer we put any broswer related energy into chromium - it is already far superior to firefox and I'd be shocked if its not the dominant browser across all platforms in time. Assuming some cross polination of resources -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upcoming Fedora 13 Tasks - install images
How far away do we appear to be from having an installable rawhide? I have created a Fedora 13 x86_64 install DVD from today's rawhide (Sat.Jan.30), installed it onto a vanilla clone box, and it runs for me. The installation process clobbered the Master Boot Record even though I asked it not to. Using the install DVD as a Rescue disk aborted with a Python error before presenting a shell. I used a Fedora 11 install DVD as a Rescue disk to restore GRUB via /sbin/grub-install. After that, the new partition with Fedora 13 rawhide boots and runs firstboot. AFter that, I connected to the 'net using Firefox 3.6. If anybody really wants a copy of the DVD, and agrees to waive my obligation under the GPL to distribute corresponding source, then send me private email and I will send a pathname. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Would you use a programming language with missing features?
On Sat, Jan 30, 2010 at 6:14 PM, Haïkel Guémar karlthe...@gmail.com wrote: Le 30/01/2010 18:05, Paulo Cavalcanti a écrit : It is not a pleasant situation when your code does not work because the programming language does not do what it is supposed to. I am not raising any kind of rant here. I am just pointing that there is a problem that could have been already solved. The use case provided there is broken by design, multiple threads try use the same Label object. http://mail.python.org/pipermail/python-bugs-list/2008-September/060101.html Until here, we agree. Whenever a tkinter object is accessed from another thread, the program will abort (when tcl is not built with thread enabled). Since Tkinter is currently *not* thread-safe, you shouldn't expect this stuff working properly. Surely, it will not be thread safe when tcl is not built with thread support. Whether you compile tcl/tk with threads support doesn't matter, the problem *lies* in the python layer. It might work on your machine, but it's guaranteed to work elsewhere. Maybe it is not 100% safe http://mail.python.org/pipermail/tkinter-discuss/2008-October/001683.html but I did not see a single example where it does not work when tcl is built with thread enabled. Now what you can do when tcl/tk is compiled with --enable-threads and python has thread support too is creating threads in python and changing tk widgets in another thread. tkinter will schedule these calls from other threads to run in the main thread (with a probability to fail). I can not comment the probability of fail. I would have to look at tkinter code. http://mail.python.org/pipermail/tkinter-discuss/2008-October/001677.html Anyway, if you need a multithreaded Tkinter, then you'll have to build mtTkinter which is not packaged for Fedora at that time. mtTkinter just makes the program work either with tcl thread enabled or not. It is a very small module (160 lines): Usage: import mtTkinter as Tkinter # Use Tkinter. as usual. or from mtTkinter import * # Use Tkinter module definitions as usual. It also has a small test, which I am attaching a screen shot. One can read: mtTkinter works with or without Tcl thread support Anyway, the discussion was good and maybe it is useful to other people too. Thanks. -- Paulo Roma Cavalcanti LCG - UFRJ attachment: mtTkinter.png-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Would you use a programming language with missing features?
On 31.1.2010 01:24, Paulo Cavalcanti wrote: Anyway, the discussion was good and maybe it is useful to other people too. :) Well, really: if you want to change something, file the bugreport, or get in touch with relevant maintainers. I'm not a tcl/tk/python expert, but if you think that your request is ligitimate and could be fulfilled, go ahead and discuss this with the relevant people. Discussion here might be interesting but doesn't bring much, not every package maintainer reads the list (unfortunately), and most of them carefully choose which threads they will follow. They definitely don't read threads with such a provocative subject (I'd just mark it as read normally as well) -- be explicit, using something like build tcl with thread support would definitely atract the relevant people more likely. Regards, Milos -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
How to take ownership of a package in rawhide branch? - Was: [Taking ownership of the orphaned packages: bytelist, jcodings, jvyamlb]
I'm trying to complete the step 3 of the Claiming Ownership of an Orphaned Package Procedure [1] that says: 3. Press the Take Ownership button for each active branch that you want to maintain. However, I don't see such buttons associated with the rawhide for all mentioned packages, i.e. bytelist, jcodings, and jvyamlb. How I can take ownership of the packages in the devel branch, but not in Fedora 11? [1] https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_an_Orphaned_Package_Procedure Thanks, Victor Victor Vasilyev wrote: Hi All, The NetBeans 6.8 [1] depends on some Java libraries whose packages have been marked as orphaned [2]. To resolve the issue and provide the feature in-time I'd like to take ownership of the following packages: - bytelist - Review Request #560169 [3] - jcodings - Review Request #560170 [4] - jvyamlb - Review Request #560172 [5] The spec files are updated and new SRPMs are prepared according to the current states of the corresponding projects. BTW Updating the packages is a step to reanimate JRuby on the Fedora platform. [6] [1] http://fedoraproject.org/wiki/Features/NetBeans_6.8 [2] http://lists.fedoraproject.org/pipermail/devel/2009-July/034863.html [3] https://bugzilla.redhat.com/show_bug.cgi?id=560169 [4] https://bugzilla.redhat.com/show_bug.cgi?id=560170 [5] https://bugzilla.redhat.com/show_bug.cgi?id=560172 [6] http://mohammed.morsi.org/blog/node/305 Cheers, Victor Vasilyev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Draft privilege escalation policy for comments
Adam Williamson wrote: I think it's sensible, yeah. It's not really much bureaucracy; I don't think it would ever be a good idea to introduce a new privilege escalation mechanism without FESco knowing about it... Right now we're in a phase where a lot of stuff (system-config-*, several parts of KDE and some other stuff) is getting ported from running the whole app under consolehelper or kdesu to PolicyKit mechanisms. This is generally seen as a *good* thing. It'd be really annoying to have to go through a FESCo vote for every single one of those. At the very least, I'd suggest adding the following clause to that paragraph: Any mechanism which requires administrative authentication to perform the privileged action (e.g. auth_admin policy in PolicyKit, kdesu etc.) is NOT a privilege escalation mechanism for the purposes of this paragraph. Rationale: Such a policy does not impact the system's security as you have to enter the root password before doing anything dangerous, so none of the invariants under Requirements can be violated. And additionally, you can always as a user run the whole app under e.g. kdesu and thus escalate your privileges using the root password, so it doesn't make sense to police apps providing such a mechanism. What really matters for security is what you can do WITHOUT the root password. This is not really clear from the policy as written now, adding the suggested sentence would clarify it. (That said, I don't see even the clarified policy as being necessary. We have a set of guidelines, maintainers should follow them, why do we have to police them? As I explained before, there is no evidence that this is necessary or useful. The PackageKit issue was caused by lack of a policy, not lack of enforcement.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
