[Bug 589261] amending values of log_to_syslog = true; log_file = /dev/null in config causes nothing, values get reverted
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=589261 --- Comment #12 from Fedora Update System upda...@fedoraproject.org 2010-08-31 21:02:22 EDT --- mldonkey-3.0.3-1.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report. -- 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. ___ ocaml-devel mailing list ocaml-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
[Bug 589261] amending values of log_to_syslog = true; log_file = /dev/null in config causes nothing, values get reverted
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=589261 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Fixed In Version|mldonkey-3.0.3-1.fc14 |mldonkey-3.0.3-1.el5 -- 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. ___ ocaml-devel mailing list ocaml-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
Re: Request compose of image for Software Review UI from Releng
Jesse Keating さんは書きました: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/26/10 5:06 AM, noriko wrote: Hi Release Engineering team F14 collection packages should be built with latest translation by today, 26-Aug. Could you please kindly compose the image with those latest packages for software translation review? Translators are scheduled to have review and correct software translation in built UI between 2010-08-30 to 2010-09-07 (deadline). Thank you so much for you help. noriko This is better done as a ticket. That is true. I've asked to change the entry a little more specific to reflect, so that a ticket to be created for F14. I've copied the nightly images made last night for you to download: http://alt.fedoraproject.org/pub/alt/stage/f14-translation/ which will be mirrored to http://serverbeach1.fedoraproject.org/pub/alt/stage/f14-translation/ Remember that once booted to these images you can yum update and get newer builds of content from updates-testing to verify translations. Thank you so much!. noriko - -- 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/ iEYEARECAAYFAkx8Q/gACgkQ4v2HLvE71NU/DwCeMdBz+QF0HPvuaA1bbTdv4/nP G0YAoLNM92NAMLYS+Toq2XEZrsDHSiky =VmV1 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Bugzappers meeting slot 2010-08-31
Hi, folks. Once again, there's a meeting slot tomorrow at the usual time, 2010-08-31 15:00 UTC. Once again, there's nothing new on the agenda page - https://fedoraproject.org/wiki/BugZappers:meeting-agenda-list . Again, I'll be around in the morning, though, just in case. If anyone would like to discuss something specific, please do reply to this email and we'll run the meeting as usual. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On 08/31/2010 05:42 AM, Jesse Keating wrote: On 8/30/10 1:06 PM, Sven Lankes wrote: On Mon, Aug 30, 2010 at 12:36:42PM -0700, Jesse Keating wrote: Why not give QA the time to settle and find out how the new things work out? Because the likes of Kevin throw fits whenever we try to insert any QA time or seem to try and improve the quality of our updates in any way other than throw more of them at people. So you're saying we cannot test the new qa and update-process 'achievements' for a while because Kevin doesn't like them? I'm saying that these changes were made in the face of extreme resistance on Kevin's (and other's) parts. So whatever the outcome it's already going counter to the Fedora that he would like to see, or continue seeing. Sure. But from what I recall, the extreme resistance amounted to little more than posting a lot of emails, many of which were slapped down pretty quickly. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 625363] Upgrade to new upstream version
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=625363 --- Comment #3 from Fedora Update System upda...@fedoraproject.org 2010-08-31 04:40:12 EDT --- perl-Directory-Queue-1.0-1.el4 has been submitted as an update for Fedora EPEL 4. https://admin.fedoraproject.org/updates/perl-Directory-Queue-1.0-1.el4 -- 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
[Bug 625363] Upgrade to new upstream version
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=625363 --- Comment #2 from Fedora Update System upda...@fedoraproject.org 2010-08-31 04:40:07 EDT --- perl-Directory-Queue-1.0-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/perl-Directory-Queue-1.0-1.fc14 -- 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
[Bug 625363] Upgrade to new upstream version
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=625363 --- Comment #5 from Fedora Update System upda...@fedoraproject.org 2010-08-31 04:40:22 EDT --- perl-Directory-Queue-1.0-1.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/perl-Directory-Queue-1.0-1.el5 -- 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: fedora mission (was Re: systemd and changes)
On 08/30/2010 07:22 PM, Stephen John Smoogen wrote: On Mon, Aug 30, 2010 at 10:03, Jesse Keating jkeat...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/28/2010 09:25 PM, Kevin Kofler wrote: Jesse Keating wrote: The cynic in me would expect that the people who want something different than the fire hose we have now are silently leaving, and those that are left are going to say they like the deluge of updates. You say that as if it were a negative thing. To me it is. It's you and people like you that want to shove a ton of updates down the throats of our stable release users (including changes that alter behavior and sonames etc...) that have ruined the Fedora I helped to build. I want my Fedora back, I don't want what you're creating. The problem to quote a tv philosopher is: The avalanche has already started, it is too late for the pebbles to vote. The changes towards a distribution that attracts people who live in the moment happened a while back, and has been building momentum for quite some time. Trying to erect barriers now is not going to help but make it so nothing exists afterwords. The things that can be done are: A) get out of the way, B) go with the flow, or C) figure out what you can build on top of it. [I am looking at option C] The pressure to stabilize is a much needed-correction to the pressure to innovate. Consider what happens without any such back-pressure. Those who can no longer stand the churn leave, with only the hard-core bleeding- edgers remaining. The churn gets faster. Then, even some of those who were the previous generation of bleeding-edgers can't cope, and they leave. Left behind, are the *serious* hard core. Etc... This is a classic case of unrestrained positive feedback, just like thermal runaway. In my view, this is exactly the situation we're in at the moment, but some people are trying to apply a correction to prevent the distro burning out. It is not too late. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
Andrew Haley píše v Út 31. 08. 2010 v 09:40 +0100: On 08/31/2010 05:42 AM, Jesse Keating wrote: I'm saying that these changes were made in the face of extreme resistance on Kevin's (and other's) parts. So whatever the outcome it's already going counter to the Fedora that he would like to see, or continue seeing. Sure. But from what I recall, the extreme resistance amounted to little more than posting a lot of emails, many of which were slapped down pretty quickly. What kind of resistance would you consider extreme? Napalm? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
GDM login issues F13: kbd switches to US keymap, mirror screens stops working
Hi, I've had two irritating issues on F13 which are likely shared by others, maybe this will trigger some eyeballs or Cc:s: 1) After GDM login, 'US layout' always appears as the new default keymap at each login even if you remove it. https://bugzilla.redhat.com/show_bug.cgi?id=594529 2) Mirror screens to external VGA ceases to work after GDM login and/or changing monitor properties (multi-screen output is OK). https://bugzilla.redhat.com/show_bug.cgi?id=628906 -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100831 changes
Compose started at Tue Aug 31 08:15:13 UTC 2010 Broken deps for x86_64 -- 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 libgnarl-4.4.so()(64bit) PragmARC-20060427-6.fc13.x86_64 requires libgnat-4.4.so()(64bit) RackTables-0.18.4-1.fc15.noarch requires perl(File::FnMatch) RackTables-0.18.4-1.fc15.noarch requires perl(Net::Telnet::Cisco) antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 cyphesis-0.5.21-2.fc13.x86_64 requires libpython2.6.so.1.0()(64bit) emerillon-0.1.2-7.fc14.x86_64 requires librest-0.6.so.0()(64bit) entangle-0.1.0-7.fc14.x86_64 requires libmozjs.so()(64bit) ethos-0.2.2-7.fc15.i686 requires libmozjs.so ethos-0.2.2-7.fc15.x86_64 requires libmozjs.so()(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 libgtkhtml-editor.so.0()(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 libcamel-provider-1.2.so.17()(64bit) evolution-sharp-0.21.1-7.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-sharp-0.21.1-7.fc14.x86_64 requires libecal-1.2.so.7()(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) gedit-vala-0.6.1-1.fc13.x86_64 requires libvala.so.0()(64bit) gjs-0.7.1-3.fc14.i686 requires libmozjs.so gjs-0.7.1-3.fc14.x86_64 requires libmozjs.so()(64bit) gnome-shell-2.31.5-5.fc14.x86_64 requires libmozjs.so()(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) gxine-0.5.905-3.fc13.x86_64 requires libmozjs.so()(64bit) intellij-idea-9.0.1.94.399-11.fc14.x86_64 requires jna-examples 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) libopenvrml-0.18.6-1.fc14.i686 requires libboost_filesystem-mt.so.1.41.0 libopenvrml-0.18.6-1.fc14.i686 requires libboost_thread-mt.so.1.41.0 libopenvrml-0.18.6-1.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) libopenvrml-0.18.6-1.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) libopenvrml-gl-0.18.6-1.fc14.i686 requires libboost_filesystem-mt.so.1.41.0 libopenvrml-gl-0.18.6-1.fc14.i686 requires libboost_thread-mt.so.1.41.0 libopenvrml-gl-0.18.6-1.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) libopenvrml-gl-0.18.6-1.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) libproxy-mozjs-0.4.4-7.fc14.x86_64 requires libmozjs.so()(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) moblin-panel-myzone-0.1.34-2.fc14.i686 requires libsocialweb-client.so.1 moblin-panel-myzone-0.1.34-2.fc14.x86_64 requires libsocialweb-client.so.1()(64bit) moblin-panel-status-0.1.21-5.fc14.x86_64 requires libsocialweb-client.so.1()(64bit) openvrml-java-0.18.6-1.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) openvrml-java-0.18.6-1.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) openvrml-javascript-0.18.6-1.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) openvrml-javascript-0.18.6-1.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) openvrml-javascript-0.18.6-1.fc14.x86_64 requires libmozjs.so()(64bit) openvrml-nodes-0.18.6-1.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) openvrml-nodes-0.18.6-1.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) openvrml-xembed-0.18.6-1.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) openvrml-xembed-0.18.6-1.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) ovirt-server-0.100-4.fc12.noarch requires qpidd ovirt-server-0.100-4.fc12.noarch requires qpidc
Re: GDM login issues F13: kbd switches to US keymap, mirror screens stops working
Hi I noted on your first bug that it sounds like one I had: https://bugzilla.redhat.com/show_bug.cgi?id=552397 Regards, -Cam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Mon, Aug 30, 2010 at 9:36 PM, Jesse Keating jkeat...@j2solutions.net wrote: Thomas Janssen thom...@fedoraproject.org wrote: What previous niche? We had a distro that was pretty general purpose, worked for servers and desktops and even laptops. We had a predictable schedule. We had new technology thanks to rawhide. We had timely bugfixes that didn't sacrifice stability, as in things didn't change out from under you on a stable release. We had an ecosystem of third parties that would build up stacks of newer things should a user be adventurous. We had a fresh release quite often that could be relied upon for at least a year. We had a culture of not just throwing crap over the wall at our users, which included ourselves. We had accountability when things did go awry and a honest effort to disrupt the users of our stable releases as little as possible. We also we're a very free distro avoiding nonfree stuff, and we worked well with upstreams. We we're easy to configure, easy to update, easy to install whether a single system or 400 systems in a lab. We we're easy to administrate in the same scenarios. This was fairly unique and what drew a lot of people to the project. I'm not sure i would call that a niche, but it sounds very good. Count me in. It's getting to the point where me, as a long time Fedora developer and sometimes leader, is not enjoying using Fedora any more. Every update run can break things, and often does. Why not give QA the time to settle and find out how the new things work out? Because the likes of Kevin throw fits whenever we try to insert any QA time or seem to try and improve the quality of our updates in any way other than throw more of them at people. Hm, ignore Kevin or the likes here. The new Bodhi and proventesters are a good step in the right direction. As proventester and 24/7-updates-testing enabled guy, i can say, it starts to work. Thanks to everybody involved. Every update takes for ever because there are so many updates. Too many to review each one and see what it does, and how to maybe test it and provide feedback. Updates runs just get pushed off longer and longer so that I have a block of time to A) apply the damn things, and B) spend a few hours recovering from any sort of fallout in my workflow. What DE is in use on your box? I use Gnome with some KDE apps. The Gnome Desktop should be safe (not a Gnome user so i can only guess here, sorry) and the KDE Desktop gets more and more stable. Means the *big* UI changes are over. Small improvements will most likely always happen, together with bugfixes, as that's the KDE philosophy. People like me likes that, but i can understand the others who don't want even small changes. I personally would like to see a F n-1 that gets just the badly needed bugfixes (security and crash). But have the latest release get mixed updates, bugfixes and smaller UI improvements. That way, the ones with slow i-net or just don't want to see much updates could be happy with n-1. And all the others as well with the latest release. Rawhide and personal repos, would still fulfil the role for people living on the real bleeding side of the edge and for hot-new-stuff to develop in. -- Best regards Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proprietary search engines
On Mon, Aug 30, 2010 at 10:52:04PM -0700, Adam Williamson wrote: Yeah, there really doesn't seem any particular reason for the search box to be there, unless Google was paying us for it to be there or something. Fedora gets to build and ship a slightly-modified version of Firefox while retaining the Firefox name due to a distribution partner agreement with Mozilla. Mozilla gets their money from Google. I don't think we *can* make it something else -- it's part of the price we are paying in order to use the non-Free name. See: https://wiki.mozilla.org/Firefox_Rebranding:Worksheet#Start_page -- Matthew Miller mat...@mattdm.org 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: fedora mission (was Re: systemd and changes)
On 08/31/2010 11:55 AM, Miloslav Trmač wrote: Andrew Haley píše v Út 31. 08. 2010 v 09:40 +0100: On 08/31/2010 05:42 AM, Jesse Keating wrote: I'm saying that these changes were made in the face of extreme resistance on Kevin's (and other's) parts. So whatever the outcome it's already going counter to the Fedora that he would like to see, or continue seeing. Sure. But from what I recall, the extreme resistance amounted to little more than posting a lot of emails, many of which were slapped down pretty quickly. What kind of resistance would you consider extreme? Napalm? Something along those lines. :-) Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 12:48:02AM -0400, Arthur Pemberton wrote: New features hit rawhide all the time, with no waiting period. So developers are going to put new features into rawhide knowing that they will never make it to updates? That seems like an excellent model, yes. When the next Fedora release tree is branched in less than six months, the new features automatically become widely available. -- Matthew Miller mat...@mattdm.org 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
LUKS open / mount order
Hi, While experimenting using an USB stick with a keyfile for a LUKS filesystem (not one of the basic ones), I found out this actually seems to work, but I'm not sure of this by design or just accidentally. In rc.sysinit, the stick (in fstab with UUID) is mounted and later the luksOpen seems to be done for the encrypted partition, using the keyfile on the stick. The encrypted partition is not mounted in rc.sysinit (luksOpen was done too late it seems), but it is now mounted in the netfs init script (!). Is this all by design and is this the recommended way of using LUKS with keyfiles on USB sticks (which can be something useful in certain environmnents)? -- --Jos Vos j...@xos.nl --X/OS Experts in Open Systems BV | Phone: +31 20 6938364 --Amsterdam, The Netherlands| Fax: +31 20 6948204 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Mon, 2010-08-30 at 22:08 -0700, Jesse Keating wrote: Developers put new features in rawhide knowing that they will be in the next release of Fedora, which would be at the /most/ 6 months from the time they drop the feature. It's more like 9 months. A feature has to wait until the next branching of a Fedora version from rawhide, and then for that Fedora version to be released. For example, a feature that landed in rawhide on 2010-02-19, just after F13 was branched, would end up in F14 on 2010-11-02. Your point is still taken. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proprietary search engines
On Tue, 2010-08-31 at 08:19 -0400, Matthew Miller wrote: Fedora gets to build and ship a slightly-modified version of Firefox while retaining the Firefox name due to a distribution partner agreement with Mozilla. Mozilla gets their money from Google. I don't think we *can* make it something else -- it's part of the price we are paying in order to use the non-Free name. See: https://wiki.mozilla.org/Firefox_Rebranding:Worksheet#Start_page Good catch. More fallout of the Mozilla trademarks... (Am I starting to sound like Kevin?) -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning a few packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/30/2010 06:07 PM, pbrobin...@gmail.com wrote: I've orphaned the following packages if anyone wants to pick them up. They are primarily dead upstream but some might still use them. libmatchbox matchbox-window-manager twitter-glib Regards, Peter I guess I will have to take matchbox-window-manager, since I use it in sandbox, unless someone else wants to take it, or has a reasonable replacement. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkx8+fwACgkQrlYvE4MpobNqSQCgngl34iyV/U6/S5jlnZ428mNO BUsAoOtULe1YRZkLgt5Ots7WGqur3bqq =l+11 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning a few packages
On Tue, Aug 31, 2010 at 1:47 PM, Daniel J Walsh dwa...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/30/2010 06:07 PM, pbrobin...@gmail.com wrote: I've orphaned the following packages if anyone wants to pick them up. They are primarily dead upstream but some might still use them. libmatchbox matchbox-window-manager twitter-glib Regards, Peter I guess I will have to take matchbox-window-manager, since I use it in sandbox, unless someone else wants to take it, or has a reasonable replacement. Well Sugar use to use it for their WM but it worked out that it was easier to use metacity. In the time I've had it the maintenance has been very low so it seems its pretty stable. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Mon, 2010-08-30 at 22:47 -0700, Adam Williamson wrote: On Mon, 2010-08-30 at 22:33 -0700, Jesse Keating wrote: Where do you see somebody proposing that no updates be issued? Where do you see somebody proposing a setup where fixing a graphics card can't be done in the stable release kernel? You've built up a nice strawman that you've lovingly kicked down. It's implicit in what Jon said; I was pointing out that he was, possibly inadvertently, suggesting a principle that was far too strict. IMO if hardware enablement can be done at no risk, then ok. But as Jesse said, rebasing some major component to achieve that would not be ok. I don't really want to pick on Xorg since it usually works well. But, in the theoretical sense my own opinion is that it's better to have a few people wait six months for stable support for some new hardware or have to install some additional - separate - packages for that, if there's a risk to the existing users. Existing user experience should come first because they are already running Fedora F-X, not contemplating it. As Jesse also said, how we define breakage varies a lot, too. For example, the latest version of evolution out of the box on F13 treats Mark Messages as Read differently from F12. It now wants you to confirm every time you do this, not just on folders that have sub-folders, or when touching the top-level Inbox. Had that behavior changed before the upgrade, I would have regarded it as a form of breakage because it affects how one reads mail vs. the day before. Sure, it's not package breakage, but it is a change in behavior. You could say that's not breakage, but it would seem to fall afoul of the existing policy described in the User_base documents on the wiki. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On 08/31/2010 11:26 AM, Arthur Pemberton wrote: Strongly free and tracking upstream is something developers would appreciate, however bug fix only updates are often contrary to what developers want and outlier users like myself. It depends on whether Fedora is a platform for development. If it is, developers usually do not want many changes. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 00:45:49 -0400, Arthur Pemberton pem...@gmail.com wrote: So far the only brokeness I have had in all of F13 is with `seabios-bin`. Wasn't there recently a packagekit problem where it stopped doing updates, making it kind of hard to get a fix unless you knew about yum? That's a pretty significant oops. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Tue, 31 Aug 2010, Bruno Wolff III wrote: On Tue, Aug 31, 2010 at 00:45:49 -0400, Arthur Pemberton pem...@gmail.com wrote: So far the only brokeness I have had in all of F13 is with `seabios-bin`. Wasn't there recently a packagekit problem where it stopped doing updates, making it kind of hard to get a fix unless you knew about yum? That's a pretty significant oops. Yes we have links on some of our sites like - http://start.fedoraproject.org/ for example. The sad thing is this is the second time this has happened in the last few releases. -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaned package: system-config-display
On Mon, 2010-08-30 at 22:13 -0700, Adam Williamson wrote: (Is it actually impossible for the vesa driver to work after KMS has kicked in, btw, or is it just something that doesn't work at present?) Right now, it may work or it may not. Typically the vesa bios assumes it's the only thing that's ever touched the card [1]. Loading a KMS driver usually changes some hardware settings that the bios treats as invariants. So, you could load vesa, and it might appear to work for a while, but it might also not work at all, or anything in between. It might work better if you unloaded the KMS driver and had it program the hardware back to its initial state on unload. But even then you're hoping you reset everything the bios cares about correctly. So to be safe, we just don't let you do that. [1] - Windows XP and earlier only ever use vesa services to set the mode for the initial boot splash. So that's typically _exactly_ as reliable as vesa services ever are: one modeset, probably to 1024x768 or 800x600, iff you've never loaded a native driver, and anything after that is a gamble. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
... So in other words, dependency 1.6 to 1.6.1 is okay as it is likely a bug fix, but 1.6 to 1.8 is not okay because it is a new release. there's no reason why 1.8 won't be ok after 2-3 weeks in updates-testing So, web developers want latest httpd/PHP/Rails/MySQL; GNOME developers want latest gtk/libgnome*; and so on. I wouldn't be so sure about that. If I was developing a web application I would want my version of httpd/PHP/Rails/MySQL to remain stable - the last thing I want is a bug to appear in the application I am writing and have to wonder if it is a problem with my code or did the update in my framework change something on me. If you develop some app you want to catch bugs in your app as fast as possible because you don't want release something that is broken just because there is newer library out there. Also my own experience: I wanted webmail client with some set of features the only client (except too big hordce imp) was latest roundcube. I had to package it myselfs because it was not even in latest fedora and then update all dendencies because it was not working with ancient php centos5 provides. I know Fedora is much faster than CentOS, but still... there's no reason why we should not update packages to newer *stable* release Similarly, everyone who cares about the tools they use daily (which developers tend to), wants the best versions of these tools, as soon as it is practical. So, newest version of emacs/vim/kdevelop/... Again, as a developer I would disagree. Again, as a developer I would agree with Miloslav The result is a distribution on which it is reasonably easy to develop current software, and a distribution on which one might not update critical system updates on the night before giving a presentation on a conference (FWIW, I can't recall a really bad updates experience). That doesn't seem to be a bad tradeoff - for a developer. So lets see, you are going to give a presentation or attend a conference, where you will likely be using an unsecured network with many threats that likely don't exist in your home or office environment, and you are saying that because we have a distrubition where anything can change and possibly break things you think it is okay that you have to forgo critical system updates that might prevent your system from being hacked? How can that be viewed as an acceptable tradeoff? That package won't be ancient old, so the risk is small to almost zero. You'd understand the tradeoff better after first not working presentation you've tried to do. I won't update nothing day or two before presentation even from current fedora/centos/... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: perl-Pugs-Compiler-Rule
perl-Pugs-Compiler-Rule has broken dependencies in the F-14 tree: On x86_64: perl-Pugs-Compiler-Rule-0.37-4.fc13.noarch requires perl(:MODULE_COMPAT_5.10.1) On i386: perl-Pugs-Compiler-Rule-0.37-4.fc13.noarch requires perl(:MODULE_COMPAT_5.10.1) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
F-14 Branched report: 20100831 changes
Compose started at Tue Aug 31 13:15:27 UTC 2010 Broken deps for x86_64 -- 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 libgnarl-4.4.so()(64bit) PragmARC-20060427-6.fc13.x86_64 requires libgnat-4.4.so()(64bit) QuantLib-test-1.0.1-3.fc14.x86_64 requires libboost_unit_test_framework.so.1.41.0()(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 libwebkit-1.0.so.2 1:anjuta-2.30.0.0-2.fc14.i686 requires libdevhelp-1.so.1 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) antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 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) cyphesis-0.5.21-2.fc13.x86_64 requires libpython2.6.so.1.0()(64bit) ekg2-python-0.2-0.12.rc1.fc14.x86_64 requires libpython2.6.so.1.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 libgtkhtml-editor.so.0()(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 libcamel-provider-1.2.so.17()(64bit) evolution-sharp-0.21.1-7.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-sharp-0.21.1-7.fc14.x86_64 requires libecal-1.2.so.7()(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) 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 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) libopenvrml-0.18.6-1.fc14.i686 requires libboost_filesystem-mt.so.1.41.0 libopenvrml-0.18.6-1.fc14.i686 requires libboost_thread-mt.so.1.41.0 libopenvrml-0.18.6-1.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) libopenvrml-0.18.6-1.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) libopenvrml-gl-0.18.6-1.fc14.i686 requires libboost_filesystem-mt.so.1.41.0 libopenvrml-gl-0.18.6-1.fc14.i686 requires libboost_thread-mt.so.1.41.0 libopenvrml-gl-0.18.6-1.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) libopenvrml-gl-0.18.6-1.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) libpst-python-0.6.47-4.fc14.x86_64 requires libboost_python.so.1.41.0()(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-5.fc14.x86_64 requires libgnome-media-profiles-3.0.so.0()(64bit) openvrml-java-0.18.6-1.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) openvrml-java-0.18.6-1.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) openvrml-javascript-0.18.6-1.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) openvrml-javascript-0.18.6-1.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) openvrml-nodes-0.18.6-1.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit)
Re: fedora mission (was Re: systemd and changes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/31/10 5:33 AM, Matt McCutchen wrote: On Mon, 2010-08-30 at 22:08 -0700, Jesse Keating wrote: Developers put new features in rawhide knowing that they will be in the next release of Fedora, which would be at the /most/ 6 months from the time they drop the feature. It's more like 9 months. A feature has to wait until the next branching of a Fedora version from rawhide, and then for that Fedora version to be released. For example, a feature that landed in rawhide on 2010-02-19, just after F13 was branched, would end up in F14 on 2010-11-02. Your point is still taken. It'd be in the Alpha for F14 much earlier. And all along the way, from rawhide - branched - alpha - beta - final it'll have users using it and providing feedback, and a progressively less scary target for eager users to jump to if they want that new feature earlier. - -- 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/ iEYEARECAAYFAkx9GsUACgkQ4v2HLvE71NWdeACgn6fdpqnOxhe9VTfJEMk8+kjr XhkAoKefWbmoR7KEewiySDGRmZiXqCxX =+rfo -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proprietary search engines
On Tue, 2010-08-31 at 08:39 -0400, Matt McCutchen wrote: On Tue, 2010-08-31 at 08:19 -0400, Matthew Miller wrote: Fedora gets to build and ship a slightly-modified version of Firefox while retaining the Firefox name due to a distribution partner agreement with Mozilla. Mozilla gets their money from Google. I don't think we *can* make it something else -- it's part of the price we are paying in order to use the non-Free name. See: https://wiki.mozilla.org/Firefox_Rebranding:Worksheet#Start_page Good catch. More fallout of the Mozilla trademarks... (Am I starting to sound like Kevin?) It doesn't seem to be an unavoidable requirement, it says: If you proposed Start/Home Page is not similar to the existing Firefox Start Page, please be prepared to provide a rationale for the change, and how it would benefit the end-user. I think we could manage such a rationale. -- 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: fedora mission (was Re: systemd and changes)
On Tue, 2010-08-31 at 08:54 -0400, Jon Masters wrote: On Mon, 2010-08-30 at 22:47 -0700, Adam Williamson wrote: On Mon, 2010-08-30 at 22:33 -0700, Jesse Keating wrote: Where do you see somebody proposing that no updates be issued? Where do you see somebody proposing a setup where fixing a graphics card can't be done in the stable release kernel? You've built up a nice strawman that you've lovingly kicked down. It's implicit in what Jon said; I was pointing out that he was, possibly inadvertently, suggesting a principle that was far too strict. IMO if hardware enablement can be done at no risk, then ok. But as Jesse I wasn't really talking about the topic of the argument, it was more of a meta-post on how the argument is being conducted. There's already clearly (at least) two schools of thought and compromising between them would be very difficult. If either or both schools start supporting their arguments with categorical statements like as if waiting six months really mattered in the real world, it's only going to make it harder. In a discussion like this it's only possible to come to a vaguely workable compromise without everyone hating each other if you at least acknowledge that the other point of view has some validity too, even if it's not the one you share. -- 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: fedora mission (was Re: systemd and changes)
On Tuesday, August 31, 2010 16:14:39 Matthew Miller wrote: On Tue, Aug 31, 2010 at 03:57:47PM +0200, Michal Hlavinka wrote: So in other words, dependency 1.6 to 1.6.1 is okay as it is likely a bug fix, but 1.6 to 1.8 is not okay because it is a new release. there's no reason why 1.8 won't be ok after 2-3 weeks in updates-testing I hope you are kidding. nope, I'm 100 % serious Of course, these imaginary numbers aren't very helpful -- some programs make only minor changes between whole-version-number releases, whereas others revolutionize the whole project beteen 0.88 and 0.89. The policy can't be based on version numbers -- it has to be on potential risk. Note: I agree there should be no updates breaking something - for example when configuration files from old version does not work with new version. That's out of the question. Fedora is not the only distro using (and testing) some program/library. Also there is very low potential risk to have some problem in F n-1 if the package works fine in F n. I really don't see any problem with: new version in rawhide and Fn updates-testing (after two weeks) updates for Fn, updates-testing for F n-1 (after two weeks) updates for F n-1, updates-testing for F n-2 Fedora = “Freedom, Friends, Features, *First*” -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 05:31:43PM +0200, Michal Hlavinka wrote: So in other words, dependency 1.6 to 1.6.1 is okay as it is likely a bug fix, but 1.6 to 1.8 is not okay because it is a new release. there's no reason why 1.8 won't be ok after 2-3 weeks in updates-testing I hope you are kidding. nope, I'm 100 % serious Unfortunately, then: this does not currently match reality. -- Matthew Miller mat...@mattdm.org 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: fedora mission (was Re: systemd and changes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/31/10 6:57 AM, Michal Hlavinka wrote: there's no reason why 1.8 won't be ok after 2-3 weeks in updates-testing An update that changes behavior for the end user would never be acceptable as an update to a stable release. Only severe exceptions should be made to this rule, where the time/effort to backport the important fixes from a new upstream release are cost prohibitive and too complicated to do on our own. rawhide is not to F-n as debian unstable is to debian testing. F-n is not to F-(n-1) as debian testing is to debian stable. - -- 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/ iEYEARECAAYFAkx9IhwACgkQ4v2HLvE71NXnpgCfcso2mCew20a1ERPE31+jJg4z MtcAnRGCoa1Lrv5loMdOCSqC+4KTchW4 =q/v4 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On 08/30/2010 10:48 PM, Arthur Pemberton wrote: So developers are going to put new features into rawhide knowing that they will never make it to updates? I do it all the time because I know it will be out ~ 6 months, which is pretty quick. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On 08/30/2010 10:50 PM, Arthur Pemberton wrote: The attention to freedom is not unique. The attention to upstream is invisible to users. But it is why I want to *develop* for Fedora. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Tuesday, August 31, 2010 17:36:39 Matthew Miller wrote: On Tue, Aug 31, 2010 at 05:31:43PM +0200, Michal Hlavinka wrote: So in other words, dependency 1.6 to 1.6.1 is okay as it is likely a bug fix, but 1.6 to 1.8 is not okay because it is a new release. there's no reason why 1.8 won't be ok after 2-3 weeks in updates-testing I hope you are kidding. nope, I'm 100 % serious Unfortunately, then: this does not currently match reality. that's not any usefull information for discussion. If you can only offend instead of bringing some new information/arguments, please do not spam this thread, there is a lot of posts already. thanks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Tuesday, August 31, 2010 17:39:11 Jesse Keating wrote: On 8/31/10 6:57 AM, Michal Hlavinka wrote: there's no reason why 1.8 won't be ok after 2-3 weeks in updates-testing An update that changes behavior for the end user would never be acceptable as an update to a stable release. Only severe exceptions should be made to this rule, where the time/effort to backport the important fixes from a new upstream release are cost prohibitive and too complicated to do on our own. I don't thing there is so much updates that change behaviour, see firefox, thunderbird, kopete, usually there are only new features with old functionality intact. What I wrote was not a rule, there is always a lot of space for maintainer's decission. rawhide is not to F-n as debian unstable is to debian testing. F-n is not to F-(n-1) as debian testing is to debian stable. no, but I think rawhide is to F-n as debian unstable is to debian stable. What I wrote as an example was expecting all versions in F-x are stable not that one version is more stable than another one. That delay was only for being really sure package is stable, because there are not too much users testing updates-testing packages if it's not new firefox/kernel/... but after a two weaks in F-n any package is tested quite well -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 07:05, Rahul Sundaram methe...@gmail.com wrote: On 08/31/2010 11:26 AM, Arthur Pemberton wrote: Strongly free and tracking upstream is something developers would appreciate, however bug fix only updates are often contrary to what developers want and outlier users like myself. It depends on whether Fedora is a platform for development. If it is, developers usually do not want many changes. It depends on the type of developer and what they are doing. Trying to lump all the developers into one bottle is one of the problems of this so-called conversation. -- Stephen J Smoogen. “The core skill of innovators is error recovery, not failure avoidance.” Randy Nelson, President of Pixar University. We have a strategic plan. It's called doing things. — Herb Kelleher, founder Southwest Airlines -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 06:08:09PM +0200, Michal Hlavinka wrote: there's no reason why 1.8 won't be ok after 2-3 weeks in updates-testing I hope you are kidding. nope, I'm 100 % serious Unfortunately, then: this does not currently match reality. that's not any usefull information for discussion. If you can only offend instead of bringing some new information/arguments, please do not spam this thread, there is a lot of posts already. thanks I don't mean to offend. And I also don't think there's any new information. The basic fact of current reality is that the testing repositories do not get enough exposure or formal testing to demonstrate that an update is okay. -- Matthew Miller mat...@mattdm.org 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: fedora mission (was Re: systemd and changes)
On 08/31/2010 12:26 PM, Stephen John Smoogen wrote: On Tue, Aug 31, 2010 at 07:05, Rahul Sundaram methe...@gmail.com wrote: It depends on whether Fedora is a platform for development. If it is, developers usually do not want many changes. It depends on the type of developer and what they are doing. Trying to lump all the developers into one bottle is one of the problems of this so-called conversation. I concur - I know some who are happy with things staying as they were in 1980. I know more who prefer reasonably current toolkits - many get frustrated when obligated to work on older installs (the 'stable' but somewhat ancient ones in particular) which may have packages a few years older than current. And its not just kernels, libraries and compilers but applications too. (e.g TeXlive without biblatex, openoffice without docx etc etc). gene/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 7:39 AM, Jesse Keating jkeat...@j2solutions.net wrote: An update that changes behavior for the end user would never be acceptable as an update to a stable release. Only severe exceptions should be made to this rule, where the time/effort to backport the important fixes from a new upstream release are cost prohibitive and too complicated to do on our own. Uhm... there are end-user applications under active development that see monthly-ish updates that can include UI changes and bug fixes together. In fact UI changes could be considered bugfixes. Are you sure there is a bright line concerning changes to end-user observable behavior? I'm not. Bugfixes can deliberately and purposefully change behavior that some users are used to. I'm a package maintainer for one such application. I have yet to hear from a single user...ever..that tracking releases from upstream has been unwanted for this specific application regardless of the UI tweaks that happen between upstream releases. In fact I have bug reports to the contrary asking me to push newer versions because I originally held back updates across a significant upstream version boundary. Am I going to be disallowed from tracking upstream's release schedule for this particular application by providing monthlyish updates and moving them through updates-testing into updates-released? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
2010/8/31 Jesse Keating jkeat...@j2solutions.net: An update that changes behavior for the end user would never be acceptable as an update to a stable release. Only severe exceptions should be made to this rule, where the time/effort to backport the important fixes from a new upstream release are cost prohibitive and too complicated to do on our own. An update that does not change behavior for the end user is ... not meaningful. Any update changes something, otherwise it would not have been issued. And sometimes it is not at all clear if that change is welcome or not. A bug fix might be in most cases, but could also mean some work to the end user as well, like removing a workaround. We should accept that people have different expectations, and draw different lines in the trade of getting new bug fixes and new features vs. coping with breakage and changed behavior. People might even have different expectations from package to package. If we decide to draw that line at a fixed point, distribution-wide, we'll lose people, inevitably. So lets try to come up with ideas how to satisfy both (or even more than two) needs. Making categories (critical packages vs. non-critical packages) is a good step in the right direction, as well as more than one repository. If there are issues the build system or the packaging tools cannot handle, good, that is a technical problem and can be solved. We're not here for politics, are we? - Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 08:40:29 -0800, Jeff Spaleta jspal...@gmail.com wrote: I'm a package maintainer for one such application. I have yet to hear from a single user...ever..that tracking releases from upstream has been unwanted for this specific application regardless of the UI tweaks that happen between upstream releases. In fact I have bug reports to the contrary asking me to push newer versions because I originally held back updates across a significant upstream version boundary. Packages that need to sync to external servers or peers such as multiplayer games have similar issues. You need to be up to date to for the package to be useful in some cases. I would like to see some per package exceptions to this policy that don't need to be revisited for every update. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Tue, 2010-08-31 at 18:18 +0200, Michal Hlavinka wrote: On Tuesday, August 31, 2010 17:39:11 Jesse Keating wrote: On 8/31/10 6:57 AM, Michal Hlavinka wrote: there's no reason why 1.8 won't be ok after 2-3 weeks in updates-testing An update that changes behavior for the end user would never be acceptable as an update to a stable release. Only severe exceptions should be made to this rule, where the time/effort to backport the important fixes from a new upstream release are cost prohibitive and too complicated to do on our own. I don't thing there is so much updates that change behaviour, see firefox, thunderbird, kopete, usually there are only new features with old functionality intact. What I wrote was not a rule, there is always a lot of space for maintainer's decission. Things like Firefox, and Thunderbird have large external teams maintaining them who appear to have goals around ensuring a consistent user experience, with testing, and so forth, over and above just getting new features. They even do self-updating on some platforms, etc. I would say they are fantastic examples of packages where you can get away with a lower commitment in favor of updating them more frequently because the upstream is known to have the user experience interest as a top priority over adding new features. But that isn't a given for every single piece of software by any means, especially when it comes to upstream testing. I was saying elsewhere that I think what could work for something like the Server SIG would be a very strong commitment to the crit-path bits, regular cross-team meetings to discuss proposals and pain points, and a very co-ordinated planning effort to change the guts of the system. There is some effort to do that kind of thing already with a different treatment of crit-path updates, but I think it should go further. Then, I suppose it would be ok to agree to have a lesser commitment for some other packages like Firefox, especially where Mozilla (and the packager) is known to be doing a very good job providing consistent experience. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 8:57 AM, Jon Masters jonat...@jonmasters.org wrote: Things like Firefox, and Thunderbird have large external teams maintaining them who appear to have goals around ensuring a consistent user experience, with testing, and so forth, over and above just getting new features. They even do self-updating on some platforms, etc. I would say they are fantastic examples of packages where you can get away with a lower commitment in favor of updating them more frequently because the upstream is known to have the user experience interest as a top priority over adding new features. But that isn't a given for every single piece of software by any means, especially when it comes to upstream testing. Uhm wait... wasn't a mid release update to thunderbird one of the historic examples of a large behavior change that precipitated a strong negative reaction? I think you are careening well away from fact based argument here. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Tue, 2010-08-31 at 09:58 -0600, Orion Poplawski wrote: On 08/30/2010 10:50 PM, Arthur Pemberton wrote: The attention to freedom is not unique. The attention to upstream is invisible to users. But it is why I want to *develop* for Fedora. You cut out the rest of Arthur's email, where he says exactly the same thing. This isn't a point scoring exercise, please read entire emails before you spot a piece you think you disagree with and try to win by contradicting 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: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 11:51:27AM -0500, Bruno Wolff III wrote: I would like to see some per package exceptions to this policy that don't need to be revisited for every update. I think it's reasonable to put packages into different tiers. Or lanes, if we don't want to think in terms of which is on top of the other. -- Matthew Miller mat...@mattdm.org 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: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 12:32 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2010-08-31 at 09:58 -0600, Orion Poplawski wrote: On 08/30/2010 10:50 PM, Arthur Pemberton wrote: The attention to freedom is not unique. The attention to upstream is invisible to users. But it is why I want to *develop* for Fedora. You cut out the rest of Arthur's email, where he says exactly the same thing. This isn't a point scoring exercise, please read entire emails before you spot a piece you think you disagree with and try to win by contradicting it. Thank you for mentioning this, I was simply not going to respond to Mr. Poplawski. Maybe I was too long winded, or failed to communicate my point: a stable (bug fix only updates, slow feature release), strongly FOSS, strongly upstream seems to be what some (I am not going to make assumptions about numbers) want. I see two problems with this: 1) the nature of such a distro would make it attractive to a smaller percentage of the Linux community 2) the only aspect of that that would be unique is the commitment to upstream -- something which will be appreciated by few I'm not saying that any aspect of such a mission would be bad, just that it would be very niche. -- Fedora 13 (www.pembo13.com) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Fri, 2010-08-27 at 18:08 -0400, Jon Masters wrote: Again, I feel it is necessary to have a survey of Fedora users. That's users you've already got. It might make the users you already have happier, sure, and that's a fine thing to do. Iif you want to grow, though, you may be limiting yourself by only considering responses from people you've already won, if that makes sense. E.g., sure, I can make a better grilled steak that I already serve, and that'll make the customers I have happier, but if I want to expand my customer base I might want to consider at least a couple of veggie-friendly dishes for the menu. If you define a desired target, then you know who to survey that you haven't even gotten as a user yet and understand better how to win them over and expand your userbase... But I don't think we even have agreement amongst contributors that we want to expand the userbase (which is troubling to me.) ~m -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
* Bruno Wolff III [31/08/2010 19:25] : Packages that need to sync to external servers or peers such as multiplayer games have similar issues. You need to be up to date to for the package to be useful in some cases. Same goes for programs that scrape web pages (I'm thinking of gcstar but I'm sure there are others). If the page layout changes, the page scraper needs to be updated and that usually involves updating the package. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Mon, 2010-08-30 at 20:41 -0400, Jon Masters wrote: Great stuff. And there's more in there too. So the current User_base in addition to being not very well linked and referenced could hardly be described as reflecting all of the views in this particular thread. Should it really reflect all the views in this thread? Isn't that literally design-by-committee? ~m -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 9:34 AM, Emmanuel Seyman emmanuel.sey...@club-internet.fr wrote: Same goes for programs that scrape web pages (I'm thinking of gcstar but I'm sure there are others). If the page layout changes, the page scraper needs to be updated and that usually involves updating the package. Yep.. gourmet does this to some extent as well for scrape recipes from specific sites as well as provide a generic web scraper for you to build your own recipe grabber. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gnupg2 evolution
Am Montag, den 30.08.2010, 10:08 -0400 schrieb seth vidal: On Mon, 2010-08-30 at 16:04 +0200, Christoph Höger wrote: Hi, I cannot use gnupg2 from evolution anymore. Apparently somewhere in evolution the command gpg is hardwired, while whe only have gpg2 nowadays. Any suggestions? Testing updates or something? yum install gnupg it's not being pulled in automatically b/c evolution doesn't actually DEPEND onf /usr/bin/gpg Yeah, that would work, if I wanted to use gnupg version 1, but I guess, I'm better off staying at version 2. gnupg2 used to ship /usr/bin/gpg - nowadays it does not. Seems like I should open up a bug report or something. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gnupg2 evolution
Christoph Höger wrote: Seems like I should open up a bug report or something. Searching the mailing lists[1] is sometimes helpful as well. [1] http://lists.fedoraproject.org/pipermail/devel/2010-July/138765.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gnupg2 evolution
On Tue, 2010-08-31 at 20:04 +0200, Christoph Höger wrote: Am Montag, den 30.08.2010, 10:08 -0400 schrieb seth vidal: On Mon, 2010-08-30 at 16:04 +0200, Christoph Höger wrote: Hi, I cannot use gnupg2 from evolution anymore. Apparently somewhere in evolution the command gpg is hardwired, while whe only have gpg2 nowadays. Any suggestions? Testing updates or something? yum install gnupg it's not being pulled in automatically b/c evolution doesn't actually DEPEND onf /usr/bin/gpg Yeah, that would work, if I wanted to use gnupg version 1, but I guess, I'm better off staying at version 2. gnupg2 used to ship /usr/bin/gpg - nowadays it does not. Seems like I should open up a bug report or something. I believe it does not anymore on purpose - but definitely file it to get an explanation. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
Jeff Spaleta (jspal...@gmail.com) said: On Tue, Aug 31, 2010 at 9:34 AM, Emmanuel Seyman emmanuel.sey...@club-internet.fr wrote: Same goes for programs that scrape web pages (I'm thinking of gcstar but I'm sure there are others). If the page layout changes, the page scraper needs to be updated and that usually involves updating the package. Yep.. gourmet does this to some extent as well for scrape recipes from specific sites as well as provide a generic web scraper for you to build your own recipe grabber. That's gross. (I realize you're blocked on the sites you rely on, but geez, can't you find sites with real APIs?) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gnupg2 evolution
Am Dienstag, den 31.08.2010, 13:11 -0500 schrieb Michael Cronenworth: Christoph Höger wrote: Seems like I should open up a bug report or something. Searching the mailing lists[1] is sometimes helpful as well. [1] http://lists.fedoraproject.org/pipermail/devel/2010-July/138765.html I've seen that. That convinced me, that the missing /usr/bin/gpg was not my fault. But I still consider this an evolution bug. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
clutter - 1.3
Heads up to Clutter consumers - I'm updating it in f15 to the 1.3 (master) branch. I've tested GNOME Shell and quadrapassel, feel free to CC me for other fallout. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 10:31 AM, Bill Nottingham nott...@redhat.com wrote: That's gross. (I realize you're blocked on the sites you rely on, but geez, can't you find sites with real APIs?) It is what it is. Though I do like being given credit for doing development work that I'm not actually responsible for. Makes me feel important. if you have specific recipe cites that have a documented API that you'd like to see added file an RFE with as much information as you can and I'll see if I can't help implement an API client plugin for that site inside the gourmet plugin system to gift to the upstream developers. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: clutter - 1.3
On Tue, Aug 31, 2010 at 7:52 PM, Colin Walters walt...@verbum.org wrote: Heads up to Clutter consumers - I'm updating it in f15 to the 1.3 (master) branch. I've tested GNOME Shell and quadrapassel, feel free to CC me for other fallout. This will break meego. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
Some people like everything up-to-date, while others are more conservative. Fine. Isn't there a middle ground? Currently there are these repos: updates and updates_testing. Maybe two more repos could be added: updates_fixes and updates_enhancements. After a package stays for a while in updates_testing, and is considered good, the package maintainer would decide where to move it. If it is security-related it would go to updates, if not he would look at the changes since the previous version. If the changes are minor, just bug fixes, the package would go to updates_fixes, if besides bug fixes it has enhancements, it would be moved to updates_enhancements. People with yum would enable the repos they need according to their requirements. People using PackageKit or yumex would have two tick boxes in option settings to enable (or not) fixes and enhancements. The downside is that if upstream the security fixes are available only at the latest source, it would take some work to port just the security fixes on top of the latest stable version. It would be easier just to get the full upstream version (including enhancements and bug fixes) and package it and move into updates. It would then be the choice of the package maintainer to decide on what to do based on time available and how comfortable he feels patching source code: either port just security fixes (which implies doing two packages, one with just security fixes and another with enhancements) or a single package with everything. --- P. S. As an alternative to the above, to simplify things a bit, a single new repo could be created, with both enhancements and fixes. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: clutter - 1.3
On Tue, 2010-08-31 at 19:57 +0100, pbrobin...@gmail.com wrote: On Tue, Aug 31, 2010 at 7:52 PM, Colin Walters walt...@verbum.org wrote: Heads up to Clutter consumers - I'm updating it in f15 to the 1.3 (master) branch. I've tested GNOME Shell and quadrapassel, feel free to CC me for other fallout. This will break meego. Well, it's F15 :) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
* Bill Nottingham [31/08/2010 21:01] : That's gross. Yup, no question about it. (I realize you're blocked on the sites you rely on, but geez, can't you find sites with real APIs?) For some of them, it is possible (DVDfr.com has a stable XML API and the webmaster has contributed to GCstar). Sadly, it's the exception rather than the rule. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: clutter - 1.3
On Tue, Aug 31, 2010 at 2:57 PM, pbrobin...@gmail.com pbrobin...@gmail.com wrote: On Tue, Aug 31, 2010 at 7:52 PM, Colin Walters walt...@verbum.org wrote: Heads up to Clutter consumers - I'm updating it in f15 to the 1.3 (master) branch. I've tested GNOME Shell and quadrapassel, feel free to CC me for other fallout. This will break meego. Okay, is there a schedule for meego supporting 1.3? That would give guidance about creating a temporary clutter-1.2 package or not. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
Jeff Spaleta (jspal...@gmail.com) said: On Tue, Aug 31, 2010 at 10:31 AM, Bill Nottingham nott...@redhat.com wrote: That's gross. (I realize you're blocked on the sites you rely on, but geez, can't you find sites with real APIs?) It is what it is. Though I do like being given credit for doing development work that I'm not actually responsible for. Makes me feel important. It is not meant to be a complaint at you or a request for you to do more work. It's a complaint at the state of the world. (Why not find the biggest windmill of all to tilt at?) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: clutter - 1.3
On Tue, Aug 31, 2010 at 8:04 PM, Bastien Nocera bnoc...@redhat.com wrote: On Tue, 2010-08-31 at 19:57 +0100, pbrobin...@gmail.com wrote: On Tue, Aug 31, 2010 at 7:52 PM, Colin Walters walt...@verbum.org wrote: Heads up to Clutter consumers - I'm updating it in f15 to the 1.3 (master) branch. I've tested GNOME Shell and quadrapassel, feel free to CC me for other fallout. This will break meego. Well, it's F15 :) Yes, but its generally considered to be good form to give heads up before it happens rather than once its on its way and pretty much too late for those that it does impact to have a say. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: clutter - 1.3
On Tue, Aug 31, 2010 at 8:16 PM, Colin Walters walt...@verbum.org wrote: On Tue, Aug 31, 2010 at 2:57 PM, pbrobin...@gmail.com pbrobin...@gmail.com wrote: On Tue, Aug 31, 2010 at 7:52 PM, Colin Walters walt...@verbum.org wrote: Heads up to Clutter consumers - I'm updating it in f15 to the 1.3 (master) branch. I've tested GNOME Shell and quadrapassel, feel free to CC me for other fallout. This will break meego. Okay, is there a schedule for meego supporting 1.3? That would give guidance about creating a temporary clutter-1.2 package or not. It not in MeeGo 1.1 and after that there's no published schedule. So for 1.2 (or what ever its called) which should come around F-15 I suspect it might happen but I've no idea. I also don't know about backwards compatibility between the releases. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gnupg2 evolution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/31/2010 11:12 AM, seth vidal wrote: On Tue, 2010-08-31 at 20:04 +0200, Christoph Höger wrote: Am Montag, den 30.08.2010, 10:08 -0400 schrieb seth vidal: On Mon, 2010-08-30 at 16:04 +0200, Christoph Höger wrote: Hi, I cannot use gnupg2 from evolution anymore. Apparently somewhere in evolution the command gpg is hardwired, while whe only have gpg2 nowadays. Any suggestions? Testing updates or something? yum install gnupg it's not being pulled in automatically b/c evolution doesn't actually DEPEND onf /usr/bin/gpg Yeah, that would work, if I wanted to use gnupg version 1, but I guess, I'm better off staying at version 2. gnupg2 used to ship /usr/bin/gpg - nowadays it does not. Seems like I should open up a bug report or something. I believe it does not anymore on purpose - but definitely file it to get an explanation. Please don't ;) It was on purpose. If you want to use gpg2 instead of gpg you should be able to just create a symlink from /usr/bin/gpg to /usr/bin/gpg2 The problem is that gpg2 is not a 100% replacement for gpg, and both are now being maintained in parallel. For a while gpg2 was providing a symlink from gpg to gpg2, but now that gpg has been revived it can't do that without conflicting with the other package. - -- Brian C. Lane b...@redhat.com Red Hat / Port Orchard, WA -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Remember Lexington Green! iQEVAwUBTH1Y+hF+jBaO/jp/AQJESAf/YBMVCap7TGbkUl4yCIY66niBaHbcZaTr 7kX12JRc/727MQBYdVMKlb+piO2gi1MRFtQSrnefUnE1+BjsDXkNzSjxGOz25c1/ kyiuj8TyqGnyWjhfng4Ov+BQv6X1kcKhLhLUDfmKulJVlmZVLOzksvZWZoiaOHjH GbUFx/YNuvdYN3Z70DNPgLj7jhZ7RqxKpGEQ5Tho9PEWXO3lTodvQFZQJ9MEV01C gVmJ6GdES9/drmcaDWpyEb6on+caNH1XmXI3G/tAFsEeXE/b2TZjXhEBI7VJqNaI oLtAVUNoHhLAZUpGY59V8VW/d0B90sMVZFVG2S2RA2NA0/6i2GDE3Q== =H2At -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 01:26:27PM -0400, Arthur Pemberton wrote: Maybe I was too long winded, or failed to communicate my point: a stable (bug fix only updates, slow feature release), strongly FOSS, strongly upstream seems to be what some (I am not going to make assumptions about numbers) want. I see two problems with this: Where, keep in mind, slow is defined as twice a year, right? 1) the nature of such a distro would make it attractive to a smaller percentage of the Linux community Do you have a basis for this claim? I think it's the opposite. 2) the only aspect of that that would be unique is the commitment to upstream -- something which will be appreciated by few I don't think that's fair at all. Fedora is unique in a lot of ways, and a waterfall of updates isn't essential to that uniqueness. -- Matthew Miller mat...@mattdm.org 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: fedora mission (was Re: systemd and changes)
On Tue, 2010-08-31 at 20:03 +0100, Piscium wrote: Some people like everything up-to-date, while others are more conservative. Fine. Isn't there a middle ground? Currently there are these repos: updates and updates_testing. Maybe two more repos could be added: updates_fixes and updates_enhancements. We've had multiple proposals along these lines (as I mentioned in passing on my general post about the three main ways to deal with software delivery in a repository-based OS). The principal objection to them is that it results in more work for already overworked developers. I don't think any of the proposals has been seriously considered at FESCo or Board level yet, though IMBW. -- 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: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 3:56 PM, Matthew Miller mat...@mattdm.org wrote: On Tue, Aug 31, 2010 at 01:26:27PM -0400, Arthur Pemberton wrote: Maybe I was too long winded, or failed to communicate my point: a stable (bug fix only updates, slow feature release), strongly FOSS, strongly upstream seems to be what some (I am not going to make assumptions about numbers) want. I see two problems with this: Where, keep in mind, slow is defined as twice a year, right? Yes. 1) the nature of such a distro would make it attractive to a smaller percentage of the Linux community Do you have a basis for this claim? I think it's the opposite. The basis is logic. Users who want stable, slow environments do so primarily because the want simpler to setup and maintain systems. Those users also don't want to install other unsupported repositories for full drivers, codecs, font engines, media, players ect which they then have to install unassisted. 2) the only aspect of that that would be unique is the commitment to upstream -- something which will be appreciated by few I don't think that's fair at all. Fedora is unique in a lot of ways, and a waterfall of updates isn't essential to that uniqueness. List those ways please, aside from the relationship with Red Hat/CentOS. -- Fedora 13 (www.pembo13.com) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Tue, 2010-08-31 at 15:56 -0400, Matthew Miller wrote: On Tue, Aug 31, 2010 at 01:26:27PM -0400, Arthur Pemberton wrote: Maybe I was too long winded, or failed to communicate my point: a stable (bug fix only updates, slow feature release), strongly FOSS, strongly upstream seems to be what some (I am not going to make assumptions about numbers) want. I see two problems with this: Where, keep in mind, slow is defined as twice a year, right? 1) the nature of such a distro would make it attractive to a smaller percentage of the Linux community Do you have a basis for this claim? I think it's the opposite. 2) the only aspect of that that would be unique is the commitment to upstream -- something which will be appreciated by few I don't think that's fair at all. Fedora is unique in a lot of ways, and a waterfall of updates isn't essential to that uniqueness. Arthur's idea was better expressed in his original mail. His point was that a Fedora aiming at the niche described (by Jesse) would differ from Ubuntu solely in its more rigorous interpretation of 'freedom' and its attention to upstream, which experience seems to show are not things the majority of people who go for the Ubuntu niche care much about. I think this is a pretty reasonable thesis - note how popular non-free software is with Ubuntu users, how many people use Mint (which is essentially Ubuntu with even more non-free stuff added), and how few people use/used the more-strictly-free Ubuntu variations that have existed. As he put it, I am suggesting that the mission you would like is contradictory: not that it cannot happen, but in that it represents an intersection of people that is very small. The niche described is a kind of mix of attributes that appeal to entirely different types of users/contributors. Do go back and read his original email, Date: Tue, 31 Aug 2010 01:56:26 -0400 (30/08/10 10:56:26 PM). -- 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: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 11:26 AM, Bill Nottingham nott...@redhat.com wrote: It is not meant to be a complaint at you or a request for you to do more work. It's a complaint at the state of the world. (Why not find the biggest windmill of all to tilt at?) I didn't mean for you to think it was a complaint. If I actually had developed anything significant in gourmet I'd be beaming with pride with the notoriety. Seriously though, there is a plugin system, it is possible to avoid webscraping. If there are recipe sites out there with documented APIs we can get those sites their own site-specific plugin with a weebit of effort without completely re-engineering how gourmet works. Even then..if the API changes we are in the same boat with regard to updates mid-release. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Tue, 2010-08-31 at 13:45 -0400, Máirín Duffy wrote: On Mon, 2010-08-30 at 20:41 -0400, Jon Masters wrote: Great stuff. And there's more in there too. So the current User_base in addition to being not very well linked and referenced could hardly be described as reflecting all of the views in this particular thread. Should it really reflect all the views in this thread? Not necessarily. What I'm saying is that it says one thing and the reality *is* very different. I see quite a few posts basically saying that that document doesn't matter to them at all, etc. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/31/10 9:40 AM, Jeff Spaleta wrote: On Tue, Aug 31, 2010 at 7:39 AM, Jesse Keating jkeat...@j2solutions.net wrote: An update that changes behavior for the end user would never be acceptable as an update to a stable release. Only severe exceptions should be made to this rule, where the time/effort to backport the important fixes from a new upstream release are cost prohibitive and too complicated to do on our own. Uhm... there are end-user applications under active development that see monthly-ish updates that can include UI changes and bug fixes together. In fact UI changes could be considered bugfixes. Are you sure there is a bright line concerning changes to end-user observable behavior? I'm not. Bugfixes can deliberately and purposefully change behavior that some users are used to. I'm a package maintainer for one such application. I have yet to hear from a single user...ever..that tracking releases from upstream has been unwanted for this specific application regardless of the UI tweaks that happen between upstream releases. In fact I have bug reports to the contrary asking me to push newer versions because I originally held back updates across a significant upstream version boundary. Am I going to be disallowed from tracking upstream's release schedule for this particular application by providing monthlyish updates and moving them through updates-testing into updates-released? I appreciate that there are going to be exceptions to the rule. There are going to be packages or suites of packages where the users far and away prefer always the latest whenever possible. In the cases where these packages are leaf node with little interaction across the rest of the distro I think that's fine to have a stated exception (and expectation) to the policy. But they should be the exceptions and not the rules. - -- 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/ iEYEARECAAYFAkx9akMACgkQ4v2HLvE71NW9IgCfU13FFR/bkUuZO25gBz4NSqrC PJsAnR6HwtshFaBMTrdOsidayuEcX2V7 =YK8m -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proprietary search engines
On Tue, 2010-08-31 at 08:27 -0700, Adam Williamson wrote: It doesn't seem to be an unavoidable requirement, it says: If you proposed Start/Home Page is not similar to the existing Firefox Start Page, please be prepared to provide a rationale for the change, and how it would benefit the end-user. I think we could manage such a rationale. We can definitely make a rationale for having a bunch of Fedora resources on the start page, but our rationale for omitting a Google search box, it's redundant and promotes a proprietary service, is not a line of reasoning I would expect Mozilla to accept. Then again, they may calculate that they are better off compromising on this issue in order to keep Fedora using their trademarks. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Starting Java SIG
On 30 August 2010 15:17, Stanislav Ochotnicky sochotni...@redhat.com wrote: Hi everyone, There has been an effort few years back to start Java SIG but it didn't work out in the end (no idea why). I decided it's time to try again :-) I would like to start Java SIG for a lot of reasons. Some of them: * Packaging guidelines are in need of an update (badly) * Consistency in java packages is somewhat lacking * More eyes see more approach, I'd like for all java related commits to go through an alias so we can all watch out for changes that can break our stuff * Have a place where we can collect tips tricks, solutions to common problems etc. Currently this information is scattered through people's wiki pages * Java needs collaboration more than most other areas, because problems cannot be safely discovered automatically when someone changes dependency. This can cause serious headaches (to me at least). Java SIG to the rescue! :-) * Other languages have their own SIGs and we don't! :-) Who am I? Owner/Co-maintainer of a bunch of Java packages (mostly maven plugins, apache-commons, junit, velocity, checkstyle, plexus libraries). Involved in recent update of maven to v2.2.1. Reply if you're interested with helping out and being able to see/influence where Java packaging in Fedora is going. I know there will be at least a few people joining in. I'll be starting Java SIG wiki page soon, plus I guess we can peruse java-devel mailing list for SIG discussions. I would definitely join the SIG. I mostly maintain Eclipse plugins and various low level Java libraries. https://admin.fedoraproject.org/pkgdb/users/packages/mbooth?acls=owneracls=approveaclsacls=commit I personally would like to see automatic OSGi dep-solving in RPM get off the ground :-) https://bugzilla.redhat.com/show_bug.cgi?id=488352 -- Mat Booth http://fedoraproject.org/get-fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Set-Infinite/el4/master] (11 commits) ...sync with devel
Summary of changes: 2d5e5a8... Use fixperms macro instead of our own chmod incantation. BR (*) 8fcf13e... - Adjust License-tag. - BR: perl(Test::More) (BZ 419631). (*) e278ad7... new perl (*) 92b56d0... Update to 0.63. (*) a30b372... - Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass (*) 347bbf4... - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass (*) b5e0539... Fix typo that causes a failure to update the common directo (*) e436824... - rebuild against perl 5.10.1 (*) 7440b81... - Mass rebuild with perl-5.12.0 (*) abcb68e... dist-git conversion (*) 694c622... sync with devel (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Set-Infinite/el4/master: 11/11] sync with devel
commit 694c62296cd62bc5de8295cd6317e142184df707 Merge: c6de05a abcb68e Author: Xavier Bachelot xav...@bachelot.org Date: Tue Aug 31 23:00:27 2010 +0200 sync with devel perl-Set-Infinite.spec | 36 sources|2 +- 2 files changed, 33 insertions(+), 5 deletions(-) --- -- 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: Proprietary search engines
On Tue, 2010-08-31 at 16:59 -0400, Matt McCutchen wrote: On Tue, 2010-08-31 at 08:27 -0700, Adam Williamson wrote: It doesn't seem to be an unavoidable requirement, it says: If you proposed Start/Home Page is not similar to the existing Firefox Start Page, please be prepared to provide a rationale for the change, and how it would benefit the end-user. I think we could manage such a rationale. We can definitely make a rationale for having a bunch of Fedora resources on the start page, but our rationale for omitting a Google search box, it's redundant and promotes a proprietary service, is not a line of reasoning I would expect Mozilla to accept. Then again, they may calculate that they are better off compromising on this issue in order to keep Fedora using their trademarks. 'It's redundant' seems fairly reasonable to me. IIRC, the presence of a search box on the start page is a hangover from when there *wasn't* one in the browser chrome by default. -- 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
[perl-Set-Infinite/el5/master] (11 commits) ...sync with devel
Summary of changes: 2d5e5a8... Use fixperms macro instead of our own chmod incantation. BR (*) 8fcf13e... - Adjust License-tag. - BR: perl(Test::More) (BZ 419631). (*) e278ad7... new perl (*) 92b56d0... Update to 0.63. (*) a30b372... - Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass (*) 347bbf4... - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass (*) b5e0539... Fix typo that causes a failure to update the common directo (*) e436824... - rebuild against perl 5.10.1 (*) 7440b81... - Mass rebuild with perl-5.12.0 (*) abcb68e... dist-git conversion (*) 8ba0682... sync with devel (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Set-Infinite/el5/master: 11/11] sync with devel
commit 8ba06820b461a5c800311c1aff83c66feceb2fb1 Merge: 7fca267 abcb68e Author: Xavier Bachelot xav...@bachelot.org Date: Tue Aug 31 22:58:39 2010 +0200 sync with devel perl-Set-Infinite.spec | 36 sources|2 +- 2 files changed, 33 insertions(+), 5 deletions(-) --- -- 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: Proprietary search engines
On Tuesday, August 31, 2010, 4:59:27 PM, Matt wrote: On Tue, 2010-08-31 at 08:27 -0700, Adam Williamson wrote: It doesn't seem to be an unavoidable requirement, it says: If you proposed Start/Home Page is not similar to the existing Firefox Start Page, please be prepared to provide a rationale for the change, and how it would benefit the end-user. I think we could manage such a rationale. We can definitely make a rationale for having a bunch of Fedora resources on the start page, but our rationale for omitting a Google search box, it's redundant and promotes a proprietary service, is not a line of reasoning I would expect Mozilla to accept. Then again, they may calculate that they are better off compromising on this issue in order to keep Fedora using their trademarks. -- Matt Personally, I _DO_ want to have something close to the standard Google search pages as my home page. On my XP systems, I use the standard Mozilla start page. Put too much crap on there (and yes, if I do not want to look for a Fedora resource, too much additional information WILL fit that classification), and I will change the Fedora start page to either the standard Mozilla page or just www.google.ca with just a few keystrokes. At that point, you have lost me as an audience, unless I specifically decide to use the handy Fedora bookmarks provided. Shocking? No. I want to use my computer, and most of the time I bring up a browser session to do searches, or use a bookmark on my toolbar. Stupid UI innovations like hiding my toolbar in the FF 4 beta are quickly reverted to the way _I_ want my browser. Please do not ignore that the browser is there for the user to use, not for Fedora to stream information in spite of the user's wishes. This is Linux, not some Microsoft (or Apple) we know what is best for you system. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: kernel maintainers - please review and commit patch in #528232
On Mon, Aug 30, 2010 at 08:50:01PM -0400, Jarod Wilson wrote: On Mon, Aug 30, 2010 at 5:53 PM, Marius Andreiana marius.andreia...@gmail.com wrote: Hi all, There's a long standing bug which prevents FC14 to boot on most EFI systems : https://bugzilla.redhat.com/show_bug.cgi?id=528232 Would a knowledgeable kernel developer please review the patch for drivers/video/efifb.c and commit it? https://bugzilla.redhat.com/show_bug.cgi?id=528232#c37 is in fact authored by one of the Fedora kernel maintainers, so it would seem they're already on it. Looks like Chuck missed it, I just committed it to F-14. regards, Kyle -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proprietary search engines
On Tue, Aug 31, 2010 at 17:20:23 -0400, Al Dunsmuir al.dunsm...@sympatico.ca wrote: Please do not ignore that the browser is there for the user to use, not for Fedora to stream information in spite of the user's wishes. Nor for Mozilla to track its users. There shouldn't be a start page at all as it opens a connection back to the start page server before you (easily) have a chance to disable it. It is especially annoying that that after updates you still get some Mozilla update page (that at fisrt glance appears to be from a remote server, though maybe there is some trickery going on) even though the start page is disabled. I would think respecting the privacy of our users would be a good reason for having no start page the default. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 4:07 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2010-08-31 at 15:56 -0400, Matthew Miller wrote: On Tue, Aug 31, 2010 at 01:26:27PM -0400, Arthur Pemberton wrote: Maybe I was too long winded, or failed to communicate my point: a stable (bug fix only updates, slow feature release), strongly FOSS, strongly upstream seems to be what some (I am not going to make assumptions about numbers) want. I see two problems with this: Where, keep in mind, slow is defined as twice a year, right? 1) the nature of such a distro would make it attractive to a smaller percentage of the Linux community Do you have a basis for this claim? I think it's the opposite. 2) the only aspect of that that would be unique is the commitment to upstream -- something which will be appreciated by few I don't think that's fair at all. Fedora is unique in a lot of ways, and a waterfall of updates isn't essential to that uniqueness. Arthur's idea was better expressed in his original mail. His point was that a Fedora aiming at the niche described (by Jesse) would differ from Ubuntu solely in its more rigorous interpretation of 'freedom' and its attention to upstream, which experience seems to show are not things the majority of people who go for the Ubuntu niche care much about. I think this is a pretty reasonable thesis - note how popular non-free software is with Ubuntu users, how many people use Mint (which is essentially Ubuntu with even more non-free stuff added), and how few people use/used the more-strictly-free Ubuntu variations that have existed. As he put it, I am suggesting that the mission you would like is contradictory: not that it cannot happen, but in that it represents an intersection of people that is very small. The niche described is a kind of mix of attributes that appeal to entirely different types of users/contributors. Exactly, the key idea is The niche described is a kind of mix of attributes that appeal to entirely different types of users/contributors. It is an admirable goal to push for, even it it may nto reflect my own desires. However, I believe that it may be analogous to selling vegan dishes at a butcher shop. -- Fedora 13 (www.pembo13.com) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proprietary search engines
On Tue, 2010-08-31 at 16:30 -0500, Bruno Wolff III wrote: On Tue, Aug 31, 2010 at 17:20:23 -0400, Al Dunsmuir al.dunsm...@sympatico.ca wrote: Please do not ignore that the browser is there for the user to use, not for Fedora to stream information in spite of the user's wishes. Nor for Mozilla to track its users. There shouldn't be a start page at all as it opens a connection back to the start page server before you (easily) have a chance to disable it. It is especially annoying that that after updates you still get some Mozilla update page (that at fisrt glance appears to be from a remote server, though maybe there is some trickery going on) even though the start page is disabled. The update page is remote. If you want to disable it, set startup.homepage_override_url to the empty string. There is also startup.homepage_welcome_url for the first run of the browser. I'm not commenting on what the default should be. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proprietary search engines
On Tue, Aug 31, 2010 at 17:46:53 -0400, Matt McCutchen m...@mattmccutchen.net wrote: The update page is remote. If you want to disable it, set startup.homepage_override_url to the empty string. There is also startup.homepage_welcome_url for the first run of the browser. Thanks! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Minutes/Summary of today's FESCo meeting (2010-08-31)
=== #fedora-meeting: FESCO (2010-08-31) === Meeting started by nirik at 19:30:01 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-08-31/fesco.2010-08-31-19.30.log.html Meeting summary --- * init process (nirik, 19:30:01) * mclasen said he would be a bit late. (nirik, 19:30:53) * #351 Create a policy for updates - status report on implementation (nirik, 19:32:02) * #382 Implementing Stable Release Vision (nirik, 19:35:34) * LINK: https://fedoraproject.org/w/index.php?title=User%3AAjax%2FStable_Release_Policydiff=195012oldid=194074 (ajax, 19:35:45) * LINK: https://fedoraproject.org/wiki/User:Ajax/Stable_Release_Policy (ajax, 19:42:04) * ACTION: ajax to add to the draft and fold in other updates critera. (nirik, 20:05:55) * ACTION: SMParrish to talk to KDE sig and see if we can come up with a process that will work for them and the new policy. (nirik, 20:06:20) * AGREED: Will send out a devel-announce post to clarify to maintainers that where possible they should also build for rawhide when doing f14 builds. (nirik, 20:36:52) * ACTION: kylem will send the email to devel-announce about rawhide builds. (nirik, 20:37:06) * #453 Fedora Annual User Survey (nirik, 20:38:56) * AGREED: jonmasters will ping the board and marketing about this and see if we can get something together. (nirik, 20:54:17) * #448 Disallow packages whose primary owner is group. (nirik, 20:55:50) * AGREED: will revisit this next week. (nirik, 21:08:14) * #455 gupnp-dlna bundled library exception (nirik, 21:09:12) * AGREED: will talk to gstreamer maintainer and revisit next week. (nirik, 21:17:37) * FES roundup (nirik, 21:18:49) * LINK: https://fedorahosted.org/fedora-engineering-services/report/6 (nirik, 21:19:05) * LINK: https://bugzilla.redhat.com/showdependencytree.cgi?id=596849hide_resolved=1 is the f14 one. (nirik, 21:21:55) * ACTION: nirik will file rel-eng ticket about the FTBFS processing. (nirik, 21:33:10) * ACTION: will ask mdomsch to re-run his suite and revisit next week. (nirik, 21:33:26) * Open Floor (nirik, 21:33:30) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=628695 Id like FESCo to handle that bug, not me :) (Oxf13, 21:49:21) Meeting ended at 21:50:41 UTC. Action Items * ajax to add to the draft and fold in other updates critera. * SMParrish to talk to KDE sig and see if we can come up with a process that will work for them and the new policy. * kylem will send the email to devel-announce about rawhide builds. * nirik will file rel-eng ticket about the FTBFS processing. * will ask mdomsch to re-run his suite and revisit next week. -- 19:30:01 nirik #startmeeting FESCO (2010-08-31) 19:30:01 zodbot Meeting started Tue Aug 31 19:30:01 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:30:01 zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:30:01 nirik #meetingname fesco 19:30:01 zodbot The meeting name has been set to 'fesco' 19:30:01 nirik #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59 19:30:01 nirik #topic init process 19:30:01 zodbot Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones 19:30:07 * kylem waves. 19:30:10 * pjones is here 19:30:14 * SMParrish here 19:30:53 nirik #info mclasen said he would be a bit late. 19:31:43 nirik I guess we have 5, so we can go ahead and get started... 19:32:02 nirik #topic #351 Create a policy for updates - status report on implementation 19:32:03 nirik .fesco 351 19:32:04 zodbot nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351 19:32:18 nirik so, all of this is done except for autoqa. Should we leave it open until thats in place? 19:32:50 nirik Thinking about it, I was wondering if we couldn't make a Updates_Policy page that has all this info and the stuff from the next ticket and so forth. 19:32:53 nirik all in one place. 19:33:48 nirik thoughts? opinions? 19:33:59 notting might be simpler that way 19:34:03 pjones I don't know if it's worth closing it; we'd just open another ticket about autoqa 19:34:07 SMParrish Leave it open until AutoQA is in place. 19:34:15 pjones but yeah, a wiki page for UpdatesPolicy seems like a good idea 19:34:19 kylem sounds reasonable, i'll write up a wiki page 19:34:49 ajax (here now) 19:35:18 nirik I'd like to see all the updates policy stuff in one place we can point people to... instead of about 5 pages with weird names. ;) 19:35:30 nirik but, lets go on to the next ticket: 19:35:34 nirik #topic #382 Implementing Stable Release Vision 19:35:34 nirik .fesco 382 19:35:35 zodbot nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/382 19:35:45 ajax
Re: fedora mission (was Re: systemd and changes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/31/10 9:40 AM, Thomas Moschny wrote: 2010/8/31 Jesse Keating jkeat...@j2solutions.net: An update that changes behavior for the end user would never be acceptable as an update to a stable release. Only severe exceptions should be made to this rule, where the time/effort to backport the important fixes from a new upstream release are cost prohibitive and too complicated to do on our own. An update that does not change behavior for the end user is ... not meaningful. Ok, fair point. change behavior is too vague here. I'm trying to draw a difference between fixing a bug (which would change the behavior) and changing things as an enhancement or a re-write, or whatever you want to call it. That is if a user is used to interacting with an application in one way that is not somehow taking advantage of a flaw, an update that comes along and changes the way a user has to interact with that software, that is what I wish to avoid. Surprise is not good, one doesn't expect to have to re-discover applications and work flows after applying vendor provided updates for a stable release. Any update changes something, otherwise it would not have been issued. And sometimes it is not at all clear if that change is welcome or not. A bug fix might be in most cases, but could also mean some work to the end user as well, like removing a workaround. We should accept that people have different expectations, and draw different lines in the trade of getting new bug fixes and new features vs. coping with breakage and changed behavior. People might even have different expectations from package to package. If we decide to draw that line at a fixed point, distribution-wide, we'll lose people, inevitably. So lets try to come up with ideas how to satisfy both (or even more than two) needs. Making categories (critical packages vs. non-critical packages) is a good step in the right direction, as well as more than one repository. If there are issues the build system or the packaging tools cannot handle, good, that is a technical problem and can be solved. We're not here for politics, are we? - Thomas I'm not proposing a iron clad rule. I'm proposing a default way of treating our updates and users. Exceptions to the default can be made, and in some cases must be made. I'm arguing though to default on the side of keeping a release consistent and stable throughout the life of the release. - -- 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/ iEYEARECAAYFAkx9fp4ACgkQ4v2HLvE71NU0YwCguxeBjFNq4+qMk7JsMhwvSGGp MSYAn2RhPBPneRTB4wHztHq3TfbxwK3B =eE3d -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
fedpkg prep
Just curious Why does 'fedpkg prep' care that the repo is in an inconsistent state? I just did a rebase to the latest f14 code on a private branch. So yes he repo in an inconsistent but that is ok. I'm going to make some changes to put it back in a consistent state but I can not do that without a source tree. So is there a way to do what the old 'make prep' did? That is stupidity untar the tarball an apply all the current patch without checking any state?? tia, steved. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proprietary search engines
On Tue, 2010-08-31 at 17:20 -0400, Al Dunsmuir wrote: Please do not ignore that the browser is there for the user to use, not for Fedora to stream information in spite of the user's wishes. This is Linux, not some Microsoft (or Apple) we know what is best for you system. Al I couldn't have summed it up better myself. That's exactly right. The browser is there for the user sitting at his desk and staring at the screen. The user. And Fedora considering forcing and flooding the home page with their own informational crap, 90% of it probably useless, makes us just as bad as Google. Don't you think it's kind of hypocritical? I can see the many valid points that have been made with this discussion, but to me it seems a bit tacky to even be discussing the issue to this degree. And I revert from using the term issue because I sincerely don't believe there is one. I think many here are forgetting that Google is our friend. And Google Inc. as a company not only support free and open source software but they are also part of that very community and have done their fair share for the FOSS community over the years. And when you think about it, sure Google Search is proprietary code and all, but it's pretty amazing what Google let you do with their tools and apps, all for free! I'm sure an exception can be made for such a small thing. Google Inc. seems to be treated as an enemy of FOSS here, but they're not. And I think it's disgraceful that's how you're all painting a unsubstantiated target on them. My solution to a problem that never was; amend the policy guidelines and move on to some more serious issues. Regards -- Chris Jones chrisjo...@comcen.com.au -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg prep
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/31/10 3:48 PM, Steve Dickson wrote: Just curious Why does 'fedpkg prep' care that the repo is in an inconsistent state? I just did a rebase to the latest f14 code on a private branch. So yes he repo in an inconsistent but that is ok. I'm going to make some changes to put it back in a consistent state but I can not do that without a source tree. So is there a way to do what the old 'make prep' did? That is stupidity untar the tarball an apply all the current patch without checking any state?? tia, steved. It only cares in that the prep function is a function of the PackageModule class. When we create an object of the PackageModule class, we also create an object for the git repo. It's when trying to create the object for the git repo that git is returning us an error, which we are passing along. It doesn't have anything to do with prep itself, any action which would necessitate creating the PackageModule object would run into this issue. Couple things I've been thinking about. We could delay creating the git object unless calling a function that requires it. We could move some of the rpm commands out of the PacakgeModule class. We could catch this and not care unless we are doing a git action. Either way, in this case your git repo does seem kinda broken, and you might want to fix that. - -- 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/ iEYEARECAAYFAkx9lAoACgkQ4v2HLvE71NWUngCgvSQ6uKm1Zztq8Vfc4ZcYjiSo bkgAn2SbhO4ppPMfttp3+y0JhXzyaHT8 =N/Xk -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg prep
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/31/10 4:45 PM, Jesse Keating wrote:
On 8/31/10 3:48 PM, Steve Dickson wrote:
Just curious
Why does 'fedpkg prep' care that the repo is in an inconsistent state?
I just did a rebase to the latest f14 code on a private branch.
So yes he repo in an inconsistent but that is ok. I'm going to
make some changes to put it back in a consistent state but
I can not do that without a source tree.
So is there a way to do what the old 'make prep' did? That is
stupidity untar the tarball an apply all the current patch
without checking any state??
tia,
steved.
It only cares in that the prep function is a function of the
PackageModule class. When we create an object of the PackageModule
class, we also create an object for the git repo. It's when trying to
create the object for the git repo that git is returning us an error,
which we are passing along. It doesn't have anything to do with prep
itself, any action which would necessitate creating the PackageModule
object would run into this issue.
Couple things I've been thinking about. We could delay creating the git
object unless calling a function that requires it. We could move some
of the rpm commands out of the PacakgeModule class. We could catch this
and not care unless we are doing a git action.
Either way, in this case your git repo does seem kinda broken, and you
might want to fix that.
Ah, in this case we do need info from the git repo, such as which branch
you are on, so that we can correctly fill in the macros that might be in
the spec such as %{?dist}, %{?fedora}, %{?fc14}, etc.. So yeah, I don't
know if I can actually fix this particular issue.
- --
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/
iEYEARECAAYFAkx9lWYACgkQ4v2HLvE71NUPNwCgvyyLotFw1I7CcNqAx0K4xYaE
RsIAn3Q3ulyjmAlknnjK25AioDA26fW5
=iVSX
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [kernel/f14/master] add in patch from lmacken to support more mac models with efifb
On Tue, Aug 31, 2010 at 05:58:49PM -0400, Luke Macken wrote: Thanks for taking care of this, Kyle. Should I send this patch upstream? if so, 1 patch per hardware? do/should I get sign-off's? Ideally, yes, you'll want to email the maintainer something like: From: Luke ... Subject: [PATCH] efifb: support new mac models ... To: The Maintainer Cc: linux-ker...@vger.kernel.org Add support for various new mac models, information from various user submissions. Signed-off-by: Luke Macken ... ... (anyone else in here) --- Diff in-line. --- I would imagine a roll-up of all the patches in one is fine, and probably preferably for the maintainer since it's less effort on their part. --Kyle -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg prep
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/31/10 5:16 PM, Steve Dickson wrote: I guess I don't understand why all this state is needed to simply lay down the tar ball and apply the current patches... The tar ball and patches have nothing to do with the version of Fedora or the state of a repo... To me, it seems like such a simple process that state or objects or whatever should not be needed... Because packages function differently (including what patches to apply) depending on Fedora / RHEL versions, etc.. These are discovered by reading the macros which may be in the spec files. Therefor we need to have those defined properly before we call rpm (the Makefile system did this too). The difference between the Make system and fedpkg is that the Make system relied upon the name of the directory you happened to be in, and a file in ../common/ that translated the directory name and figured out rpm defines. Since local clones can be in any directory you want, fedpkg cannot rely upon this. We need to know what remote branch your clone is tracking in order to determine what fedora you are targeting. That's why your git repo has to be in a healthy state. - -- 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/ iEYEARECAAYFAkx9nasACgkQ4v2HLvE71NVg7wCfWU/Mk5t/ExabTAkQzil23FA0 r+oAoLHXLjiyhS9QP5iiQdGXoq9+EjDi =Obiz -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg prep
Perhaps local and so forth could be given a --dist=foo switch, and these sorts of errors could say can't figure out your dist from git, use --dist or fix your repo. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
