Re: Firefox 4 for Fedora 14?
On 07/28/2010 01:08 AM, Mike McGrath wrote: >> On 07/27/2010 10:53 PM, Rahul Sundaram wrote: >>> >>> Are we skipping Firefox 4 for Fedora 14? Beta 2 has been released >>> recently and I am wondering if we can go with it if it fits into the >>> schedule. There are dozens of new features including WebM support that >>> would be nice to have. > > -1 didn't the last time we started using a pre-release from Mozilla turn > out pretty bad for us? That was Firefox 3.0 included as RC in Fedora 9, from an user perspective my memories about it are sweet... it was worse with Thunderbird 3, which was included in a release (F11) in Beta stage, and not even a late beta, it was something like Beta2, but AFAIK Firefox is expected to be RC around F14. And while Thunderbird 3 was included due to the slow development pace of the upstream (we used to have a very old Tb 2), Firefox 4 comes with at least a killer feature, WebM (IIRC, another killer feature is the new js engine) -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpms/python-sexy/devel python-sexy-gdk-pixbuf.patch, NONE, 1.1 python-sexy.spec, 1.15, 1.16
Orcan Ogetbil wrote, at 07/28/2010 03:19 PM +9:00: > On Wed, Jul 28, 2010 at 2:09 AM, Mamoru Tasaka wrote: >> Orcan Ogetbil wrote, at 07/28/2010 02:44 PM +9:00: >>> >>> Author: oget >>> >>> Update of /cvs/pkgs/rpms/python-sexy/devel >>> In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv31418 >>> >>> Modified Files: >>> python-sexy.spec >>> Added Files: >>> python-sexy-gdk-pixbuf.patch >>> Log Message: >>> * Wed Jul 28 2010 Orcan Ogetbil- >>> 0.1.9-12 >>> - Fix gdk-pixbuf header location issue on F-14 >>> >> >> I think this should be fixed in pygtk2, not in python-sexy. >> > > Yes, you are most probably right. Sorry, I had a few other packages > that depend on python-sexy, so I wanted to get it fixed asap. So many > python packages are flying around my head... Maybe I need some sleep. > I'll correct this tomorrow in case someone else doesn't. Feel free to > fix it. > > Thanks for the warning. > > Orcan > Yes, actually python-sexy is one of the packages which prevents me from updating python 2.7 on my box. For pygtk2 issue, I filed: https://bugzilla.redhat.com/show_bug.cgi?id=618944 Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpms/python-sexy/devel python-sexy-gdk-pixbuf.patch, NONE, 1.1 python-sexy.spec, 1.15, 1.16
On Wed, Jul 28, 2010 at 2:09 AM, Mamoru Tasaka wrote: > Orcan Ogetbil wrote, at 07/28/2010 02:44 PM +9:00: >> >> Author: oget >> >> Update of /cvs/pkgs/rpms/python-sexy/devel >> In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv31418 >> >> Modified Files: >> python-sexy.spec >> Added Files: >> python-sexy-gdk-pixbuf.patch >> Log Message: >> * Wed Jul 28 2010 Orcan Ogetbil - >> 0.1.9-12 >> - Fix gdk-pixbuf header location issue on F-14 >> > > I think this should be fixed in pygtk2, not in python-sexy. > Yes, you are most probably right. Sorry, I had a few other packages that depend on python-sexy, so I wanted to get it fixed asap. So many python packages are flying around my head... Maybe I need some sleep. I'll correct this tomorrow in case someone else doesn't. Feel free to fix it. Thanks for the warning. Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpms/python-sexy/devel python-sexy-gdk-pixbuf.patch, NONE, 1.1 python-sexy.spec, 1.15, 1.16
Orcan Ogetbil wrote, at 07/28/2010 02:44 PM +9:00: > Author: oget > > Update of /cvs/pkgs/rpms/python-sexy/devel > In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv31418 > > Modified Files: > python-sexy.spec > Added Files: > python-sexy-gdk-pixbuf.patch > Log Message: > * Wed Jul 28 2010 Orcan Ogetbil - 0.1.9-12 > - Fix gdk-pixbuf header location issue on F-14 > I think this should be fixed in pygtk2, not in python-sexy. The previous build (which failed) was: http://koji.fedoraproject.org/koji/buildinfo?buildID=185665 build.log says: --- gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/python2.7 -pthread -I/usr/include/pygtk-2.0 -I/usr/lib64/libffi-3.0.9/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -pthread -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/libxml2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -c sexy.c -fPIC -DPIC -o .libs/sexy_la-sexy.o In file included from /usr/include/gtk-2.0/gdk/gdkcairo.h:28:0, from /usr/include/gtk-2.0/gdk/gdk.h:33, from /usr/include/gtk-2.0/gtk/gtk.h:32, from /usr/include/pygtk-2.0/pygtk/pygtk.h:8, from sexy.override:8: /usr/include/gtk-2.0/gdk/gdkpixbuf.h:37:35: fatal error: gdk-pixbuf/gdk-pixbuf.h: No such file or directory --- The cflags used here comes from "pkg-config --cflags pygtk-2.0 libsexy". The problem here is that (as seen in this build.log) pygtk2 header file (/usr/include/pygtk-2.0/pygtk/pygtk.h) tries to include header file in gtk2, however - pygtk-2.0.pc says - Requires: pygobject-2.0 - - pygobject-2.0.pc says - Requires: gobject-2.0 - So needed gdk-pixbuf headers cannot be included. I think pygtk-2.0.pc should have "Requires: pygobject-2.0 gtk-2.0". Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Package Review Stats for last week ending 25th July
Top three FAS account holders who have completed reviewing "Package review" components on bugzilla for last week ending 25th July were Manuel Wolfshant, Parag AN(पराग) and Thomas Spura. Manuel Wolfshant : 9 https://bugzilla.redhat.com/show_bug.cgi?id=599638 perl-YAPE-Regex https://bugzilla.redhat.com/show_bug.cgi?id=616586 perl-MooseX-Method-Signatures https://bugzilla.redhat.com/show_bug.cgi?id=617479 perl-GD-SecurityImage https://bugzilla.redhat.com/show_bug.cgi?id=589075 dpkt https://bugzilla.redhat.com/show_bug.cgi?id=613525 klog https://bugzilla.redhat.com/show_bug.cgi?id=613646 twlog https://bugzilla.redhat.com/show_bug.cgi?id=617318 xpenguins https://bugzilla.redhat.com/show_bug.cgi?id=502358 mojomojo https://bugzilla.redhat.com/show_bug.cgi?id=617618 perl-Carp-Always Parag AN(पराग) : 7 https://bugzilla.redhat.com/show_bug.cgi?id=615128 cjkuni-uming-fonts https://bugzilla.redhat.com/show_bug.cgi?id=615129 cjkuni-ukai-fonts https://bugzilla.redhat.com/show_bug.cgi?id=616289 perl-MooseX-Clone https://bugzilla.redhat.com/show_bug.cgi?id=226562 xkeyboard-config (Merge Review) https://bugzilla.redhat.com/show_bug.cgi?id=226646 xorg-x11-util-macros (Merge Review) https://bugzilla.redhat.com/show_bug.cgi?id=603233 zeromq https://bugzilla.redhat.com/show_bug.cgi?id=615575 perl-Parse-Method-Signatures Thomas Spura : 7 https://bugzilla.redhat.com/show_bug.cgi?id=600914 txt2regex https://bugzilla.redhat.com/show_bug.cgi?id=226023 libgsf (Merge Review) https://bugzilla.redhat.com/show_bug.cgi?id=226060 libwpd (Merge Review) https://bugzilla.redhat.com/show_bug.cgi?id=226094 libXxf86dga (Merge Review) https://bugzilla.redhat.com/show_bug.cgi?id=603639 python-ufo2fdk https://bugzilla.redhat.com/show_bug.cgi?id=603640 python-compositor https://bugzilla.redhat.com/show_bug.cgi?id=603641 python-fontMath Orcan 'oget' Ogetbil : 5 https://bugzilla.redhat.com/show_bug.cgi?id=516537 globus-gram-job-manager-setup-fork https://bugzilla.redhat.com/show_bug.cgi?id=516538 globus-gram-job-manager-setup-condor https://bugzilla.redhat.com/show_bug.cgi?id=516539 globus-gram-job-manager-setup-lsf https://bugzilla.redhat.com/show_bug.cgi?id=516540 globus-gram-job-manager-setup-pbs https://bugzilla.redhat.com/show_bug.cgi?id=563822 globus-gram-job-manager-setup-sge Ankur Sinha : 5 https://bugzilla.redhat.com/show_bug.cgi?id=615847 oflb-asana-math-fonts https://bugzilla.redhat.com/show_bug.cgi?id=615848 oflb-brett-fonts https://bugzilla.redhat.com/show_bug.cgi?id=615849 oflb-icelandic-fonts https://bugzilla.redhat.com/show_bug.cgi?id=615850 oflb-roadstencil-fonts https://bugzilla.redhat.com/show_bug.cgi?id=615851 oflb-sportrop-fonts Mattias Ellert : 4 https://bugzilla.redhat.com/show_bug.cgi?id=615091 ctpl https://bugzilla.redhat.com/show_bug.cgi?id=537325 lv2-fil-plugins https://bugzilla.redhat.com/show_bug.cgi?id=583327 clementine https://bugzilla.redhat.com/show_bug.cgi?id=609193 python-dirq Mamoru Tasaka : 3 https://bugzilla.redhat.com/show_bug.cgi?id=614451 rubygem-gherkin https://bugzilla.redhat.com/show_bug.cgi?id=617797 ranger https://bugzilla.redhat.com/show_bug.cgi?id=610857 rubygem-curb Marcela Mašláňová : 2 https://bugzilla.redhat.com/show_bug.cgi?id=612565 shigofumi https://bugzilla.redhat.com/show_bug.cgi?id=558743 perl-Unicode-String (Merge Review) Stanislav Ochotnicky : 2 https://bugzilla.redhat.com/show_bug.cgi?id=609130 felix-framework https://bugzilla.redhat.com/show_bug.cgi?id=615868 felix-parent Toshio Ernie Kuratomi : 1 https://bugzilla.redhat.com/show_bug.cgi?id=592670 mongoose Chitlesh GOORAH : 1 https://bugzilla.redhat.com/show_bug.cgi?id=615319 cgnslib Chris Spike : 1 https://bugzilla.redhat.com/show_bug.cgi?id=616808 maven-changes-plugin Daniel Kopeček : 1 https://bugzilla.redhat.com/show_bug.cgi?id=614416 python-scripttest David A. Wheeler : 1 https://bugzilla.redhat.com/show_bug.cgi?id=592579 Frama-c Remi Collet : 1 https://bugzilla.redhat.com/show_bug.cgi?id=597410 php-deepend-Mockery Hans de Goede : 1 https://bugzilla.redhat.com/show_bug.cgi?id=576023 libwebcam Kevin Fenzi : 1 https://bugzilla.redhat.com/show_bug.cgi?id=226813 zsh (Merge Review) Magnus Tuominen : 1 https://bugzilla.redhat.com/show_bug.cgi?id=609738 shiboken Martin Gieseking : 1
Re: Firefox 4 for Fedora 14?
2010/7/28 Filipe Rosset : >> > > We was delayed in F-12 (two weeks) and in F-13 (two weeks), probably > we'll have a final version for Firefox 4 before or a bit after we > release F-14. Another thing, we can test a lot and assist in upstream > during our testing phase. > It's +1 for me. > > -- > Filipe > Rio Grande do Sul, Brazil > -- Agree, shipping a RC version Firefox 4 for F14 is acceptable for me, F11 already shipped Firefox 3.5 beta4, it worked without any serious issues. I suggest to build Firefox 4 Beta for F15 shortly after F14 branched from Rawhide, if it works without any serious issues, then we can backport it to F14 Beta. Firefox 4 is definitely an amazing feature for Fedora 14. Regard, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 for Fedora 14?
On Tue 27 July 2010 16:46:29 Rahul Sundaram wrote: > On 07/28/2010 05:09 AM, Christopher Aillon wrote: > > On 07/28/2010 12:49 AM, Rahul Sundaram wrote: > >> Non upstreamed patches are not a option for > >> > >> Firefox for trademark reasons as well. > > > > Non upstreamed patches are not an option because it's a pain in the to > > have to update patches every few weeks for a new FF release. We > > either can do patches or take new releases, doing both is just a > > maintenance nightmare. Since Fedora is all about doing stuff > > upstream, it sorts itself out better that way. > > Well yes. Trademark is not the only reason obviously but I don't want > to deviate the discussion more. Is Firefox 4 being considered for > Fedora 14 or not? I'd be really bothered with shipping (beta) software where we are more or less at the mercy of our upstream wrt possible issues, bugs, etc. Yes, yes, yes, I'm probably going to get flamed for that, it's mozilla, we need to work with upstream, etc, etc, but would we put other (arguably) crit-path in this position, especially at GA? I'm all for Firefox 4, but shipping a Beta in which we are limited in what patches we can ship, this late in the release cycle, it just really bothers me. > Rahul Ryan -- Ryan Rix == http://hackersramblings.wordpress.com | http://rix.si/ == == http://rix.si/page/contact/ if you need a word == signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Python 2.7 status: python2.7 is in dist-f14
Rawhide (dist-f14) now has python 2.7 Many thanks to everyone who helped get us this far! Jesse and I moved 931 builds [1] from dist-f14-py27-rebuild to dist-f14 about 45 minutes ago. If I'm reading the Koji logs correct [2] [3], these packages are now available in the buildroot for F14, so further builds for "devel" will be against python 2.7 A further 26 builds in dist-f14-py27-rebuild had newer builds in rawhide, so we'll need to rebuild these; some are important e.g. yum and anaconda (see [1] again). Packages should now be built into rawhide, rather than to the dist-f14-py27-rebuild target. AdamW did some testing earlier using the py27 tag: "quick summary, preliminary findings: we can update a bare f13 live install pretty much okay, we can compose an f14 live pretty much okay (but can't test if it boots due to unrelated issues)" ; I've also been testing in runlevel3 on a rawhide box upgraded to the tag, and using it successfully as a development host for fixing other builds. However, this may be impacted by the newer builds mentioned above. We briefly got down to 99 failing rebuilds, but there was a flaw in my original mass-rebuild method: I had only rebuilt packages with a requirement on: python(abi) = 2.6 which didn't catch packages with a requirement on: libpython2.6.so.1.0 I ran a script to rebuild anything with the second criterion that I'd missed; these mostly succeeded, but there were some new failures. This brings the total number of failing rebuilds to 108: http://dmalcolm.fedorapeople.org/python-packaging/failures-2010-07-27-04.html with some new people listed there. ...plus the re-rebuilds mentioned above. I need food and sleep, so I plan to look at these rebuilds tomorrow. Common rebuild issues (in no particular order): - gcc44 -> 45 changes - gtk issues (being discussed on desk...@lists.fedoraproject.org, though I believe most of the gtk folks are at GUADEC) - swig 1 -> swig 2 changes - configure.ac files that list python 2.2 2.3 2.4 2.5 2.6 but not 2.7 - any actual python 2.6 -> 2.7 issues (seemingly few of these so far) - boost, perhaps? (looks like we need to rebuild again for the SONAME bump) See also: https://fedoraproject.org/wiki/Features/Python_2.7 Hope this all makes sense Dave [1] http://dmalcolm.fedorapeople.org/python-packaging/mass-tag-from-dist-f14-py27-rebuild-into-dist-f14.txt [2] http://koji.fedoraproject.org/koji/taskinfo?taskID=2355260 [3] http://koji.fedoraproject.org/koji/getfile?taskID=2355261&name=createrepo.log -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 for Fedora 14?
On Tue, 27 Jul 2010, Filipe Rosset wrote: > Em 27-07-2010 18:53, Rahul Sundaram escreveu: > > Hi, > > > > Are we skipping Firefox 4 for Fedora 14? Beta 2 has been released > > recently and I am wondering if we can go with it if it fits into the > > schedule. There are dozens of new features including WebM support that > > would be nice to have. > > > > We was delayed in F-12 (two weeks) and in F-13 (two weeks), probably > we'll have a final version for Firefox 4 before or a bit after we > release F-14. Another thing, we can test a lot and assist in upstream > during our testing phase. > It's +1 for me. > If Fedora didn't have stability issues I'd be all for it, but we do. And part of it is because we shoot from the hip with stuff like this. If Mozilla doesn't think it's ready yet, I don't know why we would think it is. -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 for Fedora 14?
On 07/28/2010 05:09 AM, Christopher Aillon wrote: > On 07/28/2010 12:49 AM, Rahul Sundaram wrote: >> Non upstreamed patches are not a option for >> Firefox for trademark reasons as well. > > Non upstreamed patches are not an option because it's a pain in the to > have to update patches every few weeks for a new FF release. We > either can do patches or take new releases, doing both is just a > maintenance nightmare. Since Fedora is all about doing stuff > upstream, it sorts itself out better that way. Well yes. Trademark is not the only reason obviously but I don't want to deviate the discussion more. Is Firefox 4 being considered for Fedora 14 or not? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 for Fedora 14?
On 07/28/2010 05:01 AM, Brandon Lozza wrote: > what about iceweasel or icefox instead > > the trademark problem makes it non free > Fedora has a policy of not patching upstream software as much as possible and trademark is only partially the reason and no, trademark requirements do not make anything non-free. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 for Fedora 14?
On 07/28/2010 12:49 AM, Rahul Sundaram wrote: > Non upstreamed patches are not a option for > Firefox for trademark reasons as well. Non upstreamed patches are not an option because it's a pain in the to have to update patches every few weeks for a new FF release. We either can do patches or take new releases, doing both is just a maintenance nightmare. Since Fedora is all about doing stuff upstream, it sorts itself out better that way. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 for Fedora 14?
On Tue, Jul 27, 2010 at 6:31 PM, Brandon Lozza wrote: > On 7/27/10, Rahul Sundaram wrote: > > On 07/28/2010 04:06 AM, Sam Varshavchik wrote: > > > According to this two year-old post, it's possible to build Firefox > > > with gstreamer support: > > > > > > > http://www.bluishcoder.co.nz/2008/04/firefox-html5-video-with-gstreamer.html > > > > > > > > > Dunno if any of that is true today. > > > > > > There's precedent for Firefox using system components instead of > > > bundled ones. Firefox already uses hunspell instead of its own bundled > > > dictionary, for spell checking. It makes sense for Firefox to use > > > gstreamer, instead of any bundled codecs. > > > > > > The blog post talks about a non upstreamed patch and Firefox doesn't use > > Gstreamer at all now. It isn't just a matter of a bundled vs system > > components at this point.Non upstreamed patches are not a option for > > Firefox for trademark reasons as well. > > > > > > Rahul > > > > -- > > devel mailing list > > devel@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/devel > > > > what about iceweasel or icefox instead > > the trademark problem makes it non free > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Then that would make most Linux distributions non-free, including Fedora. So, meh. Fedora also has a policy of trying not to add patches to their own packages, so it jives just fine with Mozilla's trademark policy. Plus, those names suck, keep the Mozilla Firefox name. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 for Fedora 14?
On 7/27/10, Rahul Sundaram wrote: > On 07/28/2010 04:06 AM, Sam Varshavchik wrote: > > According to this two year-old post, it's possible to build Firefox > > with gstreamer support: > > > > > http://www.bluishcoder.co.nz/2008/04/firefox-html5-video-with-gstreamer.html > > > > > > Dunno if any of that is true today. > > > > There's precedent for Firefox using system components instead of > > bundled ones. Firefox already uses hunspell instead of its own bundled > > dictionary, for spell checking. It makes sense for Firefox to use > > gstreamer, instead of any bundled codecs. > > > The blog post talks about a non upstreamed patch and Firefox doesn't use > Gstreamer at all now. It isn't just a matter of a bundled vs system > components at this point.Non upstreamed patches are not a option for > Firefox for trademark reasons as well. > > > Rahul > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > what about iceweasel or icefox instead the trademark problem makes it non free -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 for Fedora 14?
On Tue, Jul 27, 2010 at 11:08 PM, Mike McGrath wrote: > On Tue, 27 Jul 2010, Athmane Madjoudj wrote: > >> On 07/27/2010 10:53 PM, Rahul Sundaram wrote: >> > Hi, >> > >> > Are we skipping Firefox 4 for Fedora 14? Beta 2 has been released >> > recently and I am wondering if we can go with it if it fits into the >> > schedule. There are dozens of new features including WebM support that >> > would be nice to have. >> > >> > Rahul >> >> The final version of FF4 is scheduled at oct-nov 2010 and Fedora 14 at >> 26 Oct 2010 >> >> I think, it's OK to have ff4 in F14, and better is IMHO is to have a >> parallel installation, something like: >> >> firefox3-3.x.x >> firefox-4.x.x >> >> Sources: >> >> [1] https://wiki.mozilla.org/Releases >> [2] http://fedoraproject.org/wiki/Releases/14/Schedule >> > > -1 didn't the last time we started using a pre-release from Mozilla turn > out pretty bad for us? well the last beta I presume your talking about is a certain mail client. The last time we shipped a beta firefox for release I think was for firefox 3 and it was something like beta6 with the official release coming out shortly after and from my memory the beta was relatively stable and a reasonable win in terms of performance. There was some discussion about it but I don't remember anything to the tune of thunderbird. The xulrunner dependents are obviously an issue but with gnome 3 and the move to webkit it rules out the vast majority of them and I'm not even sure thunderbird uses the offset xulrunner (but its likely there are others that do need review). Peter Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 for Fedora 14?
On 07/28/2010 04:06 AM, Sam Varshavchik wrote: > According to this two year-old post, it's possible to build Firefox > with gstreamer support: > > http://www.bluishcoder.co.nz/2008/04/firefox-html5-video-with-gstreamer.html > > > Dunno if any of that is true today. > > There's precedent for Firefox using system components instead of > bundled ones. Firefox already uses hunspell instead of its own bundled > dictionary, for spell checking. It makes sense for Firefox to use > gstreamer, instead of any bundled codecs. The blog post talks about a non upstreamed patch and Firefox doesn't use Gstreamer at all now. It isn't just a matter of a bundled vs system components at this point.Non upstreamed patches are not a option for Firefox for trademark reasons as well. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 for Fedora 14?
Rahul Sundaram writes: On 07/28/2010 03:33 AM, Brandon Lozza wrote: Doesn't our version already support WebM? Nope. We have updated Gstreamer and WebKit-Gtk in Fedora 13 and 12 for WebM support bringing it to Epiphany and Midori users and I assume Spot's Chromium repo users also have support for it but Firefox 4 will be the first stable version with WebM support built-in. According to this two year-old post, it's possible to build Firefox with gstreamer support: http://www.bluishcoder.co.nz/2008/04/firefox-html5-video-with-gstreamer.html Dunno if any of that is true today. There's precedent for Firefox using system components instead of bundled ones. Firefox already uses hunspell instead of its own bundled dictionary, for spell checking. It makes sense for Firefox to use gstreamer, instead of any bundled codecs. pgpM3jAcDvi6c.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 for Fedora 14?
Em 27-07-2010 18:53, Rahul Sundaram escreveu: > Hi, > > Are we skipping Firefox 4 for Fedora 14? Beta 2 has been released > recently and I am wondering if we can go with it if it fits into the > schedule. There are dozens of new features including WebM support that > would be nice to have. > We was delayed in F-12 (two weeks) and in F-13 (two weeks), probably we'll have a final version for Firefox 4 before or a bit after we release F-14. Another thing, we can test a lot and assist in upstream during our testing phase. It's +1 for me. -- Filipe Rio Grande do Sul, Brazil -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 for Fedora 14?
F11 or F12 had a beta version of firefox spot's chromium builds do support webm, it works great :) On Tue, Jul 27, 2010 at 6:11 PM, Athmane Madjoudj wrote: > On 07/27/2010 11:08 PM, Mike McGrath wrote: >> On Tue, 27 Jul 2010, Athmane Madjoudj wrote: >> >>> On 07/27/2010 10:53 PM, Rahul Sundaram wrote: Hi, Are we skipping Firefox 4 for Fedora 14? Beta 2 has been released recently and I am wondering if we can go with it if it fits into the schedule. There are dozens of new features including WebM support that would be nice to have. Rahul >>> >>> The final version of FF4 is scheduled at oct-nov 2010 and Fedora 14 at >>> 26 Oct 2010 >>> >>> I think, it's OK to have ff4 in F14, and better is IMHO is to have a >>> parallel installation, something like: >>> >>> firefox3-3.x.x >>> firefox-4.x.x >>> >>> Sources: >>> >>> [1] https://wiki.mozilla.org/Releases >>> [2] http://fedoraproject.org/wiki/Releases/14/Schedule >>> >> >> -1 didn't the last time we started using a pre-release from Mozilla turn >> out pretty bad for us? >> >> -Mike > > This remind me Thunderbird 3 beta in F11 > > -- > Athmane Madjoudj > -- > 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: Seeking to merge python 2.7 into rawhide
On Tue, Jul 27, 2010 at 10:35:50PM +0200, Matthias Runge wrote: > Sadly, my name (for django-lint) is on the list. I've seen a rebuild of > django-lint produced an error. Of course, fixed it, but the fix was not > taken in account for the above list. > What can I do to correct this situation, esp. my correct build was > before the failed build initiated by dmalcolm > > http://koji.fedoraproject.org/koji/packageinfo?packageID=10153 > resp. > > http://koji.fedoraproject.org/koji/buildinfo?buildID=185662 The build was done for the target dist-f14 instead of dist-f14-py27-rebuild, which is the target containing python 2.7. I am not sure, but I guess the right way would be to either increase the release and build it with "make TARGET=dist-f14-py27-rebuild" or to wait until python 2.7 is in the normal buildroot and then rebuild django-lint. Regards Till pgp0dVk45jc8h.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 for Fedora 14?
On 07/27/2010 11:08 PM, Mike McGrath wrote: > On Tue, 27 Jul 2010, Athmane Madjoudj wrote: > >> On 07/27/2010 10:53 PM, Rahul Sundaram wrote: >>> Hi, >>> >>> Are we skipping Firefox 4 for Fedora 14? Beta 2 has been released >>> recently and I am wondering if we can go with it if it fits into the >>> schedule. There are dozens of new features including WebM support that >>> would be nice to have. >>> >>> Rahul >> >> The final version of FF4 is scheduled at oct-nov 2010 and Fedora 14 at >> 26 Oct 2010 >> >> I think, it's OK to have ff4 in F14, and better is IMHO is to have a >> parallel installation, something like: >> >> firefox3-3.x.x >> firefox-4.x.x >> >> Sources: >> >> [1] https://wiki.mozilla.org/Releases >> [2] http://fedoraproject.org/wiki/Releases/14/Schedule >> > > -1 didn't the last time we started using a pre-release from Mozilla turn > out pretty bad for us? > > -Mike This remind me Thunderbird 3 beta in F11 -- Athmane Madjoudj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 for Fedora 14?
On 07/28/2010 03:38 AM, Mike McGrath wrote: > -1 didn't the last time we started using a pre-release from Mozilla turn > out pretty bad for us? > More specifics please. Which version of Firefox and what problems? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 for Fedora 14?
I'm sure there'd be enough time to squeeze in FF4.0. Assuming there's no development delays with Mozilla. Regards -- http://home.comcen.com.au/foxmulder881/signature/details.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 for Fedora 14?
On 07/28/2010 03:33 AM, Brandon Lozza wrote: > Doesn't our version already support WebM? > Nope. We have updated Gstreamer and WebKit-Gtk in Fedora 13 and 12 for WebM support bringing it to Epiphany and Midori users and I assume Spot's Chromium repo users also have support for it but Firefox 4 will be the first stable version with WebM support built-in. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 for Fedora 14?
On Tue, 27 Jul 2010, Athmane Madjoudj wrote: > On 07/27/2010 10:53 PM, Rahul Sundaram wrote: > > Hi, > > > > Are we skipping Firefox 4 for Fedora 14? Beta 2 has been released > > recently and I am wondering if we can go with it if it fits into the > > schedule. There are dozens of new features including WebM support that > > would be nice to have. > > > > Rahul > > The final version of FF4 is scheduled at oct-nov 2010 and Fedora 14 at > 26 Oct 2010 > > I think, it's OK to have ff4 in F14, and better is IMHO is to have a > parallel installation, something like: > > firefox3-3.x.x > firefox-4.x.x > > Sources: > > [1] https://wiki.mozilla.org/Releases > [2] http://fedoraproject.org/wiki/Releases/14/Schedule > -1 didn't the last time we started using a pre-release from Mozilla turn out pretty bad for us? -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 for Fedora 14?
On 07/27/2010 10:53 PM, Rahul Sundaram wrote: > Hi, > > Are we skipping Firefox 4 for Fedora 14? Beta 2 has been released > recently and I am wondering if we can go with it if it fits into the > schedule. There are dozens of new features including WebM support that > would be nice to have. > > Rahul The final version of FF4 is scheduled at oct-nov 2010 and Fedora 14 at 26 Oct 2010 I think, it's OK to have ff4 in F14, and better is IMHO is to have a parallel installation, something like: firefox3-3.x.x firefox-4.x.x Sources: [1] https://wiki.mozilla.org/Releases [2] http://fedoraproject.org/wiki/Releases/14/Schedule -- Athmane Madjoudj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 for Fedora 14?
Doesn't our version already support WebM? On Tue, Jul 27, 2010 at 5:53 PM, Rahul Sundaram wrote: > Hi, > > Are we skipping Firefox 4 for Fedora 14? Beta 2 has been released > recently and I am wondering if we can go with it if it fits into the > schedule. There are dozens of new features including WebM support that > would be nice to have. > > Rahul > -- > 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
Firefox 4 for Fedora 14?
Hi, Are we skipping Firefox 4 for Fedora 14? Beta 2 has been released recently and I am wondering if we can go with it if it fits into the schedule. There are dozens of new features including WebM support that would be nice to have. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question on SELinux AVC messages with systemd.
On Mon, Jul 26, 2010 at 02:39:55PM -0400, Bill Nottingham wrote: > Dave Jones (da...@redhat.com) said: > > of those that it does open(),.. Is there seriously a use-case for someone > > wanting > > lvm partitioned /dev/ram disks ? or /dev/loop ? > > I would assume that's for testing. point being that for those who care about doing that, they probably know how to add a line to /etc/lvm.conf we don't need to support this and other madness out of the box at the detriment of the common case user. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f14 boost-1.44.0 upgrade: notice of intent
> Do you have a list of packages which will need to be rebuilt? This is > the last day before we branch, and with the dist-git outage there will > be a short time to fix things before the Alpha freeze. Is anything in > the critpath dependent upon boost, or in the primary spins? here's the old list: openvrml pingus hugin conexus player mapnik aqsis qpidc deluge rcsslogplayer Miro asc glob2 vegastrike gnash chess pyexiv2 k3d kdeedu python-tag linkage barry rcssserver QuantLib wesnoth mkvtoolnix rb_libtorrent bmpx xmms2 wp_tray fuse-encfs referencer source-highlight HippoDraw rcsserver3d This is from: http://fedoraproject.org/wiki/Features/F13Boost141 -benjamin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Seeking to merge python 2.7 into rawhide
Am 27.07.2010 03:27, schrieb David Malcolm: > Current status: 114 failing builds > http://dmalcolm.fedorapeople.org/python-packaging/failures-2010-07-26-02.html > > See also the notes on: > https://fedoraproject.org/wiki/Features/Python_2.7#Current_status > > Many of these appear to be pre-existing FTBFS; as far as I can make out, > the #includes for parts of the GTK stack are substantially broken in > rawhide. > > Can we get all of the hundreds of successful builds into rawhide before > it drifts further? > > Dave > Sadly, my name (for django-lint) is on the list. I've seen a rebuild of django-lint produced an error. Of course, fixed it, but the fix was not taken in account for the above list. What can I do to correct this situation, esp. my correct build was before the failed build initiated by dmalcolm http://koji.fedoraproject.org/koji/packageinfo?packageID=10153 resp. http://koji.fedoraproject.org/koji/buildinfo?buildID=185662 Thanks, Matthias -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Tue, 2010-07-27 at 11:34 -0400, Bill Nottingham wrote: > Adam Williamson (awill...@redhat.com) said: > > > The 'not separating the scripts into a separate subpackage' bit. > > > > Ah. I thought the point of separating them wasn't to allow for multiple > > init systems, but because our current guidance was to use sysvinit > > scripts by default, not upstart scripts; so with them separated off, you > > only get the upstart native script if you manually install it. > > The referenced packages aren't using upstart jobs as a replacement for > traditional SysV service scripts... they're using upstart for things that > don't really fit in the service paradigm. Ah, I see, that makes sense then. Thanks. -- 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: Using LLVM for build package instead gcc, why not?
On 07/24/2010 01:09 PM, Horst H. von Brand wrote: > Jonathan MERCIER wrote: >> If we could swap out old C compilers for a more generic LLVM compiler >> for core components like the kernel, > > Won't happen until clang generates much better code than GCC; in the > meanwhile it'll have to grok all GCC extensions. The kernel also depends on a lot of GCC-specific extensions (asm syntax, variable and linker attributes, things that aren't 100% specified by language definition like data layouts/packing, etc) In principle LLVM could replicate those things, but it probably doesn't right now. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
f14 boost-1.44.0 upgrade: pushed
The boost maintainers have updated the boost package to the current release (1.44.0) in rawhide for F14. More info here: https://fedoraproject.org/wiki/Features/F14Boost144 Rebuilds for devel packages that require boost are mandatory, as SONAME was bumped. Help from package maintainers with rebuilding packages with boost dependencies is appreciated. -benjamin ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: KDE-SIG meeting report (30/2010)
Rahul Sundaram wrote: > DeviceKit or udisks backend? libudev / udisks / upower actually. The original DeviceKit is dead. The name for the Solid backend stuck, it should probably be renamed. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
On Tuesday 27 July 2010, Przemek Klosowski wrote: > On 07/26/2010 07:25 PM, M A Young wrote: > > On Mon, 26 Jul 2010, Tom "spot" Callaway wrote: > >> You're going to need to include all applicable license texts, sorry. > > > > I have commited a spec file that puts all the COPYING and LICENSE files > > into a new xen-licenses package (I don't what to include that many files > > twice). > > This is an excellent idea. Wouldn't it make sense to take it further and > create a couple dozen packages for all major licenses (GPL 2, 3, BSD, > MIT, Artistic, Apache etc etc) and specify the correct ones as > dependencies of respective packages? I suppose the Q&A section in the original announcement is intended to cover this. http://lists.fedoraproject.org/pipermail/devel-announce/2010-July/000631.html | Q. Why can't we just have a "fedora-licenses" package which has copies | of all the licenses in Fedora and just always install it? | A. Maintaining that package would be a huge pain. We have a LOT of | licenses in Fedora and they change all the time, often without notice. | However, if you'd like to write some code to help us minimize duplicate | license files on the filesystem with a "common-licenses" package, then | you should look at http://rpm.org/ticket/116. Have I mentioned that I'd | like that functionality added to rpm? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 611015] perl-Pugs-Compiler-Rule fails to build
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=611015 --- Comment #5 from Petr Pisar 2010-07-27 13:39:42 EDT --- (In reply to comment #4) > (In reply to comment #2) > > More ever adding some debugging prints into the test one can see > > Data::Dumper > > treat local hashes and AST hashes in different manner. > > Just more indentation differences? Or really different? > Just indentation. Different number of spaces before hash keys and closing bracket. (If I recall properly.). -- 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: f14 boost-1.44.0 upgrade: notice of intent
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/26/10 5:05 PM, Benjamin Kosnik wrote: > > Hey. > > The boost maintainers are planning to update the boost versions > to the current release (1.44.0) in rawhide for F14. This is in keeping > with the general plan to sync with boost every six months or so. > > See more detail here: > https://fedoraproject.org/wiki/Features/F14Boost144 > > Suggested plan is to push this to devel in the next 24 hrs, which will > be announced on fedora-devel-annou...@redhat.com. > > It is anticipated that this update will be less work than the > 1.39->1.41 transition. > > This update changes the SONAME of boost libraries, and adds some new > libraries. All boost dependencies will have to be rebuilt. As always, > timely assistance from package maintainers is welcome. > > best, > -benjamin Do you have a list of packages which will need to be rebuilt? This is the last day before we branch, and with the dist-git outage there will be a short time to fix things before the Alpha freeze. Is anything in the critpath dependent upon boost, or in the primary spins? - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxPGTMACgkQ4v2HLvE71NVfUwCfTqpmNHg4XUN6y6DMAKlyn+j3 h2UAn1zMoExqGHAZRhFiSTjpK2NwJxh8 =+nX+ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: orphaning a few packages
Sebastian Dziallas wrote: > * avogadro I'm taking this one because it's needed for kdeedu 4.5. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 611015] perl-Pugs-Compiler-Rule fails to build
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=611015
--- Comment #4 from Iain Arnell 2010-07-27 13:24:08 EDT ---
(In reply to comment #2)
> Checking test results on CPAN, results on different perl versions, checking
> source code show the problem is more mysterious.
Certainly, bleadperl is throwing up more problems.
> More ever adding some debugging prints into the test one can see Data::Dumper
> treat local hashes and AST hashes in different manner.
Just more indentation differences? Or really different?
> In addition if we patch the tests, it will start failing on lower perls.
Not too much of a problem for us. Either patch the tests only in f14+, or
better, simply do something like:
make test \
|| diff -qb t/ast/00-basic.t{,_} \
&& mv -f t/ast/00-basic.t{_,} \
&& make test
(In reply to comment #3)
>Openly said, I don't see much sense in trying to "fix" this package.
At the minute, the package itself doesn't seem to be broken - only its tests
fail for an understandable reason.
>It's not used by Fedora,
Think of the DarkPAN!
>its upstream build-matrix
>(http://matrix.cpantesters.org/?dist=Pugs-Compiler-Rule+0.37)
>also speaks a very clear language.
That its test fail - but we can see why.
>My vote goes to "let this package die".
I don't really mind either way. Just playing devil's advocate. But according to
rel-eng, Steve needs to kill it, not you (or us).
--
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-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Licensing Guidelines Update - Please Read
On 07/26/2010 07:25 PM, M A Young wrote: > On Mon, 26 Jul 2010, Tom "spot" Callaway wrote: > >> You're going to need to include all applicable license texts, sorry. > > I have commited a spec file that puts all the COPYING and LICENSE files > into a new xen-licenses package (I don't what to include that many files > twice). This is an excellent idea. Wouldn't it make sense to take it further and create a couple dozen packages for all major licenses (GPL 2, 3, BSD, MIT, Artistic, Apache etc etc) and specify the correct ones as dependencies of respective packages? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Tue, Jul 27, 2010 at 12:55:17AM -0700, Matt McCutchen wrote: > The next sentence says, "/bin contains commands that may be used by both > the system administrator and by users, but which are required when no > other filesystems are mounted (e.g. in single user mode)." systemd > qualifies on both counts: it may be used by users, and it is needed > before other filesystems are mounted. The usefulness in the distinction between /bin and /sbin is largely in "what goes in the path". Generally, daemons don't belong in normal user's paths. > > not want in the user path because a user itsself should never have to > > execute it. > Messing up the distinction between */bin and */sbin in the name of > cleaner path completion is not progress. But that's the point of the distinction. -- Matthew Miller Senior Systems Architect -- Instructional & Research Computing Services Harvard School of Engineering & Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: music list maintainer/owner - how to get changes made
On Tue, 2010-07-27 at 10:30 -0400, seth vidal wrote: > On Wed, 2010-07-28 at 00:27 +1000, David Timms wrote: > > Over on mu...@lists.fp.org, we have some difficulty because by default a > > reply to a list message doesn't automatically get sent back to the list. > > > > I find it really limiting in a forum that is supposed to be enhancing > > communication and collaboration to end up with most people replying only > > to the original author. I hope it isn't intended. > > > > Anyway, with no response from the list owner, is there somewhere else I > > can request a change ? > > The list admin address is gone - but I still have a contact for him. > > I'll see if he is willing to change it. > I talked to the guy who used to run the list - he's no longer involved in the list. Maybe ask on the list who wants to run it and we can make the appropriate changes. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Can anyone take a look at libva(FE-Legal)?
Bill Nottingham (nott...@redhat.com) said: > Chen Lei (supercyp...@gmail.com) said: > > have some patent issues. Are there any legal guys or developers who > > are familiar with libva can help to clarify the patent issues in > > libva? > > > > The Review Request is here and waits for a legal review for almost one > > year: > > https://bugzilla.redhat.com/show_bug.cgi?id=518546 > > Asking for Fedora legal reviews on the development list is extremely > unlikely to accomplish anything. Sorry. developers != lawyers, in genreal. ... and I see you've also CC'd fedora-legal. That's likely to be more fruitful. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Can anyone take a look at libva(FE-Legal)?
Chen Lei (supercyp...@gmail.com) said: > have some patent issues. Are there any legal guys or developers who > are familiar with libva can help to clarify the patent issues in > libva? > > The Review Request is here and waits for a legal review for almost one year: > https://bugzilla.redhat.com/show_bug.cgi?id=518546 Asking for Fedora legal reviews on the development list is extremely unlikely to accomplish anything. Sorry. developers != lawyers, in genreal. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: KDE-SIG meeting report (30/2010)
On 07/27/2010 09:21 PM, Jaroslav Reznik wrote: > > Solid DeviceKit backend > > * > ltinkl is working on dk backend, targetting Fedora 15 and KDE 4.6 > > open > discussion > DeviceKit or udisks backend? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: perl packaging guidelines
On 07/27/2010 08:50 AM, Iain Arnell wrote: > 2010/7/23 Marcela Mašláňová : >> Hello, >> I'd like to sent Draft for packaging guidelines for review. There were >> added some changes a long time ago and it would be nice to have it >> official. If there won't be any comments, I'll sent it at the end of >> next week to comitee. >> >> The draft: https://fedoraproject.org/wiki/PackagingDraft:Perl >> >> It would be great to have a review from someone who has English as first >> language. > I've had a look and made a few uncontroversial tweaks to spelling and grammar. > Thank you. > But I've also got a couple of slightly more controversial comments: > > Since we no longer have perl version numbers in @INC, I think the > whole "Directory Ownership" section should be updated to reflect the > current situation. With a few simple examples. Maybe something like: > > In general, perl's hierarchical naming convention for modules does not > necessarily imply any hierarchical dependencies. For example, > perl-YAML and perl-YAML-Tiny both install files to > /usr/share/perl5/YAML; but perl-YAML-Tiny does not require perl-YAML > (its whole raison d'être is to be a smaller alternative) so both > packages need to own /usr/share/perl5/YAML directory. > > Even where there is some form of hierarchy, the split between > arch-dependent and noarch packages can cause additional problems. > Although perl-Moose-Autobox does require perl-Moose, > perl-Moose-Autobox is a noarch package installing files to > /usr/share/perl5/Moose whereas perl-Moose is architecture-dependent > and installs its files to /usr/lib/perl5/Moose. Again, both packages > need to own their top-level Moose directory. > > I removed the actual part about directory ownership, because it was useless and long. If you can sum it up in shorter paragraph, please do so. > And I wonder if it's worth trying to clarify the role of perl-sig. > Since we don't have explicit group permissions in pkgdb, adding > perl-sig to initial-cc may be understood to mean that perl-sig > provenpackagers are effectively co-maintainers and may update packages > as and when necessary. > > I believe cut length of packaging guidelines is good thing. I've just mentioned Perl SIG above. But I didn't find any wiki page about us, only Chris Draft https://fedoraproject.org/wiki/ChrisWeyl/PerlDraft#Fedora_Perl_SIG_Mission Do we have something better? Marcela -- 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
Can anyone take a look at libva(FE-Legal)?
Hi all, libva is a library and tools relating to the VAAPI video playback acceleration specification. libva is included in all major distributions(debian/ubuntu meego opensuse mandriva gentoo etc.) . I need it as a dependecy to package some meego MTF packages. Howerver, the submitter(Adam Williamson) feels that i965-va-driver plugins and many other parts of libva may have some patent issues. Are there any legal guys or developers who are familiar with libva can help to clarify the patent issues in libva? The Review Request is here and waits for a legal review for almost one year: https://bugzilla.redhat.com/show_bug.cgi?id=518546 Thanks a lot! Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
KDE-SIG meeting report (30/2010)
This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply to this email or add it to the related meeting page. - - = Weekly KDE Summary = Week: 30/2010 Time: 2010-07-27 14:00 UTC Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-07-27 Meeting minutes: http://meetbot.fedoraproject.org/fedora-meeting/2010-07-27/kde-sig.2010-07-2 7-14.02.html Meeting log: http://meetbot.fedoraproject.org/fedora-meeting/2010-07-27/kde-sig.2010-07-2 7-14.02.log.html -- = Participants = * Jaroslav Reznik * Kevin Kofler * Rex Dieter * Steven Parrish * Than Ngo * Radek Novacek * Thomas Janssen --- --- = Agenda = # topics to discuss: * kde-4.5 rc3 status * Sebastian Trueg recommends to set /proc/sys/fs/inotify/max_user_watches to very high value for Nepomuk * Solid DeviceKit backend = Summary = kde-4.5 rc3 status * kdegames trademark issues o can we omit affected games (and move to RPM Fusion?) + not easy to maintain -trademark patch + games, handbook, translations tied to it... o ACTION: jreznik to contact kde legal and kdegames maintainers about trademark issues o ACTION: than to provide list of affected files * otherwise kde-4.5 rc3 is built and already in kde-unstable repo set /proc/sys/fs/inotify/max_user_watches to very high value for Nepomuk * Sebastian Trueg recommends it on kde-packagers mailing list * we're not sure what does it mean for us o what's happen when limit is reached? o what about memory consumption when higher number is set? + ACTION: jreznik to ask Sebastian * mjg59 says it's probably justifiable to increase it and he thinks increasing the value increases memory usage in itself, but it does increase the amount of kernel resources a user can allocate * ACTION: rdieter to contact fedora devel/kernel folks about raising /proc/sys/fs/inotify/max_user_watches Solid DeviceKit backend * ltinkl is working on dk backend, targetting Fedora 15 and KDE 4.6 open discussion * rdieter would like to throw out a tease that there's a good chance we'll be bringing a good qt/kde presence to fudcon zurich , pending some financial/logistical details -- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-08-03 -- Jaroslav Řezník Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 602 797 774 Red Hat, Inc. http://cz.redhat.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Seeking to merge python 2.7 into rawhide
On Tue, 2010-07-27 at 10:16 -0400, David Malcolm wrote: > > libgpod > Working on this DONE -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
Adam Williamson (awill...@redhat.com) said: > > The 'not separating the scripts into a separate subpackage' bit. > > Ah. I thought the point of separating them wasn't to allow for multiple > init systems, but because our current guidance was to use sysvinit > scripts by default, not upstart scripts; so with them separated off, you > only get the upstart native script if you manually install it. The referenced packages aren't using upstart jobs as a replacement for traditional SysV service scripts... they're using upstart for things that don't really fit in the service paradigm. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 Alpha Unresolved Blocker Bug Count = 3
On Tue, 27 Jul 2010 01:40:11 +0200, John Poelstra wrote: > It's "reminder guy" again with a public service announcement about the > upcoming Fedora 12 Alpha Release. 14 A simple one-line change for rpm-build https://bugzilla.redhat.com/show_bug.cgi?id=617166 is still not in place for accepted: http://fedoraproject.org/wiki/Features/GdbIndex Thanks, Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Tue, 2010-07-27 at 11:11 -0400, Bill Nottingham wrote: > Adam Williamson (awill...@redhat.com) said: > > > > seems like something that should be changed. readahead, > > > > system-setup-keyboard and vpnc also have direct dependencies on upstart, > > > > presumably because they (I think incorrectly) include upstart-style > > > > scripts in their main packages rather than separating them into a > > > > -upstart subpackage. > > > > > > It's intentional, as there never really was a plan to support multiple > > > init systems. > > > > Which bit? Obviously they're *intentional*, no-one writes a Requires > > line into a spec file by accident :). I only mean that, if systemd is > > going to be the default init system, then these things should be > > changed. > > The 'not separating the scripts into a separate subpackage' bit. Ah. I thought the point of separating them wasn't to allow for multiple init systems, but because our current guidance was to use sysvinit scripts by default, not upstart scripts; so with them separated off, you only get the upstart native script if you manually install 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: Seeking to merge python 2.7 into rawhide
On Tue, 2010-07-27 at 11:05 -0400, Tom "spot" Callaway wrote: > On 07/27/2010 10:48 AM, M A Young wrote: > > On Tue, 27 Jul 2010, David Malcolm wrote: > > > >>> abrt > >> cc1plus: warnings being treated as errors > >> CCApplet.cpp: In member function 'void CApplet::Disable(const char*)': > >> CCApplet.cpp:364:72: error: passing NULL to non-pointer argument 4 of > >> 'void gdk_pixbuf_saturate_and_pixelate(const GdkPixbuf*, GdkPixbuf*, > >> gfloat, gboolean)' > >> > >> I don't believe this is a python 2.7 error. > > > > That could have been broken by the gcc 4.4 to gcc 4.5 update rather than > > the python one, as gcc 4.5 is more strict about what it will allow. > > It was, and this issue was fixed in abrt-1.1.10-2. Thanks; abrt now rebuilt against python 2.7 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
Adam Williamson (awill...@redhat.com) said: > > > seems like something that should be changed. readahead, > > > system-setup-keyboard and vpnc also have direct dependencies on upstart, > > > presumably because they (I think incorrectly) include upstart-style > > > scripts in their main packages rather than separating them into a > > > -upstart subpackage. > > > > It's intentional, as there never really was a plan to support multiple > > init systems. > > Which bit? Obviously they're *intentional*, no-one writes a Requires > line into a spec file by accident :). I only mean that, if systemd is > going to be the default init system, then these things should be > changed. The 'not separating the scripts into a separate subpackage' bit. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Seeking to merge python 2.7 into rawhide
On 07/27/2010 10:48 AM, M A Young wrote: > On Tue, 27 Jul 2010, David Malcolm wrote: > >>> abrt >> cc1plus: warnings being treated as errors >> CCApplet.cpp: In member function 'void CApplet::Disable(const char*)': >> CCApplet.cpp:364:72: error: passing NULL to non-pointer argument 4 of 'void >> gdk_pixbuf_saturate_and_pixelate(const GdkPixbuf*, GdkPixbuf*, gfloat, >> gboolean)' >> >> I don't believe this is a python 2.7 error. > > That could have been broken by the gcc 4.4 to gcc 4.5 update rather than > the python one, as gcc 4.5 is more strict about what it will allow. It was, and this issue was fixed in abrt-1.1.10-2. ~spot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Tue, 2010-07-27 at 10:48 -0400, Bill Nottingham wrote:
> Adam Williamson (awill...@redhat.com) said:
> > %define with_upstart 1%{nil}
> > ...
> > if with_upstart
> > Requires: upstart >= 0.6.0
> > %else
> > Requires: SysVinit >= 2.85-38
> > %endif
> >
> > seems like something that should be changed. readahead,
> > system-setup-keyboard and vpnc also have direct dependencies on upstart,
> > presumably because they (I think incorrectly) include upstart-style
> > scripts in their main packages rather than separating them into a
> > -upstart subpackage.
>
> It's intentional, as there never really was a plan to support multiple
> init systems.
Which bit? Obviously they're *intentional*, no-one writes a Requires
line into a spec file by accident :). I only mean that, if systemd is
going to be the default init system, then these things should be
changed.
--
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: [HEADS-UP] systemd is now the default init system in rawhide
Adam Williamson (awill...@redhat.com) said:
> %define with_upstart 1%{nil}
> ...
> if with_upstart
> Requires: upstart >= 0.6.0
> %else
> Requires: SysVinit >= 2.85-38
> %endif
>
> seems like something that should be changed. readahead,
> system-setup-keyboard and vpnc also have direct dependencies on upstart,
> presumably because they (I think incorrectly) include upstart-style
> scripts in their main packages rather than separating them into a
> -upstart subpackage.
It's intentional, as there never really was a plan to support multiple
init systems.
Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Seeking to merge python 2.7 into rawhide
On Tue, 27 Jul 2010, David Malcolm wrote: >> abrt > cc1plus: warnings being treated as errors > CCApplet.cpp: In member function 'void CApplet::Disable(const char*)': > CCApplet.cpp:364:72: error: passing NULL to non-pointer argument 4 of 'void > gdk_pixbuf_saturate_and_pixelate(const GdkPixbuf*, GdkPixbuf*, gfloat, > gboolean)' > > I don't believe this is a python 2.7 error. That could have been broken by the gcc 4.4 to gcc 4.5 update rather than the python one, as gcc 4.5 is more strict about what it will allow. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Seeking to merge python 2.7 into rawhide
David Malcolm wrote, at 07/27/2010 10:27 AM +9:00: > Current status: 114 failing builds > http://dmalcolm.fedorapeople.org/python-packaging/failures-2010-07-26-02.html > > See also the notes on: > https://fedoraproject.org/wiki/Features/Python_2.7#Current_status > > Many of these appear to be pre-existing FTBFS; as far as I can make out, > the #includes for parts of the GTK stack are substantially broken in > rawhide. > > Can we get all of the hundreds of successful builds into rawhide before > it drifts further? > > Dave > By the way, it seems that in your list, the packages which don't have "Requires: python(abi) = 2.6" dependency but have dependency for "libpython2.6.so.1.0" are missing. For example: libpeas: http://koji.fedoraproject.org/koji/packageinfo?packageID=10531 vim-enhanced: http://koji.fedoraproject.org/koji/packageinfo?packageID=216 Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: music list maintainer/owner - how to get changes made
On Tue, 2010-07-27 at 09:33 -0500, Bruno Wolff III wrote: > On Wed, Jul 28, 2010 at 00:27:32 +1000, > David Timms wrote: > > > > I find it really limiting in a forum that is supposed to be enhancing > > communication and collaboration to end up with most people replying only > > to the original author. I hope it isn't intended. > > You also suggest people use reply to all, reply to recipients or reply to list > when that's what they want. reply-to munging is a hack to deal with lists > where lot's of people don't bother to distinguish between the kind of replies > they can use and use reply to sender instead of something more appropiate. or reply-to munging is a simple and elegant solution to the problem of wanting to keep posts on list. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: music list maintainer/owner - how to get changes made
On Wed, Jul 28, 2010 at 00:27:32 +1000, David Timms wrote: > > I find it really limiting in a forum that is supposed to be enhancing > communication and collaboration to end up with most people replying only > to the original author. I hope it isn't intended. You also suggest people use reply to all, reply to recipients or reply to list when that's what they want. reply-to munging is a hack to deal with lists where lot's of people don't bother to distinguish between the kind of replies they can use and use reply to sender instead of something more appropiate. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On 07/26/2010 10:33 PM, Adam Williamson wrote: > On Mon, 2010-07-26 at 11:32 -0400, Peter Jones wrote: >> On 07/25/2010 04:30 AM, Frank Murphy wrote: >>> On 25/07/10 07:34, Kevin Fenzi wrote: Greetings. first it seems that systemd-sysvinit needs to add a: Provides: sysvinit-userspace To avoid the current conflicts/upgrade problems: ---> Package upstart-sysvinit.x86_64 0:0.6.5-7.fc14 set to be installed --> Processing Conflict: upstart-sysvinit-0.6.5-7.fc14.x86_64 conflicts systemd-sysvinit --> Processing Conflict: systemd-sysvinit-4-3.fc14.x86_64 conflicts upstart-sysvinit Error: systemd-sysvinit conflicts with upstart-sysvinit >>> >>> thank Seth? for yum --exclude=systemd\* >>> >>> Will systemd be default in F14-Branched, >>> or be kept with devel? >> >> As of yet, that's still undecided. > > That doesn't sound right. AIUI, the situation is that systemd will be > default for F-14 unless we find it to be horribly broken, hence it will > become the default in F14-Branched when it branches (unless we've > already decided it's horribly broken by then, which doesn't seem > likely). If you consult http://meetbot.fedoraproject.org/meetbot/fedora-meeting/2010-06-15/fesco.2010-06-15-19.35.log.html , you'll see that what FESCo agreed on was that it was a desirable feature, and that we would revisit the question of being default in F-14 later, when there's more actual data. That being said, I expect it will remain default in the branch for at least some amount of time for the same reason, and because that's the default state if nobody specifically changes it. -- Peter In computing, turning the obvious into the useful is a living definition of the word "frustration" -- Alan Perlis 01234567890123456789012345678901234567890123456789012345678901234567890123456789 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: music list maintainer/owner - how to get changes made
On Wed, 2010-07-28 at 00:27 +1000, David Timms wrote: > Over on mu...@lists.fp.org, we have some difficulty because by default a > reply to a list message doesn't automatically get sent back to the list. > > I find it really limiting in a forum that is supposed to be enhancing > communication and collaboration to end up with most people replying only > to the original author. I hope it isn't intended. > > Anyway, with no response from the list owner, is there somewhere else I > can request a change ? The list admin address is gone - but I still have a contact for him. I'll see if he is willing to change it. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
music list maintainer/owner - how to get changes made
Over on mu...@lists.fp.org, we have some difficulty because by default a reply to a list message doesn't automatically get sent back to the list. I find it really limiting in a forum that is supposed to be enhancing communication and collaboration to end up with most people replying only to the original author. I hope it isn't intended. Anyway, with no response from the list owner, is there somewhere else I can request a change ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Seeking to merge python 2.7 into rawhide
On Mon, 2010-07-26 at 19:38 -0700, Adam Williamson wrote: > On Mon, 2010-07-26 at 21:27 -0400, David Malcolm wrote: > > Current status: 114 failing builds > > http://dmalcolm.fedorapeople.org/python-packaging/failures-2010-07-26-02.html > > > > See also the notes on: > > https://fedoraproject.org/wiki/Features/Python_2.7#Current_status > > > > Many of these appear to be pre-existing FTBFS; as far as I can make out, > > the #includes for parts of the GTK stack are substantially broken in > > rawhide. > > > > Can we get all of the hundreds of successful builds into rawhide before > > it drifts further? > > Some of the ones that are broken look like fairly important things which > we really wouldn't want to be broken in Rawhide when we're trying to > build the Alpha test compose (Thursday): > > farsight2 > telepathy-farsight Both of these are now built (thanks!) > openoffice.org Failed to build inside %install, inside unxlngi6.pro/misc/smoketest/user > libgpod Working on this > abrt cc1plus: warnings being treated as errors CCApplet.cpp: In member function 'void CApplet::Disable(const char*)': CCApplet.cpp:364:72: error: passing NULL to non-pointer argument 4 of 'void gdk_pixbuf_saturate_and_pixelate(const GdkPixbuf*, GdkPixbuf*, gfloat, gboolean)' I don't believe this is a python 2.7 error. > revelation (okay, okay, i'm sneaking this one in because *i* depend on > it :>) Blocked by GTK header breakage; hope to look at this later today > bodhi(!) Isn't this the server-side component? Does the production bodhi server run on top of rawhide? > alacarte Rebuilt > gnome-applets Working on this > gnome-games Rebuilt > python-fedora Blocked by TurboGears; hope to look at this later today > That's not an exhaustive list, just things that leap out at me as being > no-brainers, they really need to be fixed before this goes into main > Rawhide IMHO. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Seeking to merge python 2.7 into rawhide
On Mon, Jul 26, 2010 at 07:38:29PM -0700, Adam Williamson wrote: > On Mon, 2010-07-26 at 21:27 -0400, David Malcolm wrote: > > Current status: 114 failing builds > > http://dmalcolm.fedorapeople.org/python-packaging/failures-2010-07-26-02.html > > > > See also the notes on: > > https://fedoraproject.org/wiki/Features/Python_2.7#Current_status > > > > Many of these appear to be pre-existing FTBFS; as far as I can make out, > > the #includes for parts of the GTK stack are substantially broken in > > rawhide. > > > > Can we get all of the hundreds of successful builds into rawhide before > > it drifts further? > > Some of the ones that are broken look like fairly important things which > we really wouldn't want to be broken in Rawhide when we're trying to > build the Alpha test compose (Thursday): > Weighed against your list is the fact that it seems very important to land python-2.7 for testing in the alpha release. -Toshio pgpgqAbpHfur5.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100727 changes
Compose started at Tue Jul 27 08:15:30 UTC 2010 Broken deps for x86_64 -- BackupPC-3.1.0-14.1.fc14.noarch requires perl-suidperl PragmARC-20060427-6.fc13.i686 requires libgnarl-4.4.so PragmARC-20060427-6.fc13.i686 requires libgnat-4.4.so PragmARC-20060427-6.fc13.x86_64 requires libgnat-4.4.so()(64bit) PragmARC-20060427-6.fc13.x86_64 requires libgnarl-4.4.so()(64bit) 1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9 1:anjuta-2.30.0.0-2.fc14.i686 requires libdevhelp-1.so.1 1:anjuta-2.30.0.0-2.fc14.i686 requires libwebkit-1.0.so.2 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libgladeui-1.so.9()(64bit) 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libdevhelp-1.so.1()(64bit) 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libwebkit-1.0.so.2()(64bit) cairo-java-1.0.5-12.fc12.i686 requires libgcj.so.10 cairo-java-1.0.5-12.fc12.x86_64 requires libgcj.so.10()(64bit) claws-mail-plugins-geolocation-3.7.6-3.fc14.x86_64 requires libchamplain-gtk-0.4.so.0()(64bit) claws-mail-plugins-geolocation-3.7.6-3.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libedata-book-1.2.so.2()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-1.2.so.17()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libgtkhtml-editor.so.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-provider-1.2.so.17()(64bit) evolution-sharp-0.21.1-7.fc14.x86_64 requires libecal-1.2.so.7()(64bit) evolution-sharp-0.21.1-7.fc14.x86_64 requires libebook-1.2.so.9()(64bit) fmt-ptrn-java-1.3.20-5.fc13.i686 requires libgcj.so.10 fmt-ptrn-java-1.3.20-5.fc13.x86_64 requires libgcj.so.10()(64bit) frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10 frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) glib-java-0.2.6-16.fc12.i686 requires libgcj.so.10 glib-java-0.2.6-16.fc12.x86_64 requires libgcj.so.10()(64bit) gnome-python2-brasero-2.31.1-1.fc14.x86_64 requires libbrasero-burn.so.1()(64bit) gnome-python2-brasero-2.31.1-1.fc14.x86_64 requires libbrasero-media.so.1()(64bit) gnome-python2-evolution-2.31.1-1.fc14.x86_64 requires libecal-1.2.so.7()(64bit) gnome-python2-evolution-2.31.1-1.fc14.x86_64 requires libebook-1.2.so.9()(64bit) gnome-python2-totem-2.31.1-1.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gnomeradio-1.8-6.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-gtk-0.4.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit) intellij-idea-9.0.1.94.399-11.fc14.x86_64 requires jna-examples lekhonee-gnome-0.11-2.fc14.x86_64 requires libwebkit-1.0.so.2()(64bit) libgconf-java-2.12.4-14.fc12.i686 requires libgcj.so.10 libgconf-java-2.12.4-14.fc12.x86_64 requires libgcj.so.10()(64bit) libglade-java-2.12.5-12.fc12.i686 requires libgcj.so.10 libglade-java-2.12.5-12.fc12.x86_64 requires libgcj.so.10()(64bit) libgnome-java-2.12.4-12.fc12.i686 requires libgcj.so.10 libgnome-java-2.12.4-12.fc12.x86_64 requires libgcj.so.10()(64bit) libgtk-java-2.8.7-13.fc13.i686 requires libgcj.so.10 libgtk-java-2.8.7-13.fc13.x86_64 requires libgcj.so.10()(64bit) libvirt-qpid-0.2.18-1.fc14.x86_64 requires libqmf.so.1()(64bit) libvte-java-0.12.1-15.fc12.i686 requires libgcj.so.10 libvte-java-0.12.1-15.fc12.x86_64 requires libgcj.so.10()(64bit) matahari-0.0.5-1.fc14.x86_64 requires libqmf.so.1()(64bit) mine_detector-6.0-3.fc13.x86_64 requires libgnat-4.4.so()(64bit) mingw32-OpenSceneGraph-2.8.2-4.fc14.noarch requires mingw32(libpng-3.dll) nautilus-sound-converter-1.0.5-2.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) ovirt-server-0.100-4.fc12.noarch requires qpidc ovirt-server-0.100-4.fc12.noarch requires qpidd perl-Config-Model-1.205-2.fc14.noarch requires perl(YAML::Any) >= 0:0.303 perl-Data-Alias-1.07-6.fc13.x86_64 requires perl(:MODULE_COMPAT_5.10.1) perl-Pugs-Compiler-Rule-0.37-4.fc13.noarch requires perl(:MODULE_COMPAT_5.10.1) python3-beaker-1.5.3-4.fc14.noarch requires python3-paste qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit) spacewalk-certs-tools-1.1.1-1.1.fc14.noarch requires spacewalk-backend-libs >= 0:0.8.28 viking-0.9.91-3.fc13.x86_64 requires libgps.so.18()(64bit) wfut-1.1.0-8.fc12.x86_64 requires l
Re: */bin and */sbin, command completion
2010/7/27 Matt McCutchen : > On Tue, 2010-07-27 at 09:49 +0200, Rudolf Kastl wrote: >> small addition: >> >> if you want to move stuff to /bin how about ifconfig and ip. > > I don't think so. ifconfig and ip administer the system-wide network > interfaces. All the write operations require root privileges. The read > operations don't, but if they are called by an unprivileged user, it is > still for the purpose of system administration and I don't think it's > unreasonable to expect the user to go to /sbin . well obviously it is else we wouldnt have to add */sbin to a regular users PATH. From an administrator using commandline id really expect to know the difference between su and su -. kind regards, Rudolf Kastl > > -- > Matt > > -- > 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: [HEADS-UP] systemd is now the default init system in rawhide
2010/7/27 Matt McCutchen : > On Tue, 2010-07-27 at 09:42 +0200, Rudolf Kastl wrote: >> i do not understand how a daemon (like e.g. dbus-daemon) qualifies as >> "/bin : Essential user command binaries (for use by all users)" (taken >> from fhs 2.3). one could argue if a daemon qualifies as "command". >> especially since it seems it has to be run before /usr is mounted it >> is never getting executed by (all) the users. > > The next sentence says, "/bin contains commands that may be used by both > the system administrator and by users, but which are required when no > other filesystems are mounted (e.g. in single user mode)." systemd > qualifies on both counts: it may be used by users, and it is needed > before other filesystems are mounted. what about your dbus-daemon example? > >> From a usability point of view it is exactly those kinda commands i do >> not want in the user path because a user itsself should never have to >> execute it. > > Messing up the distinction between */bin and */sbin in the name of > cleaner path completion is not progress. what is progress from your point of view? unfortunately i just see that things break for no particular gain which doesent look like progress either. what exactly is the distinction for then? if we do not care about PATH i will agree with all the statements that have been made before in other threads that */bin and */sbin can be just merged because there is no real benefit anymore in separating them. How else can we fix autocompletion? There are plenty of users using shell and are relying on autocompletion for efficient usage of the terminal. > >> to me it sounds more like: /sbin : System binaries. If the system >> doesent need it why do we start it that early? > > The system does need systemd. Users also need it (that is, once the > envisioned user session-management capability is added). what about dbus-daemon... your example? for systemd: if a user is supposed to execute it (or it is executed as regular user upon login) then i agree completly, no questions asked. in its current state it is not the case though. > > -- > Matt > > -- > 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
*/bin and */sbin, command completion
On Tue, 2010-07-27 at 09:49 +0200, Rudolf Kastl wrote: > small addition: > > if you want to move stuff to /bin how about ifconfig and ip. I don't think so. ifconfig and ip administer the system-wide network interfaces. All the write operations require root privileges. The read operations don't, but if they are called by an unprivileged user, it is still for the purpose of system administration and I don't think it's unreasonable to expect the user to go to /sbin . -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Tue, 2010-07-27 at 09:42 +0200, Rudolf Kastl wrote: > i do not understand how a daemon (like e.g. dbus-daemon) qualifies as > "/bin : Essential user command binaries (for use by all users)" (taken > from fhs 2.3). one could argue if a daemon qualifies as "command". > especially since it seems it has to be run before /usr is mounted it > is never getting executed by (all) the users. The next sentence says, "/bin contains commands that may be used by both the system administrator and by users, but which are required when no other filesystems are mounted (e.g. in single user mode)." systemd qualifies on both counts: it may be used by users, and it is needed before other filesystems are mounted. > From a usability point of view it is exactly those kinda commands i do > not want in the user path because a user itsself should never have to > execute it. Messing up the distinction between */bin and */sbin in the name of cleaner path completion is not progress. > to me it sounds more like: /sbin : System binaries. If the system > doesent need it why do we start it that early? The system does need systemd. Users also need it (that is, once the envisioned user session-management capability is added). -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
2010/7/27 Rudolf Kastl : > 2010/7/27 Matt McCutchen : >> On Mon, 2010-07-26 at 10:31 +0100, Bryn M. Reeves wrote: >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> On 07/24/2010 09:39 PM, Matt McCutchen wrote: >>> > On Sat, 2010-07-24 at 16:36 -0400, Matthew Miller wrote: >>> >> On Sat, Jul 24, 2010 at 12:14:33AM -0400, Casey Dahlin wrote: >>> Why is the systemd executable in /bin instead of /sbin? >>> >>> Without looking too closely I believe systemd eventually seeks to >>> >>> replace >>> >>> things like gnome-session daemon. It has session management in mind as >>> >>> well as system. >>> >> >>> >> Still belongs in /sbin, unless it's meant to actually be executed >>> >> directly >>> >> by end-users. >>> > >>> > No. If that were the criterion, update-mime-database would belong >>> > in /sbin . >>> > >>> >>> The FHS puts it like this: >>> >>> (a) "/bin contains commands that may be used by both the system >>> administrator and by users, but which are required when no other >>> filesystems are mounted (e.g. in single user mode). It may also contain >>> commands which are used indirectly by scripts." >>> >>> (b) "/sbin contains binaries essential for booting, restoring, >>> recovering, and/or repairing the system in addition to the binaries in >>> /bin." >>> >>> So if the intent is that systemd will eventually be invoked (indirectly >>> by some script/daemon) by users this seems justified by (a). On the >>> other hand the page has this to say on "init": >>> >>> "The following files, or symbolic links to files, must be in /sbin if >>> the corresponding subsystem is installed: ... >>> init" >>> >>> It's arguable though whether this refers to SysV's init or is intended >>> to be more general. >>> >>> http://www.pathname.com/fhs/pub/fhs-2.3.html#BINESSENTIALUSERCOMMANDBINARIES >>> http://www.pathname.com/fhs/pub/fhs-2.3.html#SBINSYSTEMBINARIES >> >> A hard link or symlink at /sbin/init is needed because tools look for it >> there. However, I think the main "systemd" executable belongs in /bin. >> I read (b) as a subdivision of the category established by the previous >> sentence: "Utilities used for system administration (and other root-only >> commands) are stored in /sbin, /usr/sbin, and /usr/local/sbin." systemd >> is not (going to be) root-only, hence it doesn't go in */sbin. The >> right comparison would be to /bin/dbus-daemon. >> >> -- >> Matt > > i do not understand how a daemon (like e.g. dbus-daemon) qualifies as > "/bin : Essential user command binaries (for use by all users)" (taken > from fhs 2.3). one could argue if a daemon qualifies as "command". > especially since it seems it has to be run before /usr is mounted it > is never getting executed by (all) the users. > From a usability point of view it is exactly those kinda commands i do > not want in the user path because a user itsself should never have to > execute it. > > to me it sounds more like: /sbin : System binaries. If the system > doesent need it why do we start it that early? > > kind regards, > Rudolf Kastl > > kind regards, > Rudolf Kastl > > >> >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel >> > small addition: if you want to move stuff to /bin how about ifconfig and ip. in this regard our system is really a mess and instead of cleaning it up we worked around by polluting the users PATH and completion with */sbin. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
2010/7/27 Matt McCutchen : > On Mon, 2010-07-26 at 10:31 +0100, Bryn M. Reeves wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 07/24/2010 09:39 PM, Matt McCutchen wrote: >> > On Sat, 2010-07-24 at 16:36 -0400, Matthew Miller wrote: >> >> On Sat, Jul 24, 2010 at 12:14:33AM -0400, Casey Dahlin wrote: >> Why is the systemd executable in /bin instead of /sbin? >> >>> Without looking too closely I believe systemd eventually seeks to replace >> >>> things like gnome-session daemon. It has session management in mind as >> >>> well as system. >> >> >> >> Still belongs in /sbin, unless it's meant to actually be executed directly >> >> by end-users. >> > >> > No. If that were the criterion, update-mime-database would belong >> > in /sbin . >> > >> >> The FHS puts it like this: >> >> (a) "/bin contains commands that may be used by both the system >> administrator and by users, but which are required when no other >> filesystems are mounted (e.g. in single user mode). It may also contain >> commands which are used indirectly by scripts." >> >> (b) "/sbin contains binaries essential for booting, restoring, >> recovering, and/or repairing the system in addition to the binaries in >> /bin." >> >> So if the intent is that systemd will eventually be invoked (indirectly >> by some script/daemon) by users this seems justified by (a). On the >> other hand the page has this to say on "init": >> >> "The following files, or symbolic links to files, must be in /sbin if >> the corresponding subsystem is installed: ... >> init" >> >> It's arguable though whether this refers to SysV's init or is intended >> to be more general. >> >> http://www.pathname.com/fhs/pub/fhs-2.3.html#BINESSENTIALUSERCOMMANDBINARIES >> http://www.pathname.com/fhs/pub/fhs-2.3.html#SBINSYSTEMBINARIES > > A hard link or symlink at /sbin/init is needed because tools look for it > there. However, I think the main "systemd" executable belongs in /bin. > I read (b) as a subdivision of the category established by the previous > sentence: "Utilities used for system administration (and other root-only > commands) are stored in /sbin, /usr/sbin, and /usr/local/sbin." systemd > is not (going to be) root-only, hence it doesn't go in */sbin. The > right comparison would be to /bin/dbus-daemon. > > -- > Matt i do not understand how a daemon (like e.g. dbus-daemon) qualifies as "/bin : Essential user command binaries (for use by all users)" (taken from fhs 2.3). one could argue if a daemon qualifies as "command". especially since it seems it has to be run before /usr is mounted it is never getting executed by (all) the users. From a usability point of view it is exactly those kinda commands i do not want in the user path because a user itsself should never have to execute it. to me it sounds more like: /sbin : System binaries. If the system doesent need it why do we start it that early? kind regards, Rudolf Kastl kind regards, Rudolf Kastl > > -- > 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: [HEADS-UP] systemd is now the default init system in rawhide
On Mon, 2010-07-26 at 10:31 +0100, Bryn M. Reeves wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/24/2010 09:39 PM, Matt McCutchen wrote: > > On Sat, 2010-07-24 at 16:36 -0400, Matthew Miller wrote: > >> On Sat, Jul 24, 2010 at 12:14:33AM -0400, Casey Dahlin wrote: > Why is the systemd executable in /bin instead of /sbin? > >>> Without looking too closely I believe systemd eventually seeks to replace > >>> things like gnome-session daemon. It has session management in mind as > >>> well as system. > >> > >> Still belongs in /sbin, unless it's meant to actually be executed directly > >> by end-users. > > > > No. If that were the criterion, update-mime-database would belong > > in /sbin . > > > > The FHS puts it like this: > > (a) "/bin contains commands that may be used by both the system > administrator and by users, but which are required when no other > filesystems are mounted (e.g. in single user mode). It may also contain > commands which are used indirectly by scripts." > > (b) "/sbin contains binaries essential for booting, restoring, > recovering, and/or repairing the system in addition to the binaries in > /bin." > > So if the intent is that systemd will eventually be invoked (indirectly > by some script/daemon) by users this seems justified by (a). On the > other hand the page has this to say on "init": > > "The following files, or symbolic links to files, must be in /sbin if > the corresponding subsystem is installed: ... > init" > > It's arguable though whether this refers to SysV's init or is intended > to be more general. > > http://www.pathname.com/fhs/pub/fhs-2.3.html#BINESSENTIALUSERCOMMANDBINARIES > http://www.pathname.com/fhs/pub/fhs-2.3.html#SBINSYSTEMBINARIES A hard link or symlink at /sbin/init is needed because tools look for it there. However, I think the main "systemd" executable belongs in /bin. I read (b) as a subdivision of the category established by the previous sentence: "Utilities used for system administration (and other root-only commands) are stored in /sbin, /usr/sbin, and /usr/local/sbin." systemd is not (going to be) root-only, hence it doesn't go in */sbin. The right comparison would be to /bin/dbus-daemon. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
