From awilliam at redhat.com Fri May 1 00:53:48 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 30 Apr 2009 17:53:48 -0700 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <20090430234809.GA5813@srcf.ucam.org> References: <49F24B17.30602@redhat.com> <49F25D0D.8030304@gmail.com> <1240759385.6529.0.camel@localhost.localdomain> <1240762219.2770.9.camel@localhost.localdomain> <1241027428.3139.9.camel@localhost.localdomain> <939dd5750904301050o4efb3efau356882109b2e206b@mail.gmail.com> <1241116151.32113.273.camel@adam.local.net> <939dd5750904301208l19123893rc9cd68609f8980be@mail.gmail.com> <49F9FD08.9010904@redhat.com> <20090430234809.GA5813@srcf.ucam.org> Message-ID: <1241139228.32113.397.camel@adam.local.net> On Fri, 2009-05-01 at 00:48 +0100, Matthew Garrett wrote: > It's not about smart versus dumb. If we trust these people then we > have > to assume that in most cases they *will* know better than people who > argue against them on mailing lists. And if we don't trust them then > there's something pretty fundamentally wrong with the way we're > producing this distribution. I think the problem in this case is that they're considering the purity of their system over the quality of the product of which it forms a part. The significant objection on the part of the desktop team is that it's bad UI to have two volume controls as part of the desktop. i.e., they have a policy that it's good UI to have one application per function, this breaks that, therefore it's bad UI, therefore it's bad. There's a perfectly good logic to their thought process. The problem is it doesn't go far enough. It stops at "bad UI == bad", but that isn't always true. I think everyone advocating this change agrees that it's bad UI. It's never been presented as anything but a stopgap measure. But the issue is that, in this case, the bad UI produces a better *product*, in terms of an actual desktop operating system which we are releasing very shortly. The desktop team are thinking about their ongoing process of developing a desktop, and from that point of view, suddenly throwing in a legacy mixer application because they haven't quite finished twiddling the problems out of the new one yet is nuts. Unfortunately, we're not shipping an ongoing process of developing a desktop, we're shipping a *point release of a desktop operating system*, with all the expectations that are attached to that. Including the ability to perform really basic configuration of sound devices from a graphical interface. if you look at things from the context of the Fedora product, not from the perspective of the GNOME design process, providing only the new gnome-volume-control in Fedora 11 is a painfully obvious regression in functionality. This is clearly what our friends at Ubuntu think, given that quite late in their release cycle, they dropped the new gnome-volume-control in favour of gst-mixer *by default* (a much more invasive change than is being proposed here). They made this change on March 3rd, 2009, and have since shipped with it. I haven't seen any complaints about it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From mjg at redhat.com Fri May 1 01:56:16 2009 From: mjg at redhat.com (Matthew Garrett) Date: Fri, 1 May 2009 02:56:16 +0100 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <1241139228.32113.397.camel@adam.local.net> References: <1240759385.6529.0.camel@localhost.localdomain> <1240762219.2770.9.camel@localhost.localdomain> <1241027428.3139.9.camel@localhost.localdomain> <939dd5750904301050o4efb3efau356882109b2e206b@mail.gmail.com> <1241116151.32113.273.camel@adam.local.net> <939dd5750904301208l19123893rc9cd68609f8980be@mail.gmail.com> <49F9FD08.9010904@redhat.com> <20090430234809.GA5813@srcf.ucam.org> <1241139228.32113.397.camel@adam.local.net> Message-ID: <20090501015616.GA8328@srcf.ucam.org> On Thu, Apr 30, 2009 at 05:53:48PM -0700, Adam Williamson wrote: > The problem is it doesn't go far enough. It stops at "bad UI == bad", > but that isn't always true. I think everyone advocating this change > agrees that it's bad UI. It's never been presented as anything but a > stopgap measure. But the issue is that, in this case, the bad UI > produces a better *product*, in terms of an actual desktop operating > system which we are releasing very shortly. Does it? The desktop team would presumably assert that the cost of the reduced user experience and increased user confusion is sufficient to make the product *worse* than it would without shipping two mixers. There's no absolute truth here, so the question isn't which option is worse. The question is who we trust to make that decision. > This is clearly what our friends at Ubuntu think, given that quite late > in their release cycle, they dropped the new gnome-volume-control in > favour of gst-mixer *by default* (a much more invasive change than is > being proposed here). They made this change on March 3rd, 2009, and have > since shipped with it. I haven't seen any complaints about it. Having been a part of the Ubuntu decision making process, I think using Ubuntu as any sort of comparison here weakens the argument. We're talking about the distribution that shipped compiz by default 18 months ago, desite it clearly being a regression in a huge number of different ways. Having said that, there are ways in which the Ubuntu decision is a better one than ours. It's less flying-car future, but there's no regression and no additional user confusion. I've personally got no objection to FESCO overruling a decision on technical grounds and forcing a reversion to the previous status quo (or whatever else is available under the contingency plans), but the compromise we've ended up with here looks awfully like a baby that's been cut in half. -- Matthew Garrett | mjg59 at srcf.ucam.org From awilliam at redhat.com Fri May 1 02:16:38 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 30 Apr 2009 19:16:38 -0700 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <20090501015616.GA8328@srcf.ucam.org> References: <1240759385.6529.0.camel@localhost.localdomain> <1240762219.2770.9.camel@localhost.localdomain> <1241027428.3139.9.camel@localhost.localdomain> <939dd5750904301050o4efb3efau356882109b2e206b@mail.gmail.com> <1241116151.32113.273.camel@adam.local.net> <939dd5750904301208l19123893rc9cd68609f8980be@mail.gmail.com> <49F9FD08.9010904@redhat.com> <20090430234809.GA5813@srcf.ucam.org> <1241139228.32113.397.camel@adam.local.net> <20090501015616.GA8328@srcf.ucam.org> Message-ID: <1241144198.3751.5.camel@adam.local.net> On Fri, 2009-05-01 at 02:56 +0100, Matthew Garrett wrote: > On Thu, Apr 30, 2009 at 05:53:48PM -0700, Adam Williamson wrote: > > > The problem is it doesn't go far enough. It stops at "bad UI == bad", > > but that isn't always true. I think everyone advocating this change > > agrees that it's bad UI. It's never been presented as anything but a > > stopgap measure. But the issue is that, in this case, the bad UI > > produces a better *product*, in terms of an actual desktop operating > > system which we are releasing very shortly. > > Does it? The desktop team would presumably assert that the cost of the > reduced user experience and increased user confusion is sufficient to > make the product *worse* than it would without shipping two mixers. > There's no absolute truth here, so the question isn't which option is > worse. The question is who we trust to make that decision. Interestingly, I haven't seen anyone flat out make that assertion. I don't see how it could possibly stand up, either. I mean, the alternative they're arguing for is to stick with the current state: a release note advising people to use alsamixer. So instead of having two graphical interfaces, they're apparently happier to have one graphical interface and one obscure and extremely user-unfriendly curses interface. I really can't quite grok how that's better. Believe me, alsamixer is user-unfriendly. I have several years of experience of advising people to use it. I started out saying "oh, just run alsamixer and do XYZ..." After aforesaid years of bitter experience, I now say something like "run alsamixer. You might need to do alsamixer -c0 or -c1 or -c2 or -c3, it depends how many cards you have. You can scroll to the right by pressing the right arrow a lot of times to see more controls, even though there's no scrollbar indicating this. You toggle inputs on and off by pressing space, but you flip switches by pressing m. To get to the capture inputs you either run alsamixer with -Vcapture, or hit tab after running it." I'm just at a loss to try and grok how this is considered preferable to an alternative graphical mixer. Where's the win? > Having said that, there are ways in which the Ubuntu decision is a > better one than ours. It's less flying-car future, but there's no > regression and no additional user confusion. I've personally got no > objection to FESCO overruling a decision on technical grounds and > forcing a reversion to the previous status quo (or whatever else is > available under the contingency plans), but the compromise we've ended > up with here looks awfully like a baby that's been cut in half. I don't really think so. We all seem to agree that the new mixer interface is The Future and should suffice for most people, but not for a significant minority. We want people using the new mixer interface to make sure it's ready ASAP. So making it the default that most people will encounter and be happy with, but having a relatively easy-to-discover fallback for those whose needs aren't covered, seems sensible to me. Given the choice between reverting to the old g-v-c by default or this compromise, I'd probably choose the compromise. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From mzerqung at 0pointer.de Fri May 1 02:32:36 2009 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Fri, 1 May 2009 04:32:36 +0200 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <20090501015616.GA8328@srcf.ucam.org> References: <1240759385.6529.0.camel@localhost.localdomain> <1240762219.2770.9.camel@localhost.localdomain> <1241027428.3139.9.camel@localhost.localdomain> <939dd5750904301050o4efb3efau356882109b2e206b@mail.gmail.com> <1241116151.32113.273.camel@adam.local.net> <939dd5750904301208l19123893rc9cd68609f8980be@mail.gmail.com> <49F9FD08.9010904@redhat.com> <20090430234809.GA5813@srcf.ucam.org> <1241139228.32113.397.camel@adam.local.net> <20090501015616.GA8328@srcf.ucam.org> Message-ID: <20090501023236.GA20018@tango.0pointer.de> On Fri, 01.05.09 02:56, Matthew Garrett (mjg at redhat.com) wrote: > > This is clearly what our friends at Ubuntu think, given that quite late > > in their release cycle, they dropped the new gnome-volume-control in > > favour of gst-mixer *by default* (a much more invasive change than is > > being proposed here). They made this change on March 3rd, 2009, and have > > since shipped with it. I haven't seen any complaints about it. > > Having been a part of the Ubuntu decision making process, I think using > Ubuntu as any sort of comparison here weakens the argument. We're > talking about the distribution that shipped compiz by default 18 months > ago, desite it clearly being a regression in a huge number of different > ways. Also, the comparison with Ubuntu stinks anyway. They had an earlier freeze than we did. They were looking at an earlier version of the new g-v-c. And the based their distro on PA 0.9.14, however the new g-v-c is designed for 0.9.15 which was quite a big update. After all, it's *we* who do the development. Both Bastien and I follow the Fedora release cycle for our development. Since Ubuntu is not doing any development in this area it is very likely that they'll continue to be a few steps behind us unless they'd sync their releases to the Fedora releases. So all in all, comparing Ubuntu and Fedora here is comparing apples and oranges. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From awilliam at redhat.com Fri May 1 02:47:04 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 30 Apr 2009 19:47:04 -0700 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <20090501023236.GA20018@tango.0pointer.de> References: <1240759385.6529.0.camel@localhost.localdomain> <1240762219.2770.9.camel@localhost.localdomain> <1241027428.3139.9.camel@localhost.localdomain> <939dd5750904301050o4efb3efau356882109b2e206b@mail.gmail.com> <1241116151.32113.273.camel@adam.local.net> <939dd5750904301208l19123893rc9cd68609f8980be@mail.gmail.com> <49F9FD08.9010904@redhat.com> <20090430234809.GA5813@srcf.ucam.org> <1241139228.32113.397.camel@adam.local.net> <20090501015616.GA8328@srcf.ucam.org> <20090501023236.GA20018@tango.0pointer.de> Message-ID: <1241146024.3751.9.camel@adam.local.net> On Fri, 2009-05-01 at 04:32 +0200, Lennart Poettering wrote: > Also, the comparison with Ubuntu stinks anyway. They had an earlier freeze > than we did. They were looking at an earlier version of the new > g-v-c. And the based their distro on PA 0.9.14, however the new g-v-c > is designed for 0.9.15 which was quite a big update. I don't want to push this as it was just a point made in passing, but I think you're rather overstating the case there. Those aren't significant differences: they were faced with the same choice between the same two tools and considered the same issues we're considering. From the bug report: "what do you mean exactly there? why not using the new capplet in jaunty? look at the list of bugs, the new capplet can't control alsa directly or control other channel or enable numeric sources" they didn't choose on the basis of some trivial issue that was fixed in a newer g-v-c or pulseaudio; they chose because of the same issues we're considering. The current g-v-c in Fedora can't do any of those three things. (btw, the digital output issue is an interesting one. Presumably the PulseAudio folks will tell us that, if we want to switch from analog to digital output, we should use pavucontrol, right? So what's that? Two GUI applications to do the same thing...) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From mjg at redhat.com Fri May 1 02:47:12 2009 From: mjg at redhat.com (Matthew Garrett) Date: Fri, 1 May 2009 03:47:12 +0100 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <1241144198.3751.5.camel@adam.local.net> References: <1240762219.2770.9.camel@localhost.localdomain> <1241027428.3139.9.camel@localhost.localdomain> <939dd5750904301050o4efb3efau356882109b2e206b@mail.gmail.com> <1241116151.32113.273.camel@adam.local.net> <939dd5750904301208l19123893rc9cd68609f8980be@mail.gmail.com> <49F9FD08.9010904@redhat.com> <20090430234809.GA5813@srcf.ucam.org> <1241139228.32113.397.camel@adam.local.net> <20090501015616.GA8328@srcf.ucam.org> <1241144198.3751.5.camel@adam.local.net> Message-ID: <20090501024712.GA8817@srcf.ucam.org> On Thu, Apr 30, 2009 at 07:16:38PM -0700, Adam Williamson wrote: > On Fri, 2009-05-01 at 02:56 +0100, Matthew Garrett wrote: > > Does it? The desktop team would presumably assert that the cost of the > > reduced user experience and increased user confusion is sufficient to > > make the product *worse* than it would without shipping two mixers. > > There's no absolute truth here, so the question isn't which option is > > worse. The question is who we trust to make that decision. > > Interestingly, I haven't seen anyone flat out make that assertion. > > I don't see how it could possibly stand up, either. I mean, the > alternative they're arguing for is to stick with the current state: a > release note advising people to use alsamixer. So instead of having two > graphical interfaces, they're apparently happier to have one graphical > interface and one obscure and extremely user-unfriendly curses > interface. I really can't quite grok how that's better. The basic counterargument is that providing two mixers in the menu is a cost to every user of Fedora. This cost is being justified on the basis that the cost to some unknown number (but assumed to be a minority) of Fedora users of *not* having that mixer is large. We have no numbers to attach to any of these costs or the proportion of the user base affected. The people in the best position to make judgements about those costs are the desktop team. They've got more experience in this field than you, me or pretty much anyone else on this list. If they make an assertion about these weightings then I'm not going to feel in a position to argue against that until I've got some numbers, just as I'd be inclined to ignore them completely if they started contradicting me on power management issues without providing some numbers. Why do you feel differently? > Believe me, alsamixer is user-unfriendly. I have several years of > experience of advising people to use it. I started out saying "oh, just > run alsamixer and do XYZ..." After aforesaid years of bitter experience, > I now say something like "run alsamixer. You might need to do alsamixer > -c0 or -c1 or -c2 or -c3, it depends how many cards you have. You can > scroll to the right by pressing the right arrow a lot of times to see > more controls, even though there's no scrollbar indicating this. You > toggle inputs on and off by pressing space, but you flip switches by > pressing m. To get to the capture inputs you either run alsamixer with > -Vcapture, or hit tab after running it." > > I'm just at a loss to try and grok how this is considered preferable to > an alternative graphical mixer. Where's the win? I don't think anyone's actually argued against there being a separate graphical mixer. I think they've argued fairly strongly against it being in the menu by default. But I think you're asking the wrong question. The right question is "Who is going to need to run this program", and the followup question is "And what kind of interface do *those people* need?". If a large number of naive users need to run gst-mixer then we've already failed badly. Adding it to a menu doesn't fix that. If the users who need this functionality tend towards being advanced then the nature of the UI is less important than the functionality is exposes. > > Having said that, there are ways in which the Ubuntu decision is a > > better one than ours. It's less flying-car future, but there's no > > regression and no additional user confusion. I've personally got no > > objection to FESCO overruling a decision on technical grounds and > > forcing a reversion to the previous status quo (or whatever else is > > available under the contingency plans), but the compromise we've ended > > up with here looks awfully like a baby that's been cut in half. > > I don't really think so. We all seem to agree that the new mixer > interface is The Future and should suffice for most people, but not for > a significant minority. We want people using the new mixer interface to > make sure it's ready ASAP. So making it the default that most people > will encounter and be happy with, but having a relatively > easy-to-discover fallback for those whose needs aren't covered, seems > sensible to me. Given the choice between reverting to the old g-v-c by > default or this compromise, I'd probably choose the compromise. How is the user supposed to work out which is the fallback? Intuit it from the fact that only one of the two seemingly equivalent choices in the menu is started from the panel applet? How does the user work out what the interaction between these two applications is? How do you prevent the users who have a working pulseaudio setup from finding gst-mixer and then breaking their systems? How do they recover once they've done so? My somewhat arrogant assertion here is that unless you've been asking that sort of question then you don't understand all the issues involved in this decision. And that implies that your opinion on the matter is about as relevant as my opinion on QA workflows. That doesn't mean that you have no input on the matter. Providing well documented descriptions of failures or inadequacies in PA is helpful in ensuring that it ends up as a better project that fills as many of the needs of Fedora users as possible, but at some point you have to trust that software maintainers know what they're doing. And if what you've ended up with is something that the project as a whole doesn't find useful, then the best thing to do is to avoid using it rather than forcing UI changes upon an unwilling designer. -- Matthew Garrett | mjg59 at srcf.ucam.org From awilliam at redhat.com Fri May 1 03:38:23 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 30 Apr 2009 20:38:23 -0700 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <1241146024.3751.9.camel@adam.local.net> References: <1240759385.6529.0.camel@localhost.localdomain> <1240762219.2770.9.camel@localhost.localdomain> <1241027428.3139.9.camel@localhost.localdomain> <939dd5750904301050o4efb3efau356882109b2e206b@mail.gmail.com> <1241116151.32113.273.camel@adam.local.net> <939dd5750904301208l19123893rc9cd68609f8980be@mail.gmail.com> <49F9FD08.9010904@redhat.com> <20090430234809.GA5813@srcf.ucam.org> <1241139228.32113.397.camel@adam.local.net> <20090501015616.GA8328@srcf.ucam.org> <20090501023236.GA20018@tango.0pointer.de> <1241146024.3751.9.camel@adam.local.net> Message-ID: <1241149103.3751.42.camel@adam.local.net> On Thu, 2009-04-30 at 19:47 -0700, Adam Williamson wrote: > (btw, the digital output issue is an interesting one. Presumably the > PulseAudio folks will tell us that, if we want to switch from analog > to > digital output, we should use pavucontrol, right? So what's that? Two > GUI applications to do the same thing...) I rather want to amplify on this one, because I rather think I've hit a winner. :) what's pavucontrol? to quote rpm -q pavucontrol: "PulseAudio Volume Control (pavucontrol) is a simple GTK based volume control tool ("mixer") for the PulseAudio sound server." Why, it's a volume control tool! Isn't that exactly the same thing as gnome-volume-control? Isn't the whole objection to including gnome-alsamixer or gst-mixer that it's a terrible idea to install more than one volume control tool by default? Do we install pavucontrol by default? Why yes, yes we do. http://cvs.fedoraproject.org/viewvc/comps/comps-f11.xml.in?revision=1.210&view=markup there it is, right in the Sound and Video group, which is installed by default in the desktop spin (and the desktop spin doesn't override it out of there): pavucontrol so why do we do this kind of interface insanity? Why would we install *two* whole volume control applications for pulseaudio? Why, because pavucontrol exposes useful functionality that gnome-volume-control doesn't. Here's Lennart helpfully explaining to me in the initial bug report - 491372 - that selecting between analog and digital output isn't a problem, because PulseAudio handles it: "Adam, you are misunderstanding how SPDIF in ALSA works. The special device "spdif:" will toggle all mixer controls appropriately. It will hence work properly an all cards -- and if it doesn't it's an ALSA bug. Hence the profile logic PA exposes should provide *complete* SPDIF experience -- fiddling with low level alsa mixer controls should never be necessary." Note that "the profile logic PA exposes" makes "fiddling with low level alsa mixer controls" unnecessary. Great. But how is this profile logic exposed? Does gnome-volume-control do it? Why no, no it doesn't. You can't pick profiles with g-v-c. But that's okay! No problem! You can do it with pavucontrol, and that's installed by default! Soooo - it's fine to have pavucontrol and gnome-volume-control installed by default, because pavucontrol is an alternative graphical volume control application that exposes useful functionality which is not exposed by gnome-volume-control. However, the suggestion that an alternative graphical volume control application like gst-mixer or gnome-alsamixer should be installed by default because it'd expose useful functionality which is not exposed by gnome-volume-control is a terrible, terrible idea. It'll confuse people to death, and it only covers corner cases! Uhhh...okay. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From zaitcev at redhat.com Fri May 1 04:03:15 2009 From: zaitcev at redhat.com (Pete Zaitcev) Date: Thu, 30 Apr 2009 22:03:15 -0600 Subject: Orphaning azureus In-Reply-To: <200904301646.47342.konrad@tylerc.org> References: <200904301646.47342.konrad@tylerc.org> Message-ID: <20090430220315.7d9e4176.zaitcev@redhat.com> On Thu, 30 Apr 2009 16:46:47 -0700, Conrad Meyer wrote: > It's a steaming pile of crap, I don't use it personally, [] Do you suggest anything as a replacement? -- Pete From ivazqueznet at gmail.com Fri May 1 04:08:16 2009 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 01 May 2009 00:08:16 -0400 Subject: Orphaning azureus In-Reply-To: <20090430220315.7d9e4176.zaitcev@redhat.com> References: <200904301646.47342.konrad@tylerc.org> <20090430220315.7d9e4176.zaitcev@redhat.com> Message-ID: <1241150896.3894.70.camel@ignacio.lan> On Thu, 2009-04-30 at 22:03 -0600, Pete Zaitcev wrote: > On Thu, 30 Apr 2009 16:46:47 -0700, Conrad Meyer wrote: > > > It's a steaming pile of crap, I don't use it personally, [] > > Do you suggest anything as a replacement? Deluge and Transmission each have about 80-90% of Azureus's functionality. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From awilliam at redhat.com Fri May 1 04:08:59 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 30 Apr 2009 21:08:59 -0700 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <1241149103.3751.42.camel@adam.local.net> References: <1240759385.6529.0.camel@localhost.localdomain> <1240762219.2770.9.camel@localhost.localdomain> <1241027428.3139.9.camel@localhost.localdomain> <939dd5750904301050o4efb3efau356882109b2e206b@mail.gmail.com> <1241116151.32113.273.camel@adam.local.net> <939dd5750904301208l19123893rc9cd68609f8980be@mail.gmail.com> <49F9FD08.9010904@redhat.com> <20090430234809.GA5813@srcf.ucam.org> <1241139228.32113.397.camel@adam.local.net> <20090501015616.GA8328@srcf.ucam.org> <20090501023236.GA20018@tango.0pointer.de> <1241146024.3751.9.camel@adam.local.net> <1241149103.3751.42.camel@adam.local.net> Message-ID: <1241150939.3751.46.camel@adam.local.net> On Thu, 2009-04-30 at 20:38 -0700, Adam Williamson wrote: > Do we install pavucontrol by default? Why yes, yes we do. > > http://cvs.fedoraproject.org/viewvc/comps/comps-f11.xml.in?revision=1.210&view=markup > > there it is, right in the Sound and Video group, which is installed by > default in the desktop spin (and the desktop spin doesn't override it > out of there): I just checked, BTW - apparently we've been committing the UI error of installing two volume control applications by default since Fedora 8. pavucontrol is in the comps.xml file for F8, F9, and F10, along with gnome-media, which contains gnome-volume-control. Presumably the justification for this was that pavucontrol lets you control Pulse-related stuff that the old gnome-volume-control didn't. So, it's fine when Pulse wants to do it... Looking at my F10 system, I can find PulseAudio Volume Control in Foot menu / Sound & Video, while I find Volume Control in Foot menu / System / Preferences / Hardware. That's a nice clean UI, I suppose! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From lemenkov at gmail.com Fri May 1 04:32:32 2009 From: lemenkov at gmail.com (Peter Lemenkov) Date: Fri, 1 May 2009 08:32:32 +0400 Subject: Orphaning azureus In-Reply-To: <20090430220315.7d9e4176.zaitcev@redhat.com> References: <200904301646.47342.konrad@tylerc.org> <20090430220315.7d9e4176.zaitcev@redhat.com> Message-ID: 2009/5/1 Pete Zaitcev : > On Thu, 30 Apr 2009 16:46:47 -0700, Conrad Meyer wrote: > >> It's a steaming pile of crap, I don't use it personally, [] > > Do you suggest anything as a replacement? Deluge, transmission, etc - thousands of them! -- With best regards! From sundaram at fedoraproject.org Fri May 1 05:16:55 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 01 May 2009 10:46:55 +0530 Subject: Abandon "Default Desktop" In-Reply-To: <16de708d0904301051r647b9f14qc1fe7d343bdbd778@mail.gmail.com> References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <49F80664.6010809@robertoragusa.it> <1241037119.3213.2.camel@localhost.localdomain> <6c3f5e6c0904291514n371fa179k1901af657e05a5b5@mail.gmail.com> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <16de708d0904301051r647b9f14qc1fe7d343bdbd778@mail.gmail.com> Message-ID: <49FA85C7.8000607@fedoraproject.org> On 04/30/2009 11:21 PM, Arthur Pemberton wrote: > I think our understand of "prominently" differs. The get-fedora page > just has a link to the KDE page which is directed at KDE fans. If you want to give ideas on doing it or help in doing it better, step up and participate with the websites team. All these were discussed openly in the mailing lists and I didn't see you participating. >> I don't see why I shouldn't ask for Xfce and ratpoison >> as among the choices offered > > I'm not sure the XFCE devs would appreciate you equating their desktop > environment with a window manager. Where did I do that? You are just imagining things now. > It would make more sense for the Fedora Board to just come out and say > that they don't like anything but Gnome, and would prefer not to have > any resources go towards anything but Gnome. Because having > maintainers almost beg for a more equal access to potential users is > really kind of sad. Fedora Board cannot direct developers to do anything like that but the ground reality is that, there is much more resources in Fedora going into GNOME than any other desktop environment and that is not going to change anytime soon. Red Hat employs a lot more GNOME developers than on the KDE side and that development is reflected in Fedora as well KDE community in Fedora is very good but there is not enough volunteers in the Fedora community to keep pace with the new developments. You can see the effect of that everywhere. One example: KDE continues to include nm-applet for several releases now because the KDE equivalent is completely broken and has been for quite sometime. Not having a default desktop is not going to help fix such issues. Less fanboyism and more actual participation, please. Rahul From frankly3d at gmail.com Fri May 1 06:51:55 2009 From: frankly3d at gmail.com (Frank Murphy (Frankly3D)) Date: Fri, 01 May 2009 07:51:55 +0100 Subject: Orphaning azureus In-Reply-To: References: <200904301646.47342.konrad@tylerc.org> <20090430220315.7d9e4176.zaitcev@redhat.com> Message-ID: <49FA9C0B.9040808@gmail.com> On 01/05/09 05:32, Peter Lemenkov wrote: > 2009/5/1 Pete Zaitcev: >> On Thu, 30 Apr 2009 16:46:47 -0700, Conrad Meyer wrote: >> >>> It's a steaming pile of crap, I don't use it personally, [] >> Do you suggest anything as a replacement? > > Deluge, transmission, etc - thousands of them! > One with an hourly scheduler? Frank -- msn: frankly3d skype: frankly3d Still Learning From rc040203 at freenet.de Fri May 1 08:45:31 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 01 May 2009 10:45:31 +0200 Subject: Abandon "Default Desktop" In-Reply-To: <1241114354.7846.5.camel@localhost.localdomain> References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <49F80664.6010809@robertoragusa.it> <1241037119.3213.2.camel@localhost.localdomain> <6c3f5e6c0904291514n371fa179k1901af657e05a5b5@mail.gmail.com> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <16de708d0904301051r647b9f14qc1fe7d343bdbd778@mail.gmail.com> <1241114354.7846.5.camel@localhost.localdomain> Message-ID: <49FAB6AB.9060601@freenet.de> Jesse Keating wrote: > On Thu, 2009-04-30 at 12:51 -0500, Arthur Pemberton wrote: >> It would make more sense for the Fedora Board to just come out and say >> that they don't like anything but Gnome, and would prefer not to have >> any resources go towards anything but Gnome. Because having >> maintainers almost beg for a more equal access to potential users is >> really kind of sad. > > The board would likely never say that. However there are a large number > of Fedora resources that are focused on new technology and advancements > in the user experience. Most of this effort is focused on the Gnome > desktop. You are once again demonstrating your inability of not being able to keep RH and Fedora separate - RH is focused on Gnome. Fedora community devs actually are not focused on Gnome. From gbofspam at gmail.com Fri May 1 08:49:42 2009 From: gbofspam at gmail.com (Andrew Parker) Date: Fri, 1 May 2009 04:49:42 -0400 Subject: Abandon "Default Desktop" In-Reply-To: <49FA85C7.8000607@fedoraproject.org> References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <1241037119.3213.2.camel@localhost.localdomain> <6c3f5e6c0904291514n371fa179k1901af657e05a5b5@mail.gmail.com> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <16de708d0904301051r647b9f14qc1fe7d343bdbd778@mail.gmail.com> <49FA85C7.8000607@fedoraproject.org> Message-ID: <6c3f5e6c0905010149r34a2b311x5ccb2ac0b851ecf@mail.gmail.com> On Fri, May 1, 2009 at 1:16 AM, Rahul Sundaram wrote: > On 04/30/2009 11:21 PM, Arthur Pemberton wrote: > >> I think our understand of "prominently" differs. The get-fedora page >> just has a link to the KDE page which is directed at KDE fans. > > If you want to give ideas on doing it or help in doing it better, step > up and participate with the websites team. All these were discussed > openly in the mailing lists and I didn't see you participating. When did it become a requirement to have to fix something yourself in order to point out a problem? Is it ok with you if we raise bugzillas without assigning them to ourselves and fixing them too? From sundaram at fedoraproject.org Fri May 1 08:59:02 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 01 May 2009 14:29:02 +0530 Subject: Abandon "Default Desktop" In-Reply-To: <49FAB6AB.9060601@freenet.de> References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <49F80664.6010809@robertoragusa.it> <1241037119.3213.2.camel@localhost.localdomain> <6c3f5e6c0904291514n371fa179k1901af657e05a5b5@mail.gmail.com> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <16de708d0904301051r647b9f14qc1fe7d343bdbd778@mail.gmail.com> <1241114354.7846.5.camel@localhost.localdomain> <49FAB6AB.9060601@freenet.de> Message-ID: <49FAB9D6.6030203@fedoraproject.org> On 05/01/2009 02:15 PM, Ralf Corsepius wrote: > Jesse Keating wrote: >> On Thu, 2009-04-30 at 12:51 -0500, Arthur Pemberton wrote: >>> It would make more sense for the Fedora Board to just come out and say >>> that they don't like anything but Gnome, and would prefer not to have >>> any resources go towards anything but Gnome. Because having >>> maintainers almost beg for a more equal access to potential users is >>> really kind of sad. >> >> The board would likely never say that. However there are a large number >> of Fedora resources that are focused on new technology and advancements >> in the user experience. Most of this effort is focused on the Gnome >> desktop. > > You are once again demonstrating your inability of not being able to > keep RH and Fedora separate - RH is focused on Gnome. > > Fedora community devs actually are not focused on Gnome. Actually, I was explaining that Red Hat's focus on GNOME is naturally reflected in Fedora due to the amount of people working on Fedora from Red Hat. Your separation is artificial in this case. Rahul From sundaram at fedoraproject.org Fri May 1 09:01:47 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 01 May 2009 14:31:47 +0530 Subject: Abandon "Default Desktop" In-Reply-To: <6c3f5e6c0905010149r34a2b311x5ccb2ac0b851ecf@mail.gmail.com> References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <1241037119.3213.2.camel@localhost.localdomain> <6c3f5e6c0904291514n371fa179k1901af657e05a5b5@mail.gmail.com> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <16de708d0904301051r647b9f14qc1fe7d343bdbd778@mail.gmail.com> <49FA85C7.8000607@fedoraproject.org> <6c3f5e6c0905010149r34a2b311x5ccb2ac0b851ecf@mail.gmail.com> Message-ID: <49FABA7B.1040504@fedoraproject.org> On 05/01/2009 02:19 PM, Andrew Parker wrote: > On Fri, May 1, 2009 at 1:16 AM, Rahul Sundaram > wrote: >> On 04/30/2009 11:21 PM, Arthur Pemberton wrote: >> >>> I think our understand of "prominently" differs. The get-fedora page >>> just has a link to the KDE page which is directed at KDE fans. >> If you want to give ideas on doing it or help in doing it better, step >> up and participate with the websites team. All these were discussed >> openly in the mailing lists and I didn't see you participating. > > When did it become a requirement to have to fix something yourself in > order to point out a problem? Is it ok with you if we raise bugzillas > without assigning them to ourselves and fixing them too? Absolutely. Filing a bug reports means that the issue is reported in a place where everybody can track it and it reaches the people who can work on that problem. You also have the opportunity to participate in the discussions when it takes place. Bitching about it in the mailing list is a ineffective strategy however which was what I was pointing out. Rahul From rc040203 at freenet.de Fri May 1 09:08:59 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 01 May 2009 11:08:59 +0200 Subject: Abandon "Default Desktop" In-Reply-To: <49FAB9D6.6030203@fedoraproject.org> References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <49F80664.6010809@robertoragusa.it> <1241037119.3213.2.camel@localhost.localdomain> <6c3f5e6c0904291514n371fa179k1901af657e05a5b5@mail.gmail.com> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <16de708d0904301051r647b9f14qc1fe7d343bdbd778@mail.gmail.com> <1241114354.7846.5.camel@localhost.localdomain> <49FAB6AB.9060601@freenet.de> <49FAB9D6.6030203@fedoraproject.org> Message-ID: <49FABC2B.8050500@freenet.de> Rahul Sundaram wrote: > On 05/01/2009 02:15 PM, Ralf Corsepius wrote: >> Jesse Keating wrote: >>> On Thu, 2009-04-30 at 12:51 -0500, Arthur Pemberton wrote: >>>> It would make more sense for the Fedora Board to just come out and say >>>> that they don't like anything but Gnome, and would prefer not to have >>>> any resources go towards anything but Gnome. Because having >>>> maintainers almost beg for a more equal access to potential users is >>>> really kind of sad. >>> The board would likely never say that. However there are a large number >>> of Fedora resources that are focused on new technology and advancements >>> in the user experience. Most of this effort is focused on the Gnome >>> desktop. >> You are once again demonstrating your inability of not being able to >> keep RH and Fedora separate - RH is focused on Gnome. >> >> Fedora community devs actually are not focused on Gnome. > > Actually, I was explaining that Red Hat's focus on GNOME is naturally > reflected in Fedora due to the amount of people working on Fedora from > Red Hat. Your separation is artificial in this case. No. keating at RH's claim is simply wrong. He thinks @RH's objectives goals are identical to those of the community - He is plain wrong wrt. this. This doesn't invalidate the fact RH's predominance in Fedora-leadership and the amount of @RH's participating in Fedora shows effects. People like you and keating likely are too RH-streamlined and too close to RH to understand the importance of this consideration. From gbofspam at gmail.com Fri May 1 09:14:27 2009 From: gbofspam at gmail.com (Andrew Parker) Date: Fri, 1 May 2009 05:14:27 -0400 Subject: Abandon "Default Desktop" In-Reply-To: <49FABA7B.1040504@fedoraproject.org> References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <16de708d0904301051r647b9f14qc1fe7d343bdbd778@mail.gmail.com> <49FA85C7.8000607@fedoraproject.org> <6c3f5e6c0905010149r34a2b311x5ccb2ac0b851ecf@mail.gmail.com> <49FABA7B.1040504@fedoraproject.org> Message-ID: <6c3f5e6c0905010214x75a79082vf05c1bda57290166@mail.gmail.com> On Fri, May 1, 2009 at 5:01 AM, Rahul Sundaram wrote: > On 05/01/2009 02:19 PM, Andrew Parker wrote: >> On Fri, May 1, 2009 at 1:16 AM, Rahul Sundaram >> ?wrote: >>> On 04/30/2009 11:21 PM, Arthur Pemberton wrote: >>> >>>> I think our understand of "prominently" differs. The get-fedora page >>>> just has a link to the KDE page which is directed at KDE fans. >>> If you want to give ideas on doing it or help in doing it better, step >>> up and participate with the websites team. All these were discussed >>> openly in the mailing lists and I didn't see you participating. >> >> When did it become a requirement to have to fix something yourself in >> order to point out a problem? ?Is it ok with you if we raise bugzillas >> without assigning them to ourselves and fixing them too? > > Absolutely. Filing a bug reports means that the issue is reported in a > place where everybody can track it and it reaches the people who can > work on that problem. ?You also have the opportunity to participate in > the discussions when it takes place. Bitching about it in the mailing > list is a ineffective strategy however which was what I was pointing out. > >>>> I think our understand of "prominently" differs. The get-fedora page >>>> just has a link to the KDE page which is directed at KDE fans. that is bitching? I find it to be quite polite, and not at all bitchy or sanctimonious. From sundaram at fedoraproject.org Fri May 1 09:26:19 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 01 May 2009 14:56:19 +0530 Subject: Abandon "Default Desktop" In-Reply-To: <6c3f5e6c0905010214x75a79082vf05c1bda57290166@mail.gmail.com> References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <16de708d0904301051r647b9f14qc1fe7d343bdbd778@mail.gmail.com> <49FA85C7.8000607@fedoraproject.org> <6c3f5e6c0905010149r34a2b311x5ccb2ac0b851ecf@mail.gmail.com> <49FABA7B.1040504@fedoraproject.org> <6c3f5e6c0905010214x75a79082vf05c1bda57290166@mail.gmail.com> Message-ID: <49FAC03B.2000709@fedoraproject.org> On 05/01/2009 02:44 PM, Andrew Parker wrote: >>>>> I think our understand of "prominently" differs. The get-fedora page >>>>> just has a link to the KDE page which is directed at KDE fans. > > that is bitching? I find it to be quite polite, and not at all bitchy > or sanctimonious. I wasn't referring to that in particular but the general trend of comments about the website from the KDE focused people. I picked one mail to reply from that instead of replying to each and every one separately but the point remains the same. If you have comments on the website, file a bug report, post mockups or find other ways to work with the website team. http://fedoraproject.org/wiki/Websites/ShowUs Rahul From sundaram at fedoraproject.org Fri May 1 09:31:20 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 01 May 2009 15:01:20 +0530 Subject: Abandon "Default Desktop" In-Reply-To: <49FABC2B.8050500@freenet.de> References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <49F80664.6010809@robertoragusa.it> <1241037119.3213.2.camel@localhost.localdomain> <6c3f5e6c0904291514n371fa179k1901af657e05a5b5@mail.gmail.com> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <16de708d0904301051r647b9f14qc1fe7d343bdbd778@mail.gmail.com> <1241114354.7846.5.camel@localhost.localdomain> <49FAB6AB.9060601@freenet.de> <49FAB9D6.6030203@fedoraproject.org> <49FABC2B.8050500@freenet.de> Message-ID: <49FAC168.4060707@fedoraproject.org> On 05/01/2009 02:38 PM, Ralf Corsepius wrote: > This doesn't invalidate the fact RH's predominance in Fedora-leadership > and the amount of @RH's participating in Fedora shows effects. > > People like you and keating likely are too RH-streamlined and too close > to RH to understand the importance of this consideration. Anyone interested can look at the desktop focused features in the feature list for every release and results should speak for themselves. Those who shoulder the burden of the work decide the direction of the project as always. My employer doesn't decide my opinions. I do and I speak only for myself. I just have a different opinion and disagree with you which is completely ok. You seem to want to make everything a black and white issue when it is almost always never the case. Rahul From sundaram at fedoraproject.org Fri May 1 09:35:00 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 01 May 2009 15:05:00 +0530 Subject: RFC: Fedora 11 FAQ Message-ID: <49FAC244.3050707@fedoraproject.org> Hi, I have posted a draft of the Fedora 11 FAQ at https://fedoraproject.org/wiki/Fedora_11_FAQ Feel free to edit the wiki if you want to highlight anything else or drop me a mail and I will add them. Rahul From dwmw2 at infradead.org Fri May 1 09:32:35 2009 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 01 May 2009 10:32:35 +0100 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <20090430210019.GC25787@nostromo.devel.redhat.com> References: <1240759385.6529.0.camel@localhost.localdomain> <1240762219.2770.9.camel@localhost.localdomain> <1241027428.3139.9.camel@localhost.localdomain> <939dd5750904301050o4efb3efau356882109b2e206b@mail.gmail.com> <1241116151.32113.273.camel@adam.local.net> <939dd5750904301208l19123893rc9cd68609f8980be@mail.gmail.com> <49F9FD08.9010904@redhat.com> <20090430194821.GA25787@nostromo.devel.redhat.com> <1241123673.32113.299.camel@adam.local.net> <20090430210019.GC25787@nostromo.devel.redhat.com> Message-ID: <1241170355.13917.18.camel@macbook.infradead.org> On Thu, 2009-04-30 at 17:00 -0400, Bill Nottingham wrote: > The point isn't the amount of work going in, or anything like that; it's > more the fact that the *process* to start the change was started this > late. That indicates a real issue with the process; we've got feature > pages that define what we're trying to implement, and contingency plans > to enact if they don't work. Why did we miss the deadline to enact this > here? Was the feature page not complete enough as to what was required? > Was the time too short between alpha/beta/preview? Were the reports just > late? There were a number of individual reports of regressions, but it wasn't until quite late in the day that we realised just how bad the new mixer was, and that something really had to be done to restore the lost functionality. There seemed to be a policy of closing bugs WONTFIX and telling people that their use case, which used to work in F-10 and now doesn't, is not appropriate for Fedora. That seems to include my own report of "I want to be able to turn my volume up past 80%", as far as I can tell. That approach to bugs managed to hide the problem for a little while, which meant that we (FESCo) didn't back out the feature in good time and just revert to the old mixer, as we probably should have done. -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation From dwmw2 at infradead.org Fri May 1 09:35:59 2009 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 01 May 2009 10:35:59 +0100 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <20090501024712.GA8817@srcf.ucam.org> References: <1240762219.2770.9.camel@localhost.localdomain> <1241027428.3139.9.camel@localhost.localdomain> <939dd5750904301050o4efb3efau356882109b2e206b@mail.gmail.com> <1241116151.32113.273.camel@adam.local.net> <939dd5750904301208l19123893rc9cd68609f8980be@mail.gmail.com> <49F9FD08.9010904@redhat.com> <20090430234809.GA5813@srcf.ucam.org> <1241139228.32113.397.camel@adam.local.net> <20090501015616.GA8328@srcf.ucam.org> <1241144198.3751.5.camel@adam.local.net> <20090501024712.GA8817@srcf.ucam.org> Message-ID: <1241170559.13917.24.camel@macbook.infradead.org> On Fri, 2009-05-01 at 03:47 +0100, Matthew Garrett wrote: > The basic counterargument is that providing two mixers in the menu is a > cost to every user of Fedora. Having two mixers on the menu sucks, I agree. We should be able to access the full ALSA mixer by pressing an 'advanced...' button in the simplified mixer. Or something more well-hidden, perhaps. But people were throwing their toys out of the pram and refusing to even contemplate that kind of thing, so we ended up with the compromise. At least the functionality is still there, even if it's buried in the menus. -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation From fedora at alexhudson.com Fri May 1 09:40:47 2009 From: fedora at alexhudson.com (Alex Hudson) Date: Fri, 01 May 2009 10:40:47 +0100 Subject: Abandon "Default Desktop" In-Reply-To: <1241114797.32113.267.camel@adam.local.net> References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <16de708d0904271530v135a0a4ep3ab020d798a36c5e@mail.gmail.com> <3adc77210904271556i502559acn37c2002c124a80ff@mail.gmail.com> <49F70FB1.20603@hi.is> <3adc77210904280848pb8000a2h1189866bd6d17db5@mail.gmail.com> <1240953073.32113.225.camel@adam.local.net> <49F80664.6010809@robertoragusa.it> <1241037119.3213.2.camel@localhost.localdomain> <6c3f5e6c0904291514n371fa179k1901af657e05a5b5@mail.gmail.com> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <1241114797.32113.267.camel@adam.local.net> Message-ID: <49FAC39F.6030405@alexhudson.com> (This thread seems to be circling around a lot without seemingly getting anywhere... ) Adam Williamson wrote: > The problem is that > when you ask someone to make a choice without understanding the options, > it tends to frustrate them. This is a well-observed phenomenon in all > circles, certainly including computer user interface design. > I think it's relatively important that there be a good "default" Fedora as well as choice to change things later. I personally find it a bit surprising that the choice of desktop environment is thought of as being sufficiently important that there should be no single "default". As a user, there are apps that are vastly more important to me, and for which there is choice: e.g., OpenOffice.org vs. KOffice, Thunderbird vs. Evolution (vs. Kwhatever), Firefox vs. Epiphany. I spend 90%+ of my time in my desktop using those apps, not the desktop itself - Tbird is much, much more important to me than the choice of DE. Honestly, I could care less whether the default is GNOME or KDE. In all likelihood, I wouldn't even notice the change. But it cannot be right that every important end-user software choice is presented as a different initial download option, all on equal terms, which seems to be what the request is. DEs are not special in that regard. Cheers, Alex. From rc040203 at freenet.de Fri May 1 10:31:15 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 01 May 2009 12:31:15 +0200 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <1241170355.13917.18.camel@macbook.infradead.org> References: <1240759385.6529.0.camel@localhost.localdomain> <1240762219.2770.9.camel@localhost.localdomain> <1241027428.3139.9.camel@localhost.localdomain> <939dd5750904301050o4efb3efau356882109b2e206b@mail.gmail.com> <1241116151.32113.273.camel@adam.local.net> <939dd5750904301208l19123893rc9cd68609f8980be@mail.gmail.com> <49F9FD08.9010904@redhat.com> <20090430194821.GA25787@nostromo.devel.redhat.com> <1241123673.32113.299.camel@adam.local.net> <20090430210019.GC25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> Message-ID: <49FACF73.3060104@freenet.de> David Woodhouse wrote: > On Thu, 2009-04-30 at 17:00 -0400, Bill Nottingham wrote: >> The point isn't the amount of work going in, or anything like that; it's >> more the fact that the *process* to start the change was started this >> late. That indicates a real issue with the process; we've got feature >> pages that define what we're trying to implement, and contingency plans >> to enact if they don't work. Why did we miss the deadline to enact this >> here? Was the feature page not complete enough as to what was required? >> Was the time too short between alpha/beta/preview? Were the reports just >> late? > > There were a number of individual reports of regressions, but it wasn't > until quite late in the day that we realised just how bad the new mixer > was, and that something really had to be done to restore the lost > functionality. > > There seemed to be a policy of closing bugs WONTFIX and telling people > that their use case, which used to work in F-10 and now doesn't, is not > appropriate for Fedora. That seems to include my own report of "I want > to be able to turn my volume up past 80%", as far as I can tell. Feel lucky, on my FC11 test system, audio stopped working. > That approach to bugs managed to hide the problem for a little while, > which meant that we (FESCo) didn't back out the feature in good time and > just revert to the old mixer, as we probably should have done. > Me thinks, the actual cause behind all this is a lack of a "sense of reality", a "reality/wishful thinking mismatch", and a lack of culture to learn from "errors". It might be news to some people, but "trial and error" comprises "errors" and "backtracking" from errors. It doesn't comprise being stubborn and pressing stuff through at any price, just because "things must work". IMO, pulseaudio volume control is such case: Back to the drawing board - It's not ready for prime time. Other such cases in FC11, IMHO are: "no tap" and "no zap". Ralf From billcrawford1970 at gmail.com Fri May 1 12:43:33 2009 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Fri, 01 May 2009 13:43:33 +0100 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <1241149103.3751.42.camel@adam.local.net> References: <1240759385.6529.0.camel@localhost.localdomain> <1240762219.2770.9.camel@localhost.localdomain> <1241027428.3139.9.camel@localhost.localdomain> <939dd5750904301050o4efb3efau356882109b2e206b@mail.gmail.com> <1241116151.32113.273.camel@adam.local.net> <939dd5750904301208l19123893rc9cd68609f8980be@mail.gmail.com> <49F9FD08.9010904@redhat.com> <20090430234809.GA5813@srcf.ucam.org> <1241139228.32113.397.camel@adam.local.net> <20090501015616.GA8328@srcf.ucam.org> <20090501023236.GA20018@tango.0pointer.de> <1241146024.3751.9.camel@adam.local.net> <1241149103.3751.42.camel@adam.local.net> Message-ID: <49FAEE75.4050102@googlemail.com> Adam Williamson wrote: > "Adam, you are misunderstanding how SPDIF in ALSA works. The special > device "spdif:" will toggle all mixer controls appropriately. It will > hence work properly an all cards -- and if it doesn't it's an ALSA bug. > Hence the profile logic PA exposes should provide *complete* SPDIF > experience -- fiddling with low level alsa mixer controls should never > be necessary." Which almost begs one to ask: what happens when there are two orthogonal boolean controls involved? Four "profiles" to cover them? From rawhide at fedoraproject.org Fri May 1 13:10:20 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Fri, 1 May 2009 13:10:20 +0000 (UTC) Subject: rawhide report: 20090501 changes Message-ID: <20090501131020.8CB261F8205@releng2.fedora.phx.redhat.com> Compose started at Fri May 1 06:15:03 UTC 2009 New package perl-Net-OAuth OAuth protocol support library for Perl Removed package backintime Removed package bareftp Removed package camcardsync Removed package dnsjava Removed package globus-callout Removed package globus-gsi-openssl-error Removed package globus-gsi-proxy-ssl Removed package globus-openssl Removed package globus-rsl Removed package globus-xio Removed package gpscorrelate Removed package gxmessage Removed package jjack Removed package jsl Removed package libgarmin Removed package libvmime Removed package mingw32-libglade2 Removed package mingw32-libp11 Removed package mingw32-libxml++ Removed package msp430-gcc Removed package nssbackup Removed package ogmtools Removed package perl-B-Hooks-OP-Check Removed package perl-B-Hooks-OP-Check-StashChange Removed package perl-Log-LogLite Removed package perl-MooseX-Storage Removed package perl-Net-UPnP Removed package perl-RT-Client-REST Removed package perl-Test-Aggregate Removed package photoprint Removed package photoprint-borders Removed package php-feedcreator Removed package php-geshi Removed package pianobooster Removed package python-altgraph Removed package python-arm4 Removed package python-upoints Removed package rubygem-ferret Removed package sems Removed package sing Removed package systemtapguiserver Removed package termit Updated Packages: anaconda-11.5.0.48-2 -------------------- * Thu Apr 30 2009 Jesse Keating - 11.5.0.48-2 - Bump release to be able to tag. * Fri Apr 24 2009 Chris Lumens - 11.5.0.48-1 - Fix handling of swap files. (#496529) (dlehman) - Pass anaconda to turnOnSwap so we can use swap files. (dlehman) - Fix incorrect attribute name use for retrofit flag. (dlehman) - Use slightly better checks when testing for 0 size (#493656, #497186, - If the LV has no child, don't attempt to grab its format (#497239). (clumens) - Apply the global passphrase when doing kickstart autopart (#497533). (clumens) - Add support for encryption passphrase retrofits. (dlehman) - Bring luks_add_key and luks_remove_key back into devicelibs.crypto. (dlehman) - Don't let lvremove failures from incomplete vgs crash the install. (#497401) (dlehman) - Allow setting a mountpoint w/o formatting an encrypted partition. (#495417) (dlehman) - Remove encryption from preexisting device if "Encrypt" is deactivated. (dlehman) - Fix indentation of preexisting partition handling block. (dlehman) - The device passed to the luks passphrase dialogs is a string. (#492123) (dlehman) - Protect against tracebacks from the partition isFoo properties. (dlehman) - Fix handling of bind mounts. (#496406) (dlehman) - Add more filesystem checks. (clumens) - Support vfat filesystems in the partitioning UI (#496351). (clumens) - Remove devices in leaves first order (#496630) (hdegoede) - Don't remove an inconsistent lvm partition from the devicetree (#496638) (hdegoede) - Move isEfi to be a property on Platform instead of on X86 (#497394). (clumens) - Support --encrypted --useexisting on kickstart installs (#497147). (clumens) - When making a RAID device, require that some members be selected (#491932). (clumens) - When catching an OSError, handle it as an object instead of a tuple (#497374). (clumens) - Enforce the fstype that holds /boot on kickstart installs (#497238). (clumens) - Fix ps3 platform support (#497203) (katzj) - Clean up rpmdb locks at the end of the install (#496961) (katzj) - Don't allow /boot to be on an encrypted device (#496866). (clumens) - Use the correct unmount method (#496764). (clumens) drupal-6.11-1.fc11 ------------------ * Thu Apr 30 2009 Jon Ciesla - 6.11-1 - Update to 6.11, SA-CORE-2009-005. * Mon Apr 27 2009 Jon Ciesla - 6.10-2 - Added SELinux/sendmail note to README, BZ 497642. elinks-0.12-0.13.pre3.fc11 -------------------------- * Thu Apr 30 2009 Kamil Dudka 0.12-0.13.pre3 - use appropriate BuildRequires for nss_compat_ossl - support for trusted CA certificates loading from file in PEM format - enable certificate verification by default via configuration file(#495532) fedora-release-10.93-2 ---------------------- * Tue Apr 21 2009 Jesse Keating - 10.93-2 - Drop reference to the "test" key, we only do one key per release now * Tue Apr 14 2009 Jesse Keating - 10.93-1 - Bump for F11 Preview - Add the release name filezilla-3.2.4.1-1.fc11 ------------------------ * Tue Apr 28 2009 kwizart < kwizart at gmail.com > - 3.2.4.1-1 - Update to 3.2.4.1 * Tue Apr 21 2009 kwizart < kwizart at gmail.com > - 3.2.4-1 - Update to 3.2.4 grub-0.97-50.fc11 ----------------- * Wed Apr 29 2009 Peter Jones - 0.97-50 - Handle virtio_blk disks and their crazy new device name in grub-install (rhbz#479760) * Thu Apr 16 2009 Peter Jones - 0.97-49 - Fix efi booting on machines with continguous memory regions across the 1G boundary. gtk2-2.16.1-4.fc11 ------------------ * Thu Apr 30 2009 Matthias Clasen - 2.16.1-4 - Ship the xim immodule separately kde-settings-4.2-9.20090429svn.fc11 ----------------------------------- * Wed Apr 29 2009 Rex Dieter - 4.2-9.20090429svn - krunnerrc: disable contacts plugin, avoids akonadi launch on first login lcms-1.18-2.fc11 ---------------- * Wed Apr 22 2009 kwizart < kwizart at gmail.com > - 1.18-2 - Add lcms-CVE-2009-0793.patch from 1.18a ltsp-5.1.72-1.fc11 ------------------ * Thu Apr 30 2009 Warren Togami - 5.1.72-1 - no code changes, only important documentation update regarding disabling ltspbr0 see /etc/sysconfig/network-scripts/ifcfg-ltspbr0 nss_compat_ossl-0.9.5-3.fc11 ---------------------------- * Wed Apr 29 2009 Rob Crittenden - 0.9.5-2 - Resolve BZ 497788, implement default loading of root CAs * Wed Apr 29 2009 Rob Crittenden - 0.9.5-3 - Bump NVR so it isn't lower than F-10 * Mon Apr 20 2009 Rob Crittenden - 0.9.5-1 - Update to 0.9.5 - License changed to MIT opencv-1.0.0-15.fc11 -------------------- * Fri Apr 24 2009 kwizart < kwizart at gmail.com > - 1.0.0-15 - Disable make check failure * Wed Apr 22 2009 kwizart < kwizart at gmail.com > - 1.0.0-14 - Fix for gcc44 - Enable BR jasper-devel - Disable ldconfig run on python modules (uneeded) - Prevent timestamp change on install * Thu Feb 26 2009 Fedora Release Engineering - 1.0.0-13 - Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild Summary: Added Packages: 1 Removed Packages: 42 Modified Packages: 12 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From stickster at gmail.com Fri May 1 14:19:24 2009 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 1 May 2009 10:19:24 -0400 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <49FA33DE.7050707@gmail.com> References: <20090424161356.299d0d53@ohm.scrye.com> <49F24B17.30602@redhat.com> <49F25D0D.8030304@gmail.com> <1240759385.6529.0.camel@localhost.localdomain> <1240762219.2770.9.camel@localhost.localdomain> <1241027428.3139.9.camel@localhost.localdomain> <939dd5750904301050o4efb3efau356882109b2e206b@mail.gmail.com> <49FA33DE.7050707@gmail.com> Message-ID: <20090501141924.GF6034@localhost.localdomain> On Thu, Apr 30, 2009 at 07:27:26PM -0400, TK009 wrote: > William Jon McCann wrote: >> >> In this particular case, there is nothing wrong with telling some >> people either: > a) you may have to wait *years* in order to get the optimal experience. > b) The current release of this product is a fail! Go to this wiki page > and follow the instructions to make it work. >> We simply cannot avoid this if we continue to use a >> time-based release process. There will always be cases where we don't >> finish everything we'd like to. > But it ok to ship a crappy or not ready product as long as I created it. >> That is, it cannot >> if we ever want to recover marketshare and mindshare from other >> distributions (not to mention other/better OS's), > "we" are not competing with other distributions. That is just you > lennart and crew. > > Here is a clue, making a better product will "recover" your precious > market and mind share. Telling people only you know what is best does not. We're finally reaching a point where dialogue between parties is becoming more constructive and less vitriolic. Please don't reduce the usefulness of the conversation. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From notting at redhat.com Fri May 1 14:20:31 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 1 May 2009 10:20:31 -0400 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <1241170355.13917.18.camel@macbook.infradead.org> References: <1240762219.2770.9.camel@localhost.localdomain> <1241027428.3139.9.camel@localhost.localdomain> <939dd5750904301050o4efb3efau356882109b2e206b@mail.gmail.com> <1241116151.32113.273.camel@adam.local.net> <939dd5750904301208l19123893rc9cd68609f8980be@mail.gmail.com> <49F9FD08.9010904@redhat.com> <20090430194821.GA25787@nostromo.devel.redhat.com> <1241123673.32113.299.camel@adam.local.net> <20090430210019.GC25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> Message-ID: <20090501142031.GA11556@nostromo.devel.redhat.com> David Woodhouse (dwmw2 at infradead.org) said: > There were a number of individual reports of regressions, but it wasn't > until quite late in the day that we realised just how bad the new mixer > was, and that something really had to be done to restore the lost > functionality. OK, there were regressions, but we didn't see until too late... > There seemed to be a policy of closing bugs WONTFIX and telling people > that their use case, which used to work in F-10 and now doesn't, is not > appropriate for Fedora. That seems to include my own report of "I want > to be able to turn my volume up past 80%", as far as I can tell. ... because of how The Evil They handled the bugs ... > That approach to bugs managed to hide the problem for a little while, > which meant that we (FESCo) didn't back out the feature in good time and > just revert to the old mixer, as we probably should have done. ... which hid the issues during the proper time to handle it. Too bad the WONTFIX bug that prompted your screed (and frankly, I agree with the WONTFIX in this case) wasn't filed until AFTER THE FINAL DEVEL FREEZE. Hey, if you didn't have time to test, that's OK. Not everyone does. But when we're trying to figure out real issues, Rumsfeldian pseudo-analysis based on *KNOWN* inaccuracies doesn't help. Bill From dwalsh at redhat.com Fri May 1 14:31:12 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 01 May 2009 10:31:12 -0400 Subject: I wanted to open a discussion for F12 about running services on shell accounts. Message-ID: <49FB07B0.50100@redhat.com> I would like to run restorecond as a user service rather then as system service. I want to run it under the Users UID and under with the users context. Then I can have it watch for creation of files in the users home directory and be the equivalent of running restorecon ~/ by the user. Currently I can do this with the system service restorecond, but that is running as root and has to be able to relabel everything. I want to use something like DBUS so I have only one restorecond running for each user no matter how many times the user logs in. I built a dbus service and everything works fine. Except that I want this to work on a server when I ssh to a machine. Or if I log in via the console terminal. In those cases I do not have a dbus session so I am out of luck. I could have restorecond started via /etc/profile.d but I would need to do something for csh and bash, and I could end up with multiple restorecond under the same UID. I could build into restorecond some kind of locking to prevent this, but the dbus solution eliminates me from having to do some potentially buggy code. I doubt I am the only one who wants to run sessions on login for terminal users. Any thoughts on running a dbus session for a terminal session? From john.brown009 at gmail.com Fri May 1 14:34:42 2009 From: john.brown009 at gmail.com (TK009) Date: Fri, 01 May 2009 10:34:42 -0400 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <20090501141924.GF6034@localhost.localdomain> References: <20090424161356.299d0d53@ohm.scrye.com> <49F24B17.30602@redhat.com> <49F25D0D.8030304@gmail.com> <1240759385.6529.0.camel@localhost.localdomain> <1240762219.2770.9.camel@localhost.localdomain> <1241027428.3139.9.camel@localhost.localdomain> <939dd5750904301050o4efb3efau356882109b2e206b@mail.gmail.com> <49FA33DE.7050707@gmail.com> <20090501141924.GF6034@localhost.localdomain> Message-ID: <49FB0882.9000200@gmail.com> Paul W. Frields wrote: > On Thu, Apr 30, 2009 at 07:27:26PM -0400, TK009 wrote: > >> William Jon McCann wrote: >> >>> In this particular case, there is nothing wrong with telling some >>> people either: >>> >> a) you may have to wait *years* in order to get the optimal experience. >> b) The current release of this product is a fail! Go to this wiki page >> and follow the instructions to make it work. >> >>> We simply cannot avoid this if we continue to use a >>> time-based release process. There will always be cases where we don't >>> finish everything we'd like to. >>> >> But it ok to ship a crappy or not ready product as long as I created it. >> >>> That is, it cannot >>> if we ever want to recover marketshare and mindshare from other >>> distributions (not to mention other/better OS's), >>> >> "we" are not competing with other distributions. That is just you >> lennart and crew. >> >> Here is a clue, making a better product will "recover" your precious >> market and mind share. Telling people only you know what is best does not. >> > > We're finally reaching a point where dialogue between parties is > becoming more constructive and less vitriolic. Please don't reduce > the usefulness of the conversation. > > I respectfully disagree sir. From oget.fedora at gmail.com Fri May 1 14:36:52 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Fri, 1 May 2009 10:36:52 -0400 Subject: Orphaning azureus In-Reply-To: <49FA9C0B.9040808@gmail.com> References: <200904301646.47342.konrad@tylerc.org> <20090430220315.7d9e4176.zaitcev@redhat.com> <49FA9C0B.9040808@gmail.com> Message-ID: On Fri, May 1, 2009 at 2:51 AM, Frank Murphy (Frankly3D) wrote: > On 01/05/09 05:32, Peter Lemenkov wrote: >> >> 2009/5/1 Pete Zaitcev: >>> >>> On Thu, 30 Apr 2009 16:46:47 -0700, Conrad Meyer >>> ?wrote: >>> >>>> It's a steaming pile of crap, I don't use it personally, [] >>> >>> Do you suggest anything as a replacement? >> >> Deluge, transmission, etc - thousands of them! >> > > One with an hourly scheduler? > ktorrent. Very good one indeed. Orcan From MathStuf at gmail.com Fri May 1 14:20:03 2009 From: MathStuf at gmail.com (Ben Boeckel) Date: Fri, 01 May 2009 10:20:03 -0400 Subject: Orphaning azureus References: <200904301646.47342.konrad@tylerc.org> <20090430220315.7d9e4176.zaitcev@redhat.com> <49FA9C0B.9040808@gmail.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Frank Murphy (Frankly3D) wrote: > On 01/05/09 05:32, Peter Lemenkov wrote: >> 2009/5/1 Pete Zaitcev: >>> On Thu, 30 Apr 2009 16:46:47 -0700, Conrad Meyer wrote: >>> >>>> It's a steaming pile of crap, I don't use it personally, [] >>> Do you suggest anything as a replacement? >> >> Deluge, transmission, etc - thousands of them! >> > > One with an hourly scheduler? > > Frank > KTorrent offers one where you can put bandwidth limits on each hour as a plugin. - --Ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkn7BRMACgkQiPi+MRHG3qQWQwCfYUlsKHaJpGDdAwKHrKVSl7sJ w1wAmwbrBgHgNNRAydzVPSGDcGtUbMTx =/Lof -----END PGP SIGNATURE----- From dimi at lattica.com Fri May 1 15:01:23 2009 From: dimi at lattica.com (Dimi Paun) Date: Fri, 01 May 2009 11:01:23 -0400 Subject: Annoying screen blanking Message-ID: <1241190083.7744.54.camel@dimi.lattica.com> Folks, I must admit I am frustrated again: since the last update yesterday, a _very_ basic behavior changed with no apparent way of changing back. Namely, now my screen blanks (with the monitor displaying "No signal") after 2min of inactivity (sometimes it seems faster). This is truly frustrating: it blanks while I read a longer email, when I read something on the web, etc. Sure enough, looking for a way to switch it off proved futile too: * I couldn't find any setting for a Screensaver despite going through System | Preferences for at least 5min, on 3-4 different attempts. * Power Management says "Never" for both "Computer" and "Display" to be put to sleep. What gives? P.S. https://bugzilla.redhat.com/show_bug.cgi?id=498505 -- Dimi Paun Lattica, Inc. From notting at redhat.com Fri May 1 15:06:16 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 1 May 2009 11:06:16 -0400 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <20090501142031.GA11556@nostromo.devel.redhat.com> References: <1241027428.3139.9.camel@localhost.localdomain> <939dd5750904301050o4efb3efau356882109b2e206b@mail.gmail.com> <1241116151.32113.273.camel@adam.local.net> <939dd5750904301208l19123893rc9cd68609f8980be@mail.gmail.com> <49F9FD08.9010904@redhat.com> <20090430194821.GA25787@nostromo.devel.redhat.com> <1241123673.32113.299.camel@adam.local.net> <20090430210019.GC25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> Message-ID: <20090501150616.GB11556@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > Hey, if you didn't have time to test, that's OK. Not everyone does. > But when we're trying to figure out real issues, Rumsfeldian pseudo-analysis > based on *KNOWN* inaccuracies doesn't help. Looking over the WONTFIXes: - yours (filed 04/17, closed 04/23) - 486500 (closed WONTFIX for F10, should work in F11) - 477938 (closed WONTFIX for F10, should work in F11) - 460798 (string change, not relevant for functionality) - 455207 (closed WONTFIX for F9, should work in F11) - 454217 (closed WONTFIX for F9, should work in F11) (note, at this point we're in old F8 and F9 bugs) - 451633 (apps linked statically against ancient esound don't work. Don't do that!) - 450610 (appears that you can do what the reporter wanted in any case) - 448509 (padsp has issues with some binary-only apps) - 444684 (fixed differently, in a F9 update) - 422741 (EOL distro) - 411151 (fixed by going to autospawning) Hm, perhaps the NOTABUGs for PA and gnome-media? - 488779 (PA handles volume differently; as stated, it is not a bug) - 492757 (user tried again, it worked) - 492790 (KVM bug for not properly using PA) - 493978 (debug spew, toned down in later builds in any case) - 494112 (mplayer adjusts the wrong volume control -> mplayer bug) - 494116 (filed against wrong component) - 494684 (config error, didn't reoccur) - 494747 (VMWare bug) - 494975 (config error) - 495806 (PEBKAC, according to reporter) - 496467 (driver bug) - 497089 (went away in later rawhide) - 497177 (permission problem, fixed elsewhere) - 469335 (RT option intentionally not exposed; seems reasonable) - 469549 (config error) - 469677 (other app holding card open) - 470707 (libflashsupport needed for closed flash) - 474397 (PEBKAC) - 476429 (config error) - 476848 (debug spew, toned down in later builds in any case) - 479162 (flash, missing packages not installed) - 479492 (error in driver init) - 480499 (flash bug) - 480875 (other app holding card open) - 484332 (half-mixed rawhide & f10 system had dep issues) - 485475 (output profiles not shown in mixer - will be added later) - 486525 (misunderstanding of command-line options) - 487270 (driver bug) - 488770 (output profiles not shown in mixer - will be added later) - 483231 (complaining that applet -> notification area moved it in the panel) - 489546 (filed against wrong component) - 494340 (volume control requires PA) - 494709 (misunderstanding of new flat volume support) - 497053 (volume control requires PA) So, looking at the bugs that could possibly be categorized as 'regressions' or 'we don't support that use case yet' (not that I necessarily agree) were closed WONTFIX or NOTABUG, we have: 496284 - filed 04/17, closed 04/23 485475 - filed 02/13, closed 02/17 488770 - filed 03/05, closed 03/19 That's 3 bugs, as far as I can tell, that were closed in this manner. (And the last two are really duplicates). So, what am I missing? Bill From dr.diesel at gmail.com Fri May 1 15:09:09 2009 From: dr.diesel at gmail.com (Dr. Diesel) Date: Fri, 1 May 2009 10:09:09 -0500 Subject: Annoying screen blanking In-Reply-To: <1241190083.7744.54.camel@dimi.lattica.com> References: <1241190083.7744.54.camel@dimi.lattica.com> Message-ID: <2a28d2ab0905010809w50fbd338h8189c9f6f49fefb4@mail.gmail.com> On Fri, May 1, 2009 at 10:01 AM, Dimi Paun wrote: > Folks, > > I must admit I am frustrated again: since the last update yesterday, > a _very_ basic behavior changed with no apparent way of changing back. > > Namely, now my screen blanks (with the monitor displaying "No signal") > after 2min of inactivity (sometimes it seems faster). This is truly > frustrating: it blanks while I read a longer email, when I read > something on the web, etc. > > Sure enough, looking for a way to switch it off proved futile too: > * I couldn't find any setting for a Screensaver despite > going through System | Preferences for at least 5min, on > 3-4 different attempts. > * Power Management says "Never" for both "Computer" and "Display" > to be put to sleep. > > What gives? > > P.S. https://bugzilla.redhat.com/show_bug.cgi?id=498505 > > I haven't timed mine, but it is blanking as well, even with very recent mouse activity. Started at about the same time mentioned above. -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From awilliam at redhat.com Fri May 1 15:18:12 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 01 May 2009 08:18:12 -0700 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <20090501142031.GA11556@nostromo.devel.redhat.com> References: <1240762219.2770.9.camel@localhost.localdomain> <1241027428.3139.9.camel@localhost.localdomain> <939dd5750904301050o4efb3efau356882109b2e206b@mail.gmail.com> <1241116151.32113.273.camel@adam.local.net> <939dd5750904301208l19123893rc9cd68609f8980be@mail.gmail.com> <49F9FD08.9010904@redhat.com> <20090430194821.GA25787@nostromo.devel.redhat.com> <1241123673.32113.299.camel@adam.local.net> <20090430210019.GC25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> Message-ID: <1241191092.2811.5.camel@adam.local.net> On Fri, 2009-05-01 at 10:20 -0400, Bill Nottingham wrote: > Hey, if you didn't have time to test, that's OK. Not everyone does. > But when we're trying to figure out real issues, Rumsfeldian pseudo-analysis > based on *KNOWN* inaccuracies doesn't help. Oh, fun. I was hoping when I went to bed last night that my last post won the thread, but of course it's more fun for everyone to tactically ignore it and continue tearing strips out of each other. Please, if you want to continue this debate, address my point that the desktop objection that it's "bad UI" to ship multiple volume control applications by default holds precisely no water, on the basis that they have already been shipping multiple volume controls by default since F8 - gnome-volume-control and pavucontrol. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From awilliam at redhat.com Fri May 1 15:21:48 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 01 May 2009 08:21:48 -0700 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <49FAEE75.4050102@googlemail.com> References: <1240759385.6529.0.camel@localhost.localdomain> <1240762219.2770.9.camel@localhost.localdomain> <1241027428.3139.9.camel@localhost.localdomain> <939dd5750904301050o4efb3efau356882109b2e206b@mail.gmail.com> <1241116151.32113.273.camel@adam.local.net> <939dd5750904301208l19123893rc9cd68609f8980be@mail.gmail.com> <49F9FD08.9010904@redhat.com> <20090430234809.GA5813@srcf.ucam.org> <1241139228.32113.397.camel@adam.local.net> <20090501015616.GA8328@srcf.ucam.org> <20090501023236.GA20018@tango.0pointer.de> <1241146024.3751.9.camel@adam.local.net> <1241149103.3751.42.camel@adam.local.net> <49FAEE75.4050102@googlemail.com> Message-ID: <1241191308.2811.6.camel@adam.local.net> On Fri, 2009-05-01 at 13:43 +0100, Bill Crawford wrote: > Adam Williamson wrote: > > > "Adam, you are misunderstanding how SPDIF in ALSA works. The special > > device "spdif:" will toggle all mixer controls appropriately. It will > > hence work properly an all cards -- and if it doesn't it's an ALSA bug. > > Hence the profile logic PA exposes should provide *complete* SPDIF > > experience -- fiddling with low level alsa mixer controls should never > > be necessary." > > Which almost begs one to ask: what happens when there are two orthogonal > boolean controls involved? Four "profiles" to cover them? Run pavucontrol and have a look - most cards have a lot of profiles. I have 15 on my internal card (covering many combinations of digital, analog and 5.1 analog input / output), and six on my expansion card (just digital / analog choices). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From naheemzaffar at gmail.com Fri May 1 15:24:23 2009 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Fri, 1 May 2009 16:24:23 +0100 Subject: Annoying screen blanking In-Reply-To: <1241190083.7744.54.camel@dimi.lattica.com> References: <1241190083.7744.54.camel@dimi.lattica.com> Message-ID: <3adc77210905010824t527d6227qfe34dd9d0c3bfcdb@mail.gmail.com> 2009/5/1 Dimi Paun > Folks, > > I must admit I am frustrated again: since the last update yesterday, > a _very_ basic behavior changed with no apparent way of changing back. > I don't think its a change of behaviour, but an actual bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From awilliam at redhat.com Fri May 1 15:26:45 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 01 May 2009 08:26:45 -0700 Subject: RFC: Fedora 11 FAQ In-Reply-To: <49FAC244.3050707@fedoraproject.org> References: <49FAC244.3050707@fedoraproject.org> Message-ID: <1241191605.2811.8.camel@adam.local.net> On Fri, 2009-05-01 at 15:05 +0530, Rahul Sundaram wrote: > Hi, > > I have posted a draft of the Fedora 11 FAQ at > > https://fedoraproject.org/wiki/Fedora_11_FAQ > > Feel free to edit the wiki if you want to highlight anything else or > drop me a mail and I will add them. It's nicely written, but it seems like a bit of an awkward document in conception - somewhere between Release Notes and Errata and a general Fedora (not really Fedora 11) FAQ. Couldn't we somehow reconcile it with some of the other release documentation to avoid duplication of effort? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From awilliam at redhat.com Fri May 1 15:31:01 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 01 May 2009 08:31:01 -0700 Subject: Annoying screen blanking In-Reply-To: <1241190083.7744.54.camel@dimi.lattica.com> References: <1241190083.7744.54.camel@dimi.lattica.com> Message-ID: <1241191861.2811.10.camel@adam.local.net> On Fri, 2009-05-01 at 11:01 -0400, Dimi Paun wrote: > Folks, > > I must admit I am frustrated again: since the last update yesterday, > a _very_ basic behavior changed with no apparent way of changing back. > > Namely, now my screen blanks (with the monitor displaying "No signal") > after 2min of inactivity (sometimes it seems faster). This is truly > frustrating: it blanks while I read a longer email, when I read > something on the web, etc. > > Sure enough, looking for a way to switch it off proved futile too: > * I couldn't find any setting for a Screensaver despite > going through System | Preferences for at least 5min, on > 3-4 different attempts. > * Power Management says "Never" for both "Computer" and "Display" > to be put to sleep. > > What gives? > > P.S. https://bugzilla.redhat.com/show_bug.cgi?id=498505 It's just a bug. Your second bullet point is the giveaway: that's the bug. When it's set to go to sleep "never", the display goes to sleep after one minute. Change it to two hours and you'll be less frustrated. The report is: https://bugzilla.redhat.com/show_bug.cgi?id=498041 -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From zaitcev at redhat.com Fri May 1 15:33:46 2009 From: zaitcev at redhat.com (Pete Zaitcev) Date: Fri, 1 May 2009 09:33:46 -0600 Subject: Orphaning azureus In-Reply-To: <1241150896.3894.70.camel@ignacio.lan> References: <200904301646.47342.konrad@tylerc.org> <20090430220315.7d9e4176.zaitcev@redhat.com> <1241150896.3894.70.camel@ignacio.lan> Message-ID: <20090501093346.d78ac4d9.zaitcev@redhat.com> On Fri, 01 May 2009 00:08:16 -0400, Ignacio Vazquez-Abrams wrote: > > > It's a steaming pile of crap, I don't use it personally, [] > > > > Do you suggest anything as a replacement? > > Deluge and Transmission each have about 80-90% of Azureus's > functionality. What do you actually use for Fedora ISOs? -- Pete From sundaram at fedoraproject.org Fri May 1 15:42:42 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 01 May 2009 21:12:42 +0530 Subject: RFC: Fedora 11 FAQ In-Reply-To: <1241191605.2811.8.camel@adam.local.net> References: <49FAC244.3050707@fedoraproject.org> <1241191605.2811.8.camel@adam.local.net> Message-ID: <49FB1872.50103@fedoraproject.org> On 05/01/2009 08:56 PM, Adam Williamson wrote: > On Fri, 2009-05-01 at 15:05 +0530, Rahul Sundaram wrote: >> Hi, >> >> I have posted a draft of the Fedora 11 FAQ at >> >> https://fedoraproject.org/wiki/Fedora_11_FAQ >> >> Feel free to edit the wiki if you want to highlight anything else or >> drop me a mail and I will add them. > > It's nicely written, but it seems like a bit of an awkward document in > conception - somewhere between Release Notes and Errata and a general > Fedora (not really Fedora 11) FAQ. Couldn't we somehow reconcile it with > some of the other release documentation to avoid duplication of effort? In the past, such release specific FAQ's have often been very helpful in addressing the repeatedly asked questions. I can't anticipate the FAQ's so the initial seed information tends to be a bit more generic. I cross reference existing documentation such as release notes to avoid duplication where possible. I am not very happy with the current release notes structure and will be spending more effort for the next release to get it better match what I think is the right style. Rahul From dimi at lattica.com Fri May 1 15:38:47 2009 From: dimi at lattica.com (Dimi Paun) Date: Fri, 01 May 2009 11:38:47 -0400 Subject: Annoying screen blanking In-Reply-To: <1241191861.2811.10.camel@adam.local.net> References: <1241190083.7744.54.camel@dimi.lattica.com> <1241191861.2811.10.camel@adam.local.net> Message-ID: <1241192327.7744.59.camel@dimi.lattica.com> On Fri, 2009-05-01 at 08:31 -0700, Adam Williamson wrote: > Change it to two hours and you'll be less frustrated. The report is: > > https://bugzilla.redhat.com/show_bug.cgi?id=498041 Guys, this is a major usability issue -- it has become a pain to even read emails! This is a BLOCKER in my books, but bugzilla says: Priority: low Severity: medium (vote) This will hit everybody all the time -- how can it be a "nice to have"? -- Dimi Paun Lattica, Inc. From sundaram at fedoraproject.org Fri May 1 15:46:03 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 01 May 2009 21:16:03 +0530 Subject: Annoying screen blanking In-Reply-To: <1241192327.7744.59.camel@dimi.lattica.com> References: <1241190083.7744.54.camel@dimi.lattica.com> <1241191861.2811.10.camel@adam.local.net> <1241192327.7744.59.camel@dimi.lattica.com> Message-ID: <49FB193B.4070101@fedoraproject.org> On 05/01/2009 09:08 PM, Dimi Paun wrote: > On Fri, 2009-05-01 at 08:31 -0700, Adam Williamson wrote: >> Change it to two hours and you'll be less frustrated. The report is: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=498041 > > Guys, this is a major usability issue -- it has become a pain > to even read emails! This is a BLOCKER in my books, but bugzilla says: > > Priority: low Severity: medium (vote) > > This will hit everybody all the time -- how can it be a "nice to have"? Those fields are not used currently. Just ignore them. We use tracker bugs to set something as a blocker, for Fedora 11, it is - F11Blocker. Rahul From mzerqung at 0pointer.de Fri May 1 15:42:08 2009 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Fri, 1 May 2009 17:42:08 +0200 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <1241170355.13917.18.camel@macbook.infradead.org> References: <1240762219.2770.9.camel@localhost.localdomain> <1241027428.3139.9.camel@localhost.localdomain> <939dd5750904301050o4efb3efau356882109b2e206b@mail.gmail.com> <1241116151.32113.273.camel@adam.local.net> <939dd5750904301208l19123893rc9cd68609f8980be@mail.gmail.com> <49F9FD08.9010904@redhat.com> <20090430194821.GA25787@nostromo.devel.redhat.com> <1241123673.32113.299.camel@adam.local.net> <20090430210019.GC25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> Message-ID: <20090501154208.GB26141@tango.0pointer.de> On Fri, 01.05.09 10:32, David Woodhouse (dwmw2 at infradead.org) wrote: > There seemed to be a policy of closing bugs WONTFIX and telling people > that their use case, which used to work in F-10 and now doesn't, is not > appropriate for Fedora. That seems to include my own report of "I want > to be able to turn my volume up past 80%", as far as I can tell. Please refer to actual bug reports when you express baseless accusations like this. Also, please stop your ugly demagogy. You use expressions like "not appropriate for Fedora" while it is clear that your exotic use cases have been thought as "inappropriate for the default installed tool" only. There is quite a distinction between "appropriate for Fedora" and "appropriate for the default installed tool". And you know that. I think this mail of mine still summarizes perfectly how exotic your three use cases are (at the end): https://www.redhat.com/archives/fedora-devel-list/2009-April/msg02153.html But of course, you didn't respond to that mail... Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From notting at redhat.com Fri May 1 15:48:35 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 1 May 2009 11:48:35 -0400 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <1241191092.2811.5.camel@adam.local.net> References: <939dd5750904301050o4efb3efau356882109b2e206b@mail.gmail.com> <1241116151.32113.273.camel@adam.local.net> <939dd5750904301208l19123893rc9cd68609f8980be@mail.gmail.com> <49F9FD08.9010904@redhat.com> <20090430194821.GA25787@nostromo.devel.redhat.com> <1241123673.32113.299.camel@adam.local.net> <20090430210019.GC25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> Message-ID: <20090501154835.GD11556@nostromo.devel.redhat.com> Adam Williamson (awilliam at redhat.com) said: > On Fri, 2009-05-01 at 10:20 -0400, Bill Nottingham wrote: > > > Hey, if you didn't have time to test, that's OK. Not everyone does. > > But when we're trying to figure out real issues, Rumsfeldian pseudo-analysis > > based on *KNOWN* inaccuracies doesn't help. > > Oh, fun. I was hoping when I went to bed last night that my last post > won the thread, but of course it's more fun for everyone to tactically > ignore it and continue tearing strips out of each other. > > Please, if you want to continue this debate, This post was on the subject of 'how did we get in this situation', not the solution that was proposed. I suppose I could have split off a separate thread for that, but ... *shrug*. Bill From awilliam at redhat.com Fri May 1 15:52:45 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 01 May 2009 08:52:45 -0700 Subject: RFC: Fedora 11 FAQ In-Reply-To: <49FB1872.50103@fedoraproject.org> References: <49FAC244.3050707@fedoraproject.org> <1241191605.2811.8.camel@adam.local.net> <49FB1872.50103@fedoraproject.org> Message-ID: <1241193165.2811.13.camel@adam.local.net> On Fri, 2009-05-01 at 21:12 +0530, Rahul Sundaram wrote: > On 05/01/2009 08:56 PM, Adam Williamson wrote: > > On Fri, 2009-05-01 at 15:05 +0530, Rahul Sundaram wrote: > >> Hi, > >> > >> I have posted a draft of the Fedora 11 FAQ at > >> > >> https://fedoraproject.org/wiki/Fedora_11_FAQ > >> > >> Feel free to edit the wiki if you want to highlight anything else or > >> drop me a mail and I will add them. > > > > It's nicely written, but it seems like a bit of an awkward document in > > conception - somewhere between Release Notes and Errata and a general > > Fedora (not really Fedora 11) FAQ. Couldn't we somehow reconcile it with > > some of the other release documentation to avoid duplication of effort? > > In the past, such release specific FAQ's have often been very helpful in > addressing the repeatedly asked questions. I can't anticipate the FAQ's > so the initial seed information tends to be a bit more generic. I cross > reference existing documentation such as release notes to avoid > duplication where possible. > > I am not very happy with the current release notes structure and will be > spending more effort for the next release to get it better match what I > think is the right style. OK, understood, sounds fine to me. As I said, the current content looks good but I see a few trivial language errors - is it OK with you if I go in and fix them directly? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From awilliam at redhat.com Fri May 1 15:54:27 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 01 May 2009 08:54:27 -0700 Subject: Annoying screen blanking In-Reply-To: <49FB193B.4070101@fedoraproject.org> References: <1241190083.7744.54.camel@dimi.lattica.com> <1241191861.2811.10.camel@adam.local.net> <1241192327.7744.59.camel@dimi.lattica.com> <49FB193B.4070101@fedoraproject.org> Message-ID: <1241193267.2811.15.camel@adam.local.net> On Fri, 2009-05-01 at 21:16 +0530, Rahul Sundaram wrote: > On 05/01/2009 09:08 PM, Dimi Paun wrote: > > On Fri, 2009-05-01 at 08:31 -0700, Adam Williamson wrote: > >> Change it to two hours and you'll be less frustrated. The report is: > >> > >> https://bugzilla.redhat.com/show_bug.cgi?id=498041 > > > > Guys, this is a major usability issue -- it has become a pain > > to even read emails! This is a BLOCKER in my books, but bugzilla says: > > > > Priority: low Severity: medium (vote) > > > > This will hit everybody all the time -- how can it be a "nice to have"? > > Those fields are not used currently. Just ignore them. We use tracker > bugs to set something as a blocker, for Fedora 11, it is - F11Blocker. Right, for now the priority/severity fields are totally ignored. (I'm working on a proposal regarding that, you'll see a mail soon). The bug was set to block F11Blocker for a while, but Matthias disagreed and changed it to F11Target (which is the 'nice to have but we won't delay the release' tracker). Personally I disagree, but I'm not comfortable getting into a revision war with Matthias over it. Matthias, did you make that decision knowing that it's affecting a lot of people, on AC as well as battery power? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From dimi at lattica.com Fri May 1 15:54:06 2009 From: dimi at lattica.com (Dimi Paun) Date: Fri, 01 May 2009 11:54:06 -0400 Subject: Annoying screen blanking In-Reply-To: <49FB193B.4070101@fedoraproject.org> References: <1241190083.7744.54.camel@dimi.lattica.com> <1241191861.2811.10.camel@adam.local.net> <1241192327.7744.59.camel@dimi.lattica.com> <49FB193B.4070101@fedoraproject.org> Message-ID: <1241193246.7744.61.camel@dimi.lattica.com> On Fri, 2009-05-01 at 21:16 +0530, Rahul Sundaram wrote: > Those fields are not used currently. Just ignore them. We use tracker > bugs to set something as a blocker, for Fedora 11, it is - F11Blocker. Ah, thx. However, this bug is tracked under F11Tracker. I think it rightly belongs under F11Blocker. -- Dimi Paun Lattica, Inc. From sundaram at fedoraproject.org Fri May 1 16:08:38 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 01 May 2009 21:38:38 +0530 Subject: RFC: Fedora 11 FAQ In-Reply-To: <1241193165.2811.13.camel@adam.local.net> References: <49FAC244.3050707@fedoraproject.org> <1241191605.2811.8.camel@adam.local.net> <49FB1872.50103@fedoraproject.org> <1241193165.2811.13.camel@adam.local.net> Message-ID: <49FB1E86.7080407@fedoraproject.org> On 05/01/2009 09:22 PM, Adam Williamson wrote: > > OK, understood, sounds fine to me. As I said, the current content looks > good but I see a few trivial language errors - is it OK with you if I go > in and fix them directly? Of course. It is a wiki. Rahul From stickster at gmail.com Fri May 1 16:06:37 2009 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 1 May 2009 12:06:37 -0400 Subject: RFC: Fedora 11 FAQ In-Reply-To: <49FB1872.50103@fedoraproject.org> References: <49FAC244.3050707@fedoraproject.org> <1241191605.2811.8.camel@adam.local.net> <49FB1872.50103@fedoraproject.org> Message-ID: <20090501160637.GK6034@localhost.localdomain> On Fri, May 01, 2009 at 09:12:42PM +0530, Rahul Sundaram wrote: > On 05/01/2009 08:56 PM, Adam Williamson wrote: > > On Fri, 2009-05-01 at 15:05 +0530, Rahul Sundaram wrote: > >> Hi, > >> > >> I have posted a draft of the Fedora 11 FAQ at > >> > >> https://fedoraproject.org/wiki/Fedora_11_FAQ > >> > >> Feel free to edit the wiki if you want to highlight anything else or > >> drop me a mail and I will add them. > > > > It's nicely written, but it seems like a bit of an awkward document in > > conception - somewhere between Release Notes and Errata and a general > > Fedora (not really Fedora 11) FAQ. Couldn't we somehow reconcile it with > > some of the other release documentation to avoid duplication of effort? > > In the past, such release specific FAQ's have often been very helpful in > addressing the repeatedly asked questions. I can't anticipate the FAQ's > so the initial seed information tends to be a bit more generic. I cross > reference existing documentation such as release notes to avoid > duplication where possible. I see places where that's not done, the 'alsamixer' workaround among them. If you could look at the preview release notes and link to the appropriate places (using "f11" instead of "f11preview" in the URL), that would be good. Documentation maintenance is much more difficult if it has to be done in multiple places rather than through incorporation by reference. > I am not very happy with the current release notes structure and will be > spending more effort for the next release to get it better match what I > think is the right style. The Docs team remains open to assistance and welcomes input. I would recommend you start helping with the ideation process now, since the discussion has already started: http://www.redhat.com/archives/fedora-docs-list/2009-May/msg00001.html -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From william.jon.mccann at gmail.com Fri May 1 16:09:24 2009 From: william.jon.mccann at gmail.com (William Jon McCann) Date: Fri, 1 May 2009 12:09:24 -0400 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <1241191092.2811.5.camel@adam.local.net> References: <1240762219.2770.9.camel@localhost.localdomain> <1241116151.32113.273.camel@adam.local.net> <939dd5750904301208l19123893rc9cd68609f8980be@mail.gmail.com> <49F9FD08.9010904@redhat.com> <20090430194821.GA25787@nostromo.devel.redhat.com> <1241123673.32113.299.camel@adam.local.net> <20090430210019.GC25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> Message-ID: <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> Hey Adam, On Fri, May 1, 2009 at 11:18 AM, Adam Williamson wrote: > On Fri, 2009-05-01 at 10:20 -0400, Bill Nottingham wrote: > >> Hey, if you didn't have time to test, that's OK. Not everyone does. >> But when we're trying to figure out real issues, Rumsfeldian pseudo-analysis >> based on *KNOWN* inaccuracies doesn't help. > > Oh, fun. I was hoping when I went to bed last night that my last post > won the thread, but of course it's more fun for everyone to tactically > ignore it and continue tearing strips out of each other. Not really sure about this winning threads business but, speaking only for myself, I chose to ignore it in part because the thread clearly jumped the shark when you replied to your own message at least twice. And the rest of us likely already know about pavucontrol. Lennart wrote it and we designed the new volume control to replace it (for our target users). The fact that it is still currently in the menus is almost certainly an oversight - not a confirmation that what you are proposing is a good idea. But frankly, at this point you're out-emailing the rest of us and we're not going to be able to compete on these terms. Jon From ivazqueznet at gmail.com Fri May 1 16:17:02 2009 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 01 May 2009 12:17:02 -0400 Subject: Orphaning azureus In-Reply-To: <20090501093346.d78ac4d9.zaitcev@redhat.com> References: <200904301646.47342.konrad@tylerc.org> <20090430220315.7d9e4176.zaitcev@redhat.com> <1241150896.3894.70.camel@ignacio.lan> <20090501093346.d78ac4d9.zaitcev@redhat.com> Message-ID: <1241194622.3894.109.camel@ignacio.lan> On Fri, 2009-05-01 at 09:33 -0600, Pete Zaitcev wrote: > On Fri, 01 May 2009 00:08:16 -0400, Ignacio Vazquez-Abrams wrote: > > > > > It's a steaming pile of crap, I don't use it personally, [] > > > > > > Do you suggest anything as a replacement? > > > > Deluge and Transmission each have about 80-90% of Azureus's > > functionality. > > What do you actually use for Fedora ISOs? I currently use Transmission since I found Deluge a bit top-heavy as well. I lose a few more features, but I gain more memory back. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mclasen at redhat.com Fri May 1 16:24:58 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 01 May 2009 12:24:58 -0400 Subject: Annoying screen blanking In-Reply-To: <1241193267.2811.15.camel@adam.local.net> References: <1241190083.7744.54.camel@dimi.lattica.com> <1241191861.2811.10.camel@adam.local.net> <1241192327.7744.59.camel@dimi.lattica.com> <49FB193B.4070101@fedoraproject.org> <1241193267.2811.15.camel@adam.local.net> Message-ID: <1241195098.2471.1.camel@localhost.localdomain> On Fri, 2009-05-01 at 08:54 -0700, Adam Williamson wrote: > > The bug was set to block F11Blocker for a while, but Matthias disagreed > and changed it to F11Target (which is the 'nice to have but we won't > delay the release' tracker). Personally I disagree, but I'm not > comfortable getting into a revision war with Matthias over it. Matthias, > did you make that decision knowing that it's affecting a lot of people, > on AC as well as battery power? Feel free to move it back, if it makes people feel better about the importance of their bugs. For me the important thing is to get it fixed. Which I will, but probably not before Richard recovers from his wedding celebrations... From awilliam at redhat.com Fri May 1 16:37:34 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 01 May 2009 09:37:34 -0700 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> References: <1240762219.2770.9.camel@localhost.localdomain> <1241116151.32113.273.camel@adam.local.net> <939dd5750904301208l19123893rc9cd68609f8980be@mail.gmail.com> <49F9FD08.9010904@redhat.com> <20090430194821.GA25787@nostromo.devel.redhat.com> <1241123673.32113.299.camel@adam.local.net> <20090430210019.GC25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> Message-ID: <1241195854.2811.20.camel@adam.local.net> On Fri, 2009-05-01 at 12:09 -0400, William Jon McCann wrote: > Not really sure about this winning threads business but, speaking only > for myself, I chose to ignore it in part because the thread clearly > jumped the shark when you replied to your own message at least twice. I do that when I realize it's important to expand on something I mentioned only in passing. > And the rest of us likely already know about pavucontrol. Lennart > wrote it and we designed the new volume control to replace it (for our > target users). The fact that it is still currently in the menus is > almost certainly an oversight - not a confirmation that what you are > proposing is a good idea. That doesn't explain why it shipped alongside gnome-volume-control for the last three releases, when all along you have been telling us that shipping two graphical volume control utilities by default is a terrible idea that will confuse people and is bad UI. And, I really should have anticipated your reaction. Of *course* the correct response to me pointing out that we're already shipping two volume control applications by default and have been for a while with no apparent problems is not to accept that this means it's probably a perfectly good idea to have multiple applications so long as they each expose important functionality that the other doesn't. No, the correct response is to say that we should immediately drop one to maintain ideological purity. I mean...sheesh. Are you serious? We should drop pavucontrol because including it is an 'oversight'? Despite the fact that, as I pointed out, gnome-volume-control has no profile support and hence you can only use pavucontrol to switch from analog to digital output, or from analog stereo to analog surround? And even *Lennart* advocates using it this way, in various bug reports? Presumably none of your 'target users' has an S/PDIF output either? Or an analog surround sound setup? This is just getting ridiculous. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From billcrawford1970 at gmail.com Fri May 1 16:38:50 2009 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Fri, 01 May 2009 17:38:50 +0100 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> References: <1240762219.2770.9.camel@localhost.localdomain> <1241116151.32113.273.camel@adam.local.net> <939dd5750904301208l19123893rc9cd68609f8980be@mail.gmail.com> <49F9FD08.9010904@redhat.com> <20090430194821.GA25787@nostromo.devel.redhat.com> <1241123673.32113.299.camel@adam.local.net> <20090430210019.GC25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> Message-ID: <49FB259A.7060207@googlemail.com> William Jon McCann wrote: ... > But frankly, at this point you're out-emailing the rest of us and > we're not going to be able to compete on these terms. *maniacal laugh* Yes, he's had the patience to reply to all the arguments presented, to which the response is ... "Come on Tonto, we're outnumbered. Oh, and they're faster than we are." From cdahlin at redhat.com Fri May 1 16:44:58 2009 From: cdahlin at redhat.com (Casey Dahlin) Date: Fri, 01 May 2009 12:44:58 -0400 Subject: I wanted to open a discussion for F12 about running services on shell accounts. In-Reply-To: <49FB07B0.50100@redhat.com> References: <49FB07B0.50100@redhat.com> Message-ID: <49FB270A.8040904@redhat.com> Daniel J Walsh wrote: > I would like to run restorecond as a user service rather then as system > service. I want to run it under the Users UID and under with the users > context. > > Then I can have it watch for creation of files in the users home > directory and be the equivalent of running restorecon ~/ by the user. > > Currently I can do this with the system service restorecond, but that is > running as root and has to be able to relabel everything. > > I want to use something like DBUS so I have only one restorecond running > for each user no matter how many times the user logs in. > > I built a dbus service and everything works fine. Except that I want > this to work on a server when I ssh to a machine. Or if I log in via > the console terminal. In those cases I do not have a dbus session so I > am out of luck. > > I could have restorecond started via /etc/profile.d but I would need to > do something for csh and bash, and I could end up with multiple > restorecond under the same UID. I could build into restorecond some > kind of locking to prevent this, but the dbus solution eliminates me > from having to do some potentially buggy code. > > I doubt I am the only one who wants to run sessions on login for > terminal users. Any thoughts on running a dbus session for a terminal > session? > I'm not sure about how you could do it now, but the next version of upstart should have a lot of tools to make this easier. --CJD From mw_triad at users.sourceforge.net Fri May 1 16:47:01 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Fri, 01 May 2009 11:47:01 -0500 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <20090501154208.GB26141@tango.0pointer.de> References: <1240762219.2770.9.camel@localhost.localdomain> <1241027428.3139.9.camel@localhost.localdomain> <939dd5750904301050o4efb3efau356882109b2e206b@mail.gmail.com> <1241116151.32113.273.camel@adam.local.net> <939dd5750904301208l19123893rc9cd68609f8980be@mail.gmail.com> <49F9FD08.9010904@redhat.com> <20090430194821.GA25787@nostromo.devel.redhat.com> <1241123673.32113.299.camel@adam.local.net> <20090430210019.GC25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> <20090501154208.GB26141@tango.0pointer.de> Message-ID: Okay, first, since you're "one of those people"... /Please do not quote my e-mail address unobfuscated in message bodies./ Now that that's out of the way... Lennart Poettering wrote: > I think this mail of mine still summarizes perfectly how exotic your > three use cases are (at the end): > > https://www.redhat.com/archives/fedora-devel-list/2009-April/msg02153.html > > But of course, you didn't respond to that mail... ...but I did[1] (not to that specific mail, but to the assertion you were making). I still maintain that using line-in to connect a second device to one set of speakers is *not* exotic (or at least, not nearly as exotic as you clearly feel that it is). 1: http://permalink.gmane.org/gmane.linux.redhat.fedora.devel/111401 -- Matthew "Will somebody get this walking carpet out of my way?!" -- Princess Leia Organa (Star Wars IV) From rc040203 at freenet.de Fri May 1 18:05:26 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 01 May 2009 20:05:26 +0200 Subject: RFC: Fedora 11 FAQ In-Reply-To: <20090501160637.GK6034@localhost.localdomain> References: <49FAC244.3050707@fedoraproject.org> <1241191605.2811.8.camel@adam.local.net> <49FB1872.50103@fedoraproject.org> <20090501160637.GK6034@localhost.localdomain> Message-ID: <49FB39E6.1000702@freenet.de> Paul W. Frields wrote: > On Fri, May 01, 2009 at 09:12:42PM +0530, Rahul Sundaram wrote: >> On 05/01/2009 08:56 PM, Adam Williamson wrote: >>> On Fri, 2009-05-01 at 15:05 +0530, Rahul Sundaram wrote: >>>> Hi, >>>> >>>> I have posted a draft of the Fedora 11 FAQ at >>>> >>>> https://fedoraproject.org/wiki/Fedora_11_FAQ >>>> >>>> Feel free to edit the wiki if you want to highlight anything else or >>>> drop me a mail and I will add them. >>> It's nicely written, but it seems like a bit of an awkward document in >>> conception - somewhere between Release Notes and Errata and a general >>> Fedora (not really Fedora 11) FAQ. Couldn't we somehow reconcile it with >>> some of the other release documentation to avoid duplication of effort? >> In the past, such release specific FAQ's have often been very helpful in >> addressing the repeatedly asked questions. I can't anticipate the FAQ's >> so the initial seed information tends to be a bit more generic. I cross >> reference existing documentation such as release notes to avoid >> duplication where possible. > > I see places where that's not done, the 'alsamixer' workaround among > them. IMO the alsamixer/pulseaudio section lacks any description of what to users are supposed to do to get their issues fixed. Ralf From stickster at gmail.com Fri May 1 19:03:54 2009 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 1 May 2009 15:03:54 -0400 Subject: RFC: Fedora 11 FAQ In-Reply-To: <49FB39E6.1000702@freenet.de> References: <49FAC244.3050707@fedoraproject.org> <1241191605.2811.8.camel@adam.local.net> <49FB1872.50103@fedoraproject.org> <20090501160637.GK6034@localhost.localdomain> <49FB39E6.1000702@freenet.de> Message-ID: <20090501190354.GT6034@localhost.localdomain> On Fri, May 01, 2009 at 08:05:26PM +0200, Ralf Corsepius wrote: > Paul W. Frields wrote: >> On Fri, May 01, 2009 at 09:12:42PM +0530, Rahul Sundaram wrote: >>> On 05/01/2009 08:56 PM, Adam Williamson wrote: >>>> On Fri, 2009-05-01 at 15:05 +0530, Rahul Sundaram wrote: >>>>> Hi, >>>>> >>>>> I have posted a draft of the Fedora 11 FAQ at >>>>> >>>>> https://fedoraproject.org/wiki/Fedora_11_FAQ >>>>> >>>>> Feel free to edit the wiki if you want to highlight anything else or >>>>> drop me a mail and I will add them. >>>> It's nicely written, but it seems like a bit of an awkward document in >>>> conception - somewhere between Release Notes and Errata and a general >>>> Fedora (not really Fedora 11) FAQ. Couldn't we somehow reconcile it with >>>> some of the other release documentation to avoid duplication of effort? >>> In the past, such release specific FAQ's have often been very helpful in >>> addressing the repeatedly asked questions. I can't anticipate the FAQ's >>> so the initial seed information tends to be a bit more generic. I cross >>> reference existing documentation such as release notes to avoid >>> duplication where possible. >> >> I see places where that's not done, the 'alsamixer' workaround among >> them. > IMO the alsamixer/pulseaudio section lacks any description of what to > users are supposed to do to get their issues fixed. I think the proper thing to do is to simply refer users to: https://fedoraproject.org/wiki/Documentation_Multimedia_Beat#Volume_Control I've added a note there on how to file bugs to help solve the underlying problem. There's some sort of markup nonsense going on that's making it appear incorrectly right now, but we'll straighten it out in a few minutes, hopefully. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From jkeating at redhat.com Fri May 1 19:19:28 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 01 May 2009 12:19:28 -0700 Subject: Annoying screen blanking In-Reply-To: <1241193267.2811.15.camel@adam.local.net> References: <1241190083.7744.54.camel@dimi.lattica.com> <1241191861.2811.10.camel@adam.local.net> <1241192327.7744.59.camel@dimi.lattica.com> <49FB193B.4070101@fedoraproject.org> <1241193267.2811.15.camel@adam.local.net> Message-ID: <1241205568.3570.19.camel@localhost.localdomain> On Fri, 2009-05-01 at 08:54 -0700, Adam Williamson wrote: > > Right, for now the priority/severity fields are totally ignored. (I'm > working on a proposal regarding that, you'll see a mail soon). > > The bug was set to block F11Blocker for a while, but Matthias disagreed > and changed it to F11Target (which is the 'nice to have but we won't > delay the release' tracker). Personally I disagree, but I'm not > comfortable getting into a revision war with Matthias over it. Matthias, > did you make that decision knowing that it's affecting a lot of people, > on AC as well as battery power? I would agree with Matthias here. This isn't a data loss bug, and it's something that has a fairly easy workaround for now, and can easily be fixed with an update later. If everything else was fixed and only this bug remained, I wouldn't slip the release date for it. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bochecha at fedoraproject.org Fri May 1 19:19:27 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Fri, 1 May 2009 21:19:27 +0200 Subject: Annoying screen blanking In-Reply-To: <1241195098.2471.1.camel@localhost.localdomain> References: <1241190083.7744.54.camel@dimi.lattica.com> <1241191861.2811.10.camel@adam.local.net> <1241192327.7744.59.camel@dimi.lattica.com> <49FB193B.4070101@fedoraproject.org> <1241193267.2811.15.camel@adam.local.net> <1241195098.2471.1.camel@localhost.localdomain> Message-ID: <2d319b780905011219s52b766bdh216b589163595941@mail.gmail.com> I didn't want to reply simply to say ? me too ?, but this time it was worse: I was actually moving the mouse pointer with my touchpad when the screen blanked :-/ Could this be the same issue ? ---------- Mathieu Bridon (bochecha) From ndbecker2 at gmail.com Fri May 1 19:27:58 2009 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 01 May 2009 15:27:58 -0400 Subject: Can I do test builds on F11? Message-ID: I need to do a test build on F11. Can I check into cvs and do test build (but not try to update any package)? From Fedora at FamilleCollet.com Fri May 1 19:46:40 2009 From: Fedora at FamilleCollet.com (Remi Collet) Date: Fri, 01 May 2009 21:46:40 +0200 Subject: Can I do test builds on F11? In-Reply-To: References: Message-ID: <49FB51A0.2080908@FamilleCollet.com> Le 01/05/2009 21:27, Neal Becker a ?crit : > I need to do a test build on F11. Can I check into cvs and do test build > (but not try to update any package)? Using mock -r fedora-rawhide- Or, if you have a fedora account, koji koji build --scratch dist-f11 + From sgrubb at redhat.com Fri May 1 20:34:37 2009 From: sgrubb at redhat.com (Steve Grubb) Date: Fri, 1 May 2009 16:34:37 -0400 Subject: I wanted to open a discussion for F12 about running services on shell accounts. In-Reply-To: <49FB07B0.50100@redhat.com> References: <49FB07B0.50100@redhat.com> Message-ID: <200905011634.46707.sgrubb@redhat.com> On Friday 01 May 2009 10:31:12 am Daniel J Walsh wrote: > I want to use something like DBUS so I have only one restorecond running > for each user no matter how many times the user logs in. Using dbus messes up the audit trail. Anyone that has security requirements to know why/how an xattr changed will not like this. > I doubt I am the only one who wants to run sessions on login for > terminal users. Any thoughts on running a dbus session for a terminal > session? You could also make a pam session module that starts it. If its after the pam_loginuid module, then the session will be correct. -Steve From David.Avery at united.com Fri May 1 20:34:50 2009 From: David.Avery at united.com (Avery, David [DENTK]) Date: Fri, 1 May 2009 14:34:50 -0600 Subject: Annoying screen blanking In-Reply-To: <1241205568.3570.19.camel@localhost.localdomain> References: <1241190083.7744.54.camel@dimi.lattica.com><1241191861.2811.10.camel@adam.local.net><1241192327.7744.59.camel@dimi.lattica.com><49FB193B.4070101@fedoraproject.org><1241193267.2811.15.camel@adam.local.net> <1241205568.3570.19.camel@localhost.localdomain> Message-ID: My concern is this bug makes Fedora 11 a no-go on systems that are running as display drivers or kiosks where there as a real need for poweroff == never, screeenblank == never. -----Original Message----- From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-bounces at redhat.com] On Behalf Of Jesse Keating Sent: Friday, May 01, 2009 1:19 PM To: fedora-devel-list at redhat.com Subject: Re: Annoying screen blanking On Fri, 2009-05-01 at 08:54 -0700, Adam Williamson wrote: > > Right, for now the priority/severity fields are totally ignored. (I'm > working on a proposal regarding that, you'll see a mail soon). > > The bug was set to block F11Blocker for a while, but Matthias disagreed > and changed it to F11Target (which is the 'nice to have but we won't > delay the release' tracker). Personally I disagree, but I'm not > comfortable getting into a revision war with Matthias over it. Matthias, > did you make that decision knowing that it's affecting a lot of people, > on AC as well as battery power? I would agree with Matthias here. This isn't a data loss bug, and it's something that has a fairly easy workaround for now, and can easily be fixed with an update later. If everything else was fixed and only this bug remained, I wouldn't slip the release date for it. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating From bruno at wolff.to Fri May 1 21:34:37 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Fri, 1 May 2009 16:34:37 -0500 Subject: I wanted to open a discussion for F12 about running services on shell accounts. In-Reply-To: <49FB07B0.50100@redhat.com> References: <49FB07B0.50100@redhat.com> Message-ID: <20090501213437.GA20032@wolff.to> On Fri, May 01, 2009 at 10:31:12 -0400, Daniel J Walsh wrote: > I would like to run restorecond as a user service rather then as system > service. I want to run it under the Users UID and under with the users > context. > > Then I can have it watch for creation of files in the users home > directory and be the equivalent of running restorecon ~/ by the user. This seems to increase the risk of hostile apps being able to get executables relabelled to something they couldn't do directly. If the app has the ability to write the directory it can replace a file labelled with a label it couldn't couldn't assign directly with another file and then wait for restorecond to change the label. While the same thing would happen with a relabel or running restorecon manually, currently there is a lot more opportunity to discover the problem before the file is relabelled. From choeger at cs.tu-berlin.de Fri May 1 21:54:18 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Fri, 01 May 2009 23:54:18 +0200 Subject: presto download saving summary Message-ID: <1241214858.3682.2.camel@choeger6> Hi, presto is really awesome. It cut down a 170MB download on a 320kbit/s line to 5MB today. But where is the Size of all updates downloaded from Presto-enabled repositories: 2.4M Size of updates that would have been downloaded if Presto wasn?t enabled: 24M This is a savings of 90 percent summary gone? (taken from pauls blog entry) I do not get those messages anymore. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From mjg at redhat.com Fri May 1 23:38:35 2009 From: mjg at redhat.com (Matthew Garrett) Date: Sat, 2 May 2009 00:38:35 +0100 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <1241195854.2811.20.camel@adam.local.net> References: <939dd5750904301208l19123893rc9cd68609f8980be@mail.gmail.com> <49F9FD08.9010904@redhat.com> <20090430194821.GA25787@nostromo.devel.redhat.com> <1241123673.32113.299.camel@adam.local.net> <20090430210019.GC25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> Message-ID: <20090501233835.GA28723@srcf.ucam.org> On Fri, May 01, 2009 at 09:37:34AM -0700, Adam Williamson wrote: > That doesn't explain why it shipped alongside gnome-volume-control for > the last three releases, when all along you have been telling us that > shipping two graphical volume control utilities by default is a terrible > idea that will confuse people and is bad UI. You appear to be arguing on the assumption that people never make mistakes. > And, I really should have anticipated your reaction. Of *course* the > correct response to me pointing out that we're already shipping two > volume control applications by default and have been for a while with no > apparent problems is not to accept that this means it's probably a > perfectly good idea to have multiple applications so long as they each > expose important functionality that the other doesn't. No, the correct > response is to say that we should immediately drop one to maintain > ideological purity. How many volume control applications do you want us to ship with? The fact that mistakes have been made in the past is not an argument for further mistakes being made in the future. > I mean...sheesh. Are you serious? We should drop pavucontrol because > including it is an 'oversight'? Despite the fact that, as I pointed out, > gnome-volume-control has no profile support and hence you can only use > pavucontrol to switch from analog to digital output, or from analog > stereo to analog surround? And even *Lennart* advocates using it this > way, in various bug reports? > > Presumably none of your 'target users' has an S/PDIF output either? Or > an analog surround sound setup? > > This is just getting ridiculous. At this point? My personal feeling is that you're being needlessly hostile and appear to be assuming the worst of the desktop people. Can we get back to discussing this rationally rather than simply making observations and turning them into assertions? -- Matthew Garrett | mjg59 at srcf.ucam.org From mw_triad at users.sourceforge.net Sat May 2 00:13:20 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Fri, 01 May 2009 19:13:20 -0500 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <20090501233835.GA28723@srcf.ucam.org> References: <939dd5750904301208l19123893rc9cd68609f8980be@mail.gmail.com> <49F9FD08.9010904@redhat.com> <20090430194821.GA25787@nostromo.devel.redhat.com> <1241123673.32113.299.camel@adam.local.net> <20090430210019.GC25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> Message-ID: Matthew Garrett wrote: > How many volume control applications do you want us to ship with? The > fact that mistakes have been made in the past is not an argument for > further mistakes being made in the future. To ask the dumb question... right now pavucontrol is the only way (AFAIK) right now to change relative volume of individual apps, or choose output device per-app. Without pavucontrol, how is this supposed to be accomplished? (Or are both of these being labeled "exotic" use cases that shan't be supported OOTB?) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- "Will somebody get this walking carpet out of my way?!" -- Princess Leia Organa (Star Wars IV) From mjg at redhat.com Sat May 2 00:25:29 2009 From: mjg at redhat.com (Matthew Garrett) Date: Sat, 2 May 2009 01:25:29 +0100 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: References: <20090430194821.GA25787@nostromo.devel.redhat.com> <1241123673.32113.299.camel@adam.local.net> <20090430210019.GC25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> Message-ID: <20090502002529.GA29316@srcf.ucam.org> On Fri, May 01, 2009 at 07:13:20PM -0500, Matthew Woehlke wrote: > Matthew Garrett wrote: >> How many volume control applications do you want us to ship with? The >> fact that mistakes have been made in the past is not an argument for >> further mistakes being made in the future. > > To ask the dumb question... right now pavucontrol is the only way > (AFAIK) right now to change relative volume of individual apps, or > choose output device per-app. Without pavucontrol, how is this supposed > to be accomplished? Per-stream volume control seems to be present in g-v-c. I'm afraid I've got no idea about per-stream output control - I only have one output device available here. > (Or are both of these being labeled "exotic" use cases that shan't be > supported OOTB?) I don't know. I'd imagine that the first certainly isn't (given that it seems to be supported), but you'd need to ask someone else about the second. -- Matthew Garrett | mjg59 at srcf.ucam.org From awilliam at redhat.com Sat May 2 00:37:33 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 01 May 2009 17:37:33 -0700 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <20090501233835.GA28723@srcf.ucam.org> References: <939dd5750904301208l19123893rc9cd68609f8980be@mail.gmail.com> <49F9FD08.9010904@redhat.com> <20090430194821.GA25787@nostromo.devel.redhat.com> <1241123673.32113.299.camel@adam.local.net> <20090430210019.GC25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> Message-ID: <1241224653.2811.59.camel@adam.local.net> On Sat, 2009-05-02 at 00:38 +0100, Matthew Garrett wrote: > On Fri, May 01, 2009 at 09:37:34AM -0700, Adam Williamson wrote: > > > That doesn't explain why it shipped alongside gnome-volume-control for > > the last three releases, when all along you have been telling us that > > shipping two graphical volume control utilities by default is a terrible > > idea that will confuse people and is bad UI. > > You appear to be arguing on the assumption that people never make > mistakes. Doing something you say is a fundamental interface booboo for three straight releases is a pretty big mistake. I don't believe this was a mistake, I believe it was intentional - we want to ship the shiny new Pulse stuff. And that's fine. It just means the arbitrary "no multiple mixers" argument that's now being used to oppose gst-mixer / gnome-alsamixer is an argument of convenience. > > And, I really should have anticipated your reaction. Of *course* the > > correct response to me pointing out that we're already shipping two > > volume control applications by default and have been for a while with no > > apparent problems is not to accept that this means it's probably a > > perfectly good idea to have multiple applications so long as they each > > expose important functionality that the other doesn't. No, the correct > > response is to say that we should immediately drop one to maintain > > ideological purity. > > How many volume control applications do you want us to ship with? The > fact that mistakes have been made in the past is not an argument for > further mistakes being made in the future. Frankly, now I've noticed we *already* have two, I'm inclined to favour the "drop the new gnome-volume-control entirely" argument, if you want to keep the number of mixers down. Here's the problem. There are two really important use cases that gnome-volume-control doesn't cover: profile switching - i.e. enabling digital output (or analog surround on cards that do that, but that's not *so* important), and input switching. Legacy mixers - gnome-alsamixer / gst-mixer - handle both of these cases and everything else you'd want to do with a mixer. Just not very well, but hey, at least it's the same crappy interface people have been used to for a decade. pavucontrol does profile switching, and does it in a very nice way, thanks to the work done on Pulse during this cycle. But it doesn't do input switching. gnome-volume-control doesn't do profile switching *or* input switching. So the only mixers we have that actually cover these really basic use cases are the legacy ones. If you're completely wedded to the new g-v-c, but we want people to be able to do input switching and use digital output, we'd need at least two mixers: g-v-c and a legacy mixer. But then we lose pavucontrol's nice profile switching, which is a bit of a shame. Frankly, the combination that appears to combine the most actual usability with PulseAudio niceness is pavucontrol + a legacy mixer. g-v-c, in functional terms, has exactly no advantages over either pavucontrol or the legacy mixers. Its *only* advantage is that it's a more standard-following GNOME interface than pavucontrol. Whoopee. I don't think that outweighs the fact that it's missing two really important features. I've been ignoring digital output throughout this whole debate because Lennart had argued me out of that one in the initial bug report I filed, but I forgot that his argument depended on pavucontrol. Summary: legacy mixers do everything with a crap interface, pavucontrol does everything except one big thing with a quite nice interface, g-v-c misses two big things and has a marginally nicer interface than pavucontrol. Given that, my opinion is that the options "pavucontrol + legacy mixer" or just "legacy mixer alone" are tied in niceness, and any combination involving the new g-v-c falls rather near the bottom of the pile... > > I mean...sheesh. Are you serious? We should drop pavucontrol because > > including it is an 'oversight'? Despite the fact that, as I pointed out, > > gnome-volume-control has no profile support and hence you can only use > > pavucontrol to switch from analog to digital output, or from analog > > stereo to analog surround? And even *Lennart* advocates using it this > > way, in various bug reports? > > > > Presumably none of your 'target users' has an S/PDIF output either? Or > > an analog surround sound setup? > > > > This is just getting ridiculous. > > At this point? My personal feeling is that you're being needlessly > hostile and appear to be assuming the worst of the desktop people. Can > we get back to discussing this rationally rather than simply making > observations and turning them into assertions? I'd love to be discussing it rationally, but I don't think you guys are. I still haven't seen a convincing refutation of the "we already have multiple mixers" point besides "it's a mistake" - which, even if it's true, makes you guys look rather bad, as it's a fairly large mistake (by your own standards) in three straight stable releases...which doesn't actually seem to have caused any problems, I certainly haven't seen anyone complaining that the presence of pavucontrol alongside gnome-volume-control confused them, in F8, F9, or F10. Where does that leave the "multiple mixers are bad by definition" argument? Even if it *was* a mistake, the fact that it's been in the distro for three releases without apparently causing any trainwrecks seems rather significant to me. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From mjg at redhat.com Sat May 2 00:55:40 2009 From: mjg at redhat.com (Matthew Garrett) Date: Sat, 2 May 2009 01:55:40 +0100 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <1241224653.2811.59.camel@adam.local.net> References: <20090430194821.GA25787@nostromo.devel.redhat.com> <1241123673.32113.299.camel@adam.local.net> <20090430210019.GC25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> Message-ID: <20090502005540.GA29541@srcf.ucam.org> Put simply, any argument based on "Nobody's complained, so it's fine" is fallacious. People expect Linux to be dreadful. If something works they're happy - if it doesn't, it's because Linux isn't ready for the desktop yet. And when we've still got a community that's more inclined to tell people that they should read the documentation rather than ask whether a specific UI is sufficiently understandable, it's hardly unsurprisingly that people aren't going to spend a great deal of time complaining about how unintuitive they found some aspect of UI. If people raise issues with a suggestion and the counterargument is "Users haven't raised this problem" then we can't draw conclusions about why they haven't. Maybe it's because the average user is smart enough to figure out that the multitude of volume controls we ship are all intended for subtly different purposes. Maybe it's because they can't be bothered filing bugs. Maybe it's because they're scared of raising a contentious subject. Who knows? In the end we still come down to making decisions based on the opinions of people we deem to be experts in the field. And if you don't trust the desktop team to make the appropriate decision in this case then it would be helpful for you to say so plainly. -- Matthew Garrett | mjg59 at srcf.ucam.org From zaitcev at redhat.com Sat May 2 00:55:45 2009 From: zaitcev at redhat.com (Pete Zaitcev) Date: Fri, 1 May 2009 18:55:45 -0600 Subject: Orphaning azureus In-Reply-To: <1241194622.3894.109.camel@ignacio.lan> References: <200904301646.47342.konrad@tylerc.org> <20090430220315.7d9e4176.zaitcev@redhat.com> <1241150896.3894.70.camel@ignacio.lan> <20090501093346.d78ac4d9.zaitcev@redhat.com> <1241194622.3894.109.camel@ignacio.lan> Message-ID: <20090501185545.8db13ff7.zaitcev@redhat.com> On Fri, 01 May 2009 12:17:02 -0400, Ignacio Vazquez-Abrams wrote: > > What do you actually use for Fedora ISOs? > > I currently use Transmission since I found Deluge a bit top-heavy as > well. I lose a few more features, but I gain more memory back. Thanks a lot. Looks like we're good on this. -- Pete From cmadams at hiwaay.net Sat May 2 01:40:29 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 1 May 2009 20:40:29 -0500 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <1241224653.2811.59.camel@adam.local.net> References: <20090430194821.GA25787@nostromo.devel.redhat.com> <1241123673.32113.299.camel@adam.local.net> <20090430210019.GC25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> Message-ID: <20090502014029.GC1496739@hiwaay.net> Once upon a time, Adam Williamson said: > pavucontrol does profile switching, and does it in a very nice way, > thanks to the work done on Pulse during this cycle. But it doesn't do > input switching. > > gnome-volume-control doesn't do profile switching *or* input switching. If pavucontrol existed and worked better, why did we get yet another audio control written from scratch? Why not just work on one of the many existing ones (like pavucontrol that already knows how to talk to PA)? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From cra at WPI.EDU Sat May 2 01:42:59 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 1 May 2009 21:42:59 -0400 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <20090502014029.GC1496739@hiwaay.net> References: <1241123673.32113.299.camel@adam.local.net> <20090430210019.GC25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> <20090502014029.GC1496739@hiwaay.net> Message-ID: <20090502014259.GA28052@angus.ind.WPI.EDU> On Fri, May 01, 2009 at 08:40:29PM -0500, Chris Adams wrote: > Once upon a time, Adam Williamson said: > > pavucontrol does profile switching, and does it in a very nice way, > > thanks to the work done on Pulse during this cycle. But it doesn't do > > input switching. > > > > gnome-volume-control doesn't do profile switching *or* input switching. > > If pavucontrol existed and worked better, why did we get yet another > audio control written from scratch? Why not just work on one of the > many existing ones (like pavucontrol that already knows how to talk to > PA)? I wonder how hard it would be to add input switching to pavucontrol...then we could ditch g-v-c and the legacy mixers and keep the one pavucontrol that handles all the use cases... From cdahlin at redhat.com Sat May 2 02:11:45 2009 From: cdahlin at redhat.com (Casey Dahlin) Date: Fri, 01 May 2009 22:11:45 -0400 Subject: Abandon "Default Desktop" In-Reply-To: <49F97AA9.60601@googlemail.com> References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <16de708d0904271530v135a0a4ep3ab020d798a36c5e@mail.gmail.com> <3adc77210904271556i502559acn37c2002c124a80ff@mail.gmail.com> <49F70FB1.20603@hi.is> <3adc77210904280848pb8000a2h1189866bd6d17db5@mail.gmail.com> <1240953073.32113.225.camel@adam.local.net> <49F80664.6010809@robertoragusa.it> <1241037119.3213.2.camel@localhost.localdomain> <6c3f5e6c0904291514n371fa179k1901af657e05a5b5@mail.gmail.com> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F97AA9.60601@googlemail.com> Message-ID: <49FBABE1.50207@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bill Crawford wrote: > Roberto Ragusa wrote: > ... >> The GNOME desktop tries to avoid user choices. >> The KDE desktop tries to encourage user choices. >> >> And the decision on allowing a desktop choice divides people >> in two camps: >> 1) those that think the user should not choose >> 2) those that think the user should have to choose >> >> I'd bet people in 1) are GNOME users and people in 2) are KDE users. > > On the whole, however, I'm in the "those who think the user should be > allowed to choose" camp ;o) > Which is where we are now. - --CJD -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkn7q+EACgkQIHOkVH4pLz44cQCfRB6gAGG9+sos02UOpi9LLo6H UcgAmwfCkUVLXSjPmPVgvUdN/S9JWRK3 =C3fv -----END PGP SIGNATURE----- From awilliam at redhat.com Sat May 2 05:24:33 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 01 May 2009 22:24:33 -0700 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <20090502005540.GA29541@srcf.ucam.org> References: <20090430194821.GA25787@nostromo.devel.redhat.com> <1241123673.32113.299.camel@adam.local.net> <20090430210019.GC25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> <20090502005540.GA29541@srcf.ucam.org> Message-ID: <1241241873.2811.106.camel@adam.local.net> On Sat, 2009-05-02 at 01:55 +0100, Matthew Garrett wrote: > Put simply, any argument based on "Nobody's complained, so it's fine" is > fallacious. People expect Linux to be dreadful. If something works > they're happy - if it doesn't, it's because Linux isn't ready for the > desktop yet. And when we've still got a community that's more inclined > to tell people that they should read the documentation rather than ask > whether a specific UI is sufficiently understandable, it's hardly > unsurprisingly that people aren't going to spend a great deal of time > complaining about how unintuitive they found some aspect of UI. > > If people raise issues with a suggestion and the counterargument is > "Users haven't raised this problem" then we can't draw conclusions about > why they haven't. Maybe it's because the average user is smart enough to > figure out that the multitude of volume controls we ship are all > intended for subtly different purposes. Maybe it's because they can't be > bothered filing bugs. Maybe it's because they're scared of raising a > contentious subject. Who knows? In the end we still come down to making > decisions based on the opinions of people we deem to be experts in the > field. And if you don't trust the desktop team to make the appropriate > decision in this case then it would be helpful for you to say so > plainly. Let's see. I don't think you're really wrong. It's not a perfect basis for argument. However, let me see if I can summarize the desktop team's position: "We're in the best position to know what's right for the desktop, and we say that the best thing to do is just ship one mixer application. The one that can't handle anything except analog stereo output when there's no problem with ALSA. We consider surround output, digital output, input switching, input monitoring and all the known and as-yet unknown but undoubtedly existent cases where there *is* a problem with the ALSA mixer and hence g-v-c doesn't work properly to be, as a whole, not significant enough to make it worthwhile shipping a different mixer, either alongside g-v-c or instead of it. We're the best people to make the decision because we know what we're doing when it comes to building a desktop. Yes, we've actually been shipping two mixers by default for three releases now (and we didn't notice this until someone else pointed it out), but that's just, er, a mistake. We're still the *only* ones who can be trusted to know what we're doing here!" I'm really, honestly, not in a nasty way, not finding that to be 100% convincing. I'm not working on the basis of "do I trust the desktop team to make this decision and get it right". That's not really how I'm looking at it. I'm just evaluating this particular case, on its merits, and I don't think the call that the desktop team made was the right one. I don't really care about the reasons behind that or the politics or yadda yadda yadda. I certainly agree that the process could have been managed better - objections could have been raised much earlier - and that's something it's entirely worth dissecting...but I don't think it should take precedence over making sure Fedora 11 is the best product it can be. I just don't think shipping a mixer that doesn't handle analog surround output, digital output, input switching, input monitoring or the multiple cases of buggy volume supplied by ALSA (there's six of these bugs filed so far, btw, and counting) as our *only* graphical mixer is a good decision. I raised this concern through the proper channels, it was picked up by FESco - not at my instigation, btw, I was called into the meeting after the topic had already come up - and FESco came out in the same position I've been espousing. At that point I thought the whole thing was settled and I went on to actually work on the technical side of what needing doing, whereupon the whole argument got dragged out of its grave on this list and we had to go through everything again, three times over. I'm sorry if I don't handle the political side of things that greatly, and I'm sorry if I sometimes come off as too aggressive. That's my fault. I'm not trying to rub anyone up the wrong way. It's just a bit frustrating that no-one seems to want to engage in the actual blood and guts of this issue; all I'm hearing is vague theoretical arguments about why *this* group of people is better entitled to make the decision or why *that* line of argument is theoretically flawed or yadda yadda. I'm just not finding it very productive. Please credit me with a bit of experience and knowledge in this field too...yes, I've not been around Fedora very long, but I *have* been on the very sharp and pointy end of distribution releases at Another Place for three or four years, being The Guy for several tens of thousands of people to yell at when they don't like something in a new release, also being the guy who tracks release critical bugs and writes all the release documentation, including the Errata. I think I have a pretty decent track record of knowing a hot-button issue when I see one, and the idea that we should ship the new gnome-volume-control as our sole GUI volume control application on the desktop operating system images that most people think of as 'Fedora' (the default install you get off the DVD, and the GNOME live spin - the live spin you get if you don't explicitly select a different one, and the one we mostly hand out at events, covered in Fedora logos) just does not feel like a winning proposition to me. All I've been trying to do is back that position up with solid reasoning and logic. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From petersen at redhat.com Sat May 2 05:29:59 2009 From: petersen at redhat.com (Jens Petersen) Date: Sat, 2 May 2009 01:29:59 -0400 (EDT) Subject: Abandon "Default Desktop" In-Reply-To: <16de708d0904301051r647b9f14qc1fe7d343bdbd778@mail.gmail.com> Message-ID: <2033840182.237361241242199768.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> ----- "Arthur Pemberton" wrote: > The get-fedora page just has a link to the KDE page > which is directed at KDE fans. At list the the get-prerelease page has KDE Live Media listed below Fedora Desktop Live Media now. So perhaps that is how it will be for F11? Jens From awilliam at redhat.com Sat May 2 05:17:45 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 01 May 2009 22:17:45 -0700 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <20090502005540.GA29541@srcf.ucam.org> References: <20090430194821.GA25787@nostromo.devel.redhat.com> <1241123673.32113.299.camel@adam.local.net> <20090430210019.GC25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> <20090502005540.GA29541@srcf.ucam.org> Message-ID: <1241241465.2811.98.camel@adam.local.net> On Sat, 2009-05-02 at 01:55 +0100, Matthew Garrett wrote: > Put simply, any argument based on "Nobody's complained, so it's fine" is > fallacious. People expect Linux to be dreadful. If something works > they're happy - if it doesn't, it's because Linux isn't ready for the > desktop yet. And when we've still got a community that's more inclined > to tell people that they should read the documentation rather than ask > whether a specific UI is sufficiently understandable, it's hardly > unsurprisingly that people aren't going to spend a great deal of time > complaining about how unintuitive they found some aspect of UI. > > If people raise issues with a suggestion and the counterargument is > "Users haven't raised this problem" then we can't draw conclusions about > why they haven't. Maybe it's because the average user is smart enough to > figure out that the multitude of volume controls we ship are all > intended for subtly different purposes. Maybe it's because they can't be > bothered filing bugs. Maybe it's because they're scared of raising a > contentious subject. Who knows? In the end we still come down to making > decisions based on the opinions of people we deem to be experts in the > field. And if you don't trust the desktop team to make the appropriate > decision in this case then it would be helpful for you to say so > plainly. Let's see. I don't think you're really wrong. It's not a perfect basis for argument. However, let me see if I can summarize the desktop team's position: "We're in the best position to know what's right for the desktop, and we say that the best thing to do is just ship one mixer application. The one that can't handle anything except analog stereo output when there's no problem with ALSA. We consider surround output, digital output, input switching, input monitoring and all the known and as-yet unknown but undoubtedly existent cases where there *is* a problem with the ALSA mixer and hence g-v-c doesn't work properly to be, as a whole, not significant enough to make it worthwhile shipping a different mixer, either alongside g-v-c or instead of it. We're the best people to make the decision because we know what we're doing when it comes to building a desktop. Yes, we've actually been shipping two mixers by default for three releases now (and we didn't notice this until someone else pointed it out), but that's just, er, a mistake. We're still the *only* ones who can be trusted to know what we're doing here!" I'm really, honestly, not in a nasty way, not finding that to be 100% convincing. I'm not working on the basis of "do I trust the desktop team to make this decision and get it right". That's not really how I'm looking at it. I'm just evaluating this particular case, on its merits, and I don't think the call that the desktop team made was the right one. I don't really care about the reasons behind that or the politics or yadda yadda yadda. I certainly agree that the process could have been managed better - objections could have been raised much earlier - and that's something it's entirely worth dissecting...but I don't think it should take precedence over making sure Fedora 11 is the best product it can be. I just don't think shipping a mixer that doesn't handle analog surround output, digital output, input switching, input monitoring or the multiple cases of buggy volume supplied by ALSA (there's six of these bugs filed so far, btw, and counting) as our *only* graphical mixer is a good decision. I raised this concern through the proper channels, it was picked up by FESco - not at my instigation, btw, I was called into the meeting after the topic had already come up - and FESco came out in the same position I've been espousing. At that point I thought the whole thing was settled and I went on to actually work on the technical side of what needing doing, whereupon the whole argument got dragged out of its grave on this list and we had to go through everything again, three times over. I'm sorry if I don't handle the political side of things that greatly, and I'm sorry if I sometimes come off as too aggressive. That's my fault. I'm not trying to rub anyone up the wrong way. It's just a bit frustrating that no-one seems to want to engage in the actual blood and guts of this issue; all I'm hearing is vague theoretical arguments about why *this* group of people is better entitled to make the decision or why *that* line of argument is theoretically flawed or yadda yadda. I'm just not finding it very productive. Please credit me with a bit of experience and knowledge in this field too...yes, I've not been around Fedora very long, but I *have* been on the very sharp and pointy end of distribution releases at Another Place for three or four years, being The Guy for several tens of thousands of people to yell at when they don't like something in a new release, also being the guy who tracks release critical bugs and writes all the release documentation, including the Errata. I think I have a pretty decent track record of knowing a hot-button issue when I see one, and the idea that we should ship the new gnome-volume-control as our sole GUI volume control application on the desktop operating system images that most people think of as 'Fedora' (the default install you get off the DVD, and the GNOME live spin - the live spin you get if you don't explicitly select a different one, and the one we mostly hand out at events, covered in Fedora logos) just does not feel like a winning proposition to me. All I've been trying to do is back that position up with solid reasoning and logic. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From clive at vacuumtube.org.uk Sat May 2 08:37:19 2009 From: clive at vacuumtube.org.uk (Clive Messer) Date: Sat, 2 May 2009 09:37:19 +0100 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <20090502005540.GA29541@srcf.ucam.org> References: <20090430194821.GA25787@nostromo.devel.redhat.com> <1241224653.2811.59.camel@adam.local.net> <20090502005540.GA29541@srcf.ucam.org> Message-ID: <200905020937.19673.clive@vacuumtube.org.uk> On Saturday 02 May 2009 01:55:40 Matthew Garrett wrote: > And if you don't trust the desktop team to make the appropriate > decision in this case then it would be helpful for you to say so > plainly. Matthew, I'm not picking on you, but as someone standing on the outside looking in, Adam seems to be making structured, reasoned arguments. From my perspective, he appears to be speaking for my interests. I think the Desktop team might be rather surprised how many people do use line-in and would like a mixer installed by default that allows input switching. I've bit my tongue a couple of times whilst reading some of the mixer 'discussion' on the list. It seems to me that most of the people posting with a redhat.com address don't seem to have much of an idea what users (not developers) actually do use a mixer for. ie. not just increasing/decreasing volume levels. And for the record, I'm a fan of Pulseaudio! Regards Clive From denis at poolshark.org Sat May 2 08:47:26 2009 From: denis at poolshark.org (Denis Leroy) Date: Sat, 02 May 2009 10:47:26 +0200 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <20090502014259.GA28052@angus.ind.WPI.EDU> References: <1241123673.32113.299.camel@adam.local.net> <20090430210019.GC25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> <20090502014029.GC1496739@hiwaay.net> <20090502014259.GA28052@angus.ind.WPI.EDU> Message-ID: <49FC089E.40607@poolshark.org> On 05/02/2009 03:42 AM, Chuck Anderson wrote: > I wonder how hard it would be to add input switching to > pavucontrol...then we could ditch g-v-c and the legacy mixers and keep > the one pavucontrol that handles all the use cases... It's not just input switching. Skype is usless if I can't enable the mic boost, and general volume output is too low on my T61 because the 'hidden' PCM slider is set at an arbitrarily low value. -denis From bochecha at fedoraproject.org Sat May 2 09:02:12 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Sat, 2 May 2009 11:02:12 +0200 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <49FC089E.40607@poolshark.org> References: <1241123673.32113.299.camel@adam.local.net> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> <20090502014029.GC1496739@hiwaay.net> <20090502014259.GA28052@angus.ind.WPI.EDU> <49FC089E.40607@poolshark.org> Message-ID: <2d319b780905020202w3ac1dbd1i139fa9d2f448d98a@mail.gmail.com> > It's not just input switching. Skype is usless if I can't enable the mic > boost, and general volume output is too low on my T61 because the 'hidden' > PCM slider is set at an arbitrarily low value. Report it, it will be fixed: https://bugzilla.redhat.com/show_bug.cgi?id=497966 Regards, ---------- Mathieu Bridon (bochecha) From bnocera at redhat.com Sat May 2 10:34:16 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Sat, 02 May 2009 11:34:16 +0100 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <20090502014259.GA28052@angus.ind.WPI.EDU> References: <1241123673.32113.299.camel@adam.local.net> <20090430210019.GC25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> <20090502014029.GC1496739@hiwaay.net> <20090502014259.GA28052@angus.ind.WPI.EDU> Message-ID: <1241260456.20413.2098.camel@cookie.hadess.net> On Fri, 2009-05-01 at 21:42 -0400, Chuck Anderson wrote: > On Fri, May 01, 2009 at 08:40:29PM -0500, Chris Adams wrote: > > Once upon a time, Adam Williamson said: > > > pavucontrol does profile switching, and does it in a very nice way, > > > thanks to the work done on Pulse during this cycle. But it doesn't do > > > input switching. > > > > > > gnome-volume-control doesn't do profile switching *or* input switching. > > > > If pavucontrol existed and worked better, why did we get yet another > > audio control written from scratch? Why not just work on one of the > > many existing ones (like pavucontrol that already knows how to talk to > > PA)? > > I wonder how hard it would be to add input switching to > pavucontrol...then we could ditch g-v-c and the legacy mixers and keep > the one pavucontrol that handles all the use cases... We worked on the new gnome-volume-control because pavucontrol is a "show all the options underneath" program, just like the ALSA mixers were. We wrote use cases, we checked what other systems did, and we intend to present something to the user that's less complicated than showing up all the knobs PulseAudio offers. So shipping pavucontrol isn't a solution in itself. From ndbecker2 at gmail.com Sat May 2 10:37:13 2009 From: ndbecker2 at gmail.com (Neal Becker) Date: Sat, 02 May 2009 06:37:13 -0400 Subject: diff between 'make build' and 'make mockbuild' Message-ID: I'm trying to debug why 'make build' of python-igraph-0.5.2-2 on fc12 gives segfault. If I try to debug, using 'make mockbuild', I get a different result. In that case, I get ERROR: Bad build req: No Package Found for igraph-devel = 0.5.2. Exiting. Why does 'make build' find the required igraph-devel, but 'make mockbuild' doesn't, and what can I do about it? From howard at cohtech.com Sat May 2 11:32:03 2009 From: howard at cohtech.com (Howard Wilkinson) Date: Sat, 02 May 2009 12:32:03 +0100 Subject: Status of aic79xx driver in the linux kernel Message-ID: <49FC2F33.1010108@cohtech.com> I have been having some problems with an Adaptec 39320A-R card and have been poking around and found that the driver in the kernel claims to be derived from an Adaptec version 2.0.15 which was release in October 2005! There is a later version on the Adaptec site from April 2007 - 2.0.26. I was wondering if anybody knows the actual status of the driver in the kernel i.e. has it diverged so far that the Adaptec updates are moot; have they already been incorporated into the kernel but the docs not updated to reflect this, or ... I ask because I am trying to decide whether to invest the time to look at integrating the latest Adaptec drop to see if my problems go away. Howard. From snecklifter at gmail.com Sat May 2 11:42:44 2009 From: snecklifter at gmail.com (Christopher Brown) Date: Sat, 2 May 2009 12:42:44 +0100 Subject: Status of aic79xx driver in the linux kernel In-Reply-To: <49FC2F33.1010108@cohtech.com> References: <49FC2F33.1010108@cohtech.com> Message-ID: <364d303b0905020442y694dfe18o6cd84b6aac811fa1@mail.gmail.com> 2009/5/2 Howard Wilkinson : > I have been having some problems with an Adaptec 39320A-R card and have been > poking around and found that the driver in the kernel claims to be derived > from an Adaptec version 2.0.15 which was release in October 2005! There is a > later version on the Adaptec site from April 2007 - 2.0.26. > > I was wondering if anybody knows the actual status of the driver in the > kernel i.e. has it diverged so far that the Adaptec updates are moot; have > they already been incorporated into the kernel but the docs not updated to > reflect this, or ... > > I ask because I am trying to decide whether to invest the time to look at > integrating the latest Adaptec drop to see if my problems go away. You should ping fedora-kernel on this Howard. The list is open so does not require subscription. Cheers -- Christopher Brown From fabian.deutsch at gmx.de Sat May 2 13:03:29 2009 From: fabian.deutsch at gmx.de (Fabian Deutsch) Date: Sat, 02 May 2009 15:03:29 +0200 Subject: PPC LiveCD Message-ID: <1241269409.5092.1.camel@decade.local> Hi, there are live CDs for i686 and x86_64, is there a reason why there is no official live CD for PPC? Greetings - fabian From rawhide at fedoraproject.org Sat May 2 13:17:10 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Sat, 2 May 2009 13:17:10 +0000 (UTC) Subject: rawhide report: 20090502 changes Message-ID: <20090502131710.6B5921F8205@releng2.fedora.phx.redhat.com> Compose started at Sat May 2 06:15:04 UTC 2009 Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 0 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From jwboyer at gmail.com Sat May 2 13:30:07 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Sat, 2 May 2009 09:30:07 -0400 Subject: PPC LiveCD In-Reply-To: <1241269409.5092.1.camel@decade.local> References: <1241269409.5092.1.camel@decade.local> Message-ID: <20090502133007.GA18114@hansolo.jdub.homelinux.org> On Sat, May 02, 2009 at 03:03:29PM +0200, Fabian Deutsch wrote: >Hi, > >there are live CDs for i686 and x86_64, is there a reason why there is >no official live CD for PPC? 1) livecd-tools was broken for 1.5 years until I fixed it 2 days ago. 2) You are the first person to ask about it since around Fedora 7. There isn't much demand. josh From rc040203 at freenet.de Sat May 2 13:34:22 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 02 May 2009 15:34:22 +0200 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <49FC089E.40607@poolshark.org> References: <1241123673.32113.299.camel@adam.local.net> <20090430210019.GC25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> <20090502014029.GC1496739@hiwaay.net> <20090502014259.GA28052@angus.ind.WPI.EDU> <49FC089E.40607@poolshark.org> Message-ID: <49FC4BDE.1060908@freenet.de> Denis Leroy wrote: > On 05/02/2009 03:42 AM, Chuck Anderson wrote: >> I wonder how hard it would be to add input switching to >> pavucontrol...then we could ditch g-v-c and the legacy mixers and keep >> the one pavucontrol that handles all the use cases... > > It's not just input switching. Skype is usless if I can't enable the mic > boost, and general volume output is too low on my T61 because the > 'hidden' PCM slider is set at an arbitrarily low value. Could that be the same issue as I am facing it? cf. https://bugzilla.redhat.com/show_bug.cgi?id=498699 I had to rm -rf ~/.pulse to get PCM volume up to a usable level. Ralf From fabian.deutsch at gmx.de Sat May 2 13:36:13 2009 From: fabian.deutsch at gmx.de (Fabian Deutsch) Date: Sat, 02 May 2009 15:36:13 +0200 Subject: PPC LiveCD In-Reply-To: <20090502133007.GA18114@hansolo.jdub.homelinux.org> References: <1241269409.5092.1.camel@decade.local> <20090502133007.GA18114@hansolo.jdub.homelinux.org> Message-ID: <1241271373.5092.4.camel@decade.local> Am Samstag, den 02.05.2009, 09:30 -0400 schrieb Josh Boyer: > On Sat, May 02, 2009 at 03:03:29PM +0200, Fabian Deutsch wrote: > >Hi, > > > >there are live CDs for i686 and x86_64, is there a reason why there is > >no official live CD for PPC? > > 1) livecd-tools was broken for 1.5 years until I fixed it 2 days ago. They were broken? Just for PPC or in general? Because I used to create images until a couple of weeks (2 months?) ago. And it worked fine. Until the livecd-tools broke because of something .. > 2) You are the first person to ask about it since around Fedora 7. There isn't > much demand. Hm. Okay. Cheers - fabian From stickster at gmail.com Sat May 2 13:57:34 2009 From: stickster at gmail.com (Paul W. Frields) Date: Sat, 2 May 2009 09:57:34 -0400 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <20090502002529.GA29316@srcf.ucam.org> References: <1241123673.32113.299.camel@adam.local.net> <20090430210019.GC25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <20090502002529.GA29316@srcf.ucam.org> Message-ID: <20090502135734.GE3520@localhost.localdomain> On Sat, May 02, 2009 at 01:25:29AM +0100, Matthew Garrett wrote: > On Fri, May 01, 2009 at 07:13:20PM -0500, Matthew Woehlke wrote: > > Matthew Garrett wrote: > >> How many volume control applications do you want us to ship with? The > >> fact that mistakes have been made in the past is not an argument for > >> further mistakes being made in the future. > > > > To ask the dumb question... right now pavucontrol is the only way > > (AFAIK) right now to change relative volume of individual apps, or > > choose output device per-app. Without pavucontrol, how is this supposed > > to be accomplished? > > Per-stream volume control seems to be present in g-v-c. I'm afraid I've > got no idea about per-stream output control - I only have one output > device available here. > > > (Or are both of these being labeled "exotic" use cases that shan't be > > supported OOTB?) > > I don't know. I'd imagine that the first certainly isn't (given that it > seems to be supported), but you'd need to ask someone else about the > second. It would be a shame if the second was considered exotic, since it's supposed to be a feature of PulseAudio. I used it to create this: https://fedoraproject.org/wiki/How_to_make_a_podcast Of course, if I understand correctly, you're not saying pavucontrol would disappear, just that the design considerations under discussion might call for it to not be installed by default. Right? -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From bruno at wolff.to Sat May 2 13:59:49 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Sat, 2 May 2009 08:59:49 -0500 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <2d319b780905020202w3ac1dbd1i139fa9d2f448d98a@mail.gmail.com> References: <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> <20090502014029.GC1496739@hiwaay.net> <20090502014259.GA28052@angus.ind.WPI.EDU> <49FC089E.40607@poolshark.org> <2d319b780905020202w3ac1dbd1i139fa9d2f448d98a@mail.gmail.com> Message-ID: <20090502135949.GA32549@wolff.to> On Sat, May 02, 2009 at 11:02:12 +0200, "Mathieu Bridon (bochecha)" wrote: > > It's not just input switching. Skype is usless if I can't enable the mic > > boost, and general volume output is too low on my T61 because the 'hidden' > > PCM slider is set at an arbitrarily low value. > > Report it, it will be fixed: > https://bugzilla.redhat.com/show_bug.cgi?id=497966 More specificly there is a bug to combine master and pcm controls into one slider: https://bugzilla.redhat.com/show_bug.cgi?id=497945 From bruno at wolff.to Sat May 2 14:03:05 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Sat, 2 May 2009 09:03:05 -0500 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <1241260456.20413.2098.camel@cookie.hadess.net> References: <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> <20090502014029.GC1496739@hiwaay.net> <20090502014259.GA28052@angus.ind.WPI.EDU> <1241260456.20413.2098.camel@cookie.hadess.net> Message-ID: <20090502140305.GB32549@wolff.to> On Sat, May 02, 2009 at 11:34:16 +0100, Bastien Nocera wrote: > > We worked on the new gnome-volume-control because pavucontrol is a "show > all the options underneath" program, just like the ALSA mixers were. But it shows different sets of all controls than the ALSA mixer. I found I could use it to boost the volume, but the noise was unacceptable. It ended up just delaying me from finding alsamixer which I could use to really fix my problem. From snecklifter at gmail.com Sat May 2 14:14:36 2009 From: snecklifter at gmail.com (Christopher Brown) Date: Sat, 2 May 2009 15:14:36 +0100 Subject: PPC LiveCD In-Reply-To: <20090502133007.GA18114@hansolo.jdub.homelinux.org> References: <1241269409.5092.1.camel@decade.local> <20090502133007.GA18114@hansolo.jdub.homelinux.org> Message-ID: <364d303b0905020714p3c110487r49fcb348646012c@mail.gmail.com> 2009/5/2 Josh Boyer : > On Sat, May 02, 2009 at 03:03:29PM +0200, Fabian Deutsch wrote: >>Hi, >> >>there are live CDs for i686 and x86_64, is there a reason why there is >>no official live CD for PPC? > > 1) livecd-tools was broken for 1.5 years until I fixed it 2 days ago. > > 2) You are the first person to ask about it since around Fedora 7. ?There isn't > much demand. I assume you are talking about livecd-tools on PPC here because I use it plenty. Regards -- Christopher Brown From mjg at redhat.com Sat May 2 14:27:58 2009 From: mjg at redhat.com (Matthew Garrett) Date: Sat, 2 May 2009 15:27:58 +0100 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <20090502135734.GE3520@localhost.localdomain> References: <20090430210019.GC25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <20090502002529.GA29316@srcf.ucam.org> <20090502135734.GE3520@localhost.localdomain> Message-ID: <20090502142757.GA4295@srcf.ucam.org> On Sat, May 02, 2009 at 09:57:34AM -0400, Paul W. Frields wrote: > Of course, if I understand correctly, you're not saying pavucontrol > would disappear, just that the design considerations under discussion > might call for it to not be installed by default. Right? I'm not on the desktop team, but I guess it wouldn't be impossible. I'm actually surprised to find that it's installed by default - seeing it in the menu, I'd assumed that it just opened the same preferences as g-v-c does. The degree of overlap of functionality is pretty huge. -- Matthew Garrett | mjg59 at srcf.ucam.org From mzerqung at 0pointer.de Sat May 2 14:52:34 2009 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Sat, 2 May 2009 16:52:34 +0200 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <20090502142757.GA4295@srcf.ucam.org> References: <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <20090502002529.GA29316@srcf.ucam.org> <20090502135734.GE3520@localhost.localdomain> <20090502142757.GA4295@srcf.ucam.org> Message-ID: <20090502145234.GB7160@tango.0pointer.de> On Sat, 02.05.09 15:27, Matthew Garrett (mjg at redhat.com) wrote: > > On Sat, May 02, 2009 at 09:57:34AM -0400, Paul W. Frields wrote: > > > Of course, if I understand correctly, you're not saying pavucontrol > > would disappear, just that the design considerations under discussion > > might call for it to not be installed by default. Right? > > I'm not on the desktop team, but I guess it wouldn't be impossible. I'm > actually surprised to find that it's installed by default - seeing it in > the menu, I'd assumed that it just opened the same preferences as g-v-c > does. The degree of overlap of functionality is pretty huge. pavucontrol should have been dropped from the default install the minute the new g-v-c was pushed into Fedora. We forgot to do that. We should do it now. End of story. The reason I initially wrote pavucontrol is to have something to show off the features PA has. Such as per-stream vol control, moving streams between devices, profile switching, ... I didn't write it because I thought that it's the way volume controls should be looking like. I honestly don't like writing UI programs. My interests lie elsewhere. I wrote it as a show case, not for UIs but for what PA can be good for. pavucontrol is more powerful than g-v-c. But that's expected. I hope g-v-c will eventually learn more of the features pavucontrol has without becoming as cluttered, so that we can get rid of pavucontrol eventually. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From ndbecker2 at gmail.com Sat May 2 16:11:11 2009 From: ndbecker2 at gmail.com (Neal Becker) Date: Sat, 02 May 2009 12:11:11 -0400 Subject: Help with requires Message-ID: I'm having problems with igraph and python-igraph. igraph builds igraph-devel python-igraph needs igraph-devel. I'm assuming python-igraph needs the same version of igraph. How should this be encoded? Right now, I have -------- igraph.spec %package devel Provides: %{name}-devel-%{version} -------- python-igraph.spec BuildRequires: igraph-devel = %{version} Is this correct? From sandeen at redhat.com Sat May 2 16:23:15 2009 From: sandeen at redhat.com (Eric Sandeen) Date: Sat, 02 May 2009 11:23:15 -0500 Subject: Help with requires In-Reply-To: References: Message-ID: <49FC7373.4000304@redhat.com> Neal Becker wrote: > I'm having problems with igraph and python-igraph. > > igraph builds igraph-devel > python-igraph needs igraph-devel. > > I'm assuming python-igraph needs the same version of igraph. > > How should this be encoded? > > Right now, I have > > -------- igraph.spec > %package devel > Provides: %{name}-devel-%{version} You shouldn't need to explicitly do this, this comes automatically. > -------- python-igraph.spec > > BuildRequires: igraph-devel = %{version} This would require igraph-devel at the same version of python-igraph; that doesn't sound right to me since I guess these are separately released packages from uptream? (though they seem to have the same version in cvs...) > Is this correct? Doesn't seem quite correct to me. I'd drop the devel package Provides from the igraph spec (you should see that it still provides this anyway), and drop the version from the python-igraph BuildRequires unless these things really are in lockstep version release upstream, though that sounds odd since they seem to be two separate projects? If there -is- some minimum version for the build requires, you can hard code that in there. (BuildRequires: igraph-devel >= 0.5.2 or whatever) -Eric From kevin.kofler at chello.at Sat May 2 16:25:19 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 02 May 2009 18:25:19 +0200 Subject: FESCo Meeting Summary for 20090424 References: <49F24B17.30602@redhat.com> <49F25D0D.8030304@gmail.com> <1240759385.6529.0.camel@localhost.localdomain> <1240762219.2770.9.camel@localhost.localdomain> <1241027428.3139.9.camel@localhost.localdomain> <939dd5750904301050o4efb3efau356882109b2e206b@mail.gmail.com> <1241116151.32113.273.camel@adam.local.net> <939dd5750904301208l19123893rc9cd68609f8980be@mail.gmail.com> <49F9FD08.9010904@redhat.com> <20090430194821.GA25787@nostromo.devel.redhat.com> <49FA039D.10102@hi.is> <1241125176.32113.323.camel@adam.local.net> <49FA226B.4020006@hi.is> Message-ID: "J?hann B. Gu?mundsson" wrote: > "As of the final freeze for a release, no new builds are allowed for > packages already in the Fedora collection > (new packages can still be reviewed, added in CVS and built as potential > updates)" > > And I would think that the other application would have to follow the > above procedure and be built as potential update. > > I must be misunderstanding something which is not the first time nor the > last :( The new packages are actually getting inherited from F10 updates. This needs to be fixed somehow. (We should probably create separate f*-final tags early again.) Kevin Kofler From ndbecker2 at gmail.com Sat May 2 16:41:44 2009 From: ndbecker2 at gmail.com (Neal Becker) Date: Sat, 02 May 2009 12:41:44 -0400 Subject: Help with requires References: <49FC7373.4000304@redhat.com> Message-ID: Eric Sandeen wrote: > Neal Becker wrote: >> I'm having problems with igraph and python-igraph. >> >> igraph builds igraph-devel >> python-igraph needs igraph-devel. >> >> I'm assuming python-igraph needs the same version of igraph. >> >> How should this be encoded? >> >> Right now, I have >> >> -------- igraph.spec >> %package devel >> Provides: %{name}-devel-%{version} > > You shouldn't need to explicitly do this, this comes automatically. > >> -------- python-igraph.spec >> >> BuildRequires: igraph-devel = %{version} > > This would require igraph-devel at the same version of python-igraph; > that doesn't sound right to me since I guess these are separately > released packages from uptream? (though they seem to have the same > version in cvs...) > >> Is this correct? > > Doesn't seem quite correct to me. > > I'd drop the devel package Provides from the igraph spec (you should see > that it still provides this anyway), and drop the version from the > python-igraph BuildRequires unless these things really are in lockstep > version release upstream, though that sounds odd since they seem to be > two separate projects? > > If there -is- some minimum version for the build requires, you can hard > code that in there. (BuildRequires: igraph-devel >= 0.5.2 or whatever) > > -Eric > Come from same source and really are lockstep. Thanks. From awilliam at redhat.com Sat May 2 16:46:01 2009 From: awilliam at redhat.com (Adam Williamson) Date: Sat, 02 May 2009 09:46:01 -0700 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <20090502145234.GB7160@tango.0pointer.de> References: <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <20090502002529.GA29316@srcf.ucam.org> <20090502135734.GE3520@localhost.localdomain> <20090502142757.GA4295@srcf.ucam.org> <20090502145234.GB7160@tango.0pointer.de> Message-ID: <1241282761.2923.9.camel@adam.local.net> On Sat, 2009-05-02 at 16:52 +0200, Lennart Poettering wrote: > On Sat, 02.05.09 15:27, Matthew Garrett (mjg at redhat.com) wrote: > > > > > On Sat, May 02, 2009 at 09:57:34AM -0400, Paul W. Frields wrote: > > > > > Of course, if I understand correctly, you're not saying pavucontrol > > > would disappear, just that the design considerations under discussion > > > might call for it to not be installed by default. Right? > > > > I'm not on the desktop team, but I guess it wouldn't be impossible. I'm > > actually surprised to find that it's installed by default - seeing it in > > the menu, I'd assumed that it just opened the same preferences as g-v-c > > does. The degree of overlap of functionality is pretty huge. > > pavucontrol should have been dropped from the default install the > minute the new g-v-c was pushed into Fedora. We forgot to do that. We > should do it now. End of story. So what do we do about profile switching - digital output, analog surround output? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From awilliam at redhat.com Sat May 2 16:46:06 2009 From: awilliam at redhat.com (Adam Williamson) Date: Sat, 02 May 2009 09:46:06 -0700 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <2d319b780905020202w3ac1dbd1i139fa9d2f448d98a@mail.gmail.com> References: <1241123673.32113.299.camel@adam.local.net> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> <20090502014029.GC1496739@hiwaay.net> <20090502014259.GA28052@angus.ind.WPI.EDU> <49FC089E.40607@poolshark.org> <2d319b780905020202w3ac1dbd1i139fa9d2f448d98a@mail.gmail.com> Message-ID: <1241282766.2923.10.camel@adam.local.net> On Sat, 2009-05-02 at 11:02 +0200, Mathieu Bridon (bochecha) wrote: > > It's not just input switching. Skype is usless if I can't enable the mic > > boost, and general volume output is too low on my T61 because the 'hidden' > > PCM slider is set at an arbitrarily low value. > > Report it, it will be fixed: > https://bugzilla.redhat.com/show_bug.cgi?id=497966 We already have a report for the T61, in fact. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From kevin.kofler at chello.at Sat May 2 16:53:09 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 02 May 2009 18:53:09 +0200 Subject: FESCo Meeting Summary for 20090424 References: <1241123673.32113.299.camel@adam.local.net> <20090430210019.GC25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> <20090502014029.GC1496739@hiwaay.net> <20090502014259.GA28052@angus.ind.WPI.EDU> <1241260456.20413.2098.camel@cookie.hadess.net> Message-ID: Bastien Nocera wrote: > We worked on the new gnome-volume-control because pavucontrol is a "show > all the options underneath" program, just like the ALSA mixers were. > > We wrote use cases, we checked what other systems did, and we intend to > present something to the user that's less complicated than showing up > all the knobs PulseAudio offers. Translation: "We worked on the new gnome-volume-control because pavucontrol has too many features and we hate powerful applications. So we wrote down the simplest use cases we could come up with in a short brainstorming session and decided to remove all the useful features we didn't think of, not asking for any actual user input, and we intend to present a crippled user interface only showing that simplistic subset of features." And then you're surprised clich?s about GNOME working exactly that way circulate? Kevin Kofler From sandeen at redhat.com Sat May 2 16:53:58 2009 From: sandeen at redhat.com (Eric Sandeen) Date: Sat, 02 May 2009 11:53:58 -0500 Subject: Help with requires In-Reply-To: References: <49FC7373.4000304@redhat.com> Message-ID: <49FC7AA6.1060903@redhat.com> Neal Becker wrote: > Eric Sandeen wrote: >> I'd drop the devel package Provides from the igraph spec (you should see >> that it still provides this anyway), and drop the version from the >> python-igraph BuildRequires unless these things really are in lockstep >> version release upstream, though that sounds odd since they seem to be >> two separate projects? >> >> If there -is- some minimum version for the build requires, you can hard >> code that in there. (BuildRequires: igraph-devel >= 0.5.2 or whatever) >> >> -Eric >> > > Come from same source and really are lockstep. Thanks. Then shouldn't they all be built out of the same specfile? And has that changed? Doesn't look that way in cvs now: $ grep "^Source\|URL" igraph/devel/igraph.spec python-igraph/devel/python-igraph.spec igraph/devel/igraph.spec:URL: http://cneurocvs.rmki.kfki.hu/igraph igraph/devel/igraph.spec:Source0: http://igraph.googlecode.com/files/%{name}-%{version}.tar.gz python-igraph/devel/python-igraph.spec:URL: http://pypi.python.org/pypi/igraph-%{version} python-igraph/devel/python-igraph.spec:Source0: python-igraph-%{version}.tar.gz $ ls *igraph*/devel/*.gz igraph/devel/igraph-0.5.2.tar.gz python-igraph/devel/python-igraph-0.5.2.tar.gz $ md5sum *igraph*/devel/*.gz 092fcd018d35da599e250990e9b64e6f igraph/devel/igraph-0.5.2.tar.gz 8e80ddff5a7a3b7c25e293d4daaee6c0 python-igraph/devel/python-igraph-0.5.2.tar.gz So have they merged, and that's what you're working on now? Sorry, just curious :) -Eric From ndbecker2 at gmail.com Sat May 2 17:00:39 2009 From: ndbecker2 at gmail.com (Neal Becker) Date: Sat, 02 May 2009 13:00:39 -0400 Subject: Help with requires References: <49FC7373.4000304@redhat.com> <49FC7AA6.1060903@redhat.com> Message-ID: Eric Sandeen wrote: > Neal Becker wrote: >> Eric Sandeen wrote: > > >>> I'd drop the devel package Provides from the igraph spec (you should see >>> that it still provides this anyway), and drop the version from the >>> python-igraph BuildRequires unless these things really are in lockstep >>> version release upstream, though that sounds odd since they seem to be >>> two separate projects? >>> >>> If there -is- some minimum version for the build requires, you can hard >>> code that in there. (BuildRequires: igraph-devel >= 0.5.2 or whatever) >>> >>> -Eric >>> >> >> Come from same source and really are lockstep. Thanks. > They come from the same _organization_, but the source files are not the same. Sorry for being unclear. From jwboyer at gmail.com Sat May 2 17:17:54 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Sat, 2 May 2009 13:17:54 -0400 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: References: <1241027428.3139.9.camel@localhost.localdomain> <939dd5750904301050o4efb3efau356882109b2e206b@mail.gmail.com> <1241116151.32113.273.camel@adam.local.net> <939dd5750904301208l19123893rc9cd68609f8980be@mail.gmail.com> <49F9FD08.9010904@redhat.com> <20090430194821.GA25787@nostromo.devel.redhat.com> <49FA039D.10102@hi.is> <1241125176.32113.323.camel@adam.local.net> <49FA226B.4020006@hi.is> Message-ID: <20090502171754.GB18114@hansolo.jdub.homelinux.org> On Sat, May 02, 2009 at 06:25:19PM +0200, Kevin Kofler wrote: >"J?hann B. Gu?mundsson" wrote: >> "As of the final freeze for a release, no new builds are allowed for >> packages already in the Fedora collection >> (new packages can still be reviewed, added in CVS and built as potential >> updates)" >> >> And I would think that the other application would have to follow the >> above procedure and be built as potential update. >> >> I must be misunderstanding something which is not the first time nor the >> last :( > >The new packages are actually getting inherited from F10 updates. This needs >to be fixed somehow. (We should probably create separate f*-final tags >early again.) It has been fixed. josh From jwboyer at gmail.com Sat May 2 17:20:09 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Sat, 2 May 2009 13:20:09 -0400 Subject: PPC LiveCD In-Reply-To: <364d303b0905020714p3c110487r49fcb348646012c@mail.gmail.com> References: <1241269409.5092.1.camel@decade.local> <20090502133007.GA18114@hansolo.jdub.homelinux.org> <364d303b0905020714p3c110487r49fcb348646012c@mail.gmail.com> Message-ID: <20090502172009.GC18114@hansolo.jdub.homelinux.org> On Sat, May 02, 2009 at 03:14:36PM +0100, Christopher Brown wrote: >2009/5/2 Josh Boyer : >> On Sat, May 02, 2009 at 03:03:29PM +0200, Fabian Deutsch wrote: >>>Hi, >>> >>>there are live CDs for i686 and x86_64, is there a reason why there is >>>no official live CD for PPC? >> >> 1) livecd-tools was broken for 1.5 years until I fixed it 2 days ago. >> >> 2) You are the first person to ask about it since around Fedora 7. ?There isn't >> much demand. > >I assume you are talking about livecd-tools on PPC here because I use it plenty. Correct. josh From mjg at redhat.com Sat May 2 17:27:09 2009 From: mjg at redhat.com (Matthew Garrett) Date: Sat, 2 May 2009 18:27:09 +0100 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: References: <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> <20090502014029.GC1496739@hiwaay.net> <20090502014259.GA28052@angus.ind.WPI.EDU> <1241260456.20413.2098.camel@cookie.hadess.net> Message-ID: <20090502172709.GA6247@srcf.ucam.org> On Sat, May 02, 2009 at 06:53:09PM +0200, Kevin Kofler wrote: > Translation: > > "We worked on the new gnome-volume-control because pavucontrol has too many > features and we hate powerful applications. > > So we wrote down the simplest use cases we could come up with in a short > brainstorming session and decided to remove all the useful features we > didn't think of, not asking for any actual user input, and we intend to > present a crippled user interface only showing that simplistic subset of > features." Actually it's because we hate freedom and apple pie. Please. This kind of thing is unnecessary. -- Matthew Garrett | mjg59 at srcf.ucam.org From kevin.kofler at chello.at Sat May 2 17:30:03 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 02 May 2009 19:30:03 +0200 Subject: Abandon "Default Desktop" References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <16de708d0904271530v135a0a4ep3ab020d798a36c5e@mail.gmail.com> <3adc77210904271556i502559acn37c2002c124a80ff@mail.gmail.com> <49F70FB1.20603@hi.is> <3adc77210904280848pb8000a2h1189866bd6d17db5@mail.gmail.com> <1240953073.32113.225.camel@adam.local.net> <49F80664.6010809@robertoragusa.it> <1241037119.3213.2.camel@localhost.localdomain> <6c3f5e6c0904291514n371fa179k1901af657e05a5b5@mail.gmail.com> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <1241114797.32113.267.camel@adam.local.net> <49FAC39F.6030405@alexhudson.com> Message-ID: Alex Hudson wrote: > I personally find it a bit surprising that the choice of desktop > environment is thought of as being sufficiently important that there > should be no single "default". As a user, there are apps that are vastly > more important to me, and for which there is choice: e.g., > OpenOffice.org vs. KOffice, Thunderbird vs. Evolution (vs. Kwhatever), > Firefox vs. Epiphany. I spend 90%+ of my time in my desktop using those > apps, not the desktop itself - Tbird is much, much more important to me > than the choice of DE. The idea is that by selecting GNOME, you'd get GNOME apps as the default apps (of course, there's still the question whether to use OO.o and Mozilla apps or the official GNOME defaults, but that's already subject for debates right now, and both the current DVD defaults of OO.o + Firefox + Evolution and the current live CD defaults of Abiword + Firefox + Evolution are a mix of that), by selecting KDE, you'd get KDE apps (KOffice, kdepim, Konqueror) as the default. You can still fine-tune them in the package selection screen, the idea is just that you'd get a reasonable set preselected depending on your desktop choice rather than getting all the GNOME stuff checked by default. A related issue is the way the current comps is structured, where categories like "Graphical Internet", "Sound and Video" etc. are basically all GNOME or GTK+ apps, the equivalent KDE apps are all in "K Desktop Environment". We'd need a better comps structure (more conditionals? Maybe specific handling of conditionals based on the desktop selected in the radiobutton? Or maybe different versions of comps depending on the selected desktop?) to really treat the desktops in a fair way and make a desktop selection screen work properly. Kevin Kofler From awilliam at redhat.com Sat May 2 17:32:19 2009 From: awilliam at redhat.com (Adam Williamson) Date: Sat, 02 May 2009 10:32:19 -0700 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <1241260456.20413.2098.camel@cookie.hadess.net> References: <1241123673.32113.299.camel@adam.local.net> <20090430210019.GC25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> <20090502014029.GC1496739@hiwaay.net> <20090502014259.GA28052@angus.ind.WPI.EDU> <1241260456.20413.2098.camel@cookie.hadess.net> Message-ID: <1241285539.2923.19.camel@adam.local.net> On Sat, 2009-05-02 at 11:34 +0100, Bastien Nocera wrote: > We wrote use cases, we checked what other systems did, and we intend > to > present something to the user that's less complicated than showing up > all the knobs PulseAudio offers. Here's the other thing that gets me about this: okay, so you thought about the use cases you want to support and came up with a design. Great. But we don't even have that design yet. That design includes input switching and profile switching. These are features that Lennart and others have gone on the public record as saying are intended to be in g-v-c and will be in g-v-c in future. So obviously you consider those important use cases that we ought to be supporting. However, you say it's perfectly fine to ship - as our only installed graphical mixer in F11 - a mixer which *doesn't* yet have those features. I mean...come on! You can't just go about introducing huge functional regressions willy-nilly because you want to have the new design in as soon as you've finished a working prototype with half the features missing! This isn't PulseAudio itself, where we really needed to ship the thing before it was really done to get useful wide-based testing; in this case we already *know* what g-v-c is missing, and those features can be worked on without causing people the pain of suddenly losing these features. Frankly I'm becoming more and more in favour of advocating simply having gnome-media build the old mixer for F11 and delay the new one entirely until F12 (or, hell, it could go into F11 as an update if profile switching and input switching get implemented). That's simpler (it just requires flipping a switch in the gnome-media spec), less invasive, satisfies the "we should only have one mixer" requirement, and is more in line with what people apparently think the role of FESco should be (approving or denying new features, not mandating interface compromises). I liked the compromise because at least we have the new mixer in there for people to try out, and it'd help us find the bad-default-volume-settings-from-ALSA bugs, but maybe this way would get less resistance from both sides... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From kevin.kofler at chello.at Sat May 2 17:34:18 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 02 May 2009 19:34:18 +0200 Subject: Abandon "Default Desktop" References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <16de708d0904271530v135a0a4ep3ab020d798a36c5e@mail.gmail.com> <3adc77210904271556i502559acn37c2002c124a80ff@mail.gmail.com> <49F70FB1.20603@hi.is> <3adc77210904280848pb8000a2h1189866bd6d17db5@mail.gmail.com> <1240953073.32113.225.camel@adam.local.net> <49F80664.6010809@robertoragusa.it> <1241037119.3213.2.camel@localhost.localdomain> <6c3f5e6c0904291514n371fa179k1901af657e05a5b5@mail.gmail.com> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <1241114797.32113.267.camel@adam.local.net> Message-ID: Adam Williamson wrote: > I already explained that, we're circling *again*. The problem is that > when you ask someone to make a choice without understanding the options, > it tends to frustrate them. This is a well-observed phenomenon in all > circles, certainly including computer user interface design. This would just be one single choice, and a choice a sizable portion of our userbase wants to make (even those who happen to use Fedora's current defaults: ask them around how they'd react if Fedora would install KDE by default and making it a complex hunt of checkboxes to select GNOME instead, also by making all the use-case-specific groups default to KDE apps and having the GNOME equivalents part of the GNOME group instead; yet that's exactly what's done right now, except with GNOME<->KDE switched around). The current solution is highly inconvenient. I can only really recommend the KDE live spin for KDE users. Sadly, that one is hidden behind a small link on the default download page, with the default download not even containing KDE at all. Kevin Kofler From kevin.kofler at chello.at Sat May 2 17:41:10 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 02 May 2009 19:41:10 +0200 Subject: Abandon "Default Desktop" References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <49F80664.6010809@robertoragusa.it> <1241037119.3213.2.camel@localhost.localdomain> <6c3f5e6c0904291514n371fa179k1901af657e05a5b5@mail.gmail.com> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <16de708d0904301051r647b9f14qc1fe7d343bdbd778@mail.gmail.com> <1241114354.7846.5.camel@localhost.localdomain> <49FAB6AB.9060601@freenet.de> <49FAB9D6.6030203@fedoraproject.org> <49FABC2B.8050500@freenet.de> <49FAC168.4060707@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > Anyone interested can look at the desktop focused features in the > feature list for every release and results should speak for themselves. > Those who shoulder the burden of the work decide the direction of the > project as always. Are you suggesting we should be writing up feature pages for any single upstream KDE improvement we'll be shipping in the next release? Because that's what the GNOME folks are doing. I must say I don't see this as a very productive use of our time, you can find all the new KDE features in the upstream announcements and info pages. And as, unlike the GNOME maintainers, we also push new KDE versions as updates to existing Fedora releases, advertising their features as new features in the next Fedora wouldn't really be accurate. Kevin Kofler From mzerqung at 0pointer.de Sat May 2 17:47:16 2009 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Sat, 2 May 2009 19:47:16 +0200 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: References: <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> <20090502014029.GC1496739@hiwaay.net> <20090502014259.GA28052@angus.ind.WPI.EDU> <1241260456.20413.2098.camel@cookie.hadess.net> Message-ID: <20090502174716.GA22833@tango.0pointer.de> On Sat, 02.05.09 18:53, Kevin Kofler (kevin.kofler at chello.at) wrote: > > Bastien Nocera wrote: > > We worked on the new gnome-volume-control because pavucontrol is a "show > > all the options underneath" program, just like the ALSA mixers were. > > > > We wrote use cases, we checked what other systems did, and we intend to > > present something to the user that's less complicated than showing up > > all the knobs PulseAudio offers. > > Translation: > > "We worked on the new gnome-volume-control because pavucontrol has too many > features and we hate powerful applications. > > So we wrote down the simplest use cases we could come up with in a short > brainstorming session and decided to remove all the useful features we > didn't think of, not asking for any actual user input, and we intend to > present a crippled user interface only showing that simplistic subset of > features." > > And then you're surprised clich?s about GNOME working exactly that way > circulate? Oh my. Yes, I know you like KDE. That's OK. But please, why do you feel you have seize every opportunity to express that you think that the KDE approach in exposing as many options as possible to the user is better than the GNOME approach where we don't want to show too many options? Everyone and his dog knows by now that you like to have many options and thus are into KDE. You constant complaining and bitching about GNOME is completely pointless -- since you don't even use it yourself. You made your choices, and probably have good reasons for it. Fine. No need for constantly complaining about the choices the other camp makes. Please, grow up and don't try to make everything a fight between KDE and GNOME, neither directly nor between the lines! Thank you very much, Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From awilliam at redhat.com Sat May 2 17:53:51 2009 From: awilliam at redhat.com (Adam Williamson) Date: Sat, 02 May 2009 10:53:51 -0700 Subject: Abandon "Default Desktop" In-Reply-To: References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <16de708d0904271530v135a0a4ep3ab020d798a36c5e@mail.gmail.com> <3adc77210904271556i502559acn37c2002c124a80ff@mail.gmail.com> <49F70FB1.20603@hi.is> <3adc77210904280848pb8000a2h1189866bd6d17db5@mail.gmail.com> <1240953073.32113.225.camel@adam.local.net> <49F80664.6010809@robertoragusa.it> <1241037119.3213.2.camel@localhost.localdomain> <6c3f5e6c0904291514n371fa179k1901af657e05a5b5@mail.gmail.com> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <1241114797.32113.267.camel@adam.local.net> Message-ID: <1241286831.2923.23.camel@adam.local.net> On Sat, 2009-05-02 at 19:34 +0200, Kevin Kofler wrote: > Adam Williamson wrote: > > I already explained that, we're circling *again*. The problem is that > > when you ask someone to make a choice without understanding the options, > > it tends to frustrate them. This is a well-observed phenomenon in all > > circles, certainly including computer user interface design. > > This would just be one single choice, and a choice a sizable portion of our > userbase wants to make (even those who happen to use Fedora's current > defaults: ask them around how they'd react if Fedora would install KDE by > default and making it a complex hunt of checkboxes to select GNOME instead, > also by making all the use-case-specific groups default to KDE apps and > having the GNOME equivalents part of the GNOME group instead; yet that's > exactly what's done right now, except with GNOME<->KDE switched around). > The current solution is highly inconvenient. I can only really recommend > the KDE live spin for KDE users. Sadly, that one is hidden behind a small > link on the default download page, with the default download not even > containing KDE at all. In terms of what should happen on the web page, I don't really have an opinion. It is a tricky area with no obvious right answer. I had to deal with the same issue at MDV. A few years ago we had a download page (well, area...) which carefully exposed every possible edition of Mandriva you could choose to download - KDE, GNOME, Xfce, DVD, CD, 32-bit, 64-bit, different language 'spins'. Someone did a bit of research and found that only 33% of the people who got to the download area then managed to reach the point of actually downloading anything... so we instead implemented a massively simplified download screen, which gave you the KDE live CD by default and offered the 32-bit install DVD as a second option, and relegated everything else to the release notes. Whereupon the download numbers went up but all the 64-bit fans, GNOME fans, Xfce fans etc were up in arms. I couldn't ever think of a decent compromise, I'm not sure there *is* one. There's a penalty to exposing all the choices and a penalty to *not* exposing all the choices. As I said a few mails back, before we can even attempt an answer, we really need a definition of what set of potential users we actually care about. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From kevin.kofler at chello.at Sat May 2 17:57:56 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 02 May 2009 19:57:56 +0200 Subject: Abandon "Default Desktop" References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <49F80664.6010809@robertoragusa.it> <1241037119.3213.2.camel@localhost.localdomain> <6c3f5e6c0904291514n371fa179k1901af657e05a5b5@mail.gmail.com> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <16de708d0904301051r647b9f14qc1fe7d343bdbd778@mail.gmail.com> <1241114354.7846.5.camel@localhost.localdomain> Message-ID: Jesse Keating wrote: > The board would likely never say that. However there are a large number > of Fedora resources that are focused on new technology and advancements > in the user experience. Most of this effort is focused on the Gnome > desktop. This is due to the number of package maintainers in Fedora > that are also the upstream developers. So we do tend to see the new > things in Gnome first, and then KDE later (see NetworkManager, > PackageManager, pulseaudio, DeviceKit, power management, so on, so > forth). Well, a few things there: * sweeping KDE under the carpet is not the way to attract more effort towards KDE. We need more manpower to be more active in upstream KDE development, not just packaging, but we aren't going to get that manpower if we place ourselves as a distribution hostile to KDE. We KDE SIG people have been fairly successful at fighting the historically-motivated suspicions of KDE people about Fedora, but GNOME bias in things like the download page or the way the desktop environment gets selected on the DVD can quickly lead to new bad blood flowing. * PulseAudio has actually been the default in Fedora's KDE ever since it was the default in GNOME (Fedora 8). * KPackageKit has been available since Fedora 10 (only 1 release late) and also as an update for Fedora 9 (where PackageKit was first introduced). * power management just works with KDE apps. Up to Fedora 9, we had the KDE 3 KPowerSave. In Fedora 10, we shipped guidance-power-manager, a PyKDE4 app. And now, power management is part of KDE 4.2 itself (PowerDevil) and that's what will be the default from Fedora 11 onwards. We never relied on GNOME/GTK+ apps for power management. And I actually asked about desktop dependencies of https://fedoraproject.org/wiki/Features/PowerManagement feature and was told it's work at the lower levels and should benefit both GNOME and KDE alike. Now it's true that the KDE frontends for NetworkManager are still experimental (and so we're still defaulting to the GNOME one even in the KDE image), but the KDE spin has fully working networking with NM-gnome, which is exactly what the GNOME spin is using too, so it's not like this is going to make the KDE spin look broken. (That said, hopefully we'll be able to default to the native NM plasmoid in Fedora 12.) As for DeviceKit: what exactly does this bring to the user? I see only a limited set of new features. The main point is really that it is new code and HAL is old, and yes, a DeviceKit backend for Solid is needed. But I can't see how not having it available now is going to make KDE look bad. Kevin Kofler From oget.fedora at gmail.com Sat May 2 18:03:45 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Sat, 2 May 2009 14:03:45 -0400 Subject: Abandon "Default Desktop" In-Reply-To: References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <6c3f5e6c0904291514n371fa179k1901af657e05a5b5@mail.gmail.com> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <1241114797.32113.267.camel@adam.local.net> Message-ID: On Sat, May 2, 2009 at 1:34 PM, Kevin Kofler wrote: > Adam Williamson wrote: >> I already explained that, we're circling *again*. The problem is that >> when you ask someone to make a choice without understanding the options, >> it tends to frustrate them. This is a well-observed phenomenon in all >> circles, certainly including computer user interface design. > > This would just be one single choice, and a choice a sizable portion of our > userbase wants to make (even those who happen to use Fedora's current > defaults: ask them around how they'd react if Fedora would install KDE by > default and making it a complex hunt of checkboxes to select GNOME instead, > also by making all the use-case-specific groups default to KDE apps and > having the GNOME equivalents part of the GNOME group instead; yet that's > exactly what's done right now, except with GNOME<->KDE switched around). > The current solution is highly inconvenient. I can only really recommend > the KDE live spin for KDE users. Sadly, that one is hidden behind a small > link on the default download page, with the default download not even > containing KDE at all. > I'm not sure if it is my fault, but when I click on that "KDE fans, go here" link, I can't find the link to the live KDE spin image for x86_64. There is only one link for x86 image. I had to browse through http://download.fedoraproject.org/pub/fedora/linux/ to find the x86_64 image. Is this intentional? I respect the love for Gnome, and its simplicity. But I find Gnome simply ugly (sorry, this is the best one-word I could find). I don't believe that KDE is being treated fairly on the Fedora until you install it. Orcan From mzerqung at 0pointer.de Sat May 2 18:04:07 2009 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Sat, 2 May 2009 20:04:07 +0200 Subject: Abandon "Default Desktop" In-Reply-To: References: <1241037119.3213.2.camel@localhost.localdomain> <6c3f5e6c0904291514n371fa179k1901af657e05a5b5@mail.gmail.com> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <1241114797.32113.267.camel@adam.local.net> Message-ID: <20090502180407.GB22833@tango.0pointer.de> On Sat, 02.05.09 19:34, Kevin Kofler (kevin.kofler at chello.at) wrote: > > Adam Williamson wrote: > > I already explained that, we're circling *again*. The problem is that > > when you ask someone to make a choice without understanding the options, > > it tends to frustrate them. This is a well-observed phenomenon in all > > circles, certainly including computer user interface design. > > This would just be one single choice, and a choice a sizable portion of our > userbase wants to make (even those who happen to use Fedora's current > defaults: ask them around how they'd react if Fedora would install KDE by > default and making it a complex hunt of checkboxes to select GNOME instead, > also by making all the use-case-specific groups default to KDE apps and > having the GNOME equivalents part of the GNOME group instead; yet that's > exactly what's done right now, except with GNOME<->KDE switched around). > The current solution is highly inconvenient. I can only really recommend > the KDE live spin for KDE users. Sadly, that one is hidden behind a small > link on the default download page, with the default download not even > containing KDE at all. How naive are you? Are you aware that Red Hat employs a substantial number of developers to hack on GNOME in Fedora, but zero to hack on KDE? Do you believe that if Fedora would start to ship KDE more prominently that RH would tell its developers to hack on KDE? That is not going to happen. RH is a GNOME shop. So, it all comes down to a question of resources: we have substantial full-time man power working on GNOME in Fedora and only a hand-full of community people working on KDE in Fedora. Now, I am not saying that the KDE community work was bad or worse than the one the GNOME full-timers do, but in the end it boils down to: GNOME gets a lot of love, KDE a lot less in Fedora. So, before discussingwhether or not to feature KDE more prominently or even in the default install please come up with the necessary resources for development, support and suchlike to come even remotely near to what we can provide for GNOME. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Sat May 2 18:20:13 2009 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Sat, 2 May 2009 20:20:13 +0200 Subject: Abandon "Default Desktop" In-Reply-To: References: <1241037119.3213.2.camel@localhost.localdomain> <6c3f5e6c0904291514n371fa179k1901af657e05a5b5@mail.gmail.com> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <16de708d0904301051r647b9f14qc1fe7d343bdbd778@mail.gmail.com> <1241114354.7846.5.camel@localhost.localdomain> Message-ID: <20090502182013.GC22833@tango.0pointer.de> On Sat, 02.05.09 19:57, Kevin Kofler (kevin.kofler at chello.at) wrote: > * sweeping KDE under the carpet is not the way to attract more effort > towards KDE. We need more manpower to be more active in upstream KDE > development, not just packaging, but we aren't going to get that manpower > if we place ourselves as a distribution hostile to KDE. We KDE SIG people > have been fairly successful at fighting the historically-motivated > suspicions of KDE people about Fedora, but GNOME bias in things like the > download page or the way the desktop environment gets selected on the DVD > can quickly lead to new bad blood flowing. This is all the wrong way round. Don't misunderstand Fedora as nothing but a vechicle to attract developers. People join a project voluntarily only after they decided they love the software and know it very well. If someone reached that level he is far beyond the point where the option that something gets installed by default or not would hold him back. It's naive to believe that just by installing something by default you coul attract developers to it and get all outstanding issues get fixed miraculously. When you add something prominently in the default install you FIRST need to make sure you have enough resources to support and develop it further. Don't do it the other way round! And if the project you are pushing is an alternative for something already available in the default install then the bar is even higher and you need to have remotely similar manpower available than the other alterantive has. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From kevin.kofler at chello.at Sat May 2 18:46:51 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 02 May 2009 20:46:51 +0200 Subject: Abandon "Default Desktop" References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <49F80664.6010809@robertoragusa.it> <1241037119.3213.2.camel@localhost.localdomain> <6c3f5e6c0904291514n371fa179k1901af657e05a5b5@mail.gmail.com> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <16de708d0904301051r647b9f14qc1fe7d343bdbd778@mail.gmail.com> <49FA85C7.8000607@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > If you want to give ideas on doing it or help in doing it better, step > up and participate with the websites team. Just listing the desktop live images next to each other like the old download page did is the right way to do it. The old download page was better, the new one is a typical case of "fixing" something which was not broken. The only thing the old page was missing was clearly stating that the "Desktop Live" image is GNOME. That still didn't get fixed properly. (The word "GNOME" now at least shows up in the description, but it ought to be in the name, or at least in parentheses next to the name.) > All these were discussed openly in the mailing lists and I didn't see you > participating. I did participate, raising mostly the same issues Arthur is raising. I got ignored. >>> I don't see why I shouldn't ask for Xfce and ratpoison >>> as among the choices offered >> >> I'm not sure the XFCE devs would appreciate you equating their desktop >> environment with a window manager. > > Where did I do that? "Xfce and ratpoison" > KDE community in Fedora is very good but there is not enough volunteers > in the Fedora community to keep pace with the new developments. You can > see the effect of that everywhere. One example: KDE continues to > include nm-applet for several releases now because the KDE equivalent is > completely broken and has been for quite sometime. Not having a default > desktop is not going to help fix such issues. Less fanboyism and more > actual participation, please. Quite the opposite, hiding KDE as much as you can get away with is not going to help fix such issues. Don't you realize how GNOME bias is deterring KDE people from contributing to (and even using) Fedora? Feature it as prominently as GNOME and we'll get more people interested in KDE showing up to contribute. The more visible KDE is, the more people interested in KDE we will attract. Kevin Kofler From kevin.kofler at chello.at Sat May 2 18:48:20 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 02 May 2009 20:48:20 +0200 Subject: Abandon "Default Desktop" References: <16de708d0904301051r647b9f14qc1fe7d343bdbd778@mail.gmail.com> <2033840182.237361241242199768.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: Jens Petersen wrote: > At list the the get-prerelease page has KDE Live Media listed below Fedora > Desktop Live Media now. So perhaps that is how it will be for F11? Unfortunately, I doubt it. The get-prerelease page is modeled after the "All downloads" list, a.k.a. the old download page (which is hidden behind a link on the new download page). Kevin Kofler From kevin.kofler at chello.at Sat May 2 18:50:12 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 02 May 2009 20:50:12 +0200 Subject: Abandon "Default Desktop" References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <16de708d0904271530v135a0a4ep3ab020d798a36c5e@mail.gmail.com> <3adc77210904271556i502559acn37c2002c124a80ff@mail.gmail.com> <49F70FB1.20603@hi.is> <3adc77210904280848pb8000a2h1189866bd6d17db5@mail.gmail.com> <1240953073.32113.225.camel@adam.local.net> <49F80664.6010809@robertoragusa.it> <1241037119.3213.2.camel@localhost.localdomain> <6c3f5e6c0904291514n371fa179k1901af657e05a5b5@mail.gmail.com> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F97AA9.60601@googlemail.com> <49FBABE1.50207@redhat.com> Message-ID: Casey Dahlin wrote: > Bill Crawford wrote: >> On the whole, however, I'm in the "those who think the user should be >> allowed to choose" camp ;o) > > Which is where we are now. Not really. Right now we're in the "the user is allowed to choose, but we make it as hard as we can get away with to actually get to that choice" camp. :-( Kevin Kofler From kevin.kofler at chello.at Sat May 2 19:03:56 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 02 May 2009 21:03:56 +0200 Subject: diff between 'make build' and 'make mockbuild' References: Message-ID: Neal Becker wrote: > I'm trying to debug why 'make build' of python-igraph-0.5.2-2 on fc12 > gives segfault. If I try to debug, using 'make mockbuild', I get a > different result. In that case, I get > ERROR: Bad build req: No Package Found for igraph-devel = 0.5.2. Exiting. > > Why does 'make build' find the required igraph-devel, but 'make mockbuild' > doesn't, and what can I do about it? make mockbuild is still using F11 Rawhide. There's no F12 Rawhide yet. Kevin Kofler From jspaleta at gmail.com Sat May 2 19:05:37 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 2 May 2009 11:05:37 -0800 Subject: Abandon "Default Desktop" In-Reply-To: <20090502180407.GB22833@tango.0pointer.de> References: <1241037119.3213.2.camel@localhost.localdomain> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <1241114797.32113.267.camel@adam.local.net> <20090502180407.GB22833@tango.0pointer.de> Message-ID: <604aa7910905021205t30781959u3cfc842a01d68642@mail.gmail.com> On Sat, May 2, 2009 at 10:04 AM, Lennart Poettering wrote: > So, before discussingwhether or not to feature KDE more prominently or > even in the default install please come up with the necessary > resources for development, support and suchlike to come even remotely > near to what we can provide for GNOME. When we talk about bring resources to the table..do we have a good idea of what sort of bar to meet? If for example our current KDE SIG championed a lobbying campaign for Nokia resources for the KDE effort in Fedora, what would they need to shoot for? I don't have a problem with a "put up or shutup" challenge when it comes to development resources and long term Fedora policy. I sit outside the Red Hat fenceline (Ralf can't dismiss my opinion on the same grounds as he has done to Jesse and Rahul but I'm sure he'll find a way) and I can say that I generally agree with what Jesse has previously said concerning Red Hat, Gnome and Fedora policy. I have no delusions about Fedora and Red Hat interests being intertwined. The question is what is the resources bar that must be met to give other interests outside of RH a bigger stake in long term Fedora policy? I don't have an answer to that. I wish I did. I'd very much like to be able to give the KDE SIG an affirmative roadmap they could use to marshal support and to show sufficient resource commitment along the lines of what you are talking about. But the last thing I want to do is set a sliding bar that can never be reached. Without that sort of sufficiency definition, your challenge is very difficult to implement. -jef From jspaleta at gmail.com Sat May 2 19:08:45 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 2 May 2009 11:08:45 -0800 Subject: Abandon "Default Desktop" In-Reply-To: References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <1241114797.32113.267.camel@adam.local.net> <49FAC39F.6030405@alexhudson.com> Message-ID: <604aa7910905021208x52ca8e31oc277f87f4ae93fa5@mail.gmail.com> On Sat, May 2, 2009 at 9:30 AM, Kevin Kofler wrote: > A related issue is the way the current comps is structured, where categories > like "Graphical Internet", "Sound and Video" etc. are basically all GNOME > or GTK+ apps, the equivalent KDE apps are all in "K Desktop Environment". > We'd need a better comps structure (more conditionals? Maybe specific > handling of conditionals based on the desktop selected in the radiobutton? > Or maybe different versions of comps depending on the selected desktop?) to > really treat the desktops in a fair way and make a desktop selection screen > work properly. Okay technical feasibility questions: Would you need new anaconda functionality to be developed to get the comps functionality you wanted or is this strictly an alternative comps construction? -jef From jdieter at gmail.com Sat May 2 19:21:19 2009 From: jdieter at gmail.com (Jonathan Dieter) Date: Sat, 02 May 2009 22:21:19 +0300 Subject: presto download saving summary In-Reply-To: <1241214858.3682.2.camel@choeger6> References: <1241214858.3682.2.camel@choeger6> Message-ID: <1241292079.12755.1.camel@jdlaptop.lesbg.loc> On Fri, 2009-05-01 at 23:54 +0200, Christoph H?ger wrote: > Hi, > > presto is really awesome. It cut down a 170MB download on a 320kbit/s > line to 5MB today. > > But where is the > > Size of all updates downloaded from Presto-enabled repositories: 2.4M > Size of updates that would have been downloaded if Presto wasn?t > enabled: 24M > This is a savings of 90 percent > > summary gone? (taken from pauls blog entry) > > I do not get those messages anymore. Which version of yum-presto are you using? In the newest version (though I'm not sure if it's the one in Rawhide or the one that will be in Rawhide after GA), the message has been shortened and moved to directly after the downloads are completed. Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kevin.kofler at chello.at Sat May 2 21:01:01 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 02 May 2009 23:01:01 +0200 Subject: Abandon "Default Desktop" References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <1241114797.32113.267.camel@adam.local.net> <49FAC39F.6030405@alexhudson.com> <604aa7910905021208x52ca8e31oc277f87f4ae93fa5@mail.gmail.com> Message-ID: Jeff Spaleta wrote: > Would you need new anaconda functionality to be developed to get the > comps functionality you wanted or is this strictly an alternative > comps construction? Well, at least Anaconda needs to actually offer that radiobutton. How to deal with comps is then the next question, but I don't believe whatever required changes to be hard to implement at all and I'd be willing to write the patch. Kevin Kofler From kevin.kofler at chello.at Sat May 2 21:01:58 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 02 May 2009 23:01:58 +0200 Subject: Abandon "Default Desktop" References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <6c3f5e6c0904291514n371fa179k1901af657e05a5b5@mail.gmail.com> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <1241114797.32113.267.camel@adam.local.net> Message-ID: Orcan Ogetbil wrote: > I'm not sure if it is my fault, but when I click on that "KDE fans, go > here" link, I can't find the link to the live KDE spin image for > x86_64. There is only one link for x86 image. I had to browse through > http://download.fedoraproject.org/pub/fedora/linux/ to find the x86_64 > image. Is this intentional? It's the same for all the images, the 64-bit downloads are all only shown in the "all downloads" list, which is the second big beef I have with the new download page. Kevin Kofler From sundaram at fedoraproject.org Sat May 2 21:35:46 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 03 May 2009 03:05:46 +0530 Subject: Abandon "Default Desktop" In-Reply-To: References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <49F80664.6010809@robertoragusa.it> <1241037119.3213.2.camel@localhost.localdomain> <6c3f5e6c0904291514n371fa179k1901af657e05a5b5@mail.gmail.com> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <16de708d0904301051r647b9f14qc1fe7d343bdbd778@mail.gmail.com> <1241114354.7846.5.camel@localhost.localdomain> <49FAB6AB.9060601@freenet.de> <49FAB9D6.6030203@fedoraproject.org> <49FABC2B.8050500@freenet.de> <49FAC168.4060707@fedoraproject.org> Message-ID: <49FCBCB2.8090003@fedoraproject.org> On 05/02/2009 11:11 PM, Kevin Kofler wrote: > Rahul Sundaram wrote: >> Anyone interested can look at the desktop focused features in the >> feature list for every release and results should speak for themselves. >> Those who shoulder the burden of the work decide the direction of the >> project as always. > > Are you suggesting we should be writing up feature pages for any single > upstream KDE improvement we'll be shipping in the next release? Because > that's what the GNOME folks are doing. GNOME folks are doing it for the upstream features they are directly driving. If KDE folks in Fedora have similar development, then yes, I would expect you to write up a feature page. If you don't, that's your loss. Rahul From sundaram at fedoraproject.org Sat May 2 21:38:45 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 03 May 2009 03:08:45 +0530 Subject: Abandon "Default Desktop" In-Reply-To: References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <49F80664.6010809@robertoragusa.it> <1241037119.3213.2.camel@localhost.localdomain> <6c3f5e6c0904291514n371fa179k1901af657e05a5b5@mail.gmail.com> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <16de708d0904301051r647b9f14qc1fe7d343bdbd778@mail.gmail.com> <49FA85C7.8000607@fedoraproject.org> Message-ID: <49FCBD65.4070508@fedoraproject.org> On 05/03/2009 12:16 AM, Kevin Kofler wrote: > Rahul Sundaram wrote: >> If you want to give ideas on doing it or help in doing it better, step >> up and participate with the websites team. > > Just listing the desktop live images next to each other like the old > download page did is the right way to do it. > > The old download page was better, the new one is a typical case of "fixing" > something which was not broken. The only thing the old page was missing was > clearly stating that the "Desktop Live" image is GNOME. That still didn't > get fixed properly. (The word "GNOME" now at least shows up in the > description, but it ought to be in the name, or at least in parentheses > next to the name.) Actually the old page confused a lot of people. Do you follow Fedora forum posts or fedora-website list queries? If so, you would have know that already. Rahul From drago01 at gmail.com Sat May 2 21:39:16 2009 From: drago01 at gmail.com (drago01) Date: Sat, 2 May 2009 23:39:16 +0200 Subject: Abandon "Default Desktop" In-Reply-To: References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <1241114797.32113.267.camel@adam.local.net> Message-ID: On Sat, May 2, 2009 at 11:01 PM, Kevin Kofler wrote: > Orcan Ogetbil wrote: >> I'm not sure if it is my fault, but when I click on that "KDE fans, go >> here" link, I can't find the link to the live KDE spin image for >> x86_64. There is only one link for x86 image. I had to browse through >> http://download.fedoraproject.org/pub/fedora/linux/ to find the x86_64 >> image. Is this intentional? > > It's the same for all the images, the 64-bit downloads are all only shown in > the "all downloads" list, which is the second big beef I have with the new > download page. Which is plain wrong but the websites team seems not to care (started a thread on the websites-list which did not change anything). From sundaram at fedoraproject.org Sat May 2 21:49:38 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 03 May 2009 03:19:38 +0530 Subject: Abandon "Default Desktop" In-Reply-To: References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <1241114797.32113.267.camel@adam.local.net> Message-ID: <49FCBFF2.4060002@fedoraproject.org> On 05/03/2009 03:09 AM, drago01 wrote: > On Sat, May 2, 2009 at 11:01 PM, Kevin Kofler wrote: >> Orcan Ogetbil wrote: >>> I'm not sure if it is my fault, but when I click on that "KDE fans, go >>> here" link, I can't find the link to the live KDE spin image for >>> x86_64. There is only one link for x86 image. I had to browse through >>> http://download.fedoraproject.org/pub/fedora/linux/ to find the x86_64 >>> image. Is this intentional? >> It's the same for all the images, the 64-bit downloads are all only shown in >> the "all downloads" list, which is the second big beef I have with the new >> download page. > > Which is plain wrong but the websites team seems not to care (started > a thread on the websites-list which did not change anything). Yes, I requested you raise it to FESCo about making x86_64 the default as per your suggestion. You seem to have not done that. Note, if you want issues to be tracked, it should be filed in the tracker and not just posted to the list. Rahul From gmaxwell at gmail.com Sat May 2 21:48:45 2009 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Sat, 2 May 2009 17:48:45 -0400 Subject: RFC: Fedora 11 FAQ In-Reply-To: <49FAC244.3050707@fedoraproject.org> References: <49FAC244.3050707@fedoraproject.org> Message-ID: On Fri, May 1, 2009 at 5:35 AM, Rahul Sundaram wrote: > Hi, > > I have posted a draft of the Fedora 11 FAQ at > > https://fedoraproject.org/wiki/Fedora_11_FAQ > > Feel free to edit the wiki if you want to highlight anything else or > drop me a mail and I will add them. *Firefox 3.1 and ThunderBird 3.0 There is no such beast as firefox 3.1. The 3.1 stuff was renamed to 3.5. From sundaram at fedoraproject.org Sat May 2 21:59:01 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 03 May 2009 03:29:01 +0530 Subject: RFC: Fedora 11 FAQ In-Reply-To: References: <49FAC244.3050707@fedoraproject.org> Message-ID: <49FCC225.2070005@fedoraproject.org> On 05/03/2009 03:18 AM, Gregory Maxwell wrote: > On Fri, May 1, 2009 at 5:35 AM, Rahul Sundaram > wrote: >> Hi, >> >> I have posted a draft of the Fedora 11 FAQ at >> >> https://fedoraproject.org/wiki/Fedora_11_FAQ >> >> Feel free to edit the wiki if you want to highlight anything else or >> drop me a mail and I will add them. > > *Firefox 3.1 and ThunderBird 3.0 > > There is no such beast as firefox 3.1. > > The 3.1 stuff was renamed to 3.5. Already fixed. Strangely the wiki page shows Firefox 3.5 if I login and Firefox 3.1 otherwise. I saw something similar in another wiki page as well. Ian? Rahul From kevin.kofler at chello.at Sat May 2 22:05:16 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 03 May 2009 00:05:16 +0200 Subject: Abandon "Default Desktop" References: <1241037119.3213.2.camel@localhost.localdomain> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <1241114797.32113.267.camel@adam.local.net> <20090502180407.GB22833@tango.0pointer.de> <604aa7910905021205t30781959u3cfc842a01d68642@mail.gmail.com> Message-ID: Jeff Spaleta wrote: > When we talk about bring resources to the table..do we have a good > idea of what sort of bar to meet? If for example our current KDE SIG > championed a lobbying campaign for Nokia resources for the KDE effort > in Fedora, what would they need to shoot for? Hmmm, is this really all about money? If we had 100 volunteers working on KDE, actually outnumbering the GNOME developers on the RH payroll, but few to no payed professionals, would you still consider us second class because no money is involved? I think the primary problem here is numbers, not money. Of course, money would help getting the numbers up, but IMHO it isn't a goal by itself, just one of the ways to get there. Kevin Kofler From kevin.kofler at chello.at Sat May 2 22:20:57 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 03 May 2009 00:20:57 +0200 Subject: Abandon "Default Desktop" References: <1241037119.3213.2.camel@localhost.localdomain> <6c3f5e6c0904291514n371fa179k1901af657e05a5b5@mail.gmail.com> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <16de708d0904301051r647b9f14qc1fe7d343bdbd778@mail.gmail.com> <1241114354.7846.5.camel@localhost.localdomain> <20090502182013.GC22833@tango.0pointer.de> Message-ID: Lennart Poettering wrote: > People join a project voluntarily only after they decided they love > the software and know it very well. If someone reached that level he > is far beyond the point where the option that something gets installed > by default or not would hold him back. It's not that installing KDE on Fedora is hard for those people, it's all about the impression they get, including: * how KDE is treated in marketing compared to GNOME and * how easy it will be for end users to install the fruits of their work. Treating KDE as a second-class citizen isn't going to motivate anybody who likes developing KDE, for KDE or with KDE to participate, even if the actual hassle is minimal for those potential contributors. > It's naive to believe that just by installing something by default > you coul attract developers to it and get all outstanding issues get > fixed miraculously. The proposal isn't to make KDE the default, it's to make it an option presented directly below GNOME on the web page (as it used to be) and easily selectable in the DVD installer (with a radiobutton, as in most other DVD-sized distributions), and to not name the GNOME live spin in a misleading way which implies to a na?ve user that GNOME is the only existing desktop. Kevin Kofler From kevin.kofler at chello.at Sat May 2 22:23:00 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 03 May 2009 00:23:00 +0200 Subject: Abandon "Default Desktop" References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <1241114797.32113.267.camel@adam.local.net> Message-ID: drago01 wrote: > On Sat, May 2, 2009 at 11:01 PM, Kevin Kofler wrote: >> It's the same for all the images, the 64-bit downloads are all only shown >> in the "all downloads" list, which is the second big beef I have with the >> new download page. > > Which is plain wrong +1 > but the websites team seems not to care (started a thread on the > websites-list which did not change anything). :-( Kevin Kofler From jspaleta at gmail.com Sat May 2 22:26:09 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 2 May 2009 14:26:09 -0800 Subject: Abandon "Default Desktop" In-Reply-To: References: <1241037119.3213.2.camel@localhost.localdomain> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <1241114797.32113.267.camel@adam.local.net> <20090502180407.GB22833@tango.0pointer.de> <604aa7910905021205t30781959u3cfc842a01d68642@mail.gmail.com> Message-ID: <604aa7910905021526t15b8ba46qf52915b74fce437b@mail.gmail.com> On Sat, May 2, 2009 at 2:05 PM, Kevin Kofler wrote: > I think the primary problem here is numbers, not money. Of course, money > would help getting the numbers up, but IMHO it isn't a goal by itself, just > one of the ways to get there. It was an example... my point is I don't think there is an understanding of what sufficient means whether its people or bandwidth or iron or kittens. -jef From kevin.kofler at chello.at Sat May 2 22:25:32 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 03 May 2009 00:25:32 +0200 Subject: RFC: Fedora 11 FAQ References: <49FAC244.3050707@fedoraproject.org> <49FCC225.2070005@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > Already fixed. Strangely the wiki page shows Firefox 3.5 if I login and > Firefox 3.1 otherwise. I saw something similar in another wiki page as > well. The pages shown to anonymous users are cached. (It's one of the tricks in MediaWiki which makes it more scalable than e.g. MoinMoin.) My guess is that the cache doesn't get refreshed properly. Kevin Kofler From drago01 at gmail.com Sat May 2 22:52:17 2009 From: drago01 at gmail.com (drago01) Date: Sun, 3 May 2009 00:52:17 +0200 Subject: Abandon "Default Desktop" In-Reply-To: <49FCBFF2.4060002@fedoraproject.org> References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <1241114797.32113.267.camel@adam.local.net> <49FCBFF2.4060002@fedoraproject.org> Message-ID: On Sat, May 2, 2009 at 11:49 PM, Rahul Sundaram wrote: > On 05/03/2009 03:09 AM, drago01 wrote: >> On Sat, May 2, 2009 at 11:01 PM, Kevin Kofler wrote: >>> Orcan Ogetbil wrote: >>>> I'm not sure if it is my fault, but when I click on that "KDE fans, go >>>> here" link, I can't find the link to the live KDE spin image for >>>> x86_64. There is only one link for x86 image. I had to browse through >>>> http://download.fedoraproject.org/pub/fedora/linux/ to find the x86_64 >>>> image. Is this intentional? >>> It's the same for all the images, the 64-bit downloads are all only shown in >>> the "all downloads" list, which is the second big beef I have with the new >>> download page. >> >> Which is plain wrong but the websites team seems not to care (started >> a thread on the websites-list which did not change anything). > > Yes, I requested you raise it to FESCo about making x86_64 the default > as per your suggestion. You seem to have not done that. Note, if you > want issues to be tracked, it should be filed in the tracker and not > just posted to the list. > Yes I know but I didn't really want to "force" the change but convince the people who do the work to change it. After the thread died I went on to other things and forgot about it until Kevin mentioned it again. From drago01 at gmail.com Sat May 2 22:57:42 2009 From: drago01 at gmail.com (drago01) Date: Sun, 3 May 2009 00:57:42 +0200 Subject: Abandon "Default Desktop" In-Reply-To: References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <49F96CE6.5090504@fedoraproject.org> <1241114797.32113.267.camel@adam.local.net> <49FCBFF2.4060002@fedoraproject.org> Message-ID: On Sun, May 3, 2009 at 12:52 AM, drago01 wrote: > On Sat, May 2, 2009 at 11:49 PM, Rahul Sundaram > wrote: >> On 05/03/2009 03:09 AM, drago01 wrote: >>> On Sat, May 2, 2009 at 11:01 PM, Kevin Kofler wrote: >>>> Orcan Ogetbil wrote: >>>>> I'm not sure if it is my fault, but when I click on that "KDE fans, go >>>>> here" link, I can't find the link to the live KDE spin image for >>>>> x86_64. There is only one link for x86 image. I had to browse through >>>>> http://download.fedoraproject.org/pub/fedora/linux/ to find the x86_64 >>>>> image. Is this intentional? >>>> It's the same for all the images, the 64-bit downloads are all only shown in >>>> the "all downloads" list, which is the second big beef I have with the new >>>> download page. >>> >>> Which is plain wrong but the websites team seems not to care (started >>> a thread on the websites-list which did not change anything). >> >> Yes, I requested you raise it to FESCo about making x86_64 the default >> as per your suggestion. You seem to have not done that. Note, if you >> want issues to be tracked, it should be filed in the tracker and not >> just posted to the list. >> > > Yes I know but I didn't really want to "force" the change but convince > the people who do the work to change it. > After the thread died I went on to other things and forgot about it > until Kevin mentioned it again. > But well filled a ticket for FESCo: https://fedorahosted.org/fesco/ticket/142 From bnocera at redhat.com Sun May 3 00:34:48 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Sun, 03 May 2009 01:34:48 +0100 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <20090502140305.GB32549@wolff.to> References: <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> <20090502014029.GC1496739@hiwaay.net> <20090502014259.GA28052@angus.ind.WPI.EDU> <1241260456.20413.2098.camel@cookie.hadess.net> <20090502140305.GB32549@wolff.to> Message-ID: <1241310888.20413.3780.camel@cookie.hadess.net> On Sat, 2009-05-02 at 09:03 -0500, Bruno Wolff III wrote: > On Sat, May 02, 2009 at 11:34:16 +0100, > Bastien Nocera wrote: > > > > We worked on the new gnome-volume-control because pavucontrol is a "show > > all the options underneath" program, just like the ALSA mixers were. > > But it shows different sets of all controls than the ALSA mixer. I found > I could use it to boost the volume, but the noise was unacceptable. It > ended up just delaying me from finding alsamixer which I could use to > really fix my problem. Do you realise that your answer has nothing to do with my point? I'm talking about the usability design of gnome-volume-control, and you talk to me about which knobs it wiggles. From bnocera at redhat.com Sun May 3 00:39:38 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Sun, 03 May 2009 01:39:38 +0100 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <1241282761.2923.9.camel@adam.local.net> References: <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <20090502002529.GA29316@srcf.ucam.org> <20090502135734.GE3520@localhost.localdomain> <20090502142757.GA4295@srcf.ucam.org> <20090502145234.GB7160@tango.0pointer.de> <1241282761.2923.9.camel@adam.local.net> Message-ID: <1241311178.20413.3791.camel@cookie.hadess.net> On Sat, 2009-05-02 at 09:46 -0700, Adam Williamson wrote: > On Sat, 2009-05-02 at 16:52 +0200, Lennart Poettering wrote: > > On Sat, 02.05.09 15:27, Matthew Garrett (mjg at redhat.com) wrote: > > > > > > > > On Sat, May 02, 2009 at 09:57:34AM -0400, Paul W. Frields wrote: > > > > > > > Of course, if I understand correctly, you're not saying pavucontrol > > > > would disappear, just that the design considerations under discussion > > > > might call for it to not be installed by default. Right? > > > > > > I'm not on the desktop team, but I guess it wouldn't be impossible. I'm > > > actually surprised to find that it's installed by default - seeing it in > > > the menu, I'd assumed that it just opened the same preferences as g-v-c > > > does. The degree of overlap of functionality is pretty huge. > > > > pavucontrol should have been dropped from the default install the > > minute the new g-v-c was pushed into Fedora. We forgot to do that. We > > should do it now. End of story. > > So what do we do about profile switching - digital output, analog > surround output? Then you people can use the gst-mixer you're packaging, it will work just as well (or as badly) as it used to. From bnocera at redhat.com Sun May 3 00:47:16 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Sun, 03 May 2009 01:47:16 +0100 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: References: <1241123673.32113.299.camel@adam.local.net> <20090430210019.GC25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> <20090502014029.GC1496739@hiwaay.net> <20090502014259.GA28052@angus.ind.WPI.EDU> <1241260456.20413.2098.camel@cookie.hadess.net> Message-ID: <1241311636.20413.3815.camel@cookie.hadess.net> On Sat, 2009-05-02 at 18:53 +0200, Kevin Kofler wrote: > Bastien Nocera wrote: > > We worked on the new gnome-volume-control because pavucontrol is a "show > > all the options underneath" program, just like the ALSA mixers were. > > > > We wrote use cases, we checked what other systems did, and we intend to > > present something to the user that's less complicated than showing up > > all the knobs PulseAudio offers. > > Translation: > > "We worked on the new gnome-volume-control because pavucontrol has too many > features and we hate powerful applications. > > So we wrote down the simplest use cases we could come up with in a short > brainstorming session and decided to remove all the useful features we > didn't think of, not asking for any actual user input, and we intend to > present a crippled user interface only showing that simplistic subset of > features." > > And then you're surprised clich?s about GNOME working exactly that way > circulate? First of all, I'd appreciate if you didn't put words in my mouth. And no, we usually don't ask for as much user input as some other projects, because otherwise we get asked to show the old knobs for power users, instead of having them trying to explain what they're trying to do. I'd advise you to read "The inmates are running the asylum" by Alan Cooper (or "Is it just me or is everything shit?" if you're in a lighter mood). From bnocera at redhat.com Sun May 3 00:59:05 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Sun, 03 May 2009 01:59:05 +0100 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <1241285539.2923.19.camel@adam.local.net> References: <1241123673.32113.299.camel@adam.local.net> <20090430210019.GC25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> <20090502014029.GC1496739@hiwaay.net> <20090502014259.GA28052@angus.ind.WPI.EDU> <1241260456.20413.2098.camel@cookie.hadess.net> <1241285539.2923.19.camel@adam.local.net> Message-ID: <1241312345.20413.3851.camel@cookie.hadess.net> On Sat, 2009-05-02 at 10:32 -0700, Adam Williamson wrote: > On Sat, 2009-05-02 at 11:34 +0100, Bastien Nocera wrote: > > We wrote use cases, we checked what other systems did, and we intend > > to > > present something to the user that's less complicated than showing up > > all the knobs PulseAudio offers. > > Here's the other thing that gets me about this: okay, so you thought > about the use cases you want to support and came up with a design. > Great. > > But we don't even have that design yet. That design includes input > switching and profile switching. Tell me where I wrote that: https://fedoraproject.org/wiki/Features/VolumeControl#User_Experience *Where* I already asked this question when Will made the same assumption as you did, during the Fesco meeting. The use cases we had didn't include any need for profile switching. Yes we realised late we'd need it for some use cases, no, we didn't decide to ship an unfinished volume control that we knew would impact some use cases we didn't think of. And we already knew that we'd need profile switching for some things that we couldn't have before: - out-of-the-box multi-speaker setup support - multi-speakers testing - Bluetooth audio profile switching and service reservation (eg. only play stereo audio play through the headphones, and let a mobile phone connect to the headset, music stops when you receive a call) A couple of benefits from the current volume control compared to the old one: - "default" input and output control - microphone level checks - sound effects level control - per-application volume control (for apps that support it) The only use case(s) that we haven't catered for are for people who want to record things, and the sound card has more than 1 input. Yes, it's a big omission, but that doesn't mean you're allowed to write off the benefits we're bringing for a large number of users already. From awilliam at redhat.com Sun May 3 01:59:25 2009 From: awilliam at redhat.com (Adam Williamson) Date: Sat, 02 May 2009 18:59:25 -0700 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <1241312345.20413.3851.camel@cookie.hadess.net> References: <1241123673.32113.299.camel@adam.local.net> <20090430210019.GC25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> <20090502014029.GC1496739@hiwaay.net> <20090502014259.GA28052@angus.ind.WPI.EDU> <1241260456.20413.2098.camel@cookie.hadess.net> <1241285539.2923.19.camel@adam.local.net> <1241312345.20413.3851.camel@cookie.hadess.net> Message-ID: <1241315965.2923.33.camel@adam.local.net> On Sun, 2009-05-03 at 01:59 +0100, Bastien Nocera wrote: > > Here's the other thing that gets me about this: okay, so you thought > > about the use cases you want to support and came up with a design. > > Great. > > > > But we don't even have that design yet. That design includes input > > switching and profile switching. > > Tell me where I wrote that: > https://fedoraproject.org/wiki/Features/VolumeControl#User_Experience > > > > *Where* > > I already asked this question when Will made the same assumption as you > did, during the Fesco meeting. The use cases we had didn't include any > need for profile switching. That just makes me question even more your competence to be doing the design; if you manage to come up with a design for a mixer application without considering the importance of digital output, well. Er. That's...um. My output device is connected digitally. So are zillions of others. That's why soundcards ship with S/PDIF outputs. Even cheap crappy onboard sound, where the manufacturers would gladly save a cent any old way, universally include S/PDIF now - because people want it. How were you expecting us to hear any sound? I suspect this whole process was managed by people who are great at interface design, and great at the software side of audio/video (which I know you are), but perhaps didn't think hard enough about what people actually do with audio hardware. > Yes we realised late we'd need it for some use cases, no, we didn't > decide to ship an unfinished volume control that we knew would impact > some use cases we didn't think of. > > And we already knew that we'd need profile switching for some things > that we couldn't have before: > - out-of-the-box multi-speaker setup support > - multi-speakers testing > - Bluetooth audio profile switching and service reservation (eg. only > play stereo audio play through the headphones, and let a mobile phone > connect to the headset, music stops when you receive a call) These would all be awesome things, if they existed yet. Once they do, life will indeed be awesome. I anticipate their arrival avidly. > A couple of benefits from the current volume control compared to the old > one: > - "default" input and output control > - microphone level checks > - sound effects level control > - per-application volume control (for apps that support it) Yes, these are neat. Especially default input device control. And that's more support for the "ship two mixers" compromise (which, ironically, it turns out is exactly what we've been doing for three releases). These are great features of PulseAudio (supplied up till now by pavucontrol). I like them. I've written blog entries extolling their virtues. I've cited them in long argumentative threads about how PA is shit. But they don't excuse you from covering really basic audio use cases like *digital frickin' output*. > The only use case(s) that we haven't catered for are for people who want > to record things, and the sound card has more than 1 input. No, not correct at all. You haven't yet catered for people who want to *monitor* (rather than record) an input channel, people who have digital outputs, or people who have analog surround sound setups (the Logitech Z-5300 has been in production for about seven years for a *reason* - people buy this stuff). > Yes, it's a > big omission, but that doesn't mean you're allowed to write off the > benefits we're bringing for a large number of users already. I'm not. As I said, I like those things. Which I was I was on the side which was supporting the compromise by which we would have those features AND the features g-v-c is missing. It's not frickin' rocket science! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From chris.stone at gmail.com Sun May 3 03:21:21 2009 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 2 May 2009 20:21:21 -0700 Subject: Abandon "Default Desktop" In-Reply-To: <604aa7910905021526t15b8ba46qf52915b74fce437b@mail.gmail.com> References: <1241037119.3213.2.camel@localhost.localdomain> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <1241114797.32113.267.camel@adam.local.net> <20090502180407.GB22833@tango.0pointer.de> <604aa7910905021205t30781959u3cfc842a01d68642@mail.gmail.com> <604aa7910905021526t15b8ba46qf52915b74fce437b@mail.gmail.com> Message-ID: On Sat, May 2, 2009 at 3:26 PM, Jeff Spaleta wrote: > On Sat, May 2, 2009 at 2:05 PM, Kevin Kofler wrote: >> I think the primary problem here is numbers, not money. Of course, money >> would help getting the numbers up, but IMHO it isn't a goal by itself, just >> one of the ways to get there. > > > It was an example... my point is I don't think there is an > understanding of what sufficient means whether its people or bandwidth > or iron or kittens. So why not just declare that the KDE team is already sufficient and see where it goes? What harm could it cause? Seriously? /me wonders why bero left redhat to start ark linux... From rc040203 at freenet.de Sun May 3 05:04:47 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 03 May 2009 07:04:47 +0200 Subject: Abandon "Default Desktop" In-Reply-To: <49FAC168.4060707@fedoraproject.org> References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <49F80664.6010809@robertoragusa.it> <1241037119.3213.2.camel@localhost.localdomain> <6c3f5e6c0904291514n371fa179k1901af657e05a5b5@mail.gmail.com> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <16de708d0904301051r647b9f14qc1fe7d343bdbd778@mail.gmail.com> <1241114354.7846.5.camel@localhost.localdomain> <49FAB6AB.9060601@freenet.de> <49FAB9D6.6030203@fedoraproject.org> <49FABC2B.8050500@freenet.de> <49FAC168.4060707@fedoraproject.org> Message-ID: <49FD25EF.1040001@freenet.de> Rahul Sundaram wrote: > On 05/01/2009 02:38 PM, Ralf Corsepius wrote: > >> This doesn't invalidate the fact RH's predominance in Fedora-leadership >> and the amount of @RH's participating in Fedora shows effects. >> >> People like you and keating likely are too RH-streamlined and too close >> to RH to understand the importance of this consideration. > > Anyone interested can look at the desktop focused features in the > feature list for every release and results should speak for themselves. > Those who shoulder the burden of the work decide the direction of the > project as always. Yes. As part of upstream projects, not as part of Fedora. What currently is happening: Certain people on RH's payrole, who happen to be upstream for some packages, are abusing Fedora as vehicle to prematurely push "upstream works", sometimes at "any price". I am sure, if the same people weren't working for @RH and if these projects weren't in "RH's business interest", many of these developments would not make it into Fedora or at least not in the shape the Fedora community is facing them. One example for this is Gnome ... The KDE Fedora folks pick up the crumbs falling of Nokia's/Trolltech's/Novell/SUSE's table and "clean them up" as part of their Fedora integration works. Ralf From fedora at alexhudson.com Sun May 3 08:12:29 2009 From: fedora at alexhudson.com (Alex Hudson) Date: Sun, 03 May 2009 09:12:29 +0100 Subject: Abandon "Default Desktop" In-Reply-To: References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <16de708d0904271530v135a0a4ep3ab020d798a36c5e@mail.gmail.com> <3adc77210904271556i502559acn37c2002c124a80ff@mail.gmail.com> <49F70FB1.20603@hi.is> <3adc77210904280848pb8000a2h1189866bd6d17db5@mail.gmail.com> <1240953073.32113.225.camel@adam.local.net> <49F80664.6010809@robertoragusa.it> <1241037119.3213.2.camel@localhost.localdomain> <6c3f5e6c0904291514n371fa179k1901af657e05a5b5@mail.gmail.com> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <1241114797.32113.267.camel@adam.local.net> <49FAC39F.6030405@alexhudson.com> Message-ID: <49FD51ED.7000906@alexhudson.com> Hi Kevin, Kevin Kofler wrote: > The idea is that by selecting GNOME, you'd get GNOME apps as the default > apps (of course, there's still the question whether to use OO.o and Mozilla > apps or the official GNOME defaults, but that's already subject for debates > right now, and both the current DVD defaults of OO.o + Firefox + Evolution > and the current live CD defaults of Abiword + Firefox + Evolution are a mix > of that), by selecting KDE, you'd get KDE apps (KOffice, kdepim, Konqueror) > as the default. I think you've slightly misunderstood my point. The apps and selections are not really an issue. My point is that if there is a case for presenting users with download options to fine-tune the initial set of software to be installed, it seems that there are more important software choices to present than between desktops - browser, office suite, e-mail client, etc. If you're using a desktop you're likely to be spending much more time in those apps than the "desktop". Choice of DE seems to me relatively unimportant compared to the choice of productivity apps present on the system, and I don't see why the DE should be promoted to a special status for what seem to be essentially political reasons rather than technical ones. Even if you accept that the choice is useful, I don't see why you'd start with the DE. Cheers, Alex. From choeger at cs.tu-berlin.de Sun May 3 09:15:41 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Sun, 03 May 2009 11:15:41 +0200 Subject: just lost my pipe In-Reply-To: <49F1FB32.7020909@redhat.com> References: <1240593824.2536.8.camel@choeger6> <49F1FB32.7020909@redhat.com> Message-ID: <1241342141.3682.4.camel@choeger6> It finally happened again: This was AltGr + '<': KeyPress event, serial 30, synthetic NO, window 0x4c00001, root 0xfd, subw 0x0, time 149129465, (454,214), root:(463,323), state 0x2010, keycode 94 (keysym 0x3c, less), same_screen YES, XLookupString gives 1 bytes: (3c) "<" XmbLookupString gives 1 bytes: (3c) "<" XFilterEvent returns: False After switching to tty2 to verify that this happens only in X everything is fine again: Expected results: KeyPress event, serial 30, synthetic NO, window 0x4c00001, root 0xfd, subw 0x0, time 149420489, (407,292), root:(410,359), state 0x2090, keycode 94 (keysym 0x7c, bar), same_screen YES, XKeysymToKeycode returns keycode: 51 XLookupString gives 1 bytes: (7c) "|" XmbLookupString gives 1 bytes: (7c) "|" XFilterEvent returns: False WTF? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From sundaram at fedoraproject.org Sun May 3 09:24:35 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 03 May 2009 14:54:35 +0530 Subject: Abandon "Default Desktop" In-Reply-To: <49FD25EF.1040001@freenet.de> References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <49F80664.6010809@robertoragusa.it> <1241037119.3213.2.camel@localhost.localdomain> <6c3f5e6c0904291514n371fa179k1901af657e05a5b5@mail.gmail.com> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <16de708d0904301051r647b9f14qc1fe7d343bdbd778@mail.gmail.com> <1241114354.7846.5.camel@localhost.localdomain> <49FAB6AB.9060601@freenet.de> <49FAB9D6.6030203@fedoraproject.org> <49FABC2B.8050500@freenet.de> <49FAC168.4060707@fedoraproject.org> <49FD25EF.1040001@freenet.de> Message-ID: <49FD62D3.5070100@fedoraproject.org> On 05/03/2009 10:34 AM, Ralf Corsepius wrote: >> Anyone interested can look at the desktop focused features in the >> feature list for every release and results should speak for themselves. >> Those who shoulder the burden of the work decide the direction of the >> project as always. > Yes. As part of upstream projects, not as part of Fedora. For one, the feature list is a Fedora specific workflow and regardless of whether it is distribution integration or upstream development, the principle, that drives development remains the same. > What currently is happening: Certain people on RH's payrole, who happen > to be upstream for some packages, are abusing Fedora as vehicle to > prematurely push "upstream works", sometimes at "any price". FESCo processes the feature list the same way regardless of who is driving it and that is a elected body. Getting paid to work on free and open source software is a awesome thing. Early integration of upstream features is what I consider the unique factor of Fedora and it's stated mission. > I am sure, if the same people weren't working for @RH and if these > projects weren't in "RH's business interest", many of these developments > would not make it into Fedora or at least not in the shape the Fedora > community is facing them. I consider Red Hat's participation in Fedora as a net advantage. Maybe you don't. I can't help that. Rahul From sundaram at fedoraproject.org Sun May 3 09:28:34 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 03 May 2009 14:58:34 +0530 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <1241311178.20413.3791.camel@cookie.hadess.net> References: <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <20090502002529.GA29316@srcf.ucam.org> <20090502135734.GE3520@localhost.localdomain> <20090502142757.GA4295@srcf.ucam.org> <20090502145234.GB7160@tango.0pointer.de> <1241282761.2923.9.camel@adam.local.net> <1241311178.20413.3791.camel@cookie.hadess.net> Message-ID: <49FD63C2.3080203@fedoraproject.org> On 05/03/2009 06:09 AM, Bastien Nocera wrote: > On Sat, 2009-05-02 at 09:46 -0700, Adam Williamson wrote: >> So what do we do about profile switching - digital output, analog >> surround output? > > Then you people can use the gst-mixer you're packaging, it will work > just as well (or as badly) as it used to. So the recommendation is to use the old gst-mixer but the problem then is the opposition to having it installed by default as well as the problem of discovering it even when it is installed by default. While you are trying to reach perfection, the current experience is a giant regression for many users. A good compromise would be a advanced button which calls the old gst-mixer. Rahul From rawhide at fedoraproject.org Sun May 3 13:56:46 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Sun, 3 May 2009 13:56:46 +0000 (UTC) Subject: rawhide report: 20090503 changes Message-ID: <20090503135647.0E9B61F820B@releng2.fedora.phx.redhat.com> Compose started at Sun May 3 06:15:08 UTC 2009 Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 0 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From paul at all-the-johnsons.co.uk Sun May 3 15:52:01 2009 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 03 May 2009 16:52:01 +0100 Subject: Setting up apache problem Message-ID: <1241365921.18564.9.camel@localhost.localdomain> Hi, I've just about everything set up correctly, but when I restart httpd, I keep getting the error that DocumentRoot /var/www/html/willowherbdesigns doesn't exist, despite it being there (it's a symlink to /web/willowherbdesigns). I have FollowSymLinks set in the options. When I check the error logs, I'm seeing the following error avahi_entry_group_add_service_strlst("localhost") failed: Invalid host name error avahi_entry_group_add_service_strlst("127.0.0.1") failed: Invalid host name Any ideas? TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mjg at redhat.com Sun May 3 16:08:27 2009 From: mjg at redhat.com (Matthew Garrett) Date: Sun, 3 May 2009 17:08:27 +0100 Subject: Moblin 2 and Fedora In-Reply-To: <20090202113524.184e402c@infradead.org> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <49844F3B.6060905@fedoraproject.org> <5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com> <20090131110644.1a80ddf5@infradead.org> <4984BC61.3040908@fedoraproject.org> <20090131153457.573762ab@infradead.org> <604aa7910902020825v23bc3687m1151596fa74cb8a5@mail.gmail.com> <20090202101002.4380c005@infradead.org> <1233598383.7493.42.camel@localhost.localdomain> <20090202113524.184e402c@infradead.org> Message-ID: <20090503160827.GA21833@srcf.ucam.org> On Mon, Feb 02, 2009 at 11:35:24AM -0800, Arjan van de Ven wrote: > So I would like to really ask you and others to stop thinking of Moblin > as "Fedora with changes" and measure everything against that. I realize > it's easy to think that, and a lot of things just won't make sense in > that mindset. I ended up analysing this while otherwise bored. There's nothing especially surprising in the moblin repositories. The large majority of the packages are Fedora derived, with a small number from suse (primarily the toolchain, as Arjan said) and a few custom ones. Figuring out the proportion of the packages that were Fedora derived was actually surprisingly difficult. A large number of the specfiles have been processed through something called specbuilder. The behaviour of this seems to have varied between versions - some remove the original changelog, some don't. In some cases the specfiles are identical to the Fedora ones (to the extent of including comments) but have simply had the changelog entries stripped. Using a few heuristics, I'd estimate that somewhere in the region of 80 packages (ie, <10%) of moblin is from-scratch packaging by Intel. The rest is either obtained from Suse (gcc, cache, gdbm, gmp, osc - binutils is from Fedora, oddly), is identical to the Fedora package or is a simple mechanical transformation of a Fedora package, in some cases updated to a newer upstream as compared to the point where the moblin packages were forked. Moblin includes some 2000 patches, and again most of these are derived from Fedora or Suse. Moblin-specific patches are mostly either backports or code that has been submitted upstream but not yet released. There's a few counterexamples (code that should be upstream but doesn't seem to have been submitted), but that's in the minority and certainly no worse than any other distribution. The rest are changes to defaults or UI alterations to fit in with limited screen resolutions. There's absolutely nothing wrong with any of this, but right now it's kind of hard to see how moblin is anyone other than Fedora with changes. I don't think that puts Intel under any sort of obligation to feed changes back to us and I agree that Koji isn't ideally suited to producing the kind of derivative that Intel want to, but it would be nice to acknowledge the amount of the project that's built on the work of Fedora contributors. -- Matthew Garrett | mjg59 at srcf.ucam.org From mschwendt at gmail.com Sun May 3 16:11:32 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sun, 3 May 2009 18:11:32 +0200 Subject: Help with requires In-Reply-To: <49FC7373.4000304@redhat.com> References: <49FC7373.4000304@redhat.com> Message-ID: <20090503181132.1cf6f94d@faldor.intranet> On Sat, 02 May 2009 11:23:15 -0500, Eric wrote: > Neal Becker wrote: > > I'm having problems with igraph and python-igraph. > > > > igraph builds igraph-devel > > python-igraph needs igraph-devel. > > > > I'm assuming python-igraph needs the same version of igraph. > > > > How should this be encoded? > > > > Right now, I have > > > > -------- igraph.spec > > %package devel > > Provides: %{name}-devel-%{version} > > You shouldn't need to explicitly do this, this comes automatically. No, it doesn't. The one you have in mind is Provides: %{name} = %{version}-%{release} that is also automatic for every sub-package's %package name. From william.jon.mccann at gmail.com Sun May 3 16:44:26 2009 From: william.jon.mccann at gmail.com (William Jon McCann) Date: Sun, 3 May 2009 12:44:26 -0400 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <1241315965.2923.33.camel@adam.local.net> References: <1241123673.32113.299.camel@adam.local.net> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> <20090502014029.GC1496739@hiwaay.net> <20090502014259.GA28052@angus.ind.WPI.EDU> <1241260456.20413.2098.camel@cookie.hadess.net> <1241285539.2923.19.camel@adam.local.net> <1241312345.20413.3851.camel@cookie.hadess.net> <1241315965.2923.33.camel@adam.local.net> Message-ID: <939dd5750905030944l342328b7jbc80b74100f34a9e@mail.gmail.com> Adam, On Sat, May 2, 2009 at 9:59 PM, Adam Williamson wrote: > On Sun, 2009-05-03 at 01:59 +0100, Bastien Nocera wrote: > >> > Here's the other thing that gets me about this: okay, so you thought >> > about the use cases you want to support and came up with a design. >> > Great. >> > >> > But we don't even have that design yet. That design includes input >> > switching and profile switching. >> >> Tell me where I wrote that: >> https://fedoraproject.org/wiki/Features/VolumeControl#User_Experience >> >> >> >> *Where* >> >> I already asked this question when Will made the same assumption as you >> did, during the Fesco meeting. The use cases we had didn't include any >> need for profile switching. > > That just makes me question even more your competence to be doing the > design; if you manage to come up with a design for a mixer application > without considering the importance of digital output, well. Er. > That's...um. My output device is connected digitally. So are zillions of > others. That's why soundcards ship with S/PDIF outputs. Even cheap > crappy onboard sound, where the manufacturers would gladly save a cent > any old way, universally include S/PDIF now - because people want it. > How were you expecting us to hear any sound? This is getting crazy. You are questioning Bastien's interface design competence. Pretty bold statement from someone, I suspect, many of us have never heard of before. Your rhetorical style isn't really helping here either. Would be nice if you stopped throwing around meaningless statistics (zillions) and gave us some credit for actually knowing what the hell we are doing. If only to give the impression that you know what the hell you are doing. > I suspect this whole process was managed by people who are great at > interface design, and great at the software side of audio/video (which I > know you are), but perhaps didn't think hard enough about what people > actually do with audio hardware. And your suspicion is wrong. We've discussed these things many times. We've even had pretty heated discussions about it ourselves. However, in order to move forward, we need to make choices. Inevitably, we will not please everyone. ... >> Yes, it's a >> big omission, but that doesn't mean you're allowed to write off the >> benefits we're bringing for a large number of users already. > > I'm not. As I said, I like those things. Which I was I was on the side > which was supporting the compromise by which we would have those > features AND the features g-v-c is missing. It's not frickin' rocket > science! Please read my first post again: https://www.redhat.com/archives/fedora-devel-list/2009-April/msg02534.html It is just not as simple as you make it out to be. A great product is not a list of features. It must be designed. When we use a time-based release process we will NEVER have a perfect or great Fedora release. It just can't happen. Fedora is the vanguard. It is the continual forward motion of our designs (mostly upstream ones). We are *different* from Ubuntu and where you used to work.[1] We differentiate ourselves by having an uncompromising position on freedom and design. We don't ship non-free codecs even though (as you say) zillions of people need them. We ship the best of breed software and software that represents the right way forward even when it isn't yet perfect. There are many technical reasons why we do this and why it is good for us, upstreams, and informing/educating/engaging our users. But the principle reason is that it is the Fedora brand. Jon [1] Also since we are not creating a product where Ubuntu and Mandriva are. And if we want to change this there is a heck of a lot of work to do. From seg at haxxed.com Sun May 3 16:55:01 2009 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 03 May 2009 11:55:01 -0500 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <1241311636.20413.3815.camel@cookie.hadess.net> References: <1241123673.32113.299.camel@adam.local.net> <20090430210019.GC25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> <20090502014029.GC1496739@hiwaay.net> <20090502014259.GA28052@angus.ind.WPI.EDU> <1241260456.20413.2098.camel@cookie.hadess.net> <1241311636.20413.3815.camel@cookie.hadess.net> Message-ID: <1241369701.2632.52.camel@localhost.localdomain> On Sun, 2009-05-03 at 01:47 +0100, Bastien Nocera wrote: > First of all, I'd appreciate if you didn't put words in my mouth. > > And no, we usually don't ask for as much user input as some other > projects, because otherwise we get asked to show the old knobs for power > users, instead of having them trying to explain what they're trying to > do. And then you explain to them why they're abnormal for even wanting to do what they want to do! Then dismiss and ignore them. That makes them happy! > I'd advise you to read "The inmates are running the asylum" by Alan > Cooper (or "Is it just me or is everything shit?" if you're in a lighter > mood). Ah yes, the chapter about arguing with your end users was a good read. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Sun May 3 16:56:08 2009 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 03 May 2009 11:56:08 -0500 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <20090502005540.GA29541@srcf.ucam.org> References: <20090430194821.GA25787@nostromo.devel.redhat.com> <1241123673.32113.299.camel@adam.local.net> <20090430210019.GC25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> <20090502005540.GA29541@srcf.ucam.org> Message-ID: <1241369768.2632.54.camel@localhost.localdomain> On Sat, 2009-05-02 at 01:55 +0100, Matthew Garrett wrote: > In the end we still come down to making > decisions based on the opinions of people we deem to be experts in the > field. And if you don't trust the desktop team to make the appropriate > decision in this case then it would be helpful for you to say so > plainly. Well, to put it bluntly, no. We don't trust the desktop team and we *shouldn't* trust the desktop team. So they're "expert in their field". Fine. Cool. We need experts. But the problem with experts is they're totally consumed by their field, and lack the ability to view their piece of the puzzle in the overall picture. There's a reason we have release managers and FESCo. Someone has to manage the Big Picture, and sometimes that requires the "experts" to compromise their Perfect Vision for the good of the overall project. ... And are we seriously designing UI based purely on "the opinions of experts"? Is there any actual end user testing in the loop? Are we honestly expected to trust the desktop team based purely on "We're experts and we say so!" How reasonable is that? No, trusting experts is for sheep. We want to see data. Show us usability studies, or meta-studies of bug reports. *Something* more than "we say so". We trust data, not experts. As it is, the people in the trenches doing QA and user support have way more convincing data than the desktop team. Designing HCI without Humans in the loop is bogus beyond belief. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Sun May 3 17:07:43 2009 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 03 May 2009 12:07:43 -0500 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <20090430234809.GA5813@srcf.ucam.org> References: <49F24B17.30602@redhat.com> <49F25D0D.8030304@gmail.com> <1240759385.6529.0.camel@localhost.localdomain> <1240762219.2770.9.camel@localhost.localdomain> <1241027428.3139.9.camel@localhost.localdomain> <939dd5750904301050o4efb3efau356882109b2e206b@mail.gmail.com> <1241116151.32113.273.camel@adam.local.net> <939dd5750904301208l19123893rc9cd68609f8980be@mail.gmail.com> <49F9FD08.9010904@redhat.com> <20090430234809.GA5813@srcf.ucam.org> Message-ID: <1241370463.2632.60.camel@localhost.localdomain> On Fri, 2009-05-01 at 00:48 +0100, Matthew Garrett wrote: > On Thu, Apr 30, 2009 at 03:33:28PM -0400, Tom spot Callaway wrote: > > > Remember kids, we probably shouldn't be listening to you. Red Hat > > Desktop == Smart. You == Dumb. > > The problem with the desktop is that it's obvious, looks simple and > everyone has an opinion on it. But not all of these opinions are equally > valid. This kind of situation is much easier to deal with in, say, the > kernel VM system - in that case it would be perfectly acceptable for > people who spend their entire working lives concentrating on a specific > topic to say that they know better than people who occasionally touch > upon it. ... And the kernel VM people tend to be able to back up their expertise with hard data. If a patch isn't an improvement in some provable manner, it doesn't get in to the kernel. And the kernel has a pretty hard line stance on regressions. If a patch causes regressions, it's ripped out immediately. No matter who wrote it. We trust data, not experts. > It's not about smart versus dumb. If we trust these people then we have > to assume that in most cases they *will* know better than people who > argue against them on mailing lists. And if we don't trust them then > there's something pretty fundamentally wrong with the way we're > producing this distribution. Trust, but verify. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From william.jon.mccann at gmail.com Sun May 3 17:11:47 2009 From: william.jon.mccann at gmail.com (William Jon McCann) Date: Sun, 3 May 2009 13:11:47 -0400 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <1241369768.2632.54.camel@localhost.localdomain> References: <20090430194821.GA25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> <20090502005540.GA29541@srcf.ucam.org> <1241369768.2632.54.camel@localhost.localdomain> Message-ID: <939dd5750905031011oe9b5194s7b8c448a6930b1bf@mail.gmail.com> Hi, On Sun, May 3, 2009 at 12:56 PM, Callum Lerwick wrote: > On Sat, 2009-05-02 at 01:55 +0100, Matthew Garrett wrote: >> In the end we still come down to making >> decisions based on the opinions of people we deem to be experts in the >> field. And if you don't trust the desktop team to make the appropriate >> decision in this case then it would be helpful for you to say so >> plainly. > > Well, to put it bluntly, no. We don't trust the desktop team and we > *shouldn't* trust the desktop team. > > So they're "expert in their field". Fine. Cool. We need experts. But the > problem with experts is they're totally consumed by their field, and > lack the ability to view their piece of the puzzle in the overall > picture. > > There's a reason we have release managers and FESCo. Someone has to > manage the Big Picture, and sometimes that requires the "experts" to > compromise their Perfect Vision for the good of the overall project. > > ... And are we seriously designing UI based purely on "the opinions of > experts"? Is there any actual end user testing in the loop? > > Are we honestly expected to trust the desktop team based purely on > "We're experts and we say so!" How reasonable is that? No, trusting > experts is for sheep. We want to see data. Show us usability studies, or > meta-studies of bug reports. *Something* more than "we say so". We trust > data, not experts. > > As it is, the people in the trenches doing QA and user support have way > more convincing data than the desktop team. > > Designing HCI without Humans in the loop is bogus beyond belief. I think you are conflating user experience design with usability. Our user experience design and interface design takes place very early in the Fedora development cycle. It is primarily informed by our experiences, research, and vision. Currently, the user testing is done primarily after a Fedora release. However, we don't have a process in place to collect trustworthy, actionable data. Ubuntu has actually just completed a round of real user testing and will be presenting the results at GUADEC. So, that should be interesting. It would be great if we organized something similar. A word of caution though - this is hard to do correctly. It is quite easy to collect misleading and confusing data. The exact process of the testing matters a great deal. FWIW, I'm hoping to do something like this in the next few months. Jon From awilliam at redhat.com Sun May 3 17:12:03 2009 From: awilliam at redhat.com (Adam Williamson) Date: Sun, 03 May 2009 10:12:03 -0700 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <939dd5750905030944l342328b7jbc80b74100f34a9e@mail.gmail.com> References: <1241123673.32113.299.camel@adam.local.net> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> <20090502014029.GC1496739@hiwaay.net> <20090502014259.GA28052@angus.ind.WPI.EDU> <1241260456.20413.2098.camel@cookie.hadess.net> <1241285539.2923.19.camel@adam.local.net> <1241312345.20413.3851.camel@cookie.hadess.net> <1241315965.2923.33.camel@adam.local.net> <939dd5750905030944l342328b7jbc80b74100f34a9e@mail.gmail.com> Message-ID: <1241370723.2923.54.camel@adam.local.net> On Sun, 2009-05-03 at 12:44 -0400, William Jon McCann wrote: > >> I already asked this question when Will made the same assumption as you > >> did, during the Fesco meeting. The use cases we had didn't include any > >> need for profile switching. > > > > That just makes me question even more your competence to be doing the > > design; if you manage to come up with a design for a mixer application > > without considering the importance of digital output, well. Er. > > That's...um. My output device is connected digitally. So are zillions of > > others. That's why soundcards ship with S/PDIF outputs. Even cheap > > crappy onboard sound, where the manufacturers would gladly save a cent > > any old way, universally include S/PDIF now - because people want it. > > How were you expecting us to hear any sound? > > This is getting crazy. You are questioning Bastien's interface design > competence. Pretty bold statement from someone, I suspect, many of us > have never heard of before. Sorry, not exactly - in fact I said "I suspect this whole process was managed by people who are great at interface design..." The problem is that it seems Bastien didn't think too hard about what use cases the design would need to cover, in terms of actual uses of actual hardware. Note that this is not the same as attacking the interface design per se. The design is fine for the use cases it covers. The problem is it doesn't cover all of the use cases it needs to. Whether you've heard of me before or not ought to be irrelevant. The point should be whether what I say is valid or not. > Your rhetorical style isn't really helping here either. Would be nice > if you stopped throwing around meaningless statistics (zillions) and > gave us some credit for actually knowing what the hell we are doing. > If only to give the impression that you know what the hell you are > doing. It's hard to give you credit for knowing what the hell you're doing when your actions don't substantiate it. Designing a mixer application with no regards for any use case more advanced than "analog stereo output" is not a great way to indicate that you know what you're doing. > > I suspect this whole process was managed by people who are great at > > interface design, and great at the software side of audio/video (which I > > know you are), but perhaps didn't think hard enough about what people > > actually do with audio hardware. > > And your suspicion is wrong. We've discussed these things many times. > We've even had pretty heated discussions about it ourselves. > However, in order to move forward, we need to make choices. > Inevitably, we will not please everyone. I just cannot for the life of me see how you could possibly think that making it impossible to enable digital or analog surround output is a sensible choice. And it seems you now agree, since profile switching is planned for a future g-v-c release. Ditto with input switching. So did you get it wrong at first or are you getting it wrong now? > ... > >> Yes, it's a > >> big omission, but that doesn't mean you're allowed to write off the > >> benefits we're bringing for a large number of users already. > > > > I'm not. As I said, I like those things. Which I was I was on the side > > which was supporting the compromise by which we would have those > > features AND the features g-v-c is missing. It's not frickin' rocket > > science! > > Please read my first post again: > https://www.redhat.com/archives/fedora-devel-list/2009-April/msg02534.html > > It is just not as simple as you make it out to be. A great product is > not a list of features. It must be designed. When we use a > time-based release process we will NEVER have a perfect or great > Fedora release. It just can't happen. Fedora is the vanguard. It is > the continual forward motion of our designs (mostly upstream ones). > We are *different* from Ubuntu and where you used to work.[1] I've never worked for Ubuntu. (No-one works for Ubuntu, in fact, people work for Canonical. But I've never worked for them either. I worked for Mandriva.) I find it surprising that you say we'll never have a great Fedora release. That's a bit sad. Perfect? Of course not. But if everyone agreed that we'd never have a great Fedora release, I'd wonder what the hell I was wasting my time on. I hope yours is a minority position. > We > differentiate ourselves by having an uncompromising position on > freedom and design. We don't ship non-free codecs even though (as you > say) zillions of people need them. We ship the best of breed software > and software that represents the right way forward even when it isn't > yet perfect. There are many technical reasons why we do this and why > it is good for us, upstreams, and informing/educating/engaging our > users. I know all this rhetoric. It does not apply to the issue at hand. We do not need to ship a prototype design with half the features missing as our default (and only!) mixer in order effectively to work on it. Honestly I doubt it would even need to be *packaged*, as I doubt the people who are working on it would use the packaged code, and you seem - to say the least - resistant to any kind of external input on how it should work. But it would be perfectly easy for it to be packaged and available without it being the sole graphical mixer available by default for people who just want to get sound out of their systems - including developers of all sorts of other components and people who contribute to Fedora in other ways, not just 'Joe Users'. Many of the people who have gone on record as stating that they were negatively affected by the new mixer are Fedora developers and contributors. Yes, we "ship the best of breed software and software that represents the right way forward even when it isn't yet perfect". But there's a balance, here, and you're fooling yourself if you think there isn't. If that were all there was to the story, Fedora stable releases wouldn't exist, and everyone would use Rawhide. After all, that's the code that represents the right way forward even if it isn't yet perfect. Hell, we'd be running something rawer than Rawhide. But that isn't the case. We don't update the kernel every 24 hours to the last code someone kicked into git, we don't update GNOME every 24 hours with the latest code from SVN (or git, now), we don't ship stable releases in this state, we actually *ship stable releases* (and many of our developers use them). Why? Because even developers need a base of reasonably usable code in all the bits they're *not* working on. This applies to volume control applications as much as to anything else. Your wonderful new volume control application design is *not finished* and is, apparently by general admission at this point, the source of major functional regressions for perfectly smart people including Fedora hackers. Please either let us ship something alongside it that provides the important functionality that it is missing, or hold off on shipping it until it's done. That's all that's being asked here. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From awilliam at redhat.com Sun May 3 17:19:19 2009 From: awilliam at redhat.com (Adam Williamson) Date: Sun, 03 May 2009 10:19:19 -0700 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <1241370723.2923.54.camel@adam.local.net> References: <1241123673.32113.299.camel@adam.local.net> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> <20090502014029.GC1496739@hiwaay.net> <20090502014259.GA28052@angus.ind.WPI.EDU> <1241260456.20413.2098.camel@cookie.hadess.net> <1241285539.2923.19.camel@adam.local.net> <1241312345.20413.3851.camel@cookie.hadess.net> <1241315965.2923.33.camel@adam.local.net> <939dd5750905030944l342328b7jbc80b74100f34a9e@mail.gmail.com> <1241370723.2923.54.camel@adam.local.net> Message-ID: <1241371159.2923.55.camel@adam.local.net> On Sun, 2009-05-03 at 10:12 -0700, Adam Williamson wrote: > > We are *different* from Ubuntu and where you used to work.[1] > > I've never worked for Ubuntu. (No-one works for Ubuntu, in fact, people > work for Canonical. But I've never worked for them either. I worked for > Mandriva.) Sorry, just realized I missed the "and" in that sentence. Disregard this bit, then. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From richardfearn at gmail.com Sun May 3 17:40:39 2009 From: richardfearn at gmail.com (Richard Fearn) Date: Sun, 3 May 2009 18:40:39 +0100 Subject: Setting up apache problem In-Reply-To: <1241365921.18564.9.camel@localhost.localdomain> References: <1241365921.18564.9.camel@localhost.localdomain> Message-ID: <212718d80905031040w3dc8626qb7fd31dcf14efdee@mail.gmail.com> Hello, > I've just about everything set up correctly, but when I restart httpd, I > keep getting the error that DocumentRoot /var/www/html/willowherbdesigns > doesn't exist, despite it being there (it's a symlink > to /web/willowherbdesigns). Probably because the content under /web doesn't have the right SELinux context; it should be system_u:object_r:httpd_sys_content_t:s0. You can check the context with ls -lZ, and if it's wrong, relabel using chcon system_u:object_r:httpd_sys_content_t:s0 /web/willowherbdesigns Regards, Rich From seg at haxxed.com Sun May 3 17:56:32 2009 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 03 May 2009 12:56:32 -0500 Subject: The Great Pulseaudio Mixer Debate: a modest (productive) proposal In-Reply-To: <49F85255.3090708@hidayahonline.org> References: <1240596206.3955.245.camel@adam.local.net> <200904251714.07573.billcrawford1970@gmail.com> <6d959d480904250934h1fb12465ue60b55866d4a188c@mail.gmail.com> <200904271329.04618.billcrawford1970@gmail.com> <49F5E241.2030603@cchtml.com> <1240964482.2656.8.camel@localhost.localdomain> <49F85255.3090708@hidayahonline.org> Message-ID: <1241373392.2632.65.camel@localhost.localdomain> On Wed, 2009-04-29 at 21:12 +0800, Basil Mohamed Gohar wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/29/2009 08:21 AM, Callum Lerwick wrote: > > On Mon, 2009-04-27 at 13:59 -0400, Ben Boeckel wrote: > >>> Subject: Re: The Great Pulseaudio Mixer Debate: a > >> modest (productive) > >>> proposal > >>> From: Ben Boeckel > >>> To: fedora-devel-list at redhat.com > >>> Date: 04/27/2009 10:12 AM > >>> > >>>> I've had X lock up or temporarily freeze and > >> kaffeine > >>>> (playing through PA via xine) still plays. The only > >> way > >>>> I've been able to get it to skip is to force > >> basically > >>>> everything into swap with programs that take up 3+GB > >> of > >>>> RAM (making markov chains from big.txt takes...quite > >> a > >>>> bit in duck-typed languages). Maybe it's the dual > >> core > >>>> 3.0GHz, but I've found it hard to skip apps using > >> PA. > >>>> PA is taking 0% CPU and kaffeine jumps to 1% playing > >>>> flac files. Also, PA hasn't even jumped towards the > >> top > >>>> of usage at all in the past few minutes. > >>> > >>> That's amazing, because I have a 3ghz dual core and > >> PA takes ~10% CPU to > >>> play FLAC from Rhythmbox and can skip if I'm doing a > >> lot of work - say > >>> ffmpeg transcoding and moving files. Intel HD audio > >> (yes, generic) > >>> Analog Devices chip. > >>> > >> Maybe its a difference between xine and gstreamer? > >> > >> % lspci | grep -i audio > >> 00:1b.0 Audio device: Intel Corporation 82801JI (ICH10 > >> Family) HD Audio Controller > > > > Check your logs. This is quite possibly the difference between "My > > hardware does 44.1khz natively" and "My hardware only does 48000khz and > > playing anything but a DVD requires resampling". Later Intel chipsets > > all seem to be the latter. > > > Not sure if this is the right place to post this, but I also have a huge > CPU hit on my 4+ year old laptop, and I am sure that it handles > different sampling rates without much difficulty. > > So, my question is, what logs can I check to find out if this is > happening (if I understood the message correctly)? Hrm, pulseaudio's logging seems to have changed. You can try running "pulseaudio -k;pulseaudio -v" then dig through the spew: I: alsa-util.c: Device hw:M5455,0 doesn't support 44100 Hz, changed to 48000 Hz. I: alsa-sink.c: Successfully opened device hw:M5455,0. If you see something like that, your hardware requires resampling. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Sun May 3 18:32:04 2009 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 03 May 2009 13:32:04 -0500 Subject: Fedora 11 Preview Release announcement In-Reply-To: <9497e9990904300628s591b87c2t4044f1f2460a061f@mail.gmail.com> References: <1240940619.2567.139.camel@macbook.infradead.org> <1241028268.3139.10.camel@localhost.localdomain> <49F8B687.9050102@robertoragusa.it> <9497e9990904300628s591b87c2t4044f1f2460a061f@mail.gmail.com> Message-ID: <1241375524.2632.97.camel@localhost.localdomain> On Thu, 2009-04-30 at 14:28 +0100, Mat Booth wrote: > And if that's the biggest problem with Fedora, we're not doing too badly. :-) I'd argue more about how completely broken OpenGL has been since FC6 if I thought it would do any good. Lets compare FC6: http://www.haxxed.com/random/SecondLifeIsFree.jpg With F10/F11: https://bugzilla.redhat.com/show_bug.cgi?id=474977 https://bugzilla.redhat.com/show_bug.cgi?id=483280 https://bugzilla.redhat.com/show_bug.cgi?id=487432 https://bugzilla.redhat.com/show_bug.cgi?id=496539 FC6 and F7 worked beautifully. F8/9 began a habit of locking up the machine randomly. Then modesetting completely screwed OpenGL entirely in F10. Still broken in F11. I've just given up and moved all my gaming and game development to Windows XP. And my wife's laptop doesn't even have Fedora on it anymore. Windows Just Works. Everything she used in Fedora: OpenOffice, pidgin, gimp and Firefox all run just fine in Windows, plus she can run WoW, flash and all the proprietary crap she needs for school with no trouble at all. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mjg at redhat.com Sun May 3 18:34:29 2009 From: mjg at redhat.com (Matthew Garrett) Date: Sun, 3 May 2009 19:34:29 +0100 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <1241370463.2632.60.camel@localhost.localdomain> References: <1240759385.6529.0.camel@localhost.localdomain> <1240762219.2770.9.camel@localhost.localdomain> <1241027428.3139.9.camel@localhost.localdomain> <939dd5750904301050o4efb3efau356882109b2e206b@mail.gmail.com> <1241116151.32113.273.camel@adam.local.net> <939dd5750904301208l19123893rc9cd68609f8980be@mail.gmail.com> <49F9FD08.9010904@redhat.com> <20090430234809.GA5813@srcf.ucam.org> <1241370463.2632.60.camel@localhost.localdomain> Message-ID: <20090503183429.GA24482@srcf.ucam.org> On Sun, May 03, 2009 at 12:07:43PM -0500, Callum Lerwick wrote: > On Fri, 2009-05-01 at 00:48 +0100, Matthew Garrett wrote: > > The problem with the desktop is that it's obvious, looks simple and > > everyone has an opinion on it. But not all of these opinions are equally > > valid. This kind of situation is much easier to deal with in, say, the > > kernel VM system - in that case it would be perfectly acceptable for > > people who spend their entire working lives concentrating on a specific > > topic to say that they know better than people who occasionally touch > > upon it. > > ... And the kernel VM people tend to be able to back up their expertise > with hard data. If a patch isn't an improvement in some provable manner, > it doesn't get in to the kernel. Like everything else, kernel VM performance is a tradeoff. Improvements may benefit certain workloads while impairing others. It's rare for changes to improve things for everybody - so the end result is a judgement call, generally by the people who are assumed to know what they're doing. -- Matthew Garrett | mjg59 at srcf.ucam.org From paul at all-the-johnsons.co.uk Sun May 3 18:47:15 2009 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 03 May 2009 19:47:15 +0100 Subject: Setting up apache problem In-Reply-To: <212718d80905031040w3dc8626qb7fd31dcf14efdee@mail.gmail.com> References: <1241365921.18564.9.camel@localhost.localdomain> <212718d80905031040w3dc8626qb7fd31dcf14efdee@mail.gmail.com> Message-ID: <1241376435.18564.15.camel@localhost.localdomain> Hi, > > I've just about everything set up correctly, but when I restart httpd, I > > keep getting the error that DocumentRoot /var/www/html/willowherbdesigns > > doesn't exist, despite it being there (it's a symlink > > to /web/willowherbdesigns). > > Probably because the content under /web doesn't have the right SELinux > context; it should be system_u:object_r:httpd_sys_content_t:s0. > > You can check the context with ls -lZ, and if it's wrong, relabel using > > chcon system_u:object_r:httpd_sys_content_t:s0 /web/willowherbdesigns Just given that a shot, restarted httpd and still get the same DocumentRoot not existing. This is confusing as ls -l /var/www/html shows a symlink to /web/willowherbdesigns. After restarting, pointing the browser to 127.0.0.1 gives an error 400 (Bad request) Your browser sent a request that this server could not understand. Something is going funny somewhere, but I'm unsure still where. My hosts file looks like this # Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1 localhost.localdomain localhost PB3.linux ::1 localhost6.localdomain6 localhost6 so there is nothing in there which could cause an issue. Help! TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bnocera at redhat.com Sun May 3 18:52:02 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Sun, 03 May 2009 19:52:02 +0100 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <1241370723.2923.54.camel@adam.local.net> References: <1241123673.32113.299.camel@adam.local.net> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> <20090502014029.GC1496739@hiwaay.net> <20090502014259.GA28052@angus.ind.WPI.EDU> <1241260456.20413.2098.camel@cookie.hadess.net> <1241285539.2923.19.camel@adam.local.net> <1241312345.20413.3851.camel@cookie.hadess.net> <1241315965.2923.33.camel@adam.local.net> <939dd5750905030944l342328b7jbc80b74100f34a9e@mail.gmail.com> <1241370723.2923.54.camel@adam.local.net> Message-ID: <1241376722.21010.1025.camel@cookie.hadess.net> On Sun, 2009-05-03 at 10:12 -0700, Adam Williamson wrote: > > The problem is that it seems Bastien didn't think too hard about what > use cases the design would need to cover, in terms of actual uses of > actual hardware. Note that this is not the same as attacking the > interface design per se. The design is fine for the use cases it > covers. > The problem is it doesn't cover all of the use cases it needs to. The use cases were there for people to read for *1 frickin' year*. It went through Fesco's approval. You would have thought *someone* *anyone* would have seen that use cases were missing. You didn't, I didn't, people tried to close the door after the horse had bolted. From bnocera at redhat.com Sun May 3 19:00:58 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Sun, 03 May 2009 20:00:58 +0100 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <1241315965.2923.33.camel@adam.local.net> References: <1241123673.32113.299.camel@adam.local.net> <20090430210019.GC25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> <20090502014029.GC1496739@hiwaay.net> <20090502014259.GA28052@angus.ind.WPI.EDU> <1241260456.20413.2098.camel@cookie.hadess.net> <1241285539.2923.19.camel@adam.local.net> <1241312345.20413.3851.camel@cookie.hadess.net> <1241315965.2923.33.camel@adam.local.net> Message-ID: <1241377258.21010.1050.camel@cookie.hadess.net> On Sat, 2009-05-02 at 18:59 -0700, Adam Williamson wrote: > On Sun, 2009-05-03 at 01:59 +0100, Bastien Nocera wrote: > > > > Here's the other thing that gets me about this: okay, so you thought > > > about the use cases you want to support and came up with a design. > > > Great. > > > > > > But we don't even have that design yet. That design includes input > > > switching and profile switching. > > > > Tell me where I wrote that: > > https://fedoraproject.org/wiki/Features/VolumeControl#User_Experience > > > > > > > > *Where* > > > > I already asked this question when Will made the same assumption as you > > did, during the Fesco meeting. The use cases we had didn't include any > > need for profile switching. > > That just makes me question even more your competence to be doing the > design; if you manage to come up with a design for a mixer application > without considering the importance of digital output, well. Er. > That's...um. My output device is connected digitally. So are zillions of > others. That's why soundcards ship with S/PDIF outputs. Even cheap > crappy onboard sound, where the manufacturers would gladly save a cent > any old way, universally include S/PDIF now - because people want it. > How were you expecting us to hear any sound? > > I suspect this whole process was managed by people who are great at > interface design, and great at the software side of audio/video (which I > know you are), but perhaps didn't think hard enough about what people > actually do with audio hardware. I call BS here. PulseAudio never supported SPDIF outputs properly before. So we really haven't made the experience any worse. > > A couple of benefits from the current volume control compared to the old > > one: > > - "default" input and output control > > - microphone level checks > > - sound effects level control > > - per-application volume control (for apps that support it) > > Yes, these are neat. Especially default input device control. And that's > more support for the "ship two mixers" compromise (which, ironically, it > turns out is exactly what we've been doing for three releases). These > are great features of PulseAudio (supplied up till now by pavucontrol). > I like them. I've written blog entries extolling their virtues. I've > cited them in long argumentative threads about how PA is shit. But they > don't excuse you from covering really basic audio use cases like > *digital frickin' output*. > > The only use case(s) that we haven't catered for are for people who want > > to record things, and the sound card has more than 1 input. > > No, not correct at all. You haven't yet catered for people who want to > *monitor* (rather than record) an input channel What on earth is "monitoring" an input? There's a volume level in gnome-volume-control, we didn't have that before. I stand by the statement I made above. If I didn't understand the problem properly, feel free to hop onto the fedora-desktop list and explain what's missing from: http://fedoraproject.org/wiki/Features/VolumeControlContinued > , people who have digital > outputs, or people who have analog surround sound setups (the Logitech > Z-5300 has been in production for about seven years for a *reason* - > people buy this stuff). Analog surround will be supported by the next version of gnome-volume-control. You had to poke in ALSA to get this working before, now you can use pavucontrol, or a one-liner in pacmd to fix that. Not a regression then. > > Yes, it's a > > big omission, but that doesn't mean you're allowed to write off the > > benefits we're bringing for a large number of users already. > > I'm not. As I said, I like those things. Which I was I was on the side > which was supporting the compromise by which we would have those > features AND the features g-v-c is missing. It's not frickin' rocket > science! Seriously. The discussion started because there were regressions, then you go on accusing us of missing features that were never properly supported in the first place. SPDIF and analog surround weren't supported by the crappy mixers we had before, and they're not supported now. But now we have the framework to make those work. I see that as a great step forward. From galibert at pobox.com Sun May 3 19:10:44 2009 From: galibert at pobox.com (Olivier Galibert) Date: Sun, 3 May 2009 21:10:44 +0200 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <1241376722.21010.1025.camel@cookie.hadess.net> References: <1241224653.2811.59.camel@adam.local.net> <20090502014029.GC1496739@hiwaay.net> <20090502014259.GA28052@angus.ind.WPI.EDU> <1241260456.20413.2098.camel@cookie.hadess.net> <1241285539.2923.19.camel@adam.local.net> <1241312345.20413.3851.camel@cookie.hadess.net> <1241315965.2923.33.camel@adam.local.net> <939dd5750905030944l342328b7jbc80b74100f34a9e@mail.gmail.com> <1241370723.2923.54.camel@adam.local.net> <1241376722.21010.1025.camel@cookie.hadess.net> Message-ID: <20090503191044.GC11682@dspnet.fr.eu.org> On Sun, May 03, 2009 at 07:52:02PM +0100, Bastien Nocera wrote: > The use cases were there for people to read for *1 frickin' year*. It > went through Fesco's approval. You would have thought *someone* *anyone* > would have seen that use cases were missing. You mean the "User Experience" section of Features/VolumeControl is supposed to be *exhaustive*? Is that the standard way features are to be described? Did FESCO know? OG. From seg at haxxed.com Sun May 3 19:13:30 2009 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 03 May 2009 14:13:30 -0500 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <1241376722.21010.1025.camel@cookie.hadess.net> References: <1241123673.32113.299.camel@adam.local.net> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> <20090502014029.GC1496739@hiwaay.net> <20090502014259.GA28052@angus.ind.WPI.EDU> <1241260456.20413.2098.camel@cookie.hadess.net> <1241285539.2923.19.camel@adam.local.net> <1241312345.20413.3851.camel@cookie.hadess.net> <1241315965.2923.33.camel@adam.local.net> <939dd5750905030944l342328b7jbc80b74100f34a9e@mail.gmail.com> <1241370723.2923.54.camel@adam.local.net> <1241376722.21010.1025.camel@cookie.hadess.net> Message-ID: <1241378010.2632.111.camel@localhost.localdomain> On Sun, 2009-05-03 at 19:52 +0100, Bastien Nocera wrote: > On Sun, 2009-05-03 at 10:12 -0700, Adam Williamson wrote: > > > > The problem is that it seems Bastien didn't think too hard about what > > use cases the design would need to cover, in terms of actual uses of > > actual hardware. Note that this is not the same as attacking the > > interface design per se. The design is fine for the use cases it > > covers. > > The problem is it doesn't cover all of the use cases it needs to. > > The use cases were there for people to read for *1 frickin' year*. It > went through Fesco's approval. You would have thought *someone* *anyone* > would have seen that use cases were missing. You keep falling back on the feature page. Sorry, it's kind of hard to test something that doesn't exist. I don't understand why you seem to be having so much trouble understanding that. > You didn't, I didn't, people tried to close the door after the horse had > bolted. Wide testing isn't going to happen until at least the release of Beta. That's why it's called Beta. This "Oh, you didn't complain a year ago you're too late" thing is a cop-out. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mclasen at redhat.com Sun May 3 19:21:42 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Sun, 03 May 2009 15:21:42 -0400 Subject: mixers up for review Message-ID: <1241378502.3062.3.camel@localhost.localdomain> Sorry to interrupt, but there are now two graphical mixer applications up for review: https://bugzilla.redhat.com/show_bug.cgi?id=497593 https://bugzilla.redhat.com/show_bug.cgi?id=498136 Maybe the people who shouted the loudest about the desktop teams crimes against humanity could take some time off their busy flame-writing schedule to review one of those ? Just an idea, Matthias From awilliam at redhat.com Sun May 3 19:37:56 2009 From: awilliam at redhat.com (Adam Williamson) Date: Sun, 03 May 2009 12:37:56 -0700 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <1241377258.21010.1050.camel@cookie.hadess.net> References: <1241123673.32113.299.camel@adam.local.net> <20090430210019.GC25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> <20090502014029.GC1496739@hiwaay.net> <20090502014259.GA28052@angus.ind.WPI.EDU> <1241260456.20413.2098.camel@cookie.hadess.net> <1241285539.2923.19.camel@adam.local.net> <1241312345.20413.3851.camel@cookie.hadess.net> <1241315965.2923.33.camel@adam.local.net> <1241377258.21010.1050.camel@cookie.hadess.net> Message-ID: <1241379476.2923.77.camel@adam.local.net> On Sun, 2009-05-03 at 20:00 +0100, Bastien Nocera wrote: > > That just makes me question even more your competence to be doing the > > design; if you manage to come up with a design for a mixer application > > without considering the importance of digital output, well. Er. > > That's...um. My output device is connected digitally. So are zillions of > > others. That's why soundcards ship with S/PDIF outputs. Even cheap > > crappy onboard sound, where the manufacturers would gladly save a cent > > any old way, universally include S/PDIF now - because people want it. > > How were you expecting us to hear any sound? > > > > I suspect this whole process was managed by people who are great at > > interface design, and great at the software side of audio/video (which I > > know you are), but perhaps didn't think hard enough about what people > > actually do with audio hardware. > > I call BS here. PulseAudio never supported SPDIF outputs properly > before. So we really haven't made the experience any worse. PulseAudio didn't before this cycle, no. I'm talking about regressions compared to the tools included and easily accessible in F10 and previous releases, not just in the Pulse features. I'll talk about this a bit more further down. > > > The only use case(s) that we haven't catered for are for people who want > > > to record things, and the sound card has more than 1 input. > > > > No, not correct at all. You haven't yet catered for people who want to > > *monitor* (rather than record) an input channel > > What on earth is "monitoring" an input? Just looping the sound from an input around to the output in real-time, not recording from it. In implementation terms it's mostly the same as input switching, but in *usage* terms it's a distinct case - take the guy from this list who wants to listen to sound from an external device via the line-in on his card. > There's a volume level in > gnome-volume-control, we didn't have that before. I stand by the > statement I made above. If I didn't understand the problem properly, > feel free to hop onto the fedora-desktop list and explain what's missing > from: > http://fedoraproject.org/wiki/Features/VolumeControlContinued > > > , people who have digital > > outputs, or people who have analog surround sound setups (the Logitech > > Z-5300 has been in production for about seven years for a *reason* - > > people buy this stuff). > > Analog surround will be supported by the next version of > gnome-volume-control. You had to poke in ALSA to get this working > before, now you can use pavucontrol, or a one-liner in pacmd to fix > that. > > Not a regression then. It is a regression, because in previous releases, we shipped an ALSA mixer by default which *did* allow this functionality. Sure, it allowed it with a really crappy interface, but it allowed it. (Is this next version of g-v-c coming soon enough for us to shove it into F11 at release? That would be nice.) Your mention of pavucontrol seems to expose a bit of confusion, because we have Lennart saying "pavucontrol should have been dropped from the default install the minute the new g-v-c was pushed into Fedora. We forgot to do that. We should do it now. End of story.", and William saying "The fact that it is still currently in the menus is almost certainly an oversight". So are you guys saying pavucontrol should be installed by default, or not? Do you agree with Lennart and William on this? For now I'll act on the assumption that the counter-proposal is to drop pavucontrol and ship only new g-v-c by default, since that seems to be the majority position on your side. If that's the case, any functionality provided by pavucontrol but not g-v-c is not important, as it wouldn't be installed by default. > Seriously. The discussion started because there were regressions, then > you go on accusing us of missing features that were never properly > supported in the first place. > > SPDIF and analog surround weren't supported by the crappy mixers we had > before, and they're not supported now. But now we have the framework to > make those work. I see that as a great step forward. This just isn't factually accurate. Analog surround: on every card I've ever seen, this is how this is implemented. The card has the usual set of jacks - line / speaker out, line in, mic in, maybe an aux in or something. There is a switch-type mixer control which enables or disables analog surround. When it's enabled, two of the jacks, which are usually line-in and mic-in or something, instead become the extra outputs needed for surround output: one for the rear speakers, one for the sub and the center channel. When it's disabled, they have their original functions. There's also (usually) some extra volume range-type elements which let you control the volume of each of the parts of the surround system separately, so you can compensate for how far away your surround speakers or sub are to make sure the sound is balanced. These elements are all exposed by ALSA, so any ALSA mixer - including the old gnome-volume-control - can enable this functionality. Yes, it's a crappy interface, but the function is available, and many people at this point know how to use it. We shipped an ALSA mixer by default in F10. The proposal of those opposed to the compromise approved by FESco is not to ship one by default in F11 (and, as far as I can tell, not to ship pavucontrol either). Hence, this feature was exposed by a graphical application installed by default in F10, while under that proposal, it will not be in F11. That is a regression. Digital output: there are two main ways of implementing this. Method 1: there is a switch-type ALSA mixer element which enables or disables digital output (usually labelled IEC958 Output or something similar). Hence any ALSA mixer allows you to enable or disable digital output. As discussed above, this would therefore be available in F10, not in F11: hence, regression. Method 2: the digital output is implemented as a separate playback 'interface' (sorry, I don't know the correct technical term for it) by ALSA, so to output to it, you have to do something like 'mplayer -ao alsa:device=spdif', or create a little ~/.asoundrc file that sets up this routing by default. Indeed there was no GUI way to do this in F10, so the implementation of support for it via PA's profile system is an improvement, and a really nice one (that I personally benefit from). So there is no regression in this case. FWIW, I believe Creative cards, which are likely the most popular expansion cards, usually use the switch-type mixer element method. I'm not sure which method Intel onboard hardware, which is probably the most common type of sound hardware taken all-in-all, use. So, summary: in two out of three of the cases for analog surround output and digital output, the anti-FESco-compromise position results in a regression from functionality exposed via a GUI tool installed by default in F10. In one case, it results in no benefit, because g-v-c doesn't support profiles yet and they apparently don't want to ship pavucontrol any more. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From seg at haxxed.com Sun May 3 20:00:44 2009 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 03 May 2009 15:00:44 -0500 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <20090503183429.GA24482@srcf.ucam.org> References: <1240759385.6529.0.camel@localhost.localdomain> <1240762219.2770.9.camel@localhost.localdomain> <1241027428.3139.9.camel@localhost.localdomain> <939dd5750904301050o4efb3efau356882109b2e206b@mail.gmail.com> <1241116151.32113.273.camel@adam.local.net> <939dd5750904301208l19123893rc9cd68609f8980be@mail.gmail.com> <49F9FD08.9010904@redhat.com> <20090430234809.GA5813@srcf.ucam.org> <1241370463.2632.60.camel@localhost.localdomain> <20090503183429.GA24482@srcf.ucam.org> Message-ID: <1241380844.2632.119.camel@localhost.localdomain> On Sun, 2009-05-03 at 19:34 +0100, Matthew Garrett wrote: > On Sun, May 03, 2009 at 12:07:43PM -0500, Callum Lerwick wrote: > > On Fri, 2009-05-01 at 00:48 +0100, Matthew Garrett wrote: > > > The problem with the desktop is that it's obvious, looks simple and > > > everyone has an opinion on it. But not all of these opinions are equally > > > valid. This kind of situation is much easier to deal with in, say, the > > > kernel VM system - in that case it would be perfectly acceptable for > > > people who spend their entire working lives concentrating on a specific > > > topic to say that they know better than people who occasionally touch > > > upon it. > > > > ... And the kernel VM people tend to be able to back up their expertise > > with hard data. If a patch isn't an improvement in some provable manner, > > it doesn't get in to the kernel. > > Like everything else, kernel VM performance is a tradeoff. Improvements > may benefit certain workloads while impairing others. It's rare for > changes to improve things for everybody - so the end result is a > judgement call, generally by the people who are assumed to know what > they're doing. No, it is not a judgement call. Hard performance measurements are not subjective. We developers are not sheep, and this is not a closed proprietary project. We expect our experts to show their work. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mjg at redhat.com Sun May 3 20:35:43 2009 From: mjg at redhat.com (Matthew Garrett) Date: Sun, 3 May 2009 21:35:43 +0100 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <1241380844.2632.119.camel@localhost.localdomain> References: <1240762219.2770.9.camel@localhost.localdomain> <1241027428.3139.9.camel@localhost.localdomain> <939dd5750904301050o4efb3efau356882109b2e206b@mail.gmail.com> <1241116151.32113.273.camel@adam.local.net> <939dd5750904301208l19123893rc9cd68609f8980be@mail.gmail.com> <49F9FD08.9010904@redhat.com> <20090430234809.GA5813@srcf.ucam.org> <1241370463.2632.60.camel@localhost.localdomain> <20090503183429.GA24482@srcf.ucam.org> <1241380844.2632.119.camel@localhost.localdomain> Message-ID: <20090503203543.GA26344@srcf.ucam.org> On Sun, May 03, 2009 at 03:00:44PM -0500, Callum Lerwick wrote: > On Sun, 2009-05-03 at 19:34 +0100, Matthew Garrett wrote: > > Like everything else, kernel VM performance is a tradeoff. Improvements > > may benefit certain workloads while impairing others. It's rare for > > changes to improve things for everybody - so the end result is a > > judgement call, generally by the people who are assumed to know what > > they're doing. > > No, it is not a judgement call. Hard performance measurements are not > subjective. > > We developers are not sheep, and this is not a closed proprietary > project. We expect our experts to show their work. Choosing the workloads that are important is a judgement call. -- Matthew Garrett | mjg59 at srcf.ucam.org From loupgaroublond at gmail.com Sun May 3 21:25:13 2009 From: loupgaroublond at gmail.com (loupgaroublond at gmail.com) Date: Sun, 3 May 2009 17:25:13 -0400 (EDT) Subject: Packaging python bits with setuptools that depend on non-distutil packages Message-ID: Hey List, I'm working on a couple of projects to get them to use setuptools, but i've come across an interesting dillema. Some core systems modules, such as dbus and rpm aren't normally provided as eggs, because they are built as part of the build process of the original C code. This yields two issues. 1) I cannot use virtualenv to test these packages in a clean room. I like to test things in as clean of an area as possible, and sometimes it's difficult to figure out what i've installed might be modifying some expected behavior. Virtualenv let's you build very light weight containers for testing python code in, but without distutils, it's hard to run some setup script or rely on easy_install to provide the needed bits. 2) How do we normally declare dependencies on these components in setuptools? If i were to push the package i'm making to the Python Cheese shop, it would depend on something the user may not actually have installed. How do i go about declaring these dependencies? To make a short story long, i'm sure there are ways to include code snippets in dbus, rpm, and possibly other packages that also generate egg info. This would at least let me declare those packages as dependencies. The bigger issue i have though, is how can i import them in some generic fashion into virtualenv? Please advise. -Yaakov -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 270 bytes Desc: OpenPGP digital signature URL: From jspaleta at gmail.com Sun May 3 22:11:42 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 3 May 2009 14:11:42 -0800 Subject: Moblin 2 and Fedora In-Reply-To: <20090503160827.GA21833@srcf.ucam.org> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com> <20090131110644.1a80ddf5@infradead.org> <4984BC61.3040908@fedoraproject.org> <20090131153457.573762ab@infradead.org> <604aa7910902020825v23bc3687m1151596fa74cb8a5@mail.gmail.com> <20090202101002.4380c005@infradead.org> <1233598383.7493.42.camel@localhost.localdomain> <20090202113524.184e402c@infradead.org> <20090503160827.GA21833@srcf.ucam.org> Message-ID: <604aa7910905031511u1eaa6364y4223155904db1fb7@mail.gmail.com> On Sun, May 3, 2009 at 8:08 AM, Matthew Garrett wrote: > There's absolutely nothing wrong with any of this, but right now it's > kind of hard to see how moblin is anyone other than Fedora with changes. > I don't think that puts Intel under any sort of obligation to feed > changes back to us and I agree that Koji isn't ideally suited to > producing the kind of derivative that Intel want to, but it would be > nice to acknowledge the amount of the project that's built on the work > of Fedora contributors. There is more than a touch of irony here, as in the past Fedora packagers have been on occasion have ruffled feathers of 3rd party by using 3rd party specfiles as a starting point for a package view for inclusion into Fedora. We certainly aren't in a position to demand any sort of official recognition. But at the same time we aren't restrained from point out that our process is influential. I guess ideally I'd like to see it work like how rock bands influence each other. To be an influential rock band, that inherently means that other bands come up behind you and take your style of doing things along with pieces of other bands that have influenced them and make something new. The more influential a rock band you are, the more rock bands you influence. Doesn't mean you were packing football stadiums with fans..it means the other artists and the potential artists..the creators of value..were directly impacted by your work and incorporated it into their own. And of course those newer rock bands don't spend all that much time making it a point that they were influenced by other bands. Sure if they are directly asked in an interview they'll gladly talk about it..but in general they don't spend 15 minutes in their shows stepping through their evolution as artists. The fans that care can hear the influences in the new band's music. The question is, can moblin contributors hear/feel/smell/taste the influence from Fedora in the work moblin is doing? -jef"So basically what I'm saying is.... maybe Fedora is open source's The Ramones... and moblin is headed towards being U2 or maybe Greenday."Spaleta From dr.diesel at gmail.com Mon May 4 00:52:05 2009 From: dr.diesel at gmail.com (Dr. Diesel) Date: Sun, 3 May 2009 20:52:05 -0400 Subject: Is this part of the Intel driver issues? In-Reply-To: <2a28d2ab0905031745wf1fed02p10bf058f3f81a967@mail.gmail.com> References: <2a28d2ab0905031745wf1fed02p10bf058f3f81a967@mail.gmail.com> Message-ID: <2a28d2ab0905031752j7628ea54u8f1eb59873168b80@mail.gmail.com> General desktop cruising caused this, see attached pic. System was hard locked, vt switch failed, mouse was locked. F11 Rawhide all updates to date. lspci -v 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller]) Subsystem: Toshiba America Info Systems Device ff02 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at dc100000 (32-bit, non-prefetchable) [size=512K] I/O ports at 1800 [size=8] Memory at c0000000 (32-bit, prefetchable) [size=256M] Memory at dc200000 (32-bit, non-prefetchable) [size=256K] Expansion ROM at [disabled] Capabilities: Kernel driver in use: i915 Kernel modules: i915 Shall I BZ it against Xorg Intel? -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0_IMAGE_042.jpg Type: image/jpeg Size: 21040 bytes Desc: not available URL: From rc040203 at freenet.de Mon May 4 05:07:57 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 04 May 2009 07:07:57 +0200 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <939dd5750905031011oe9b5194s7b8c448a6930b1bf@mail.gmail.com> References: <20090430194821.GA25787@nostromo.devel.redhat.com> <1241170355.13917.18.camel@macbook.infradead.org> <20090501142031.GA11556@nostromo.devel.redhat.com> <1241191092.2811.5.camel@adam.local.net> <939dd5750905010909p26e217d8x52e3374ade92c5f2@mail.gmail.com> <1241195854.2811.20.camel@adam.local.net> <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> <20090502005540.GA29541@srcf.ucam.org> <1241369768.2632.54.camel@localhost.localdomain> <939dd5750905031011oe9b5194s7b8c448a6930b1bf@mail.gmail.com> Message-ID: <49FE782D.2040406@freenet.de> William Jon McCann wrote: > Hi, > > On Sun, May 3, 2009 at 12:56 PM, Callum Lerwick wrote: >> As it is, the people in the trenches doing QA and user support have way >> more convincing data than the desktop team. >> >> Designing HCI without Humans in the loop is bogus beyond belief. > > I think you are conflating user experience design with usability. Our > user experience design and interface design takes place very early in > the Fedora development cycle. It is primarily informed by our > experiences, research, and vision. Currently, the user testing is > done primarily after a Fedora release. IMNSHO, this is a serious defect of the development process. Your remark also explains a lot of the (IMNSHO) silly decisions and regressions Fedora desktop users are being confronted with. Simply deviate a "mu" from the desktop team developers' use-cases/hw/setup and you are likely to get stuck somewhere. > It would be great if we organized something similar. You already have an essential component of it: It's called user feedback. It's up to those in charge to take it into account or to ignoring it. I regret having to say so, but I feel the latter is what is happening to a wide extend. > A word of > caution though - this is hard to do correctly. Right, but it's pretty easy to identify errors and regressions. The problem is developers to draw consequences from them. > It is quite easy to > collect misleading and confusing data. The exact process of the > testing matters a great deal. FWIW, I'm hoping to do something like > this in the next few months. Glad to hear this. To me, it's very apparent that much of recent years' RH/GNOME desktop works have hardly seen much usability testing before pushing them into Fedora. Ralf From abu_hurayrah at hidayahonline.org Mon May 4 05:41:29 2009 From: abu_hurayrah at hidayahonline.org (Basil Mohamed Gohar) Date: Mon, 04 May 2009 13:41:29 +0800 Subject: Setting up apache problem In-Reply-To: <212718d80905031040w3dc8626qb7fd31dcf14efdee@mail.gmail.com> References: <1241365921.18564.9.camel@localhost.localdomain> <212718d80905031040w3dc8626qb7fd31dcf14efdee@mail.gmail.com> Message-ID: <49FE8009.8080600@hidayahonline.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/04/2009 01:40 AM, Richard Fearn wrote: > Hello, > >> I've just about everything set up correctly, but when I restart httpd, I >> keep getting the error that DocumentRoot /var/www/html/willowherbdesigns >> doesn't exist, despite it being there (it's a symlink >> to /web/willowherbdesigns). > > Probably because the content under /web doesn't have the right SELinux > context; it should be system_u:object_r:httpd_sys_content_t:s0. > > You can check the context with ls -lZ, and if it's wrong, relabel using > > chcon system_u:object_r:httpd_sys_content_t:s0 /web/willowherbdesigns > > Regards, > > Rich > The error httpd throws in this kind of case (SELinux) is 403 Forbidden, not 404 not found or does not exist. I know because I've had to deal with it a lot. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkn+gAQACgkQaVgOCFr0s2JzaACeOJAX0Hi+PnmG9KkGFxbAGcS2 83IAnRAacXUuE1V0/g2q50NeGTRPdFjY =0M3h -----END PGP SIGNATURE----- From pingou at pingoured.fr Mon May 4 06:07:04 2009 From: pingou at pingoured.fr (Pierre-Yves) Date: Mon, 04 May 2009 08:07:04 +0200 Subject: Is this part of the Intel driver issues? In-Reply-To: <2a28d2ab0905031752j7628ea54u8f1eb59873168b80@mail.gmail.com> References: <2a28d2ab0905031745wf1fed02p10bf058f3f81a967@mail.gmail.com> <2a28d2ab0905031752j7628ea54u8f1eb59873168b80@mail.gmail.com> Message-ID: <1241417224.3288.2.camel@red.localdomain> On Sun, 2009-05-03 at 20:52 -0400, Dr. Diesel wrote: > General desktop cruising caused this, see attached pic. System was > hard locked, vt switch failed, mouse was locked. > > F11 Rawhide all updates to date. > Shall I BZ it against Xorg Intel? Looks a bit like the issue I had (see https://bugzilla.redhat.com/show_bug.cgi?id=497415 and the picture attached) Best regards, Pierre From kevin.kofler at chello.at Mon May 4 07:04:36 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 04 May 2009 09:04:36 +0200 Subject: Abandon "Default Desktop" References: <49FD51ED.7000906@alexhudson.com> Message-ID: Alex Hudson wrote: > I think you've slightly misunderstood my point. The apps and selections > are not really an issue. My point is that if there is a case for > presenting users with download options to fine-tune the initial set of > software to be installed, it seems that there are more important > software choices to present than between desktops - browser, office > suite, e-mail client, etc. If you're using a desktop you're likely to be > spending much more time in those apps than the "desktop". But the desktop environments also come with a lot of applications, not just the desktop itself. The choice of desktop should also imply a choice for the default applications. If you choose KDE, you should by default get KDE apps for "browser, office suite, e-mail client, etc.", if you choose GNOME, GNOME apps. This is mostly already the case with the live images right now (except that you get Firefox as your browser if you choose GNOME, whereas the official default browser of GNOME is Epiphany). Kevin Kofler From snecklifter at gmail.com Mon May 4 08:41:18 2009 From: snecklifter at gmail.com (Christopher Brown) Date: Mon, 4 May 2009 09:41:18 +0100 Subject: Moblin 2 and Fedora In-Reply-To: <604aa7910905031511u1eaa6364y4223155904db1fb7@mail.gmail.com> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <20090131110644.1a80ddf5@infradead.org> <4984BC61.3040908@fedoraproject.org> <20090131153457.573762ab@infradead.org> <604aa7910902020825v23bc3687m1151596fa74cb8a5@mail.gmail.com> <20090202101002.4380c005@infradead.org> <1233598383.7493.42.camel@localhost.localdomain> <20090202113524.184e402c@infradead.org> <20090503160827.GA21833@srcf.ucam.org> <604aa7910905031511u1eaa6364y4223155904db1fb7@mail.gmail.com> Message-ID: <364d303b0905040141k4cbcfd1aie92bd808ef665a8b@mail.gmail.com> 2009/5/3 Jeff Spaleta : > On Sun, May 3, 2009 at 8:08 AM, Matthew Garrett wrote: >> There's absolutely nothing wrong with any of this, but right now it's >> kind of hard to see how moblin is anyone other than Fedora with changes. >> I don't think that puts Intel under any sort of obligation to feed >> changes back to us and I agree that Koji isn't ideally suited to >> producing the kind of derivative that Intel want to, but it would be >> nice to acknowledge the amount of the project that's built on the work >> of Fedora contributors. > > > There is more than a touch of irony here, as in the past Fedora > packagers have been on occasion have ruffled feathers of 3rd party by > using 3rd party specfiles as a starting point for a package view for > inclusion into Fedora. ?We certainly aren't in a position to demand > any sort of official recognition. ?But at the same time we aren't > restrained from point out that our process is influential. > > I guess ideally I'd like to see it work like how rock bands influence > each other. ?To be an influential rock band, that inherently means > that other bands come up behind you and take your style of doing > things along with pieces of other bands that have influenced them and > make something new. ?The more influential a rock band you are, the > more rock bands you influence. Doesn't mean you were packing football > stadiums with fans..it means the other artists and the potential > artists..the creators of value..were directly impacted by your work > and incorporated it into their own. ?And of course those newer rock > bands don't spend all that much time making it a point that they were > influenced by other bands. Sure if they are directly asked in an > interview they'll gladly talk about it..but in general they don't > spend 15 minutes in their shows stepping through their evolution as > artists. ?The fans that care can hear the influences in the new band's > music. ?The question is, can moblin contributors hear/feel/smell/taste > the influence from Fedora in the work moblin is doing? > > -jef"So basically what I'm saying is.... maybe Fedora is open source's > The Ramones... and moblin is headed towards being U2 or maybe > Greenday."Spaleta The influences analogy is not one I would have chosen. U2 don't play "Sheena is a punk rocker" at their gigs (with a few different chords (patches)) and pretend it is theirs. Its not quite Oracle Unbreakable though, which is nice. I think really what has been identified are two things that Fedora would like to see. 1. Patches 2. Attribution With reference to 1, Arjan has stated that some are so Moblin specific there is little point trying to upstream them. This happens in Fedora too. Some patches are so Fedora-specific that there is no point trying to get them applied. What I think people are saying is that Moblin could be doing more. Perhaps both Fedora and Moblin could consider splitting out patches into two categories: fedora-foobarchanges.patch foobarchanges.patch Those that start fedora- are stated as "There is never any intention to get this stuff upstream as it won't benefit anybody, its stuff that $PROJECT requires but no-one else". Then have some simple justification in the spec file. With reference to 2, I believe it simply courteous of projects downstream to mention those on whose shoulders they stand in whatever manner they deem fit. Regards -- Christopher Brown From dwmw2 at infradead.org Mon May 4 09:41:39 2009 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 04 May 2009 10:41:39 +0100 Subject: The Great Pulseaudio Mixer Debate: a modest (productive) proposal In-Reply-To: <1241373392.2632.65.camel@localhost.localdomain> References: <1240596206.3955.245.camel@adam.local.net> <200904251714.07573.billcrawford1970@gmail.com> <6d959d480904250934h1fb12465ue60b55866d4a188c@mail.gmail.com> <200904271329.04618.billcrawford1970@gmail.com> <49F5E241.2030603@cchtml.com> <1240964482.2656.8.camel@localhost.localdomain> <49F85255.3090708@hidayahonline.org> <1241373392.2632.65.camel@localhost.localdomain> Message-ID: <1241430099.6126.42.camel@macbook.infradead.org> On Sun, 2009-05-03 at 12:56 -0500, Callum Lerwick wrote: > Hrm, pulseaudio's logging seems to have changed. You can try running > "pulseaudio -k;pulseaudio -v" then dig through the spew: After I do this, my volume control applet in the panel (actually, for some bizarre reason it's now in the notification area, rather than in the place in the panel where I explicitly placed it in F-10) no longer works. -- dwmw2 From linuxhippy at gmail.com Mon May 4 10:30:54 2009 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Mon, 4 May 2009 06:30:54 -0400 Subject: Is this part of the Intel driver issues? In-Reply-To: <2a28d2ab0905031752j7628ea54u8f1eb59873168b80@mail.gmail.com> References: <2a28d2ab0905031745wf1fed02p10bf058f3f81a967@mail.gmail.com> <2a28d2ab0905031752j7628ea54u8f1eb59873168b80@mail.gmail.com> Message-ID: <194f62550905040330l6044bb8byf8bd0dca39dc8280@mail.gmail.com> Hi, > General desktop cruising caused this, see attached pic.? System was hard > locked, vt switch failed, mouse was locked. > > F11 Rawhide all updates to date. I experience exactly the same, happens to me every 2 or 3 days. I already filed a bug about it: https://bugs.freedesktop.org/show_bug.cgi?id=21441 Would be great if you could leave your comment + Xorg.log + photo there, to generate some noise about that issue. And yes, this is part of the intel driver issues ... it seems it will take some time to reach the quality 2.4 had :-/ Thanks, Clemens From mzerqung at 0pointer.de Mon May 4 12:56:21 2009 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Mon, 4 May 2009 14:56:21 +0200 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <1241379476.2923.77.camel@adam.local.net> References: <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> <20090502014029.GC1496739@hiwaay.net> <20090502014259.GA28052@angus.ind.WPI.EDU> <1241260456.20413.2098.camel@cookie.hadess.net> <1241285539.2923.19.camel@adam.local.net> <1241312345.20413.3851.camel@cookie.hadess.net> <1241315965.2923.33.camel@adam.local.net> <1241377258.21010.1050.camel@cookie.hadess.net> <1241379476.2923.77.camel@adam.local.net> Message-ID: <20090504125621.GA11402@tango.0pointer.de> On Sun, 03.05.09 12:37, Adam Williamson (awilliam at redhat.com) wrote: > > On Sun, 2009-05-03 at 20:00 +0100, Bastien Nocera wrote: > > > > That just makes me question even more your competence to be doing the > > > design; if you manage to come up with a design for a mixer application > > > without considering the importance of digital output, well. Er. > > > That's...um. My output device is connected digitally. So are zillions of > > > others. That's why soundcards ship with S/PDIF outputs. Even cheap > > > crappy onboard sound, where the manufacturers would gladly save a cent > > > any old way, universally include S/PDIF now - because people want it. > > > How were you expecting us to hear any sound? > > > > > > I suspect this whole process was managed by people who are great at > > > interface design, and great at the software side of audio/video (which I > > > know you are), but perhaps didn't think hard enough about what people > > > actually do with audio hardware. > > > > I call BS here. PulseAudio never supported SPDIF outputs properly > > before. So we really haven't made the experience any worse. > > PulseAudio didn't before this cycle, no. I'm talking about regressions > compared to the tools included and easily accessible in F10 and previous > releases, not just in the Pulse features. I'll talk about this a bit > more further down. There are no regressions in comparison to the the SPDIF status quo ante. Accessing iec985:xxx was previously available and basically still is. > > SPDIF and analog surround weren't supported by the crappy mixers we had > > before, and they're not supported now. But now we have the framework to > > make those work. I see that as a great step forward. > > This just isn't factually accurate. > > Analog surround: on every card I've ever seen, this is how this is > implemented. Analog surround support in ALSA mixer has been completely broken since time began and still is. I cannot tape over that fact in PA. When used for surround sound the ALSA mixer knows channels such as "Rear Front Left" and "Side Front Left". That is broken. The ALSA mixer *never* worked for surround sound volume control and still doesn't. PA synthesizes software volume control when doing surround playback which is currently the best option we have, and works even if it is not optimal. And certainly is better then the status quo ante. > There is a switch-type mixer control which enables or disables analog > surround. When it's enabled, two of the jacks, which are usually line-in > and mic-in or something, instead become the extra outputs needed for > surround output: one for the rear speakers, one for the sub and the > center channel. When it's disabled, they have their original > functions. ALSA should switch the necessary controls when we open the "surround51:" devices and suchlike. If it doesn't switch those controls then please file a bug against ALSA. > There's also (usually) some extra volume range-type elements which let > you control the volume of each of the parts of the surround system > separately, so you can compensate for how far away your surround > speakers or sub are to make sure the sound is balanced. Nice idea. Completely broken, as mentioned above. > These elements are all exposed by ALSA, so any ALSA mixer - including > the old gnome-volume-control - can enable this functionality. Yes, it's > a crappy interface, but the function is available, and many people > at No. It's not available. The ALSA mixer is completely broken for surround sound. > Digital output: there are two main ways of implementing this. > > Method 1: there is a switch-type ALSA mixer element which enables or > disables digital output (usually labelled IEC958 Output or something > similar). Hence any ALSA mixer allows you to enable or disable digital > output. As discussed above, this would therefore be available in F10, > not in F11: hence, regression. Nah. using this is a misuse. You always should access SPDIF via the 'iec985' device, which is what PA does. It will switch the appropriate controls automatically and lock them and switch them back after use. The fact that these controls are available is an implementation detail which should be and is hidden by PA. > aethod 2: the digital output is implemented as a separate playback > 'interface' (sorry, I don't know the correct technical term for it) by > ALSA, so to output to it, you have to do something like 'mplayer -ao > alsa:device=spdif', or create a little ~/.asoundrc file that sets up > this routing by default. Indeed there was no GUI way to do this in F10, > so the implementation of support for it via PA's profile system is an > improvement, and a really nice one (that I personally benefit from). So > there is no regression in this case. This distinction is nonsense. It's the same as method 1. All sound cards have controls to configure a few spdif settings and as long as you access the device via "iec985:" alsa should configure everything as necessary. > So, summary: in two out of three of the cases for analog surround output > and digital output, the anti-FESco-compromise position results in a > regression from functionality exposed via a GUI tool installed by > default in F10. In one case, it results in no benefit, because g-v-c > doesn't support profiles yet and they apparently don't want to ship > pavucontrol any more. This is wrong. PA handles spdif correctly. There is not regression. And PA handles the surround mixer situation better than the raw ALSA mixer. There is no regression. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From rawhide at fedoraproject.org Mon May 4 13:47:38 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Mon, 4 May 2009 13:47:38 +0000 (UTC) Subject: rawhide report: 20090504 changes Message-ID: <20090504134738.B26141F820B@releng2.fedora.phx.redhat.com> Compose started at Mon May 4 06:15:04 UTC 2009 Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 0 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From dwalsh at redhat.com Mon May 4 14:21:14 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 04 May 2009 10:21:14 -0400 Subject: I wanted to open a discussion for F12 about running services on shell accounts. In-Reply-To: <20090501213437.GA20032@wolff.to> References: <49FB07B0.50100@redhat.com> <20090501213437.GA20032@wolff.to> Message-ID: <49FEF9DA.8060300@redhat.com> On 05/01/2009 05:34 PM, Bruno Wolff III wrote: > On Fri, May 01, 2009 at 10:31:12 -0400, > Daniel J Walsh wrote: >> I would like to run restorecond as a user service rather then as system >> service. I want to run it under the Users UID and under with the users >> context. >> >> Then I can have it watch for creation of files in the users home >> directory and be the equivalent of running restorecon ~/ by the user. > > This seems to increase the risk of hostile apps being able to get executables > relabelled to something they couldn't do directly. If the app has the ability > to write the directory it can replace a file labelled with a label it couldn't > couldn't assign directly with another file and then wait for restorecond to > change the label. > > While the same thing would happen with a relabel or running restorecon > manually, currently there is a lot more opportunity to discover the problem > before the file is relabelled. > The suggesting here is to use dbus to start applications in terminal shell as the same user UID, not to have the system dbus start the app. So I fail to see how this affects auditing. The goal here is to run restorecond as my UID. Not Root. Adding some module to pam does not help the multiple restorecond programs running, problem. And I still have the problem of cleaning up in the pam stack on exit. My thinking is we use dbus for setting up a session and it needs to be in charge of cleaning up the session when all of the same UID's leave. Otherwise every app that wants this functionality needs to do it. The current restorecond as Bruno points out is a potential security problem in a user can create a file and the restorecond can relabel it, potentially to a label the user is not allowed to relabel to. I know Nalin has looked into the potential for this as a better way of doing kerberos ticket handling and ssh-agent. So there are other potential users then restorecond. From awilliam at redhat.com Mon May 4 14:29:35 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 04 May 2009 07:29:35 -0700 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: <20090504125621.GA11402@tango.0pointer.de> References: <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> <20090502014029.GC1496739@hiwaay.net> <20090502014259.GA28052@angus.ind.WPI.EDU> <1241260456.20413.2098.camel@cookie.hadess.net> <1241285539.2923.19.camel@adam.local.net> <1241312345.20413.3851.camel@cookie.hadess.net> <1241315965.2923.33.camel@adam.local.net> <1241377258.21010.1050.camel@cookie.hadess.net> <1241379476.2923.77.camel@adam.local.net> <20090504125621.GA11402@tango.0pointer.de> Message-ID: <1241447375.2923.94.camel@adam.local.net> On Mon, 2009-05-04 at 14:56 +0200, Lennart Poettering wrote: > time began and still is. I cannot tape over that fact in PA. ... > Nah. using this is a misuse. You always should access SPDIF via the > 'iec985' device, which is what PA does. It will switch the appropriate ... > This is wrong. PA handles spdif correctly. There is not > regression. And PA handles the surround mixer situation better than > the raw ALSA mixer. There is no regression. Lennart - I'm not talking about PA. I've already said the way PA does analog surround and S/PDIF, with its profile support, is a great improvement. I like it. But the current counter-proposal for F11 is to ship gnome-volume-control and no other mixer by default. g-v-c does not expose PA's profile support. So no matter how great PA is - by this proposal, we would *not be exposing* all that greatness by default in F11 at all. People would somehow have to figure out to install pavucontrol before they could get to that greatness. The question is g-v-c vs. legacy mixer, not PulseAudio per se. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From ajax at redhat.com Mon May 4 14:58:35 2009 From: ajax at redhat.com (Adam Jackson) Date: Mon, 04 May 2009 10:58:35 -0400 Subject: Moblin 2 and Fedora In-Reply-To: <20090503160827.GA21833@srcf.ucam.org> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <49844F3B.6060905@fedoraproject.org> <5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com> <20090131110644.1a80ddf5@infradead.org> <4984BC61.3040908@fedoraproject.org> <20090131153457.573762ab@infradead.org> <604aa7910902020825v23bc3687m1151596fa74cb8a5@mail.gmail.com> <20090202101002.4380c005@infradead.org> <1233598383.7493.42.camel@localhost.localdomain> <20090202113524.184e402c@infradead.org> <20090503160827.GA21833@srcf.ucam.org> Message-ID: <1241449115.2766.148.camel@atropine.boston.devel.redhat.com> On Sun, 2009-05-03 at 17:08 +0100, Matthew Garrett wrote: > On Mon, Feb 02, 2009 at 11:35:24AM -0800, Arjan van de Ven wrote: > > So I would like to really ask you and others to stop thinking of Moblin > > as "Fedora with changes" and measure everything against that. I realize > > it's easy to think that, and a lot of things just won't make sense in > > that mindset. > > I ended up analysing this while otherwise bored. There's nothing > especially surprising in the moblin repositories. The large majority of > the packages are Fedora derived, with a small number from suse > (primarily the toolchain, as Arjan said) and a few custom ones. > > Figuring out the proportion of the packages that were Fedora derived was > actually surprisingly difficult. A large number of the specfiles have > been processed through something called specbuilder. The behaviour of > this seems to have varied between versions - some remove the original > changelog, some don't. In some cases the specfiles are identical to the > Fedora ones (to the extent of including comments) but have simply had > the changelog entries stripped. There is a reasonably legitimate technical reason for this, which is that the changelogs end up in the rpmdb, which is wasted disk space for the moblin use case (user just wants firefox and doesn't care about package changelogs). It's about 24M on my machine, for instance. Of course that's also something you could strip out at rpmbuild time... > There's absolutely nothing wrong with any of this, but right now it's > kind of hard to see how moblin is anyone other than Fedora with changes. > I don't think that puts Intel under any sort of obligation to feed > changes back to us and I agree that Koji isn't ideally suited to > producing the kind of derivative that Intel want to, but it would be > nice to acknowledge the amount of the project that's built on the work > of Fedora contributors. Just to underline this point, let's look at what the Moblin FAQ has to say on the subject: Q Is Moblin v2.0 based on another distribution? Moblin v2.0 borrows components from various distributions, but is not based on another distribution. [ source: http://moblin.org/documentation/moblin-overview/faq ] This seems... disingenuous? I guess it all depends on what the definition of the word "based" is. It's also the sort of statement that begs immediate deconstruction. If moblin _isn't_ based on another distribution, why does it feel the need to say so. On the other hand, if it is, why does it say it isn't. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From pbrobinson at gmail.com Mon May 4 15:06:11 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 4 May 2009 16:06:11 +0100 Subject: Moblin 2 and Fedora In-Reply-To: <1241449115.2766.148.camel@atropine.boston.devel.redhat.com> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <20090131110644.1a80ddf5@infradead.org> <4984BC61.3040908@fedoraproject.org> <20090131153457.573762ab@infradead.org> <604aa7910902020825v23bc3687m1151596fa74cb8a5@mail.gmail.com> <20090202101002.4380c005@infradead.org> <1233598383.7493.42.camel@localhost.localdomain> <20090202113524.184e402c@infradead.org> <20090503160827.GA21833@srcf.ucam.org> <1241449115.2766.148.camel@atropine.boston.devel.redhat.com> Message-ID: <5256d0b0905040806y4c54d921t112aedbca08bb9ca@mail.gmail.com> >> > So I would like to really ask you and others to stop thinking of Moblin >> > as "Fedora with changes" and measure everything against that. I realize >> > it's easy to think that, and a lot of things just won't make sense in >> > that mindset. >> >> I ended up analysing this while otherwise bored. There's nothing >> especially surprising in the moblin repositories. The large majority of >> the packages are Fedora derived, with a small number from suse >> (primarily the toolchain, as Arjan said) and a few custom ones. >> >> Figuring out the proportion of the packages that were Fedora derived was >> actually surprisingly difficult. A large number of the specfiles have >> been processed through something called specbuilder. The behaviour of >> this seems to have varied between versions - some remove the original >> changelog, some don't. In some cases the specfiles are identical to the >> Fedora ones (to the extent of including comments) but have simply had >> the changelog entries stripped. > > There is a reasonably legitimate technical reason for this, which is > that the changelogs end up in the rpmdb, which is wasted disk space for > the moblin use case (user just wants firefox and doesn't care about > package changelogs). ?It's about 24M on my machine, for instance. > > Of course that's also something you could strip out at rpmbuild time... > >> There's absolutely nothing wrong with any of this, but right now it's >> kind of hard to see how moblin is anyone other than Fedora with changes. >> I don't think that puts Intel under any sort of obligation to feed >> changes back to us and I agree that Koji isn't ideally suited to >> producing the kind of derivative that Intel want to, but it would be >> nice to acknowledge the amount of the project that's built on the work >> of Fedora contributors. > > Just to underline this point, let's look at what the Moblin FAQ has to > say on the subject: > > Q Is Moblin v2.0 based on another distribution? > ? ? ? ?Moblin v2.0 borrows components from various distributions, but > ? ? ? ?is not based on another distribution. > > ? ?[ source: http://moblin.org/documentation/moblin-overview/faq ] > > This seems... disingenuous? ?I guess it all depends on what the > definition of the word "based" is. ?It's also the sort of statement that > begs immediate deconstruction. ?If moblin _isn't_ based on another > distribution, why does it feel the need to say so. ?On the other hand, > if it is, why does it say it isn't. And why when moblin 2 was announced did they make announcements that they were moving from Ubuntu to Fedora such as reported here http://www.theregister.co.uk/2008/07/23/moblin_reworked/ I would also be interested to know what was wrong with the Fedora toolchain that they decided to use the Suse one (or maybe what was right about the suse one). Peter From a.badger at gmail.com Mon May 4 15:17:22 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 04 May 2009 08:17:22 -0700 Subject: Packaging python bits with setuptools that depend on non-distutil packages In-Reply-To: References: Message-ID: <49FF0702.4070209@gmail.com> loupgaroublond at gmail.com wrote: > Hey List, > > I'm working on a couple of projects to get them to use setuptools, but > i've come across an interesting dillema. Some core systems modules, such > as dbus and rpm aren't normally provided as eggs, because they are built > as part of the build process of the original C code. This yields two > issues. > > 1) I cannot use virtualenv to test these packages in a clean room. I > like to test things in as clean of an area as possible, and sometimes > it's difficult to figure out what i've installed might be modifying some > expected behavior. Virtualenv let's you build very light weight > containers for testing python code in, but without distutils, it's hard > to run some setup script or rely on easy_install to provide the needed > bits. > easy_install is of only marginal use when dealing with modules that have to be compiled. Getting built eggs for that case is going to be a hard sell. > 2) How do we normally declare dependencies on these components in > setuptools? If i were to push the package i'm making to the Python > Cheese shop, it would depend on something the user may not actually have > installed. How do i go about declaring these dependencies? > The best thing to do is to not depend on those packages that do not provide egg-info. Trying to describe a dependency on them in the setup.py is doing no one any favors (as your user's cannot satisfy the dependencies so they cannot ever install this.) > To make a short story long, i'm sure there are ways to include code > snippets in dbus, rpm, and possibly other packages that also generate > egg info. This would at least let me declare those packages as > dependencies. The bigger issue i have though, is how can i import them > in some generic fashion into virtualenv? > Now that that's out of the way.... look at pygobject2 for some Makefile rules that may help you. -Toshio From arjan at infradead.org Mon May 4 15:27:12 2009 From: arjan at infradead.org (Arjan van de Ven) Date: Mon, 4 May 2009 08:27:12 -0700 Subject: Moblin 2 and Fedora In-Reply-To: <20090503160827.GA21833@srcf.ucam.org> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <49844F3B.6060905@fedoraproject.org> <5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com> <20090131110644.1a80ddf5@infradead.org> <4984BC61.3040908@fedoraproject.org> <20090131153457.573762ab@infradead.org> <604aa7910902020825v23bc3687m1151596fa74cb8a5@mail.gmail.com> <20090202101002.4380c005@infradead.org> <1233598383.7493.42.camel@localhost.localdomain> <20090202113524.184e402c@infradead.org> <20090503160827.GA21833@srcf.ucam.org> Message-ID: <20090504082712.6c9786e9@infradead.org> On Sun, 3 May 2009 17:08:27 +0100 Matthew Garrett wrote: [ I wasn't on the CC, just saw this by accident] > A large number of the specfiles > have been processed through something called specbuilder. If there is anything in Moblin that I'd like Fedora to consider adopting, it is specbuilder. Specbuilder is basically the (start of) an autopackaging tool, where we try to automatically generate packaging for a class of upstream projects. The class we're focusing on is those upstream packages that use autoconf/automake/etc and use pkgconfig. For these packages we have a very small .ini file with some basic metadata (which we're trying to autogenerate at much as possible as well), which specbuilder then turns into a .spec file for building. These ini files are relatively small and simple, and can mostly be autogenerated. The result is a very consistent set of rpms, and we're working on being able to generate other packaging formats from this same minimal metadata as well.... For example the ini file for the Intel IIG graphics driver package looks like this: [header] Summary = Xorg X11 Intel video driver Name = xorg-x11-drv-intel LocaleName = xorg-x11-drv-intel Version = 2.7.0 Release = 1 Group = User Interface/X Hardware Support License = MIT URL = http://www.x.org/ Files = xorg-x11-drv-intel.files Requires = xorg-x11-server-Xorg hwdata SubPackages = devel tools [configuration] Sources = http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-%{version}.tar.bz2 PkgConfig = xorg-server libdrm xf86driproto xvmc gl x11 xproto fontsproto randrproto renderproto xextproto glproto xineramaproto xi dri2proto xext configure = reconfigure ConfigOptions = --enable-dri Patches = regdumper.patch copy-fb.patch biosdumper.patch [devel] Summary = Xorg X11 Intel video driver XvMC development package Group = Development/System Files = xorg-x11-drv-intel-devel.files [tools] Summary = Xorg X11 Intel video driver diagnostics tools Group = Development/System Files = xorg-x11-drv-intel-tools.files -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org From sundaram at fedoraproject.org Mon May 4 15:31:53 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 04 May 2009 21:01:53 +0530 Subject: Moblin 2 and Fedora In-Reply-To: <1241449115.2766.148.camel@atropine.boston.devel.redhat.com> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <49844F3B.6060905@fedoraproject.org> <5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com> <20090131110644.1a80ddf5@infradead.org> <4984BC61.3040908@fedoraproject.org> <20090131153457.573762ab@infradead.org> <604aa7910902020825v23bc3687m1151596fa74cb8a5@mail.gmail.com> <20090202101002.4380c005@infradead.org> <1233598383.7493.42.camel@localhost.localdomain> <20090202113524.184e402c@infradead.org> <20090503160827.GA21833@srcf.ucam.org> <1241449115.2766.148.camel@atropine.boston.devel.redhat.com> Message-ID: <49FF0A69.8030609@fedoraproject.org> On 05/04/2009 08:28 PM, Adam Jackson wrote: > > Just to underline this point, let's look at what the Moblin FAQ has to > say on the subject: > > Q Is Moblin v2.0 based on another distribution? > Moblin v2.0 borrows components from various distributions, but > is not based on another distribution. > > [ source: http://moblin.org/documentation/moblin-overview/faq ] > > This seems... disingenuous? I guess it all depends on what the > definition of the word "based" is. It's also the sort of statement that > begs immediate deconstruction. If moblin _isn't_ based on another > distribution, why does it feel the need to say so. On the other hand, > if it is, why does it say it isn't. I don't see us accomplishing much by stating the obvious, which is that Moblin is indeed based on Fedora even if Intel does not want to acknowledge that for whatever reasons. Considering that they seem to have moved it over to Linux Foundation, it all might just be political considerations. Let's move beyond that. Now, is there useful patches that we need to push upstream? Are there additional packages, we can import into Fedora? Let's look at that list. We know of sreadahead. Has the kernel portion been upstreamed? Arjan pointed out memuse in http://lwn.net/Articles/331423/. What's the rest? Rahul From sundaram at fedoraproject.org Mon May 4 15:38:24 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 04 May 2009 21:08:24 +0530 Subject: Moblin 2 and Fedora In-Reply-To: <20090504082712.6c9786e9@infradead.org> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <49844F3B.6060905@fedoraproject.org> <5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com> <20090131110644.1a80ddf5@infradead.org> <4984BC61.3040908@fedoraproject.org> <20090131153457.573762ab@infradead.org> <604aa7910902020825v23bc3687m1151596fa74cb8a5@mail.gmail.com> <20090202101002.4380c005@infradead.org> <1233598383.7493.42.camel@localhost.localdomain> <20090202113524.184e402c@infradead.org> <20090503160827.GA21833@srcf.ucam.org> <20090504082712.6c9786e9@infradead.org> Message-ID: <49FF0BF0.9010507@fedoraproject.org> On 05/04/2009 08:57 PM, Arjan van de Ven wrote: > On Sun, 3 May 2009 17:08:27 +0100 > Matthew Garrett wrote: > > [ I wasn't on the CC, just saw this by accident] > >> A large number of the specfiles >> have been processed through something called specbuilder. > > If there is anything in Moblin that I'd like Fedora to consider > adopting, it is specbuilder. Specbuilder is basically the (start of) an > autopackaging tool, where we try to automatically generate packaging for > a class of upstream projects. The class we're focusing on is those > upstream packages that use autoconf/automake/etc and use pkgconfig. Is there a upstream project page or should we look directly at http://repo.moblin.org/moblin/development/core/source/spec-builder-0.13-1.25.moblin2.src.rpm ? Rahul From jkeating at redhat.com Mon May 4 16:13:33 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 04 May 2009 09:13:33 -0700 Subject: Abandon "Default Desktop" In-Reply-To: References: <49FD51ED.7000906@alexhudson.com> Message-ID: <1241453613.3570.41.camel@localhost.localdomain> On Mon, 2009-05-04 at 09:04 +0200, Kevin Kofler wrote: > (except that you get Firefox as your browser if you choose GNOME, whereas > the official default browser of GNOME is Epiphany). This is one of the reasons why it's not the Gnome spin, it's the Fedora Desktop spin. If somebody wanted to make a GNOME spin that highlighted the best of the GNOME world and GNOME only, they could. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jlaska at redhat.com Mon May 4 16:14:38 2009 From: jlaska at redhat.com (James Laska) Date: Mon, 04 May 2009 12:14:38 -0400 Subject: 2009-05-07 - Fedora Test Day - Virtualization Message-ID: <1241453678.2726.76.camel@flatline.devel.redhat.com> Greetings folks, For those subscribed to fedora-virt-list, you may already have seen Mark McLoughlin's announcement [1] of this weeks Virtualization test day. Fedora 11 hosts a number of virtualization improvements, including: * Features/KVM PCI Device Assignment * Features/KVM and QEMU merge * Features/SVirt Mandatory Access Control * Features/VirtImprovedConsole * Features/VirtVNCAuth We plan to review+test the F11 features, as well as use this an opportunity to lay the ground work for future virtualization testing. Testing has been divided into several test areas which incorporate features as well as existing functionality (see https://fedoraproject.org/wiki/Test_Day:2009-05-07_Virtualization#How_to_test.3F). During the next few days we plan to create additional test cases for the current test areas. I invite you to join #fedora-qa this Thursday, May 7 2009 to review the Fedora 11 Virtualization features [2] and help iron out integration issues. I'm expecting a good turn out this week from the virt developers, which means we could use strong representation from testers. While a live image will be available, testing against an installed F11/rawhide system is recommended. Stay tuned for more details at https://fedoraproject.org/wiki/Test_Day:2009-05-07_Virtualization. Thanks, James [1] http://www.redhat.com/archives/fedora-virt/2009-April/msg00287.html [2] https://fedoraproject.org/wiki/Category:F11_Virt_Features -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From oget.fedora at gmail.com Mon May 4 16:35:18 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Mon, 4 May 2009 12:35:18 -0400 Subject: Abandon "Default Desktop" In-Reply-To: <1241453613.3570.41.camel@localhost.localdomain> References: <49FD51ED.7000906@alexhudson.com> <1241453613.3570.41.camel@localhost.localdomain> Message-ID: On Mon, May 4, 2009 at 12:13 PM, Jesse Keating wrote: > On Mon, 2009-05-04 at 09:04 +0200, Kevin Kofler wrote: >> (except that you get Firefox as your browser if you choose GNOME, whereas >> the official default browser of GNOME is Epiphany). > > This is one of the reasons why it's not the Gnome spin, it's the Fedora > Desktop spin. ?If somebody wanted to make a GNOME spin that highlighted > the best of the GNOME world and GNOME only, they could. > Some entirely observational, non-scientific and quite possibly coincidental statistics: In my department (Physics) we have RHEL and Windows on the lab computers right now. Also since this is a Physics department, there is a significant proportion of Linux users (grad students, postdocs, professors, administrators), who use different flavors of Linux on their personal computers. I have only seen 1 person in the last 7 years that I have spent here, using Gnome. The rest uses KDE (even in the lab on RHEL computers) or Windows. Is this really coincidence? Are we (KDE users) really the minority? Orcan, one of "Them strange physicists..." From skvidal at fedoraproject.org Mon May 4 16:37:47 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 4 May 2009 12:37:47 -0400 (EDT) Subject: Abandon "Default Desktop" In-Reply-To: References: <49FD51ED.7000906@alexhudson.com> <1241453613.3570.41.camel@localhost.localdomain> Message-ID: On Mon, 4 May 2009, Orcan Ogetbil wrote: > On Mon, May 4, 2009 at 12:13 PM, Jesse Keating wrote: >> On Mon, 2009-05-04 at 09:04 +0200, Kevin Kofler wrote: >>> (except that you get Firefox as your browser if you choose GNOME, whereas >>> the official default browser of GNOME is Epiphany). >> >> This is one of the reasons why it's not the Gnome spin, it's the Fedora >> Desktop spin. ?If somebody wanted to make a GNOME spin that highlighted >> the best of the GNOME world and GNOME only, they could. >> > > Some entirely observational, non-scientific and quite possibly > coincidental statistics: In my department (Physics) we have RHEL and > Windows on the lab computers right now. Also since this is a Physics > department, there is a significant proportion of Linux users (grad > students, postdocs, professors, administrators), who use different > flavors of Linux on their personal computers. > > I have only seen 1 person in the last 7 years that I have spent here, > using Gnome. The rest uses KDE (even in the lab on RHEL computers) or > Windows. > > Is this really coincidence? Are we (KDE users) really the minority? > > Orcan, one of "Them strange physicists..." I was the head sysadmin for a physics dept for 6 yrs. We had a lot of linux users. In fact, the majority of the dept used linux on the desktop. They used whatever was the default when they hit enter at the xdm/gdm/etc prompt. and that's what they stuck with unless they had some compelling reason to do otherwise. so, there you go, my anecdotal experience offsets yours. ta-da! -sv From johannbg at hi.is Mon May 4 17:01:29 2009 From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=) Date: Mon, 04 May 2009 17:01:29 +0000 Subject: Abandon "Default Desktop" In-Reply-To: <1241453613.3570.41.camel@localhost.localdomain> References: <49FD51ED.7000906@alexhudson.com> <1241453613.3570.41.camel@localhost.localdomain> Message-ID: <49FF1F69.1090100@hi.is> Jesse Keating wrote: > On Mon, 2009-05-04 at 09:04 +0200, Kevin Kofler wrote: > >> (except that you get Firefox as your browser if you choose GNOME, whereas >> the official default browser of GNOME is Epiphany). >> > > This is one of the reasons why it's not the Gnome spin, it's the Fedora > Desktop spin. If somebody wanted to make a GNOME spin that highlighted > the best of the GNOME world and GNOME only, they could. > > So if the other *DE SIG decide to ship firefox ( or any or few other applications that are not upstream ones ) instead of the DE upstream default browser they can claim the "Fedora Default Desktop"? Are all the other *DE spins we ship exactly like their corresponding upstream projects? Where do you want to draw the line here? One application that vary from upstream ten, hundred thousand before they can claim to be Fedora's default desktop? This argument does not hold water sorry. Fedora *DE spins and how close or not so close they want to be to upstream is totally up to the corresponding *DE SIG to decide since they are the projects representing within Fedora and it's up to them to use what ever ( marketing or combination of application ) methods they choose to reach out to as many end users as possible on they're corresponding live cd but let them do so on a fair ground and drop the default desktop concept. JBG -------------- next part -------------- A non-text attachment was scrubbed... Name: johannbg.vcf Type: text/x-vcard Size: 372 bytes Desc: not available URL: From jkeating at redhat.com Mon May 4 17:13:00 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 04 May 2009 10:13:00 -0700 Subject: Abandon "Default Desktop" In-Reply-To: <49FF1F69.1090100@hi.is> References: <49FD51ED.7000906@alexhudson.com> <1241453613.3570.41.camel@localhost.localdomain> <49FF1F69.1090100@hi.is> Message-ID: <1241457180.3570.45.camel@localhost.localdomain> On Mon, 2009-05-04 at 17:01 +0000, "J?hann B. Gu?mundsson" wrote: > So if the other *DE SIG decide to ship firefox ( or any or few other > applications that are not upstream ones ) instead of the DE upstream > default browser they can claim the "Fedora Default Desktop"? No. > > Are all the other *DE spins we ship exactly like their corresponding > upstream projects? Depends on what the other *DE spins want to do and what they want to call themselves. > > Where do you want to draw the line here? There is no real line. When designing the Desktop spin, we had to pick a name. Calling it the Gnome spin was disingenuous as it does not feature a pure Gnome desktop. What it features is what the Fedora project decided was it's best desktop foot forward, the user experience we wanted people to get if they were to get nothing else from Fedora. Ergo we called it the Desktop spin. > > One application that vary from upstream ten, hundred thousand before > they can claim to be Fedora's default desktop? > > This argument does not hold water sorry. > > Fedora *DE spins and how close or not so close they want to be to > upstream is totally up to the corresponding *DE SIG > to decide since they are the projects representing within Fedora and > it's up to them to use what ever ( marketing or combination of > application ) methods they choose to reach out to as many end users as > possible on they're corresponding live cd but let them do so on a fair > ground and drop the default desktop concept. That's a great speech, except that it is entirely misdirected. I'm not telling other spins what to call themselves or what to include. I'm telling you why the Desktop spin is named the way it is, and why it isn't called the GNOME spin. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Mon May 4 17:20:10 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 04 May 2009 10:20:10 -0700 Subject: Abandon "Default Desktop" In-Reply-To: <49FF1F69.1090100@hi.is> References: <49FD51ED.7000906@alexhudson.com> <1241453613.3570.41.camel@localhost.localdomain> <49FF1F69.1090100@hi.is> Message-ID: <49FF23CA.3000103@gmail.com> J?hann B. Gu?mundsson wrote: > Jesse Keating wrote: >> On Mon, 2009-05-04 at 09:04 +0200, Kevin Kofler wrote: >> >>> (except that you get Firefox as your browser if you choose GNOME, >>> whereas >>> the official default browser of GNOME is Epiphany). >>> >> >> This is one of the reasons why it's not the Gnome spin, it's the Fedora >> Desktop spin. If somebody wanted to make a GNOME spin that highlighted >> the best of the GNOME world and GNOME only, they could. >> >> > So if the other *DE SIG decide to ship firefox ( or any or few other > applications that are not upstream ones ) instead of the DE upstream > default browser they can claim the "Fedora Default Desktop"? > s/Fedora Default Desktop/Fedora Desktop/ Jesse isn't saying that having Firefox is the deciding factor for the question of whether it should be the default. The choice of name is bikeshedable (It's really the Red Hat Desktop Team's vision at the moment; your points about how many different choices than upstream made makes it no longer GNOME) but the name is separate from the issue of it being the default live image. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From lsof at nodata.co.uk Mon May 4 17:33:11 2009 From: lsof at nodata.co.uk (nodata) Date: Mon, 04 May 2009 19:33:11 +0200 Subject: i915 video card: anyone else have it working with rawhide? Message-ID: <1241458391.26761.5.camel@prague> Hello, Since 2.6.29.1-46 my Intel i915 video card has been broken with Fedora. Once X starts the machine has basically crashed, switching vts gives me an epileptically fast cursor then the machine becomes unresponsive. Has anyone else had similar problems? nd p.s. https://bugzilla.redhat.com/show_bug.cgi?id=496335 From johannbg at hi.is Mon May 4 18:03:53 2009 From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=) Date: Mon, 04 May 2009 18:03:53 +0000 Subject: Abandon "Default Desktop" In-Reply-To: <49FF23CA.3000103@gmail.com> References: <49FD51ED.7000906@alexhudson.com> <1241453613.3570.41.camel@localhost.localdomain> <49FF1F69.1090100@hi.is> <49FF23CA.3000103@gmail.com> Message-ID: <49FF2E09.1010607@hi.is> Toshio Kuratomi wrote: ...... > Jesse isn't saying that having Firefox is the deciding factor for the > question of whether it should be the default. The choice of name is > bikeshedable (It's really the Red Hat Desktop Team's vision at the > moment; your points about how many different choices than upstream made > makes it no longer GNOME) but the name is separate from the issue of it > being the default live image. > Interesting.. So does a *DE SIG that emerges have to follow upstream to the letter to be allowed to be called Fedora-? Can a Gnome SIG be created to act as Gnome representatives within the Fedora project and it's spin thus gets named Fedora-Gnome which may or may not differ from the current desktop spin? What are the criteria that other DE's need to meet to be allowed to be the "default" or "Fedora-Desktop"? Which begs another question how do we handle if more then one DE can and will meet that criteria? JBG -------------- next part -------------- A non-text attachment was scrubbed... Name: johannbg.vcf Type: text/x-vcard Size: 372 bytes Desc: not available URL: From darrellpf at gmail.com Mon May 4 18:10:17 2009 From: darrellpf at gmail.com (darrell pfeifer) Date: Mon, 4 May 2009 11:10:17 -0700 Subject: i915 video card: anyone else have it working with rawhide? In-Reply-To: <1241458391.26761.5.camel@prague> References: <1241458391.26761.5.camel@prague> Message-ID: NoData, > Since 2.6.29.1-46 my Intel i915 video card has been broken with Fedora. > > Once X starts the machine has basically crashed, switching vts gives me > an epileptically fast cursor then the machine becomes unresponsive. > > Has anyone else had similar problems? > > nd > > p.s. https://bugzilla.redhat.com/show_bug.cgi?id=496335 > The newer kernels and newer intel driver seem be work better without modesetting. Try nomodeset on the boot line. darrell -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at scrye.com Mon May 4 18:21:48 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Mon, 4 May 2009 12:21:48 -0600 Subject: i915 video card: anyone else have it working with rawhide? In-Reply-To: References: <1241458391.26761.5.camel@prague> Message-ID: <20090504122148.1f24a711@ohm.scrye.com> On Mon, 4 May 2009 11:10:17 -0700 darrell pfeifer wrote: > NoData, > > > > Since 2.6.29.1-46 my Intel i915 video card has been broken with > > Fedora. > > > > Once X starts the machine has basically crashed, switching vts > > gives me an epileptically fast cursor then the machine becomes > > unresponsive. > > > > Has anyone else had similar problems? No. I have a eepc900 here with a 915 in it and (aside from the font corruption bug) it's working just fine. > > p.s. https://bugzilla.redhat.com/show_bug.cgi?id=496335 Added myself there to see if I can help any. > The newer kernels and newer intel driver seem be work better without > modesetting. > > Try nomodeset on the boot line. Worth a try, but all my intel machines are working fine with modesetting... > darrell kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From jkeating at redhat.com Mon May 4 18:26:31 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 04 May 2009 11:26:31 -0700 Subject: Abandon "Default Desktop" In-Reply-To: <49FF2E09.1010607@hi.is> References: <49FD51ED.7000906@alexhudson.com> <1241453613.3570.41.camel@localhost.localdomain> <49FF1F69.1090100@hi.is> <49FF23CA.3000103@gmail.com> <49FF2E09.1010607@hi.is> Message-ID: <1241461591.3570.51.camel@localhost.localdomain> On Mon, 2009-05-04 at 18:03 +0000, "J?hann B. Gu?mundsson" wrote: > So does a *DE SIG that emerges have to follow upstream to the letter > to be allowed to be called Fedora-? No, but the people behind the spin / SIG should agree with each other on these things. > > Can a Gnome SIG be created to act as Gnome representatives within the > Fedora project > and it's spin thus gets named Fedora-Gnome which may or may not differ > from the current desktop spin? If there was a motivated team of people, sure, they could create a Gnome spin. They'd have to go through the spin SIG and get all the approval levels. Depending on how much difference there would be between the gnome spin and the desktop spin, we may choose to not produce/distribute their spin as part of a Fedora release though. > > What are the criteria that other DE's need to meet to be allowed to be > the "default" or "Fedora-Desktop"? We only have one default, one Fedora Desktop spin. We aren't going to have multiple. > Which begs another question how do we handle if more then one DE can and > will meet that criteria? I don't think we can have that scenario. The Desktop sig creates the Desktop spin, and its that spin that the Fedora project puts forward as it's default spin. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dcbw at redhat.com Mon May 4 18:31:20 2009 From: dcbw at redhat.com (Dan Williams) Date: Mon, 04 May 2009 14:31:20 -0400 Subject: i915 video card: anyone else have it working with rawhide? In-Reply-To: <20090504122148.1f24a711@ohm.scrye.com> References: <1241458391.26761.5.camel@prague> <20090504122148.1f24a711@ohm.scrye.com> Message-ID: <1241461880.8638.3.camel@localhost.localdomain> On Mon, 2009-05-04 at 12:21 -0600, Kevin Fenzi wrote: > On Mon, 4 May 2009 11:10:17 -0700 > darrell pfeifer wrote: > > > NoData, > > > > > > > Since 2.6.29.1-46 my Intel i915 video card has been broken with > > > Fedora. > > > > > > Once X starts the machine has basically crashed, switching vts > > > gives me an epileptically fast cursor then the machine becomes > > > unresponsive. > > > > > > Has anyone else had similar problems? > > No. I have a eepc900 here with a 915 in it and (aside from the font > corruption bug) it's working just fine. Dell Latitude D410 here (i915 as well) and aside from the glyph corruption bug, mine is working fine too. dan > > > p.s. https://bugzilla.redhat.com/show_bug.cgi?id=496335 > > Added myself there to see if I can help any. > > > The newer kernels and newer intel driver seem be work better without > > modesetting. > > > > Try nomodeset on the boot line. > > Worth a try, but all my intel machines are working fine with > modesetting... > > > darrell > > kevin > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From dcbw at redhat.com Mon May 4 18:33:28 2009 From: dcbw at redhat.com (Dan Williams) Date: Mon, 04 May 2009 14:33:28 -0400 Subject: Moblin 2 and Fedora In-Reply-To: <49FF0A69.8030609@fedoraproject.org> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <49844F3B.6060905@fedoraproject.org> <5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com> <20090131110644.1a80ddf5@infradead.org> <4984BC61.3040908@fedoraproject.org> <20090131153457.573762ab@infradead.org> <604aa7910902020825v23bc3687m1151596fa74cb8a5@mail.gmail.com> <20090202101002.4380c005@infradead.org> <1233598383.7493.42.camel@localhost.localdomain> <20090202113524.184e402c@infradead.org> <20090503160827.GA21833@srcf.ucam.org> <1241449115.2766.148.camel@atropine.boston.devel.redhat.com> <49FF0A69.8030609@fedoraproject.org> Message-ID: <1241462009.8638.5.camel@localhost.localdomain> On Mon, 2009-05-04 at 21:01 +0530, Rahul Sundaram wrote: > On 05/04/2009 08:28 PM, Adam Jackson wrote: > > > > > Just to underline this point, let's look at what the Moblin FAQ has to > > say on the subject: > > > > Q Is Moblin v2.0 based on another distribution? > > Moblin v2.0 borrows components from various distributions, but > > is not based on another distribution. > > > > [ source: http://moblin.org/documentation/moblin-overview/faq ] > > > > This seems... disingenuous? I guess it all depends on what the > > definition of the word "based" is. It's also the sort of statement that > > begs immediate deconstruction. If moblin _isn't_ based on another > > distribution, why does it feel the need to say so. On the other hand, > > if it is, why does it say it isn't. > > I don't see us accomplishing much by stating the obvious, which is that > Moblin is indeed based on Fedora even if Intel does not want to > acknowledge that for whatever reasons. Considering that they seem to > have moved it over to Linux Foundation, it all might just be political > considerations. Let's move beyond that. > > Now, is there useful patches that we need to push upstream? Are there > additional packages, we can import into Fedora? Let's look at that list. > We know of sreadahead. Has the kernel portion been upstreamed? Arjan > pointed out memuse in http://lwn.net/Articles/331423/. What's the rest? Yeah, how about Poulsbo support? Is anyone at Intel actually working on upstreaming the unencumbered 2D parts of that, including the kernel bits and the X driver? Random crack in gregkh's tree doesn't count. Dan From oget.fedora at gmail.com Mon May 4 18:31:59 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Mon, 4 May 2009 14:31:59 -0400 Subject: Abandon "Default Desktop" In-Reply-To: References: <49FD51ED.7000906@alexhudson.com> <1241453613.3570.41.camel@localhost.localdomain> Message-ID: 2009/5/4 Seth Vidal wrote: > On Mon, 4 May 2009, Orcan Ogetbil wrote: >> >> I have only seen 1 person in the last 7 years that I have spent here, >> using Gnome. The rest uses KDE (even in the lab on RHEL computers) or >> Windows. >> >> Is this really coincidence? Are we (KDE users) really the minority? >> >> Orcan, one of ?"Them strange physicists..." > > I was the head sysadmin for a physics dept for 6 yrs. We had a lot of linux > users. In fact, the majority of the dept used linux on the desktop. > > They used whatever was the default when they hit enter at the xdm/gdm/etc > prompt. > > and that's what they stuck with unless they had some compelling reason to do > otherwise. > > so, there you go, my anecdotal experience offsets yours. > I believe you. I was only talking about my personal observations. I did not make a study on this and it might even be my selective perception. Nevertheless, I hope that Redhat does such studies continuously. A person already makes a choice (a very big and "radical" one) when he decides to use Linux. A second choice is made by deciding on Fedora. Why should we enforce that these were the last choices he makes? As Roberto stated previously in this thread, those who think that "the user should have to choose" are more likely to be in the KDE camp. If KDE were the default "Desktop spin" in Fedora, I don't think that KDE people would oppose the idea of dropping the name "Desktop spin", or offering other DE's during installation, for the sake of having choices. I wish Gnome camp was (more) open minded... Orcan From lsof at nodata.co.uk Mon May 4 18:40:26 2009 From: lsof at nodata.co.uk (nodata) Date: Mon, 04 May 2009 20:40:26 +0200 Subject: i915 video card: anyone else have it working with rawhide? In-Reply-To: References: <1241458391.26761.5.camel@prague> Message-ID: <1241462427.4398.2.camel@prague> Am Montag, den 04.05.2009, 11:10 -0700 schrieb darrell pfeifer: > NoData, > > > Since 2.6.29.1-46 my Intel i915 video card has been broken > with Fedora. > > Once X starts the machine has basically crashed, switching vts > gives me > an epileptically fast cursor then the machine becomes > unresponsive. > > Has anyone else had similar problems? > > nd > > p.s. https://bugzilla.redhat.com/show_bug.cgi?id=496335 > > The newer kernels and newer intel driver seem be work better without > modesetting. > > Try nomodeset on the boot line. nomodeset did the trick. I can now boot and nothing crashes. Would be nice if modesetting worked though. I get 1280x1024 resolution in X now, despite configuring 1400x1050 in s-c-d, so everything is stretched wide. Didn't have this problem with Fedora 10. Makes looking at photos a bit worrying :) From dcbw at redhat.com Mon May 4 18:44:15 2009 From: dcbw at redhat.com (Dan Williams) Date: Mon, 04 May 2009 14:44:15 -0400 Subject: i915 video card: anyone else have it working with rawhide? In-Reply-To: <1241462427.4398.2.camel@prague> References: <1241458391.26761.5.camel@prague> <1241462427.4398.2.camel@prague> Message-ID: <1241462655.8638.6.camel@localhost.localdomain> On Mon, 2009-05-04 at 20:40 +0200, nodata wrote: > Am Montag, den 04.05.2009, 11:10 -0700 schrieb darrell pfeifer: > > NoData, > > > > > > Since 2.6.29.1-46 my Intel i915 video card has been broken > > with Fedora. > > > > Once X starts the machine has basically crashed, switching vts > > gives me > > an epileptically fast cursor then the machine becomes > > unresponsive. > > > > Has anyone else had similar problems? > > > > nd > > > > p.s. https://bugzilla.redhat.com/show_bug.cgi?id=496335 > > > > The newer kernels and newer intel driver seem be work better without > > modesetting. > > > > Try nomodeset on the boot line. > > nomodeset did the trick. I can now boot and nothing crashes. > > Would be nice if modesetting worked though. Can you post the lspci output for your machine, and grab /var/log/Xorg.0.log when modesetting is enabled and X starts, and you experience the problem? Dan > I get 1280x1024 resolution in X now, despite configuring 1400x1050 in > s-c-d, so everything is stretched wide. Didn't have this problem with > Fedora 10. Makes looking at photos a bit worrying :) > > From lsof at nodata.co.uk Mon May 4 19:04:30 2009 From: lsof at nodata.co.uk (nodata) Date: Mon, 04 May 2009 21:04:30 +0200 Subject: i915 video card: anyone else have it working with rawhide? In-Reply-To: <1241462655.8638.6.camel@localhost.localdomain> References: <1241458391.26761.5.camel@prague> <1241462427.4398.2.camel@prague> <1241462655.8638.6.camel@localhost.localdomain> Message-ID: <1241463870.2389.0.camel@prague> Am Montag, den 04.05.2009, 14:44 -0400 schrieb Dan Williams: > On Mon, 2009-05-04 at 20:40 +0200, nodata wrote: > > Am Montag, den 04.05.2009, 11:10 -0700 schrieb darrell pfeifer: > > > NoData, > > > > > > > > > Since 2.6.29.1-46 my Intel i915 video card has been broken > > > with Fedora. > > > > > > Once X starts the machine has basically crashed, switching vts > > > gives me > > > an epileptically fast cursor then the machine becomes > > > unresponsive. > > > > > > Has anyone else had similar problems? > > > > > > nd > > > > > > p.s. https://bugzilla.redhat.com/show_bug.cgi?id=496335 > > > > > > The newer kernels and newer intel driver seem be work better without > > > modesetting. > > > > > > Try nomodeset on the boot line. > > > > nomodeset did the trick. I can now boot and nothing crashes. > > > > Would be nice if modesetting worked though. > > Can you post the lspci output for your machine, and > grab /var/log/Xorg.0.log when modesetting is enabled and X starts, and > you experience the problem? > > Dan Have posted it on the bugzilla page. s-c-d is choosing the wrong driver (vesa instead of intel), and if I have no xorg.conf I get vesa too. (Booting with nomodeset and manually setting the driver to intel works though) From johannbg at hi.is Mon May 4 19:10:25 2009 From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=) Date: Mon, 04 May 2009 19:10:25 +0000 Subject: Abandon "Default Desktop" In-Reply-To: <1241461591.3570.51.camel@localhost.localdomain> References: <49FD51ED.7000906@alexhudson.com> <1241453613.3570.41.camel@localhost.localdomain> <49FF1F69.1090100@hi.is> <49FF23CA.3000103@gmail.com> <49FF2E09.1010607@hi.is> <1241461591.3570.51.camel@localhost.localdomain> Message-ID: <49FF3DA1.2050801@hi.is> Jesse Keating wrote: > On Mon, 2009-05-04 at 18:03 +0000, "J?hann B. Gu?mundsson" wrote: > >> So does a *DE SIG that emerges have to follow upstream to the letter >> to be allowed to be called Fedora-? >> > > No, but the people behind the spin / SIG should agree with each other on > these things. > > So actually you can call the current "Fedora-Desktop" Fedora-Gnome interesting turnaround. >> Can a Gnome SIG be created to act as Gnome representatives within the >> Fedora project >> and it's spin thus gets named Fedora-Gnome which may or may not differ >> from the current desktop spin? >> > > If there was a motivated team of people, sure, they could create a Gnome > spin. They'd have to go through the spin SIG and get all the approval > levels. Depending on how much difference there would be between the > gnome spin and the desktop spin, we may choose to not produce/distribute > their spin as part of a Fedora release though. > > In other words should Gnome SIG emerge it's a 50% chance that we don't ship it since we already have a Gnome Spin which we call Fedora-Desktop.... >> What are the criteria that other DE's need to meet to be allowed to be >> the "default" or "Fedora-Desktop"? >> > > We only have one default, one Fedora Desktop spin. We aren't going to > have multiple. > > I'm suggesting that we have no default and no "Fedora Desktop" spin ( Current Fedora-Desktop would be renamed to Fedora-Gnome to allow all DE to compete among them self on equal ground ) >> Which begs another question how do we handle if more then one DE can and >> will meet that criteria? >> > > I don't think we can have that scenario. The Desktop sig creates the > Desktop spin, and its that spin that the Fedora project puts forward as > it's default spin. > > Is the current Desktop SIG made up by representatives from each of the *DE's which then can make neutral informed decision what the current status is amongst all the DE and thus choose what should be Fedora ( next ) Desktop... Or Is the Desktop SIG governed by single DE oriented persons and or is made up by majority of individual that work for the same company that can thus influence the decision either directly or indirectly on what is and will be Fedora's Desktop? JBG -------------- next part -------------- A non-text attachment was scrubbed... Name: johannbg.vcf Type: text/x-vcard Size: 372 bytes Desc: not available URL: From lsof at nodata.co.uk Mon May 4 19:19:14 2009 From: lsof at nodata.co.uk (nodata) Date: Mon, 04 May 2009 21:19:14 +0200 Subject: i915 video card: anyone else have it working with rawhide? In-Reply-To: <1241463870.2389.0.camel@prague> References: <1241458391.26761.5.camel@prague> <1241462427.4398.2.camel@prague> <1241462655.8638.6.camel@localhost.localdomain> <1241463870.2389.0.camel@prague> Message-ID: <1241464754.2324.0.camel@prague> Am Montag, den 04.05.2009, 21:04 +0200 schrieb nodata: > Am Montag, den 04.05.2009, 14:44 -0400 schrieb Dan Williams: > > On Mon, 2009-05-04 at 20:40 +0200, nodata wrote: > > > Am Montag, den 04.05.2009, 11:10 -0700 schrieb darrell pfeifer: > > > > NoData, > > > > > > > > > > > > Since 2.6.29.1-46 my Intel i915 video card has been broken > > > > with Fedora. > > > > > > > > Once X starts the machine has basically crashed, switching vts > > > > gives me > > > > an epileptically fast cursor then the machine becomes > > > > unresponsive. > > > > > > > > Has anyone else had similar problems? > > > > > > > > nd > > > > > > > > p.s. https://bugzilla.redhat.com/show_bug.cgi?id=496335 > > > > > > > > The newer kernels and newer intel driver seem be work better without > > > > modesetting. > > > > > > > > Try nomodeset on the boot line. > > > > > > nomodeset did the trick. I can now boot and nothing crashes. > > > > > > Would be nice if modesetting worked though. > > > > Can you post the lspci output for your machine, and > > grab /var/log/Xorg.0.log when modesetting is enabled and X starts, and > > you experience the problem? > > > > Dan > > Have posted it on the bugzilla page. > > s-c-d is choosing the wrong driver (vesa instead of intel), and if I > have no xorg.conf I get vesa too. Correction: if I have no xorg.conf I now get intel. > > (Booting with nomodeset and manually setting the driver to intel works > though) > From awilliam at redhat.com Mon May 4 19:26:33 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 04 May 2009 12:26:33 -0700 Subject: Moblin 2 and Fedora In-Reply-To: <1241462009.8638.5.camel@localhost.localdomain> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <49844F3B.6060905@fedoraproject.org> <5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com> <20090131110644.1a80ddf5@infradead.org> <4984BC61.3040908@fedoraproject.org> <20090131153457.573762ab@infradead.org> <604aa7910902020825v23bc3687m1151596fa74cb8a5@mail.gmail.com> <20090202101002.4380c005@infradead.org> <1233598383.7493.42.camel@localhost.localdomain> <20090202113524.184e402c@infradead.org> <20090503160827.GA21833@srcf.ucam.org> <1241449115.2766.148.camel@atropine.boston.devel.redhat.com> <49FF0A69.8030609@fedoraproject.org> <1241462009.8638.5.camel@localhost.localdomain> Message-ID: <1241465193.2923.220.camel@adam.local.net> On Mon, 2009-05-04 at 14:33 -0400, Dan Williams wrote: > Yeah, how about Poulsbo support? Is anyone at Intel actually working on > upstreaming the unencumbered 2D parts of that, including the kernel bits > and the X driver? Random crack in gregkh's tree doesn't count. Well, on that topic, I notice a huge new pile of crack showed up in the Ubuntu Mobile special-sauce repositories on April 30, which appears to be the psb driver for Ubuntu 8.10. At least... http://ppa.launchpad.net/ubuntu-mobile/ubuntu/pool/main/x/xserver-xorg-video-psb/ http://ppa.launchpad.net/ubuntu-mobile/ubuntu/pool/main/x/xpsb-glx/ http://ppa.launchpad.net/ubuntu-mobile/ubuntu/pool/main/libd/libdrm-poulsbo/ http://ppa.launchpad.net/ubuntu-mobile/ubuntu/pool/main/p/psb-kernel-source/ http://ppa.launchpad.net/ubuntu-mobile/ubuntu/pool/main/p/psb-firmware/ http://ppa.launchpad.net/ubuntu-mobile/ubuntu/pool/main/p/psb-meta/ oh, so much crack. Why must there be so much crack?! so, yeah, it seems like at least one bit of Intel is still working on special sauce for Ubuntu (presumably at Dell's behest), not upstreaming. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From kevin.kofler at chello.at Mon May 4 19:36:08 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 04 May 2009 21:36:08 +0200 Subject: FESCo Meeting Summary for 20090424 References: <20090501233835.GA28723@srcf.ucam.org> <1241224653.2811.59.camel@adam.local.net> <20090502014029.GC1496739@hiwaay.net> <20090502014259.GA28052@angus.ind.WPI.EDU> <1241260456.20413.2098.camel@cookie.hadess.net> <1241285539.2923.19.camel@adam.local.net> <1241312345.20413.3851.camel@cookie.hadess.net> <1241315965.2923.33.camel@adam.local.net> <1241377258.21010.1050.camel@cookie.hadess.net> <1241379476.2923.77.camel@adam.local.net> <20090504125621.GA11402@tango.0pointer.de> Message-ID: Lennart Poettering wrote: > When used for surround sound the ALSA mixer knows channels such as > "Rear Front Left" and "Side Front Left". That is broken. It may seem broken for you, and the interface is certainly suboptimal, but it's better than not being able to control the surround balance at all. For users, the current interface WORKS. > Nah. using this is a misuse. You always should access SPDIF via the > 'iec985' device, which is what PA does. It will switch the appropriate > controls automatically and lock them and switch them back after use. > > The fact that these controls are available is an implementation detail > which should be and is hidden by PA. But until that works and is exposed in the relevant UIs, toggling the boolean switch WORKS. You can argue that the interface is crap, and I actually agree with you there, but not that it's not there (it is). Kevin Kofler From jwboyer at gmail.com Mon May 4 19:41:48 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 4 May 2009 15:41:48 -0400 Subject: Abandon "Default Desktop" In-Reply-To: <49FF3DA1.2050801@hi.is> References: <49FD51ED.7000906@alexhudson.com> <1241453613.3570.41.camel@localhost.localdomain> <49FF1F69.1090100@hi.is> <49FF23CA.3000103@gmail.com> <49FF2E09.1010607@hi.is> <1241461591.3570.51.camel@localhost.localdomain> <49FF3DA1.2050801@hi.is> Message-ID: <20090504194148.GA4683@yoda.jdub.homelinux.org> On Mon, May 04, 2009 at 07:10:25PM +0000, "J?hann B. Gu?mundsson" wrote: >> I don't think we can have that scenario. The Desktop sig creates the >> Desktop spin, and its that spin that the Fedora project puts forward as >> it's default spin. >> >> > Is the current Desktop SIG made up by representatives from each of the > *DE's which > then can make neutral informed decision what the current status is > amongst all the DE and thus choose > what should be Fedora ( next ) Desktop... > > Or > > Is the Desktop SIG governed by single DE oriented persons and or is made up > by majority of individual that work for the same company that can thus > influence the decision either directly or indirectly on what > is and will be Fedora's Desktop? Where are you going with this? Do you have some other DE that you would like to propose as the default? If not, discussing theoreticals is frankly a waste of time. josh From kevin.kofler at chello.at Mon May 4 19:44:22 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 04 May 2009 21:44:22 +0200 Subject: Abandon "Default Desktop" References: <49FD51ED.7000906@alexhudson.com> <1241453613.3570.41.camel@localhost.localdomain> Message-ID: Orcan Ogetbil wrote: > As Roberto stated previously in this thread, those who think that "the > user should have to choose" are more likely to be in the KDE camp. If > KDE were the default "Desktop spin" in Fedora, I don't think that KDE > people would oppose the idea of dropping the name "Desktop spin", or > offering other DE's during installation, for the sake of having > choices. Yeah, as one of those "KDE people", I wouldn't want the KDE spin to be called "Desktop spin" (not any more that I like the GNOME spin being called that way right now). Such a generic name doesn't say what the users actually get, which is bad both for the desktop being present on the spin and for users who want to know what they get. Plus, it misleads newcomers into thinking there's only one desktop, when there are actually 2 with comparable levels of popularity, and some lightweight options with growing user base (at least XFCE and LXDE, and some people would cite WM-only solutions there too). Kevin Kofler From kevin.kofler at chello.at Mon May 4 19:49:39 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 04 May 2009 21:49:39 +0200 Subject: Abandon "Default Desktop" References: <49FD51ED.7000906@alexhudson.com> <1241453613.3570.41.camel@localhost.localdomain> <49FF1F69.1090100@hi.is> <49FF23CA.3000103@gmail.com> <49FF2E09.1010607@hi.is> <1241461591.3570.51.camel@localhost.localdomain> <49FF3DA1.2050801@hi.is> Message-ID: "J?hann B. Gu?mundsson" wrote: > I'm suggesting that we have no default and no "Fedora Desktop" spin > ( Current Fedora-Desktop would be renamed to Fedora-Gnome to allow > all DE to compete among them self on equal ground ) Me too. > Is the current Desktop SIG made up by representatives from each of the > *DE's which > then can make neutral informed decision what the current status is > amongst all the DE and thus choose > what should be Fedora ( next ) Desktop... > > Or > > Is the Desktop SIG governed by single DE oriented persons and or is made > up by majority of individual that work for the same company that can thus > influence the decision either directly or indirectly on what > is and will be Fedora's Desktop? The latter, of course (and I'm sure you know that :-) ). And this is exactly the problem with the naming. The "Fedora Desktop team" is basically identical to the Red Hat Desktop Team which is really a GNOME team, not a desktop team. How Red Hat calls their departments is their own business, but their internal naming should not leak into the names of released products/projects/spins/whatever. Just because it's produced by a team calling itself the "Desktop Team" doesn't make it the "desktop spin". Kevin Kofler From arjan at infradead.org Mon May 4 19:52:51 2009 From: arjan at infradead.org (Arjan van de Ven) Date: Mon, 4 May 2009 12:52:51 -0700 Subject: Moblin 2 and Fedora In-Reply-To: <1241462009.8638.5.camel@localhost.localdomain> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <49844F3B.6060905@fedoraproject.org> <5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com> <20090131110644.1a80ddf5@infradead.org> <4984BC61.3040908@fedoraproject.org> <20090131153457.573762ab@infradead.org> <604aa7910902020825v23bc3687m1151596fa74cb8a5@mail.gmail.com> <20090202101002.4380c005@infradead.org> <1233598383.7493.42.camel@localhost.localdomain> <20090202113524.184e402c@infradead.org> <20090503160827.GA21833@srcf.ucam.org> <1241449115.2766.148.camel@atropine.boston.devel.redhat.com> <49FF0A69.8030609@fedoraproject.org> <1241462009.8638.5.camel@localhost.localdomain> Message-ID: <20090504125251.41e491a6@infradead.org> On Mon, 04 May 2009 14:33:28 -0400 Dan Williams wrote: > On Mon, 2009-05-04 at 21:01 +0530, Rahul Sundaram wrote: > > On 05/04/2009 08:28 PM, Adam Jackson wrote: > > > > > > > > Just to underline this point, let's look at what the Moblin FAQ > > > has to say on the subject: > > > > > > Q Is Moblin v2.0 based on another distribution? > > > Moblin v2.0 borrows components from various > > > distributions, but is not based on another distribution. > > > > > > [ source: > > > http://moblin.org/documentation/moblin-overview/faq ] > > > > > > This seems... disingenuous? I guess it all depends on what the > > > definition of the word "based" is. It's also the sort of > > > statement that begs immediate deconstruction. If moblin _isn't_ > > > based on another distribution, why does it feel the need to say > > > so. On the other hand, if it is, why does it say it isn't. > > > > I don't see us accomplishing much by stating the obvious, which is > > that Moblin is indeed based on Fedora even if Intel does not want to > > acknowledge that for whatever reasons. Considering that they seem to > > have moved it over to Linux Foundation, it all might just be > > political considerations. Let's move beyond that. > > > > Now, is there useful patches that we need to push upstream? Are > > there additional packages, we can import into Fedora? Let's look at > > that list. We know of sreadahead. Has the kernel portion been > > upstreamed? Arjan pointed out memuse in > > http://lwn.net/Articles/331423/. What's the rest? > > Yeah, how about Poulsbo support? Is anyone at Intel actually working > on upstreaming the unencumbered 2D parts of that, including the > kernel bits and the X driver? Random crack in gregkh's tree doesn't > count. > it's not very useful if the various upstream maintainers say that they won't accept it no matter what... at that point... yes people stop working on it. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org From kevin.kofler at chello.at Mon May 4 19:56:06 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 04 May 2009 21:56:06 +0200 Subject: Abandon "Default Desktop" References: <49FD51ED.7000906@alexhudson.com> <1241453613.3570.41.camel@localhost.localdomain> Message-ID: Jesse Keating wrote: > On Mon, 2009-05-04 at 09:04 +0200, Kevin Kofler wrote: >> (except that you get Firefox as your browser if you choose GNOME, whereas >> the official default browser of GNOME is Epiphany). > > This is one of the reasons why it's not the Gnome spin, it's the Fedora > Desktop spin. I don't see this as a good reason not to call it the GNOME spin. It's still GNOME, even if you replaced one application. Many distributions install Firefox by default if you select GNOME. That said, one wild suggestion: why don't we kick out Firefox entirely? Their outrageous trademark policies (every single patch needs to be approved by upstream) make the Firefox stack the *only* packages not qualifying for provenpackager access, which is an impediment to Fedora's development. Additionally, their artwork has a non-Free copyright license according to the Debian folks who audited it. (And upstream's claim that this is a requirement for a trademarked logo is just plain wrong, e.g. all the official renditions of KDE's gear trademark are under the LGPL.) My suggestion: ship Epiphany on the GNOME spin, and then either have a rebranded Firefox (Iceweasel or whatever) in the repo or no Firefox at all. > If somebody wanted to make a GNOME spin that highlighted the best of the > GNOME world and GNOME only, they could. Realistically speaking, nobody is going to produce a spin just to replace 1 application (or maybe 2 if you suggest replacing Pidgin with Empathy too, but that's where the "Desktop" spin is headed towards anyway). This is a bogus argument. Kevin Kofler From kevin.kofler at chello.at Mon May 4 19:59:12 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 04 May 2009 21:59:12 +0200 Subject: Packaging python bits with setuptools that depend on non-distutil packages References: Message-ID: loupgaroublond at gmail.com wrote: > To make a short story long, i'm sure there are ways to include code > snippets in dbus, rpm, and possibly other packages that also generate egg > info. This would at least let me declare those packages as dependencies. > The bigger issue i have though, is how can i import them in some generic > fashion into virtualenv? The Fedora way is to use mock to create your chroot. RPM is the package management tool around here, not python-distutils. Kevin Kofler From notting at redhat.com Mon May 4 20:01:48 2009 From: notting at redhat.com (Bill Nottingham) Date: Mon, 4 May 2009 16:01:48 -0400 Subject: Fedora Release Engineering Meeting Recap - 2009-05-04 Message-ID: <20090504200148.GB3699@nostromo.devel.redhat.com> == Preview Release == Known issues: * PPC had a variety of issues o oversized o installed the wrong kernel o failed to install a bootloader * assorted anaconda partitioning issues Discussed maybe using a separate config for PPC to keep it under size constraints, but it was decided to stay with one config. == Deltarpm for F11 == Work needs done to either compose updates in a chroot (which has the F11 deltarpm support) or to backport it to the OS release used to generate updates. Seth Vidal is going to investigate which of these makes more sense. Given the timeframe, this is tight for F11 final. rawhide will continue to have deltas, as that's a separate compose process. == F12 schedule == The schedule proposed by John Poelstra for Fedora 12 in https://fedorahosted.org/rel-eng/ticket/1271 was reviewed. The following changes were approved: * the alpha milestone was removed entirely * due to conferences such as the Red Hat Summit, LinuxCon, and Linux Plumber's Conference, each milestone from 'Final freeze: development' (2009-09-15) should be shifted out one week. This pushes GA from 2009-10-27 to 2009-11-03. The schedule will be presented for FESCo discussion at the 2009-05-08 meeting. For more information on any of these, see the full transcript at: https://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2009-may-04 From mzerqung at 0pointer.de Mon May 4 20:21:56 2009 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Mon, 4 May 2009 22:21:56 +0200 Subject: FESCo Meeting Summary for 20090424 In-Reply-To: References: <20090502014029.GC1496739@hiwaay.net> <20090502014259.GA28052@angus.ind.WPI.EDU> <1241260456.20413.2098.camel@cookie.hadess.net> <1241285539.2923.19.camel@adam.local.net> <1241312345.20413.3851.camel@cookie.hadess.net> <1241315965.2923.33.camel@adam.local.net> <1241377258.21010.1050.camel@cookie.hadess.net> <1241379476.2923.77.camel@adam.local.net> <20090504125621.GA11402@tango.0pointer.de> Message-ID: <20090504202156.GA13575@tango.0pointer.de> On Mon, 04.05.09 21:36, Kevin Kofler (kevin.kofler at chello.at) wrote: > > Lennart Poettering wrote: > > When used for surround sound the ALSA mixer knows channels such as > > "Rear Front Left" and "Side Front Left". That is broken. > > It may seem broken for you, and the interface is certainly suboptimal, but > it's better than not being able to control the surround balance at all. For > users, the current interface WORKS. Only if in your vocabulary "works" means "I know all bugs and can work around them". Otherwise surround mixing in ALSA does not qualify as "works" I would say. > > The fact that these controls are available is an implementation detail > > which should be and is hidden by PA. > > But until that works and is exposed in the relevant UIs, toggling the > boolean switch WORKS. That may work because you are lucky. Controlling digital out via the manually fiddling with the direct mixer controls is not how things are supposed to work in ALSA. You are supposed to use "iec958" as device string when doing SPDIF. Doing it by directly controlling the mixer like you can do on some cards always has been a dirty hack (an uncessary one even!) and hence the fact that this is now hidden should not be considered a regression in any way. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From robert at marcanoonline.com Mon May 4 20:25:28 2009 From: robert at marcanoonline.com (Robert Marcano) Date: Mon, 04 May 2009 15:55:28 -0430 Subject: Multiple repositories or multiple subdirectories Message-ID: <1241468728.3748.16.camel@localhost.localdomain> I have local mirrors of the Fedora repositories to serve the internal requirements without downloading each update for every machine. We do not install games nor KDE applications, but everytime there is an update for those packages the network is used. There are solutions like SpaceWalk for the updates problem, but at the same time we need to have some packages available to install if needed, not only updates. Another options is to use an intelligent mirror that check package groups and download only the groups you are interested from the mirror, but that adds another complexity over the standard mirror tool that is rsync Maybe creating a repository layout like repodata base x gnome kde development ... could make easy for mirrors to tell rsync to ignore some directories. createrepo already support a nested structure, What do you think about that?. From kevin.kofler at chello.at Mon May 4 20:30:23 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 04 May 2009 22:30:23 +0200 Subject: Abandon "Default Desktop" References: <49FD51ED.7000906@alexhudson.com> <1241453613.3570.41.camel@localhost.localdomain> <49FF1F69.1090100@hi.is> <49FF23CA.3000103@gmail.com> <49FF2E09.1010607@hi.is> <1241461591.3570.51.camel@localhost.localdomain> <49FF3DA1.2050801@hi.is> <20090504194148.GA4683@yoda.jdub.homelinux.org> Message-ID: Josh Boyer wrote: > Where are you going with this? Do you have some other DE that you would > like to propose as the default? "some other DE" == KDE, obviously. Did you really have to ask? And no, J?hann isn't asking for KDE to be *the* default, and neither am I. We're asking for there not to be one default in the first place, but a choice between 2 equally-placed desktops (matching their respective popularity), and (why not?) an easy access to the emerging options (XFCE, LXDE) which are currently entirely hidden, you need to go to spins.fp.o to even see them. Kevin Kofler From awilliam at redhat.com Mon May 4 20:34:16 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 04 May 2009 13:34:16 -0700 Subject: Moblin 2 and Fedora In-Reply-To: <20090504125251.41e491a6@infradead.org> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <49844F3B.6060905@fedoraproject.org> <5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com> <20090131110644.1a80ddf5@infradead.org> <4984BC61.3040908@fedoraproject.org> <20090131153457.573762ab@infradead.org> <604aa7910902020825v23bc3687m1151596fa74cb8a5@mail.gmail.com> <20090202101002.4380c005@infradead.org> <1233598383.7493.42.camel@localhost.localdomain> <20090202113524.184e402c@infradead.org> <20090503160827.GA21833@srcf.ucam.org> <1241449115.2766.148.camel@atropine.boston.devel.redhat.com> <49FF0A69.8030609@fedoraproject.org> <1241462009.8638.5.camel@localhost.localdomain> <20090504125251.41e491a6@infradead.org> Message-ID: <1241469256.2923.273.camel@adam.local.net> On Mon, 2009-05-04 at 12:52 -0700, Arjan van de Ven wrote: > it's not very useful if the various upstream maintainers say that they > won't accept it no matter what... at that point... yes people stop > working on it. I haven't seen anywhere where that's been said. On the kernel/drm side of things, the LKML discussion resulted in some questions about the large amount of proprietary code the changes seemed to depend on, but no definitive Yes or No was reached: Greg decided himself to change approach and try to come up with a basic 2D-only driver which would not depend on any proprietary code, then propose whatever kernel elements would be needed for that instead. AFAIK he is still working on that. To my knowledge there hasn't been any kind of proposal of any Poulsbo-related code to X.org. (and since Greg is working off his own bat on this - obviously not representing Intel, Canonical or Dell, or even Novell - there's been a sum total of zero attempts to upstream any Poulsbo-related code from anyone who's being paid by anyone to work on it...) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From rdieter at math.unl.edu Mon May 4 20:36:37 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 04 May 2009 15:36:37 -0500 Subject: Multiple repositories or multiple subdirectories References: <1241468728.3748.16.camel@localhost.localdomain> Message-ID: Robert Marcano wrote: mirror tool that is rsync > > Maybe creating a repository layout like ... > could make easy for mirrors to tell rsync to ignore some directories. > createrepo already support a nested structure, What do you think about > that?. If space is a concern, have you considered simply using a caching proxy? -- Rex From kevin.kofler at chello.at Mon May 4 20:35:01 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 04 May 2009 22:35:01 +0200 Subject: Multiple repositories or multiple subdirectories References: <1241468728.3748.16.camel@localhost.localdomain> Message-ID: Robert Marcano wrote: > Maybe creating a repository layout like > > repodata > base > x > gnome > kde > development > ... > > could make easy for mirrors to tell rsync to ignore some directories. > createrepo already support a nested structure, What do you think about > that?. The problem is that those subsets are not a coverage of the entire repository: they are neither disjunct nor does their union cover the entire set. Or in less mathematical terms: 1. those categories overlap and 2. they are not exhaustive, i.e. there are packages which do not fall into any of those categories. Kevin Kofler From jkeating at redhat.com Mon May 4 20:40:23 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 04 May 2009 13:40:23 -0700 Subject: Multiple repositories or multiple subdirectories In-Reply-To: References: <1241468728.3748.16.camel@localhost.localdomain> Message-ID: <1241469623.3570.54.camel@localhost.localdomain> On Mon, 2009-05-04 at 15:36 -0500, Rex Dieter wrote: > If space is a concern, have you considered simply using a caching > proxy? Or use something like reposync to get what you want instead of straight rsync. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From robert at marcanoonline.com Mon May 4 20:43:13 2009 From: robert at marcanoonline.com (Robert Marcano) Date: Mon, 04 May 2009 16:13:13 -0430 Subject: Multiple repositories or multiple subdirectories In-Reply-To: References: <1241468728.3748.16.camel@localhost.localdomain> Message-ID: <1241469793.3748.21.camel@localhost.localdomain> On Mon, 2009-05-04 at 15:36 -0500, Rex Dieter wrote: > Robert Marcano wrote: > > mirror tool that is rsync > > > > Maybe creating a repository layout like > ... > > could make easy for mirrors to tell rsync to ignore some directories. > > createrepo already support a nested structure, What do you think about > > that?. > > If space is a concern, have you considered simply using a caching proxy? space is not a concern, network usage is. Yes, but still it is a problem to make available for installation (not only updates) groups of packages when network connection is not fast enough (a common problem in my country, and I think in others too), It is easier to setup rsync at night time, and leave the little bandwidth available for daily operations > > -- Rex > > > From awilliam at redhat.com Mon May 4 22:26:23 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 04 May 2009 15:26:23 -0700 Subject: mixers up for review In-Reply-To: <1241378502.3062.3.camel@localhost.localdomain> References: <1241378502.3062.3.camel@localhost.localdomain> Message-ID: <1241475983.2923.276.camel@adam.local.net> On Sun, 2009-05-03 at 15:21 -0400, Matthias Clasen wrote: > Sorry to interrupt, but there are now two graphical mixer applications > up for review: > > https://bugzilla.redhat.com/show_bug.cgi?id=497593 > https://bugzilla.redhat.com/show_bug.cgi?id=498136 > > Maybe the people who shouted the loudest about the desktop teams crimes > against humanity could take some time off their busy flame-writing > schedule to review one of those ? The review of gst-mixer is now complete, and I submitted builds for devel (F-12) and F-11. I have filed a ticket with rel-eng requesting that the F-11 build be pushed through the freeze and into the F-11 repositories: https://fedorahosted.org/rel-eng/ticket/1727 -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From awilliam at redhat.com Mon May 4 22:45:53 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 04 May 2009 15:45:53 -0700 Subject: mixers up for review In-Reply-To: <1241475983.2923.276.camel@adam.local.net> References: <1241378502.3062.3.camel@localhost.localdomain> <1241475983.2923.276.camel@adam.local.net> Message-ID: <1241477153.2923.279.camel@adam.local.net> On Mon, 2009-05-04 at 15:26 -0700, Adam Williamson wrote: > On Sun, 2009-05-03 at 15:21 -0400, Matthias Clasen wrote: > > Sorry to interrupt, but there are now two graphical mixer applications > > up for review: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=497593 > > https://bugzilla.redhat.com/show_bug.cgi?id=498136 > > > > Maybe the people who shouted the loudest about the desktop teams crimes > > against humanity could take some time off their busy flame-writing > > schedule to review one of those ? > > The review of gst-mixer is now complete, and I submitted builds for > devel (F-12) and F-11. I have filed a ticket with rel-eng requesting > that the F-11 build be pushed through the freeze and into the F-11 > repositories: > > https://fedorahosted.org/rel-eng/ticket/1727 I should have mentioned - you can grab the F-11 build out of Koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=1335932 please anyone, if you can, do so and verify that it works for you as it did in Fedora 10. thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From seg at haxxed.com Mon May 4 22:46:31 2009 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 04 May 2009 17:46:31 -0500 Subject: Abandon "Default Desktop" In-Reply-To: References: <49FD51ED.7000906@alexhudson.com> <1241453613.3570.41.camel@localhost.localdomain> Message-ID: <1241477191.6639.0.camel@localhost.localdomain> On Mon, 2009-05-04 at 14:31 -0400, Orcan Ogetbil wrote: > A person already makes a choice (a very big and "radical" one) when he > decides to use Linux. A second choice is made by deciding on Fedora. > Why should we enforce that these were the last choices he makes? http://www.joelonsoftware.com/uibook/chapters/fog0000000059.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Mon May 4 23:14:24 2009 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 04 May 2009 18:14:24 -0500 Subject: The Great Pulseaudio Mixer Debate: a modest (productive) proposal In-Reply-To: <1241430099.6126.42.camel@macbook.infradead.org> References: <1240596206.3955.245.camel@adam.local.net> <200904251714.07573.billcrawford1970@gmail.com> <6d959d480904250934h1fb12465ue60b55866d4a188c@mail.gmail.com> <200904271329.04618.billcrawford1970@gmail.com> <49F5E241.2030603@cchtml.com> <1240964482.2656.8.camel@localhost.localdomain> <49F85255.3090708@hidayahonline.org> <1241373392.2632.65.camel@localhost.localdomain> <1241430099.6126.42.camel@macbook.infradead.org> Message-ID: <1241478864.6639.9.camel@localhost.localdomain> On Mon, 2009-05-04 at 10:41 +0100, David Woodhouse wrote: > On Sun, 2009-05-03 at 12:56 -0500, Callum Lerwick wrote: > > Hrm, pulseaudio's logging seems to have changed. You can try running > > "pulseaudio -k;pulseaudio -v" then dig through the spew: > > After I do this, my volume control applet in the panel (actually, for > some bizarre reason it's now in the notification area, rather than in > the place in the panel where I explicitly placed it in F-10) no longer > works. Ummm, yeah. Killing pulseaudio makes the panel applet unhappy. It seems the crash recovery needs some work. You have to restart the applet too. It's nice that gnome-session doesn't seem to do auto-restart anymore... I suppose "paman" is a less destructive way of getting the info, but killing and restarting the daemon seemed easier to explain... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From oget.fedora at gmail.com Tue May 5 00:00:49 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Mon, 4 May 2009 20:00:49 -0400 Subject: Abandon "Default Desktop" In-Reply-To: <1241477191.6639.0.camel@localhost.localdomain> References: <49FD51ED.7000906@alexhudson.com> <1241453613.3570.41.camel@localhost.localdomain> <1241477191.6639.0.camel@localhost.localdomain> Message-ID: On Mon, May 4, 2009 at 6:46 PM, Callum Lerwick wrote: > On Mon, 2009-05-04 at 14:31 -0400, Orcan Ogetbil wrote: >> A person already makes a choice (a very big and "radical" one) when he >> decides to use Linux. A second choice is made by deciding on Fedora. >> Why should we enforce that these were the last choices he makes? > > http://www.joelonsoftware.com/uibook/chapters/fog0000000059.html > Nope, that text doesn't have any scientific value. It contains variations of "Nobody cares", "Nobody wants..." without backup. I neither have met this Nobody person, nor do I care what he wants more than I care for any other user in the pool. In fact, I know more people who care about certain design choices than who don't. Moreover, the text tends to confuse bad design with customizability (although it tries hard not to). Try again. Orcan From jwboyer at gmail.com Tue May 5 00:05:07 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 4 May 2009 20:05:07 -0400 Subject: Abandon "Default Desktop" In-Reply-To: References: <49FD51ED.7000906@alexhudson.com> <1241453613.3570.41.camel@localhost.localdomain> <49FF1F69.1090100@hi.is> <49FF23CA.3000103@gmail.com> <49FF2E09.1010607@hi.is> <1241461591.3570.51.camel@localhost.localdomain> <49FF3DA1.2050801@hi.is> <20090504194148.GA4683@yoda.jdub.homelinux.org> Message-ID: <20090505000507.GA22259@hansolo.jdub.homelinux.org> On Mon, May 04, 2009 at 10:30:23PM +0200, Kevin Kofler wrote: >Josh Boyer wrote: >> Where are you going with this? Do you have some other DE that you would >> like to propose as the default? > >"some other DE" == KDE, obviously. Did you really have to ask? I was simply using the same terms that we being used. I like to be clear, so yes I needed to ask. >And no, J?hann isn't asking for KDE to be *the* default, and neither am I. >We're asking for there not to be one default in the first place, but a >choice between 2 equally-placed desktops (matching their respective >popularity), and (why not?) an easy access to the emerging options (XFCE, >LXDE) which are currently entirely hidden, you need to go to spins.fp.o to >even see them. Can you take this, write up a more specific proposal, and either send it here or to FESCo? I don't want to guess on what you mean by "equally-placed" or "easy" because personally I already think things are placed evenly and easily accessed. The only difference IMO is that KDE is actually called KDE. josh From bruno at wolff.to Tue May 5 00:36:18 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 4 May 2009 19:36:18 -0500 Subject: I wanted to open a discussion for F12 about running services on shell accounts. In-Reply-To: <49FEF9DA.8060300@redhat.com> References: <49FB07B0.50100@redhat.com> <20090501213437.GA20032@wolff.to> <49FEF9DA.8060300@redhat.com> Message-ID: <20090505003617.GA28538@wolff.to> On Mon, May 04, 2009 at 10:21:14 -0400, Daniel J Walsh wrote: >> > The suggesting here is to use dbus to start applications in terminal > shell as the same user UID, not to have the system dbus start the app. > So I fail to see how this affects auditing. The goal here is to run > restorecond as my UID. Not Root. Adding some module to pam does not > help the multiple restorecond programs running, problem. And I still > have the problem of cleaning up in the pam stack on exit. I don't think you understand what my comcern is. It may be that it isn't a big enough risk that its worth worrying about. But I'll try to describe it better. The user has some files in is home directory label say special_t that are not writeable by processes except for a few given processes. There are some processes which read these files (but not ones labelled user_home_t) and do things where one would be concerned if bad data was in these files. These files' names are known to selinux for relabelling purposes. Some app is run by the user. This app then removes files labelled special_t and creates new ones with the same names labelled user_home_t as normal. The daemon process then relabels these files to special_t and bad things proceed to happen. From seg at haxxed.com Tue May 5 00:39:51 2009 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 04 May 2009 19:39:51 -0500 Subject: GConf changes in F12 In-Reply-To: <1240988317.4309.15.camel@moose> References: <1240942944.2770.8.camel@localhost.localdomain> <1240962427.2770.12.camel@localhost.localdomain> <1240988317.4309.15.camel@moose> Message-ID: <1241483991.6639.64.camel@localhost.localdomain> On Wed, 2009-04-29 at 16:58 +1000, Rodd Clarkson wrote: > On Tue, 2009-04-28 at 19:47 -0400, Matthias Clasen wrote: > > On Wed, 2009-04-29 at 01:11 +0200, Kevin Kofler wrote: > > > Matthias Clasen wrote: > > > > Previously, translations were merged by intltool from .po files into > > > > schemas files and then copied by gconftool from the schemas file into > > > > the database. > > > > > > Is that what caused the insanely-sized .xml files in libgweather? Or is that > > > a separate issue? > > > > No, the xml files in libgweather are just big on their own, no GConf > > involved. > > I'm guessing this has to do with all the international data in > libgweather. No, it's due to immense amounts of redundant data, (all the data is duplicated for *every* language, none of it is shared) and quite a bit of XML overhead. > Is it possible to build this (like we do for openoffice.org with it's > language packs) so that you only grab the locations you need? And > assuming your interested in the weather in some location your not, could > you automate the downloading of the location required? Since it requires a net connection to get the weather information *anyway*, this would not be unreasonable. Still, as I pointed out before, lzma compressing the 76mb of data brings it down to 1.5mb. It's read-only data, there is simply no reason for it to be any bigger than that. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Tue May 5 00:41:54 2009 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 04 May 2009 19:41:54 -0500 Subject: Abandon "Default Desktop" In-Reply-To: References: <49FD51ED.7000906@alexhudson.com> <1241453613.3570.41.camel@localhost.localdomain> <1241477191.6639.0.camel@localhost.localdomain> Message-ID: <1241484114.6639.65.camel@localhost.localdomain> On Mon, 2009-05-04 at 20:00 -0400, Orcan Ogetbil wrote: > On Mon, May 4, 2009 at 6:46 PM, Callum Lerwick wrote: > > On Mon, 2009-05-04 at 14:31 -0400, Orcan Ogetbil wrote: > >> A person already makes a choice (a very big and "radical" one) when he > >> decides to use Linux. A second choice is made by deciding on Fedora. > >> Why should we enforce that these were the last choices he makes? > > > > http://www.joelonsoftware.com/uibook/chapters/fog0000000059.html > > > > Nope, that text doesn't have any scientific value. It contains > variations of "Nobody cares", "Nobody wants..." without backup. I > neither have met this Nobody person, nor do I care what he wants more > than I care for any other user in the pool. In fact, I know more > people who care about certain design choices than who don't. Moreover, > the text tends to confuse bad design with customizability (although it > tries hard not to). I'm sure you have scientific studies showing people love playing 20 questions to get anything done, right? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From oget.fedora at gmail.com Tue May 5 01:00:13 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Mon, 4 May 2009 21:00:13 -0400 Subject: Abandon "Default Desktop" In-Reply-To: <1241484114.6639.65.camel@localhost.localdomain> References: <49FD51ED.7000906@alexhudson.com> <1241453613.3570.41.camel@localhost.localdomain> <1241477191.6639.0.camel@localhost.localdomain> <1241484114.6639.65.camel@localhost.localdomain> Message-ID: On Mon, May 4, 2009 at 8:41 PM, Callum Lerwick wrote: > On Mon, 2009-05-04 at 20:00 -0400, Orcan Ogetbil wrote: >> On Mon, May 4, 2009 at 6:46 PM, Callum Lerwick wrote: >> > On Mon, 2009-05-04 at 14:31 -0400, Orcan Ogetbil wrote: >> >> A person already makes a choice (a very big and "radical" one) when he >> >> decides to use Linux. A second choice is made by deciding on Fedora. >> >> Why should we enforce that these were the last choices he makes? >> > >> > http://www.joelonsoftware.com/uibook/chapters/fog0000000059.html >> > >> >> Nope, that text doesn't have any scientific value. It contains >> variations of "Nobody cares", "Nobody wants..." without backup. I >> neither have met this Nobody person, nor do I care what he wants more >> than I care for any other user in the pool. In fact, I know more >> people who care about certain design choices than who don't. Moreover, >> the text tends to confuse bad design with customizability (although it >> tries hard not to). > > I'm sure you have scientific studies showing people love playing 20 > questions to get anything done, right? > No, I particularly like having choices. Whenever I am getting furniture or some kitchen appliance, I go to the store and make my selection according to my taste. I find it important the way my furniture looks. Also I make sure that my kitchen appliance have the capabilities that I am interested. And I know quite a lot of people who do it the same way. In fact, very few houses I have seen have identical furniture and kitchen appliances. The reason for this is people have made decisions among multiple choices. You may want to grab the first microwave oven you see and get out of the store, but believe me, most people are not like you. If you don't believe me, look out of your window. You might see different brands of cars. I think that would be a proof that is "scientific enough". Have a choice :) Orcan From loupgaroublond at gmail.com Tue May 5 01:32:17 2009 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Mon, 4 May 2009 21:32:17 -0400 (EDT) Subject: Packaging python bits with setuptools that depend on non-distutil packages In-Reply-To: Message-ID: 2009/5/4 Kevin Kofler : > loupgaroublond at gmail.com wrote: >> To make a short story long, i'm sure there are ways to include code >> snippets in dbus, rpm, and possibly other packages that also generate egg >> info. This would at least let me declare those packages as dependencies. >> The bigger issue i have though, is how can i import them in some generic >> fashion into virtualenv? > > The Fedora way is to use mock to create your chroot. RPM is the package > management tool around here, not python-distutils. With python that's not entirely the case. If you're using mock to create such an environment to do development work, you're essentially going to have to copy your source code into mock, do your development from inside mock and then copy the good results out of mock when you're done. The difference between using mock and virtualenv is that one creates a new chroot to do certain kinds of automated work in, and the other creates a virtual environment in place on top of your current file system. The advantages of this is that you can ask setuptools to include your development directory in the current working environment. You can do your development on your development tree, and have any changes you make show up live in your environment. With a compiled language it's not obvious why you want to do this, but in a 'interpreted' language like python, the benefits are easy to see. I could rig together something similar on top of mock that is transparent to the user, but why bother? -Yaakov -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 270 bytes Desc: OpenPGP digital signature URL: From naheemzaffar at gmail.com Tue May 5 01:48:21 2009 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Tue, 5 May 2009 02:48:21 +0100 Subject: Abandon "Default Desktop" In-Reply-To: References: <1241453613.3570.41.camel@localhost.localdomain> <1241477191.6639.0.camel@localhost.localdomain> <1241484114.6639.65.camel@localhost.localdomain> Message-ID: <3adc77210905041848s3b377abeoe3f61ad0e0f7e20a@mail.gmail.com> 2009/5/5 Orcan Ogetbil > No, I particularly like having choices. Whenever I am getting > furniture or some kitchen appliance, I go to the store and make my > selection according to my taste. > And how about being forced to make a choice between different pieces of furniture that you have no clue about based on, say, a one line description before you are allowed to walk in through the door to see them? Would that also be appreciated? -------------- next part -------------- An HTML attachment was scrubbed... URL: From airlied at redhat.com Tue May 5 02:10:29 2009 From: airlied at redhat.com (Dave Airlie) Date: Tue, 05 May 2009 12:10:29 +1000 Subject: Moblin 2 and Fedora In-Reply-To: <20090504125251.41e491a6@infradead.org> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <49844F3B.6060905@fedoraproject.org> <5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com> <20090131110644.1a80ddf5@infradead.org> <4984BC61.3040908@fedoraproject.org> <20090131153457.573762ab@infradead.org> <604aa7910902020825v23bc3687m1151596fa74cb8a5@mail.gmail.com> <20090202101002.4380c005@infradead.org> <1233598383.7493.42.camel@localhost.localdomain> <20090202113524.184e402c@infradead.org> <20090503160827.GA21833@srcf.ucam.org> <1241449115.2766.148.camel@atropine.boston.devel.redhat.com> <49FF0A69.8030609@fedoraproject.org> <1241462009.8638.5.camel@localhost.localdomain> <20090504125251.41e491a6@infradead.org> Message-ID: <1241489429.10737.3.camel@clockmaker.usersys.redhat.com> On Mon, 2009-05-04 at 12:52 -0700, Arjan van de Ven wrote: > On Mon, 04 May 2009 14:33:28 -0400 > Dan Williams wrote: > > > On Mon, 2009-05-04 at 21:01 +0530, Rahul Sundaram wrote: > > > On 05/04/2009 08:28 PM, Adam Jackson wrote: > > > > > > > > > > > Just to underline this point, let's look at what the Moblin FAQ > > > > has to say on the subject: > > > > > > > > Q Is Moblin v2.0 based on another distribution? > > > > Moblin v2.0 borrows components from various > > > > distributions, but is not based on another distribution. > > > > > > > > [ source: > > > > http://moblin.org/documentation/moblin-overview/faq ] > > > > > > > > This seems... disingenuous? I guess it all depends on what the > > > > definition of the word "based" is. It's also the sort of > > > > statement that begs immediate deconstruction. If moblin _isn't_ > > > > based on another distribution, why does it feel the need to say > > > > so. On the other hand, if it is, why does it say it isn't. > > > > > > I don't see us accomplishing much by stating the obvious, which is > > > that Moblin is indeed based on Fedora even if Intel does not want to > > > acknowledge that for whatever reasons. Considering that they seem to > > > have moved it over to Linux Foundation, it all might just be > > > political considerations. Let's move beyond that. > > > > > > Now, is there useful patches that we need to push upstream? Are > > > there additional packages, we can import into Fedora? Let's look at > > > that list. We know of sreadahead. Has the kernel portion been > > > upstreamed? Arjan pointed out memuse in > > > http://lwn.net/Articles/331423/. What's the rest? > > > > Yeah, how about Poulsbo support? Is anyone at Intel actually working > > on upstreaming the unencumbered 2D parts of that, including the > > kernel bits and the X driver? Random crack in gregkh's tree doesn't > > count. > > > > it's not very useful if the various upstream maintainers say that they > won't accept it no matter what... at that point... yes people stop > working on it. http://marc.info/?l=linux-kernel&m=113378006232564&w=2 You've come a long way :) Dave. From seg at haxxed.com Tue May 5 02:27:39 2009 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 04 May 2009 21:27:39 -0500 Subject: Abandon "Default Desktop" In-Reply-To: References: <49FD51ED.7000906@alexhudson.com> <1241453613.3570.41.camel@localhost.localdomain> <1241477191.6639.0.camel@localhost.localdomain> <1241484114.6639.65.camel@localhost.localdomain> Message-ID: <1241490459.6639.115.camel@localhost.localdomain> On Mon, 2009-05-04 at 21:00 -0400, Orcan Ogetbil wrote: > On Mon, May 4, 2009 at 8:41 PM, Callum Lerwick wrote: > > On Mon, 2009-05-04 at 20:00 -0400, Orcan Ogetbil wrote: > >> On Mon, May 4, 2009 at 6:46 PM, Callum Lerwick wrote: > >> > On Mon, 2009-05-04 at 14:31 -0400, Orcan Ogetbil wrote: > >> >> A person already makes a choice (a very big and "radical" one) when he > >> >> decides to use Linux. A second choice is made by deciding on Fedora. > >> >> Why should we enforce that these were the last choices he makes? > >> > > >> > http://www.joelonsoftware.com/uibook/chapters/fog0000000059.html > >> > > >> > >> Nope, that text doesn't have any scientific value. It contains > >> variations of "Nobody cares", "Nobody wants..." without backup. I > >> neither have met this Nobody person, nor do I care what he wants more > >> than I care for any other user in the pool. In fact, I know more > >> people who care about certain design choices than who don't. Moreover, > >> the text tends to confuse bad design with customizability (although it > >> tries hard not to). > > > > I'm sure you have scientific studies showing people love playing 20 > > questions to get anything done, right? > > > > No, I particularly like having choices. Whenever I am getting > furniture or some kitchen appliance, I go to the store and make my > selection according to my taste. I find it important the way my > furniture looks. Also I make sure that my kitchen appliance have the > capabilities that I am interested. And if you actually read the essay, it's not against choice. It's about being very careful and responsible in what you force the user to choose. Choice for the sake of choice is not desirable. > And I know quite a lot of people who do it the same way. In fact, very > few houses I have seen have identical furniture and kitchen > appliances. The reason for this is people have made decisions among > multiple choices. > You may want to grab the first microwave oven you > see and get out of the store, but believe me, most people are not like > you. I doubt that most people *want* to spend hours obsessing over what microwave to buy. I note that all your examples pertain purely to aesthetics. Yes, *that* is one thing average people care about. They want things to look unique, and personal. They *do not* care about underlying mechanics. > If you don't believe me, look out of your window. You might see > different brands of cars. I think that would be a proof that is > "scientific enough". And when most people jump in their car, they don't want to spend hours selecting ignition timings and suspension settings and transmission tunings and the gender and accent of the navigation system's voice before they can start the car. Those who want to do so are free to buy a BMW with iDrive. Those people, dare I say it, are not in the majority. > Have a choice :) No one's taking any choices away. Having choices available is something completely different from *forcing* users to *make* choices they do not understand or care about. A non-technical user who just wants a platform to run Firefox and email photos to grandma does not want to play 20 questions about this "desktop environment" thing they've never heard of before they can do so. And as KDE itself has embraced this mistaken philosophy of "choice is always desirable", why would we ever want to inflict it on non-technical users? People who want to play 20-questions already know where to find KDE. Devo said it best: "Freedom of choice is what you've got, freedom from choice is what you want." http://www.dailymotion.com/video/x1ymz7_devo-freedom-of-choice_music -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From wm161 at wm161.net Tue May 5 03:15:20 2009 From: wm161 at wm161.net (Trever Fischer) Date: Mon, 4 May 2009 23:15:20 -0400 Subject: Abandon "Default Desktop" In-Reply-To: <1241490459.6639.115.camel@localhost.localdomain> References: <1241490459.6639.115.camel@localhost.localdomain> Message-ID: <200905042315.31519.wm161@wm161.net> On Monday 04 May 2009 10:27:39 pm Callum Lerwick wrote: > On Mon, 2009-05-04 at 21:00 -0400, Orcan Ogetbil wrote: > > On Mon, May 4, 2009 at 8:41 PM, Callum Lerwick wrote: > > > On Mon, 2009-05-04 at 20:00 -0400, Orcan Ogetbil wrote: > > >> On Mon, May 4, 2009 at 6:46 PM, Callum Lerwick wrote: > > >> > On Mon, 2009-05-04 at 14:31 -0400, Orcan Ogetbil wrote: > > >> >> A person already makes a choice (a very big and "radical" one) when > > >> >> he decides to use Linux. A second choice is made by deciding on > > >> >> Fedora. Why should we enforce that these were the last choices he > > >> >> makes? > > >> > > > >> > http://www.joelonsoftware.com/uibook/chapters/fog0000000059.html > > >> > > >> Nope, that text doesn't have any scientific value. It contains > > >> variations of "Nobody cares", "Nobody wants..." without backup. I > > >> neither have met this Nobody person, nor do I care what he wants more > > >> than I care for any other user in the pool. In fact, I know more > > >> people who care about certain design choices than who don't. Moreover, > > >> the text tends to confuse bad design with customizability (although it > > >> tries hard not to). > > > > > > I'm sure you have scientific studies showing people love playing 20 > > > questions to get anything done, right? > > > > No, I particularly like having choices. Whenever I am getting > > furniture or some kitchen appliance, I go to the store and make my > > selection according to my taste. I find it important the way my > > furniture looks. Also I make sure that my kitchen appliance have the > > capabilities that I am interested. > > And if you actually read the essay, it's not against choice. It's about > being very careful and responsible in what you force the user to choose. > > Choice for the sake of choice is not desirable. > > > And I know quite a lot of people who do it the same way. In fact, very > > few houses I have seen have identical furniture and kitchen > > appliances. The reason for this is people have made decisions among > > multiple choices. > > > > You may want to grab the first microwave oven you > > see and get out of the store, but believe me, most people are not like > > you. > > I doubt that most people *want* to spend hours obsessing over what > microwave to buy. > > I note that all your examples pertain purely to aesthetics. Yes, *that* > is one thing average people care about. They want things to look unique, > and personal. They *do not* care about underlying mechanics. > > > If you don't believe me, look out of your window. You might see > > different brands of cars. I think that would be a proof that is > > "scientific enough". > > And when most people jump in their car, they don't want to spend hours > selecting ignition timings and suspension settings and transmission > tunings and the gender and accent of the navigation system's voice > before they can start the car. > > Those who want to do so are free to buy a BMW with iDrive. Those people, > dare I say it, are not in the majority. > > > Have a choice :) > > No one's taking any choices away. Having choices available is something > completely different from *forcing* users to *make* choices they do not > understand or care about. > > A non-technical user who just wants a platform to run Firefox and email > photos to grandma does not want to play 20 questions about this "desktop > environment" thing they've never heard of before they can do so. > > And as KDE itself has embraced this mistaken philosophy of "choice is > always desirable", why would we ever want to inflict it on non-technical > users? People who want to play 20-questions already know where to find > KDE. I'm confused. Is this thread about bashing other desktop design philosophies now? I thought this was all originally a thread to introduce a way to put the major desktop environments on even footing. I think you two should take a step back here and look at what we're trying to accomplish. Let's just put a big 'ole 3-way radio button in the installer with "GNOME", "KDE", and "Other/None" in the DVD installer and be done with it. I realize that picking a desktop environment probably isn't something a new Linux user is familiar with. But that doesn't mean we can't put some link on the download page explaining the term and the differences between the two. The only way I see this being resolved is with: A) We cave in and give the user a choice, which is something few other distros with a graphical installer do (only suse comes to mind), or B) We remain a stick in the mud, staying with the tried and true GNOME desktop. Picking A will almost certainly bring in more KDE users and help make KDE less of a second class citizen in Fedora. Picking B will make one less decision for linux newbies to make when they install Fedora. I believe option A will benefit fedora in the longer run. -- Trever Fischer (tdfischer) Fedora Ambassador, KDE Hacker http://wm161.net GPG: C40F2998 hkp://wwwkeys.pgp.net -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From seg at haxxed.com Tue May 5 03:50:47 2009 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 04 May 2009 22:50:47 -0500 Subject: Abandon "Default Desktop" In-Reply-To: <200905042315.31519.wm161@wm161.net> References: <1241490459.6639.115.camel@localhost.localdomain> <200905042315.31519.wm161@wm161.net> Message-ID: <1241495447.6639.129.camel@localhost.localdomain> On Mon, 2009-05-04 at 23:15 -0400, Trever Fischer wrote: > I'm confused. Is this thread about bashing other desktop design philosophies > now? I thought this was all originally a thread to introduce a way to put the > major desktop environments on even footing. My point is putting GNOME and KDE on "even footing" is not advantageous to our overall ease of use. Yes, I'm disagreeing with the OP. > I think you two should take a step > back here and look at what we're trying to accomplish. I don't know what you're trying to accomplish, but IMHO ease of use is far more advantageous to the distribution's overall health than political neutrality that no one but a bunch of nerds cares about. > Let's just put a big > 'ole 3-way radio button in the installer with "GNOME", "KDE", and "Other/None" > in the DVD installer and be done with it. I realize that picking a desktop > environment probably isn't something a new Linux user is familiar with. But > that doesn't mean we can't put some link on the download page explaining the > term and the differences between the two. And as Joel's essay points out, no amount of explaining or lecturing is going to make the user care. You can't make them care. They will never care. They want Firefox. They've heard of Firefox. They don't want GNOME or KDE, they don't want Epiphany, they don't want Konqueror, they want Firefox, they want their Myspace, and they want their webmail. > The only way I see this being resolved is with: > > A) We cave in and give the user a choice, which is something few other distros > with a graphical installer do (only suse comes to mind), or > B) We remain a stick in the mud, staying with the tried and true GNOME > desktop. > Picking A will almost certainly bring in more KDE users and help make KDE less > of a second class citizen in Fedora. Picking B will make one less decision for > linux newbies to make when they install Fedora. > > I believe option A will benefit fedora in the longer run. And I disagree. B is better. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From thuforuk at yahoo.co.uk Tue May 5 04:10:36 2009 From: thuforuk at yahoo.co.uk (Dariusz J. Garbowski) Date: Mon, 04 May 2009 22:10:36 -0600 Subject: Abandon "Default Desktop" In-Reply-To: <1241495447.6639.129.camel@localhost.localdomain> References: <1241490459.6639.115.camel@localhost.localdomain> <200905042315.31519.wm161@wm161.net> <1241495447.6639.129.camel@localhost.localdomain> Message-ID: <49FFBC3C.9050304@yahoo.co.uk> On 05/04/2009 09:50 PM, Callum Lerwick wrote: > On Mon, 2009-05-04 at 23:15 -0400, Trever Fischer wrote: > >> I'm confused. Is this thread about bashing other desktop design philosophies >> now? I thought this was all originally a thread to introduce a way to put the >> major desktop environments on even footing. >> > > My point is putting GNOME and KDE on "even footing" is not advantageous > to our overall ease of use. Yes, I'm disagreeing with the OP. > Care to elaborate? Why is it "not advantageous to our overall ease of use" (whatever this actually means)? >> I think you two should take a step >> back here and look at what we're trying to accomplish. >> > > I don't know what you're trying to accomplish, but IMHO ease of use is > far more advantageous to the distribution's overall health than > political neutrality that no one but a bunch of nerds cares about. > Like "net neutrality" that only "bunch of nerds cares about"? >> Let's just put a big >> 'ole 3-way radio button in the installer with "GNOME", "KDE", and "Other/None" >> in the DVD installer and be done with it. I realize that picking a desktop >> environment probably isn't something a new Linux user is familiar with. But >> that doesn't mean we can't put some link on the download page explaining the >> term and the differences between the two. >> > > And as Joel's essay points out, no amount of explaining or lecturing is > going to make the user care. You can't make them care. They will never > care. They want Firefox. They've heard of Firefox. They don't want GNOME > or KDE, they don't want Epiphany, they don't want Konqueror, they want > Firefox, they want their Myspace, and they want their webmail. > ...they want Windows... and so on... I want KDE but then again you'll say that I am not "them"... Come on! "They"? As agent Mulder would say "they are out there"? >> The only way I see this being resolved is with: >> >> A) We cave in and give the user a choice, which is something few other distros >> with a graphical installer do (only suse comes to mind), or >> B) We remain a stick in the mud, staying with the tried and true GNOME >> desktop. >> > > >> Picking A will almost certainly bring in more KDE users and help make KDE less >> of a second class citizen in Fedora. Picking B will make one less decision for >> linux newbies to make when they install Fedora. >> >> I believe option A will benefit fedora in the longer run. >> > > And I disagree. B is better. > And I disagree. A is better. What do we do now then? -- thufor ___________________________________________________________ Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html From surenkarapetyan at gmail.com Tue May 5 06:24:20 2009 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Tue, 5 May 2009 11:24:20 +0500 Subject: Abandon "Default Desktop" In-Reply-To: <1241490459.6639.115.camel@localhost.localdomain> References: <1241490459.6639.115.camel@localhost.localdomain> Message-ID: <200905051124.21327.surenkarapetyan@gmail.com> On Tuesday 05 May 2009 07:27:39 Callum Lerwick wrote: > I note that all your examples pertain purely to aesthetics. Yes, *that* > is one thing average people care about. They want things to look unique, > and personal. They *do not* care about underlying mechanics. > Average people use Windows, Mac OS X and even Ubuntu. They don't use Fedora. > No one's taking any choices away. Having choices available is something > completely different from *forcing* users to *make* choices they do not > understand or care about. Yes in that sense no one could ever take the choice away - It's free software - The user is free to "svn co" and compile himself. Suren From adelessafi at gmail.com Tue May 5 07:02:08 2009 From: adelessafi at gmail.com (Adel ESSAFI) Date: Tue, 5 May 2009 08:02:08 +0100 Subject: easycap video adapter Message-ID: Hi list I have an easycap video adapter. When plugged on linux, the system detects it but I am still not able ti use it (with cheese or mogulus). when I di lsusb, I get this entry. [adel at localhost ~]$ lsusb Bus 002 Device 005: ID 05e1:0408 Syntek Semiconductor Co., Ltd Can you help please? Regards Adel -- http://ilovefedora.blogspot.com/ -- PhD candidate in Computer Science Address BP 108, Bureau de poste Tunis republique 1001 Tunis Tunisia tel: +216 97 246 706 fax: +216 71 391 166 From frankly3d at gmail.com Tue May 5 08:26:11 2009 From: frankly3d at gmail.com (Frank Murphy (Frankly3D)) Date: Tue, 05 May 2009 09:26:11 +0100 Subject: Preupgrade Icon? Message-ID: <49FFF823.2040204@gmail.com> to qualify Not a developer. Yet As I install Fedora onto box(s) for newbies to Linux. Can a "clickable icon" be made up for preupgrade. As to most of them, command line usage across the telephone can be a little daunting. They don't even know how to use it, on non-Linux systems. Frank -- msn: frankly3d skype: frankly3d Still Learning From Juha.Tuomala at iki.fi Tue May 5 08:57:01 2009 From: Juha.Tuomala at iki.fi (Juha Tuomala) Date: Tue, 5 May 2009 11:57:01 +0300 Subject: Moblin 2 and Fedora In-Reply-To: <1241449115.2766.148.camel@atropine.boston.devel.redhat.com> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <20090503160827.GA21833@srcf.ucam.org> <1241449115.2766.148.camel@atropine.boston.devel.redhat.com> Message-ID: <200905051157.01667.Juha.Tuomala@iki.fi> On Monday 04 May 2009 17:58:35 Adam Jackson wrote: > On Sun, 2009-05-03 at 17:08 +0100, Matthew Garrett wrote: > > been processed through something called specbuilder. The behaviour of > > this seems to have varied between versions - some remove the original > > changelog, some don't. In some cases the specfiles are identical to the > > Fedora ones (to the extent of including comments) but have simply had > > the changelog entries stripped. > > There is a reasonably legitimate technical reason for this, which is > that the changelogs end up in the rpmdb, which is wasted disk space for > the moblin use case (user just wants firefox and doesn't care about > package changelogs). It's about 24M on my machine, for instance. > > Of course that's also something you could strip out at rpmbuild time... Which sounds pretty good idea, so I went and asked: #rpm.org hi, any change ever seeing that feature metioned in moblin thread in fedora-devel mailing list? it was about dropping changelog from binaries in rpmbuild. Tuju: that's actually already implemented upstream, just not in any released version yet well that's great news. here's the reference: http://rpm.org/ticket/47 http://rpm.org/ticket/47 > DESCRIPTION > To save space in the packages and the rpmdb a macro could limit the > changelog in binary packages. That way ancient log entries could still be > looked up in the spec file. Limit could be done by #entries or by time or > both. > > 04/16/09 12:20:34 changed by jnovy > status changed from new to closed. > resolution set to fixed. > The new changelog trimming feature is now implemented upstream. The current > implementation allows changelog trimming based on changelog entry date. It > is specified via _changelog_trimtime macro: # The Unix time of the latest > kept changelog entry in binary packages. # Any older entry is not packaged > in binary packages. > %_changelog_trimtime 0 Tuju -- Varo hattup?isi? autoilijoita. From Juha.Tuomala at iki.fi Tue May 5 08:57:01 2009 From: Juha.Tuomala at iki.fi (Juha Tuomala) Date: Tue, 5 May 2009 11:57:01 +0300 Subject: Moblin 2 and Fedora In-Reply-To: <1241449115.2766.148.camel@atropine.boston.devel.redhat.com> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <20090503160827.GA21833@srcf.ucam.org> <1241449115.2766.148.camel@atropine.boston.devel.redhat.com> Message-ID: <200905051157.01667.Juha.Tuomala@iki.fi> On Monday 04 May 2009 17:58:35 Adam Jackson wrote: > On Sun, 2009-05-03 at 17:08 +0100, Matthew Garrett wrote: > > been processed through something called specbuilder. The behaviour of > > this seems to have varied between versions - some remove the original > > changelog, some don't. In some cases the specfiles are identical to the > > Fedora ones (to the extent of including comments) but have simply had > > the changelog entries stripped. > > There is a reasonably legitimate technical reason for this, which is > that the changelogs end up in the rpmdb, which is wasted disk space for > the moblin use case (user just wants firefox and doesn't care about > package changelogs). It's about 24M on my machine, for instance. > > Of course that's also something you could strip out at rpmbuild time... Which sounds pretty good idea, so I went and asked: #rpm.org hi, any change ever seeing that feature metioned in moblin thread in fedora-devel mailing list? it was about dropping changelog from binaries in rpmbuild. Tuju: that's actually already implemented upstream, just not in any released version yet well that's great news. here's the reference: http://rpm.org/ticket/47 http://rpm.org/ticket/47 > DESCRIPTION > To save space in the packages and the rpmdb a macro could limit the > changelog in binary packages. That way ancient log entries could still be > looked up in the spec file. Limit could be done by #entries or by time or > both. > > 04/16/09 12:20:34 changed by jnovy > status changed from new to closed. > resolution set to fixed. > The new changelog trimming feature is now implemented upstream. The current > implementation allows changelog trimming based on changelog entry date. It > is specified via _changelog_trimtime macro: # The Unix time of the latest > kept changelog entry in binary packages. # Any older entry is not packaged > in binary packages. > %_changelog_trimtime 0 Tuju -- Varo hattup?isi? autoilijoita. From bochecha at fedoraproject.org Tue May 5 09:58:00 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Tue, 5 May 2009 11:58:00 +0200 Subject: Preupgrade Icon? In-Reply-To: <49FFF823.2040204@gmail.com> References: <49FFF823.2040204@gmail.com> Message-ID: <2d319b780905050258x2f366c36m707766eff4618010@mail.gmail.com> Wait a little until F11 is released. Then PackageKit will see it was released, and propose automatically to upgrade to Fedora 11 (using PreUpgrade) . That is, unless the user specified to not check for ? Major upgrades ? in the PackageKit preferences. ---------- Mathieu Bridon (bochecha) From oget.fedora at gmail.com Tue May 5 10:45:38 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Tue, 5 May 2009 06:45:38 -0400 Subject: Abandon "Default Desktop" In-Reply-To: <1241490459.6639.115.camel@localhost.localdomain> References: <1241453613.3570.41.camel@localhost.localdomain> <1241477191.6639.0.camel@localhost.localdomain> <1241484114.6639.65.camel@localhost.localdomain> <1241490459.6639.115.camel@localhost.localdomain> Message-ID: On Mon, May 4, 2009 at 10:27 PM, Callum Lerwick wrote: > On Mon, 2009-05-04 at 21:00 -0400, Orcan Ogetbil wrote: > >> You may want to grab the first microwave oven you >> see and get out of the store, but believe me, most people are not like >> you. > > I doubt that most people *want* to spend hours obsessing over what > microwave to buy. > > I note that all your examples pertain purely to aesthetics. Yes, *that* > is one thing average people care about. They want things to look unique, > and personal. They *do not* care about underlying mechanics. > At no point, I said or implied to expose the internals of the DE to the user. All I am saying is, let us provide them some information accompanied by some screenshots (as aesthetics is important, and some people think that Gnome is just ugly) for the DE they will live with. We will say: "Look, these are your choices". I believe that the users deserve such an option. >> If you don't believe me, look out of your window. You might see >> different brands of cars. I think that would be a proof that is >> "scientific enough". > > And when most people jump in their car, they don't want to spend hours > selecting ignition timings and suspension settings and transmission > tunings and the gender and accent of the navigation system's voice > before they can start the car. > No. They don't have to spend hours for this. Maybe 10-30 seconds... Many people don't know that they have a choice. They use Windows. Some people don't know that they have a further choice. They use an ugly (to their taste) DE. > > And as KDE itself has embraced this mistaken philosophy of "choice is > always desirable", why would we ever want to inflict it on non-technical > users? People who want to play 20-questions already know where to find > KDE. > My mom (who can't use a digital camera because it is too complicated) has used KDE for years. Please stop this FUD. It's not fair. Orcan From benjavalero at gmail.com Tue May 5 10:51:33 2009 From: benjavalero at gmail.com (=?UTF-8?Q?Benjam=C3=ADn_Valero_Espinosa?=) Date: Tue, 5 May 2009 12:51:33 +0200 Subject: easycap video adapter In-Reply-To: References: Message-ID: 2009/5/5 Adel ESSAFI > I have an easycap video adapter. When plugged on linux, the system > detects it but I am still not able ti use it (with cheese or mogulus). > when I di lsusb, I get this entry. > > [adel at localhost ~]$ lsusb > Bus 002 Device 005: ID 05e1:0408 Syntek Semiconductor Co., Ltd > > Can you help please? > Nowadays there is no easy way to make it work. There is a driver in development for Syntek webcams [1], and a patch to do this driver work with the EasyCap video adapter [2]. In [3] you can find instructions to make it work (in Ubuntu and in Spanish, but it is better than nothing). For me it works, although I am still trying to capture video and audio at once with mencoder (I get a strange floating point exception), because gstreamer is a little slower in that task. Whatever I can help, you got my email. Benja [1] http://syntekdriver.sourceforge.net/ [2] https://sourceforge.net/forum/forum.php?thread_id=2803299&forum_id=616182 [3] http://crysol.org/es/node/1103 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wm161 at wm161.net Tue May 5 13:32:20 2009 From: wm161 at wm161.net (Trever Fischer) Date: Tue, 5 May 2009 09:32:20 -0400 Subject: Abandon "Default Desktop" In-Reply-To: <1241495447.6639.129.camel@localhost.localdomain> References: <200905042315.31519.wm161@wm161.net> <1241495447.6639.129.camel@localhost.localdomain> Message-ID: <200905050932.31973.wm161@wm161.net> On Monday 04 May 2009 11:50:47 pm Callum Lerwick wrote: > On Mon, 2009-05-04 at 23:15 -0400, Trever Fischer wrote: > > I'm confused. Is this thread about bashing other desktop design > > philosophies now? I thought this was all originally a thread to introduce > > a way to put the major desktop environments on even footing. > > My point is putting GNOME and KDE on "even footing" is not advantageous > to our overall ease of use. Yes, I'm disagreeing with the OP. > > > I think you two should take a step > > back here and look at what we're trying to accomplish. > > I don't know what you're trying to accomplish, but IMHO ease of use is > far more advantageous to the distribution's overall health than > political neutrality that no one but a bunch of nerds cares about. > Mainly, I'm trying to stop this thread from going on too much longer. Its getting to be another one of those pulseaudio, or c-a-b threads. > > Let's just put a big > > 'ole 3-way radio button in the installer with "GNOME", "KDE", and > > "Other/None" in the DVD installer and be done with it. I realize that > > picking a desktop environment probably isn't something a new Linux user > > is familiar with. But that doesn't mean we can't put some link on the > > download page explaining the term and the differences between the two. > > And as Joel's essay points out, no amount of explaining or lecturing is > going to make the user care. You can't make them care. They will never > care. They want Firefox. They've heard of Firefox. They don't want GNOME > or KDE, they don't want Epiphany, they don't want Konqueror, they want > Firefox, they want their Myspace, and they want their webmail. Its a fact of life that there is more than one desktop environment in linux. Linux is about choice. If our target audience doesn't want choice, why are they using linux then? You're making this a lot bigger than it really is. Choosing a desktop environment is but one choice out of millions that a user makes. Let's suppose they chose to buy a copy of Windows Vista. Barring the exorbitant pricing, which Vista do they buy? Consider this as well: Does Aunt Tilly go out and actually buy a copy of Vista? No, she just buys a new computer and uses what it comes with. It tends to be the more advanced and knowledgeable users who do the research on what "edition" they want. Aunt Tilly doesn't care what browser she uses, or why free software is superior. She just uses her computer. Chances are, she'll never hear about Fedora or even Linux unless her nephew or niece comes over and shows her Ubuntu. I don't think our target audience is really Aunt Tilly. Its nice to keep telling ourselves it is, but our target audience is really more along the lines of "people who are fed up with choices being made for them because someone else thinks its better" AKA Microsoft, Cannocal[1], or Apple. If there's a reason to switch to Fedora, thats a popular one. Its 100% true we can't make the user care. So why is preventing the majority of people who /do/ care to have a choice from having a choice a good thing? If the user doesn't care, they'll pick the first one just so they can speed through the installer. If we want to target people who don't care, we can advertise a "I don't care what software I use, just give me a web browser" spin that contains ratpoison and a fullscreen firefox. It really isn't a huge decision here. The user is asked to slow down and consider what kind of experience they want, or they can just keep clicking next and hope for the best. GNOME users seem satisfied with the lack of customization compared to KDE (not bashing, as I myself rarely twiddle with the trillions of options available to me), so if a new user is happy with defaults even though there is a choice, they'll pick the first option in the list. I'd like to relate all this to the first time I tried Linux when I installed Fedora Core 3. I clicked through the installer and when it got to the package selection screen, I was astonished by the sheer volume of choices. GNOME was checked as the desktop environment, so I just clicked next and hoped for the best. If I had never played around with the KDE3 desktop on Knoppix, I might just be a GNOME hacker today. I later installed Fedora Core 4 on another desktop and I was happy to be able to pick between GNOME and KDE. Today, I'm disappointed that I have to tell my KDE friends to dig through the fedora website to find the KDE LiveCD. I'm also disappointed that there are so few KDE developers actively involved with Fedora to get all these new features like the *Kits and pulseaudio up to par with the GNOME suite. That just makes it look like nobody in Fedora likes KDE. > > > The only way I see this being resolved is with: > > > > A) We cave in and give the user a choice, which is something few other > > distros with a graphical installer do (only suse comes to mind), or > > B) We remain a stick in the mud, staying with the tried and true GNOME > > desktop. > > > > Picking A will almost certainly bring in more KDE users and help make KDE > > less of a second class citizen in Fedora. Picking B will make one less > > decision for linux newbies to make when they install Fedora. > > > > I believe option A will benefit fedora in the longer run. > > And I disagree. B is better. So that makes one for A, and one for B. Obviously we must fight to the death :) [1] I'm not saying they are as evil, but I'm not a fan of the default ubuntu settings for some things... -- Trever Fischer (tdfischer) Fedora Ambassador, KDE Hacker http://wm161.net GPG: C40F2998 hkp://wwwkeys.pgp.net -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From rawhide at fedoraproject.org Tue May 5 14:56:06 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Tue, 5 May 2009 14:56:06 +0000 (UTC) Subject: rawhide report: 20090505 changes Message-ID: <20090505145606.8779F1F81FE@releng2.fedora.phx.redhat.com> Compose started at Tue May 5 06:15:03 UTC 2009 New package gst-mixer Legacy gnome-volume-control for advanced use cases Updated Packages: akonadi-1.1.2-1.fc11 -------------------- * Thu Apr 30 2009 Rex Dieter - 1.1.2-1 - akonadi-1.1.2 - optimize scriptlets a bit anaconda-11.5.0.49-1.fc11 ------------------------- * Mon May 04 2009 David Cantrell - 11.5.0.49-1 - Collect network interfaces from NetworkManager (#493995) (dcantrell) - Handle fstab entries whose filesystem we don't recognize.(#498120) (dlehman) - Add an error signifying an unrecognized entry in /etc/fstab. (dlehman) - Don't drop discovered format with unknown devices when parsing fstab. (dlehman) - Fix display of paths for device-mapper device in bootloader widget. (dlehman) - Don't call udevDeviceFormat if we're just going to clear the device (#497323). (clumens) - Pass clearPartType to the devicetree as well. (clumens) - Break the complex should-clear logic out of clearPartitions. (clumens) - Handle clearpart in the early kickstart pass too. (clumens) - Correct setting the SELinux context on mountpoints (#494995). (clumens) - make resetFileContext return the context set (wwoods) - Allow editing of the hdiso source partition so it can be mounted (#498591). (clumens) - Add a ignoreProtected= parameter to deviceImmutable that does the obvious. (clumens) - Be more aggressive unmounting before install starts (#498260) (katzj) - Add %{?dist} to the release number in the spec file. (dcantrell) - Configure network in kickstartNetworkUp() iff NM is not connected (#490518) (dcantrell) - Don't segfault with "ks someotherparam" (#498307). (clumens) - Fix the arch upgrade check in yuminstall.py, too (#498280). (clumens) - Move _resetRpmDb into iutil so we can access it everywhere. (clumens) - Don't mount bind mounts last, that makes /dev break. (pjones) - Pass anaconda to storage.FSSet.turnOnSwap. (dlehman) - Ignore spurious formatting on partitioned devices. (dlehman) - Revert "DeviceError only returns a message, not (message, device) tuple (#496343)." (dlehman) - Fix action sorting for partitions on the same disk. (#498064) (dlehman) - Fix traceback in second editing of existing raid dev (#497234). (rvykydal) - Allow existing LVs with filesystems to be resized (#490913) (dcantrell) - Rate limit pulse() calls to ProgressWindow. (pjones) - Don't populate flags.cmdline with "True" values when no = is used. (pjones) - Add "nomodeset" to the list of command line arguments copied to grub.conf (pjones) - Use device.format.mountType insead of device.format.type for fstab. (pjones) - Initialize x86 class variables before efiBootloaderInfo.__init__() (pjones) - Fix a segfault on nfs+kickstart (pjones) - Fix an error when raising FormatCreateException. (clumens) - Add more windows to the rescue interface class (#498014). (clumens) - Remove requirement for EFI machines to be x86, since IA64 is too (#497934). (clumens) - Fix the kernel package selection on ppc64 machines (#497264). (clumens) - Include fsck.ext4 and mkfs.ext4 in the images (#497996). (clumens) - Properly restore SIGCHLD if X startup fails (wwoods) - Fix kickstart PV references handling for lvm on raid (#497352). (rvykydal) atlas-3.8.3-4.fc11 ------------------ * Sat May 02 2009 Deji Akingunola - 3.8.3-4 - Use the right -msse* option for the -sse* subpackages (Fedora bug #498715) * Tue Apr 21 2009 Karsten Hopp 3.8.3-3.1 - add s390x to 64 bit archs brasero-2.26.1-3.fc11 --------------------- * Fri May 01 2009 Bill Nottingham - 2.26.1-3 - require main package in brasero-nautilus (#498632) fedora-bookmarks-11-1 --------------------- * Fri May 01 2009 Christopher Aillon - 11-1 - Refresh Fedora Project link set - Add new Free Content link - Remove obsolete links gajim-0.12.1-3.fc11 ------------------- * Sat May 02 2009 Debarshi Ray - 0.12.1-3 - Added 'Requires: gnome-python2-bonobo'. (Red Hat Bugzilla #470181) gnome-bluetooth-2.27.4-4.fc11 ----------------------------- * Fri May 01 2009 Bastien Nocera 2.27.4-4 - Touch the icon theme directory, should fix the icon not appearing properly on new installs gnome-media-2.26.0-6.fc11 ------------------------- * Fri May 01 2009 Bastien Nocera 2.26.0-5 - Move streams straight away when changing the default sink (#489049) * Fri May 01 2009 Matthias Clasen 2.26.0-6 - Fix cramped appearance of the balance slider * Mon Apr 27 2009 Matthias Clasen - 2.26.0-4 - Fix alignment of sliders on the application tab as well * Thu Apr 23 2009 - Bastien Nocera - 2.26.0-3 - Don't show debug when disabling the debug output (#493138) gnutls-2.6.6-1.fc11 ------------------- * Mon May 04 2009 Tomas Mraz 2.6.6-1 - upgrade to a new upstream version - security fixes gvfs-1.2.2-4.fc11 ----------------- * Sat May 02 2009 Matthias Clasen - 1.2.2-4 - Really hide drives that are supposed to be hidden (#498649) initscripts-8.95-1 ------------------ * Fri May 01 2009 Bill Nottingham - 8.95-1 - don't kill runlevel events on subsequent entering of the same runlevel (#498514) - lang.*sh: handle spaces in $HOME (#498482) - network-functions: explicitly source from the proper directory. (#496233) - remove persistent names on sys-unconfig. (#448322) - init.d/functions: cgexec has moved to /bin (#495715) - allow changing of VLAN type even if the module is already loaded. (#495053, ) - translation updates: fr, ml, pt kernel-2.6.29.2-126.fc11 ------------------------ * Mon May 04 2009 Ben Skeggs 2.6.29.2-125 - Disable CONFIG_FB_NVIDIA due to very bad interactions with nouveau * Mon May 04 2009 Ben Skeggs 2.6.29.2-126 - Explicitly enable CONFIG_FB_MODE_HELPERS to fix build.. * Sun May 03 2009 Ben Skeggs 2.6.29.2-124 - drm-nouveau.patch: ignore unsupported dcb encoder types completely - nv50: module option to run output scripts, too raw to be by default yet, but will fix a number of issues in the places where they work. * Sat May 02 2009 Ben Skeggs 2.6.29.2-122 - drm-nouveau.patch: nv50 connector grouping fixes - bios parser updates from ddx (nv50 panel mode from VBIOS table) - pre-nv50 modesetting updates from ddx (in disabled codepath) * Sat May 02 2009 Kyle McMartin 2.6.29.2-123 - Build htmldocs single threaded. * Fri May 01 2009 Eric Sandeen - Fix ext4 corruption on partial write into prealloc block * Fri May 01 2009 Kyle McMartin 2.6.29.2-121 - More bluetooth fixes from 2.6.30-rc. - linux-2.6-v4l-dvb-fixes.patch: restore, accidently nuked. - linux-2.6-v4l-dvb-experimental.patch: restore to previous version to fix rejects against restored -fixes. * Thu Apr 30 2009 Dave Airlie 2.6.29.1-117 - drm-radeon-kms-fixes.patch: add r300 clip regs * Thu Apr 30 2009 Dave Airlie 2.6.29.1-118 - drm-radeon-kms-fixes.patch: revert rs480 snoop break * Thu Apr 30 2009 Kyle McMartin 2.6.29.2-119 - Update to 2.6.29.2 - Patches rebased: linux-2.6-v4l-dvb-experimental.patch drm-next.patch - Patches merged upstream: linux-2.6-acer-wmi-bail-on-aao.patch linux-2.6-e820-mark-esi-clobbered.patch linux-2.6-kvm-kconfig-irqchip.patch linux-2.6-kvm-mask-notifiers.patch linux-2.6-kvm-reset-pit-irq-on-unmask.patch linux-2.6-md-raid1-dont-assume-new-bvecs-are-init.patch linux-2.6-mm-define-unique-value-for-as_unevictable.patch linux-2.6-net-fix-another-gro-bug.patch linux-2.6-posix-timers-fix-clock-monotonicity.patch linux-2.6-posix-timers-fix-rlimit_cpu-fork-2.patch linux-2.6-posix-timers-fix-rlimit_cpu-setitimer.patch linux-2.6-v4l-dvb-fixes.patch linux-2.6-v4l-dvb-update.patch linux-2.6.29.1-sparc-regression.patch pat-remove-page-granularity-tracking-for-vm_insert_pfn_maps.patch libvoikko-2.1-1.fc11 -------------------- * Sat May 02 2009 Ville-Pekka Vainio - 2.1-1 - 2.1 final, including fixes to grammar checking links-2.2-9.fc11 ---------------- * Tue Apr 21 2009 Lubomir Rintel - 2.2-9 - Add epoch to beat elinks obsoletes mozplugger-1.10.1-5.fc11 ------------------------ * Mon May 04 2009 Than Ngo - 1.10.1-5 - fix #469257, selinux policy and mozplugger do not get along plymouth-0.7.0-0.2009.03.10.4.fc11 ---------------------------------- * Fri May 01 2009 Ray Strode - 0.7.0-0.2009.03.10.4 - Make spinfinity provide plymouth(system-plugin) qdevelop-0.27.4-3.fc11 ---------------------- * Thu Apr 30 2009 Kevin Kofler - 0.27.4-3 - Fix failure to compile a project with Qt 4.5.1 (#497734, patch by Than Ngo) * Wed Apr 22 2009 Nicoleau Fabien - 0.27.4-2 - Rebuild for Qt 4.5 qemu-0.10-16.fc11 ----------------- * Fri May 01 2009 Mark McLoughlin - 2:0.10-16 - Really provide qemu-kvm as a metapackage selinux-policy-3.6.12-28.fc11 ----------------------------- * Mon May 04 2009 Dan Walsh 3.6.12-28 - Fix package selection handling * Fri May 01 2009 Dan Walsh 3.6.12-27 - Fix /sbin/ip6tables-save context - Allod udev to transition to mount - Fix loading of mls policy file * Thu Apr 30 2009 Dan Walsh 3.6.12-26 - Add shorewall policy * Wed Apr 29 2009 Dan Walsh 3.6.12-25 - Additional rules for fprintd and sssd tigervnc-0.0.90-0.7.20090427svn3789.fc11 ---------------------------------------- * Thu Apr 30 2009 Adam Tkac 0.0.90-0.7.20090427svn3789 - server package now requires xorg-x11-fonts-misc (#498184) tracker-0.6.94-1.fc11 --------------------- * Fri May 01 2009 Deji Akingunola - 0.6.94-1 - Update to 0.6.94 release xorg-x11-drv-nouveau-0.0.12-33.20090501gitf69b34a.fc11 ------------------------------------------------------ * Mon May 04 2009 Ben Skeggs 0.0.12-33.20090501gitf69b34a - rh#492572: only apply bicubic filter when scaling >=2x - rh#497654: correct exa offscreen memory size * Fri May 01 2009 Ben Skeggs 0.0.12-32.20090501gitf69b34a - upstream update fixing serious issues in nv50 output setup xsane-0.996-7.fc11 ------------------ * Sun May 03 2009 Warren Togami - 0.996-7 - rebuild to make it work (gcc miscompile?) Summary: Added Packages: 1 Removed Packages: 0 Modified Packages: 23 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From cdahlin at redhat.com Tue May 5 14:57:05 2009 From: cdahlin at redhat.com (Casey Dahlin) Date: Tue, 05 May 2009 10:57:05 -0400 Subject: just lost my pipe In-Reply-To: <1241342141.3682.4.camel@choeger6> References: <1240593824.2536.8.camel@choeger6> <49F1FB32.7020909@redhat.com> <1241342141.3682.4.camel@choeger6> Message-ID: <4A0053C1.5020900@redhat.com> Christoph H?ger wrote: > It finally happened again: > > This was AltGr + '<': > > KeyPress event, serial 30, synthetic NO, window 0x4c00001, > root 0xfd, subw 0x0, time 149129465, (454,214), root:(463,323), > state 0x2010, keycode 94 (keysym 0x3c, less), same_screen YES, > XLookupString gives 1 bytes: (3c) "<" > XmbLookupString gives 1 bytes: (3c) "<" > XFilterEvent returns: False > > After switching to tty2 to verify that this happens only in X everything > is fine again: > > Expected results: > KeyPress event, serial 30, synthetic NO, window 0x4c00001, > root 0xfd, subw 0x0, time 149420489, (407,292), root:(410,359), > state 0x2090, keycode 94 (keysym 0x7c, bar), same_screen YES, > XKeysymToKeycode returns keycode: 51 > XLookupString gives 1 bytes: (7c) "|" > XmbLookupString gives 1 bytes: (7c) "|" > XFilterEvent returns: False > > > WTF? > Please open a bug about this if you haven't already. --CJD From tgl at redhat.com Tue May 5 15:34:14 2009 From: tgl at redhat.com (Tom Lane) Date: Tue, 05 May 2009 11:34:14 -0400 Subject: I wanted to open a discussion for F12 about running services on shell accounts. In-Reply-To: <49FEF9DA.8060300@redhat.com> References: <49FB07B0.50100@redhat.com> <20090501213437.GA20032@wolff.to> <49FEF9DA.8060300@redhat.com> Message-ID: <17674.1241537654@sss.pgh.pa.us> Daniel J Walsh writes: > The suggesting here is to use dbus to start applications in terminal > shell as the same user UID, not to have the system dbus start the app. I just ran into something in F-10 that would really need to be fixed if this starts to happen. I ssh'd into my F-10 machine and started firefox (across the X11 -Y-mode tunnel). After I quit and tried to end the session, the ssh tunnel stayed open. Investigation showed that there was a dbus session holding a connection open --- I suppose firefox had started it. I had to kill it manually to terminate the ssh session. In short, if you launch one automatically you'd better have provisions to make it go away automatically... regards, tom lane From goeran at uddeborg.se Tue May 5 15:44:14 2009 From: goeran at uddeborg.se (=?utf-8?Q?G=C3=B6ran?= Uddeborg) Date: Tue, 5 May 2009 17:44:14 +0200 Subject: GConf changes in F12 In-Reply-To: <1240942944.2770.8.camel@localhost.localdomain> References: <1240942944.2770.8.camel@localhost.localdomain> Message-ID: <18944.24270.538957.141077@gargle.gargle.HOWL> Matthias Clasen writes: > The only tool that ever uses these translations, gconf-editor, The command line tool, gconftool-2, also uses them. But it is part of GConf, which you patched you said, so maybe that is already taken care of? From mmcgrath at redhat.com Tue May 5 15:59:06 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 5 May 2009 10:59:06 -0500 (CDT) Subject: Outage Notification - 2009-05-06 18:00 UTC Message-ID: There will be an outage starting at 2009-05-06 18:00 UTC, which will last approximately 2 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2009-05-06 18:00 UTC' Affected Services: Primary Mirror Server Fedora Wiki infrastructure.fedoraproject.org Unaffected Services: Buildsystem CVS / Source Control Database DNS Fedora Hosted Fedora People Fedora Talk Mail Mirror System Torrent Translation Services Websites Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/1370 Reason for Outage: Firmware upgrade for our netapps. This will only take about 15 minutes or so but I've scheduled a larger window. This will take our primary mirror offline for a bit as well as the wiki uploads. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From mcepl at redhat.com Tue May 5 16:10:18 2009 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 5 May 2009 18:10:18 +0200 Subject: Feedback request: Priority / Severity use on Bugzilla Message-ID: Hi, folks. We in the QA and Bugzappers groups have recently been discussing the use of the Priority and Severity fields in Bugzilla. At present, the status is that these are more or less ignored by Bugzappers and most maintainers; some maintainers use and set them for their own packages according to their own system. The reason for their neglect, as we see it, is that there's been no convention for their use, and no overall responsibility in setting them - they're usually set arbitrarily by reporters, and thus convey no useful information. We think it may be useful for the Bugzappers group to start setting these fields as part of the triage process. To address one potential issue right off the top - this would be *entirely* advisory, like all the other work of the Bugzappers: it's intended to provide a service to maintainers, nothing more. It would not be in any way prescriptive - we don't want any other group to be able to tell maintainers what they should work on. We simply think that setting these fields consistently as part of triage might prove useful to some, or all, maintainers. It's also just proposed as a trial - if we try it and it doesn't seem to be working out well, we'll stop it. We have a draft convention for how these fields should be set here: http://fedoraproject.org/wiki/User:Beland/Bugzilla_Legend#Severity_and_Priority . As you can see, it basically suggests that the severity field be used to rate the importance of the issue in the context only of the affected package, and priority be used to rate the importance of the issue in the context of the distribution as a whole. There is an alternative proposal that triagers would set only the severity field, which would work mostly as it does in the other proposal, except that the Urgent severity would be used for issues which, in the triager's judgement, have serious consequences for the distro as a whole. The priority field, in this proposal, is reserved for the package maintainer(s) to use, no-one else gets to set it at any point. In our proposals, triagers would set these field(s) in as consistent a manner as possible as part of the initial triage process. Bug reporters could be prevented from setting the fields at all, at any time, to address the possibility that they might just set their reports to High or Urgent regardless of their actual importance. There's no action required or even suggested of any maintainer for any value of either field - it's simply there to provide information. We feel that maintainers might then find it useful to organize their bugs by severity or priority to make it easier to identify the most urgent issues to address. A few specifics: the system would happily accommodate maintainers who have their own systems for using these fields. Triagers would be specifically instructed not to touch these fields if they had been previously touched by the maintainer - effectively, maintainer's decision on these fields is final. So if you disagree with the triager's opinion, or you have your own system for using these fields, you could simply set them to whatever you like and the Bugzappers will not change them back. So, really, we just want your feedback: do you think this proposal might prove useful to you as a maintainer? Can you see any problems with it, or potential refinements or improvements? Which of the two slightly differing proposals would you prefer? Bugzappers' mission is to ease the lives of maintainers, so we don't want to put this in place unless it's seen as beneficial by at least some maintainers. Thanks! Mat?j on behalf of Fedora BugZappers From mclasen at redhat.com Tue May 5 16:23:12 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 05 May 2009 12:23:12 -0400 Subject: GConf changes in F12 In-Reply-To: <18944.24270.538957.141077@gargle.gargle.HOWL> References: <1240942944.2770.8.camel@localhost.localdomain> <18944.24270.538957.141077@gargle.gargle.HOWL> Message-ID: <1241540592.6131.45.camel@localhost.localdomain> On Tue, 2009-05-05 at 17:44 +0200, G?ran Uddeborg wrote: > Matthias Clasen writes: > > The only tool that ever uses these translations, gconf-editor, > > The command line tool, gconftool-2, also uses them. But it is part of > GConf, which you patched you said, so maybe that is already taken care > of? Yes, libgconf has been patched to use the client-side translations, so gconftool-2 should be taken care of. From sokerlp at gmail.com Tue May 5 16:32:20 2009 From: sokerlp at gmail.com (Oscar) Date: Tue, 5 May 2009 11:32:20 -0500 Subject: Preupgrade Icon? In-Reply-To: <2d319b780905050258x2f366c36m707766eff4618010@mail.gmail.com> References: <49FFF823.2040204@gmail.com> <2d319b780905050258x2f366c36m707766eff4618010@mail.gmail.com> Message-ID: <8536ef10905050932r6a915b81se9b053ecaf631c88@mail.gmail.com> :-o that's great!!! So is this a new way to upgrade or just packagekit running preupgrade?? Atentamente Oscar: On Tue, May 5, 2009 at 4:58 AM, Mathieu Bridon (bochecha) < bochecha at fedoraproject.org> wrote: > Wait a little until F11 is released. Then PackageKit will see it was > released, and propose automatically to upgrade to Fedora 11 (using > PreUpgrade) . > > That is, unless the user specified to not check for ? Major upgrades ? > in the PackageKit preferences. > > > ---------- > > Mathieu Bridon (bochecha) > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.kofler at chello.at Tue May 5 17:45:22 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 05 May 2009 19:45:22 +0200 Subject: Abandon "Default Desktop" References: <49FD51ED.7000906@alexhudson.com> <1241453613.3570.41.camel@localhost.localdomain> <1241477191.6639.0.camel@localhost.localdomain> <1241484114.6639.65.camel@localhost.localdomain> <1241490459.6639.115.camel@localhost.localdomain> Message-ID: Callum Lerwick wrote: > I note that all your examples pertain purely to aesthetics. Yes, *that* > is one thing average people care about. They want things to look unique, > and personal. They *do not* care about underlying mechanics. A desktop environment is also largely an aesthetic choice. Kevin Kofler From kevin.kofler at chello.at Tue May 5 17:44:05 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 05 May 2009 19:44:05 +0200 Subject: Abandon "Default Desktop" References: <1241490459.6639.115.camel@localhost.localdomain> <200905042315.31519.wm161@wm161.net> <1241495447.6639.129.camel@localhost.localdomain> Message-ID: Callum Lerwick wrote: > And as Joel's essay points out, no amount of explaining or lecturing is > going to make the user care. You can't make them care. They will never > care. They want Firefox. They've heard of Firefox. They don't want GNOME > or KDE, they don't want Epiphany, they don't want Konqueror, they want > Firefox, they want their Myspace, and they want their webmail. And they want their Window$ and their [insert random Window$-only software, no matter whether we have a better equivalent or not]. Trying to target that kind of users is a lost cause. Kevin Kofler From kevin.kofler at chello.at Tue May 5 17:58:28 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 05 May 2009 19:58:28 +0200 Subject: Abandon "Default Desktop" References: <49FD51ED.7000906@alexhudson.com> <1241453613.3570.41.camel@localhost.localdomain> <49FF1F69.1090100@hi.is> <49FF23CA.3000103@gmail.com> <49FF2E09.1010607@hi.is> <1241461591.3570.51.camel@localhost.localdomain> <49FF3DA1.2050801@hi.is> <20090504194148.GA4683@yoda.jdub.homelinux.org> <20090505000507.GA22259@hansolo.jdub.homelinux.org> Message-ID: Josh Boyer wrote: > Can you take this, write up a more specific proposal, and either send > it here or to FESCo? > > I don't want to guess on what you mean by "equally-placed" or "easy" > because personally I already think things are placed evenly and > easily accessed. The only difference IMO is that KDE is actually > called KDE. Well, it has already been mentioned a few times in this thread, but it boils down to 3 things: 1. Call a spade a spade, or rather call the GNOME Desktop spin the GNOME Desktop spin. 2. Place the KDE Desktop spin directly below the GNOME Desktop spin on the get-fedora page instead of hiding it behind an extra click. 3. Add a radiobutton allowing the selection of at least GNOME and KDE to the DVD installer and make sure the resulting package selection is sane (might need comps tweaks and minimal tweaks to Anaconda's comps handling as well). Of course, at least parts of these changes can be done for F12 at the earliest, I'm well aware of that, I'm NOT asking for it to be done for the F11 release. Kevin Kofler From bochecha at fedoraproject.org Tue May 5 18:03:47 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Tue, 5 May 2009 20:03:47 +0200 Subject: Abandon "Default Desktop" In-Reply-To: References: <49FD51ED.7000906@alexhudson.com> <49FF1F69.1090100@hi.is> <49FF23CA.3000103@gmail.com> <49FF2E09.1010607@hi.is> <1241461591.3570.51.camel@localhost.localdomain> <49FF3DA1.2050801@hi.is> <20090504194148.GA4683@yoda.jdub.homelinux.org> <20090505000507.GA22259@hansolo.jdub.homelinux.org> Message-ID: <2d319b780905051103n26d41e95heb37ac5a9056ef55@mail.gmail.com> > 3. Add a radiobutton allowing the selection of at least GNOME and KDE to the > DVD installer and make sure the resulting package selection is sane (might > need comps tweaks and minimal tweaks to Anaconda's comps handling as well). Make it a checkbox, some people want both. Wow, that looks a lot like what we already have in the packages selection page on the DVD... ---------- Mathieu Bridon (bochecha) From seg at haxxed.com Tue May 5 18:18:17 2009 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 05 May 2009 13:18:17 -0500 Subject: Abandon "Default Desktop" In-Reply-To: References: <1241490459.6639.115.camel@localhost.localdomain> <200905042315.31519.wm161@wm161.net> <1241495447.6639.129.camel@localhost.localdomain> Message-ID: <1241547497.31208.5.camel@localhost.localdomain> On Tue, 2009-05-05 at 19:44 +0200, Kevin Kofler wrote: > Callum Lerwick wrote: > > And as Joel's essay points out, no amount of explaining or lecturing is > > going to make the user care. You can't make them care. They will never > > care. They want Firefox. They've heard of Firefox. They don't want GNOME > > or KDE, they don't want Epiphany, they don't want Konqueror, they want > > Firefox, they want their Myspace, and they want their webmail. > > And they want their Window$ and their [insert random Window$-only software, > no matter whether we have a better equivalent or not]. Trying to target > that kind of users is a lost cause. Those users are irrelevant to this discussion, they're not trying to use Fedora. The last thing we want to do, after finally convincing them to make the big choice of trying Fedora, is confuse them and scare them off with KDE vs GNOME politics. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Tue May 5 18:45:26 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 06 May 2009 00:15:26 +0530 Subject: Moblin 2 and Fedora In-Reply-To: <20090504125251.41e491a6@infradead.org> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <49844F3B.6060905@fedoraproject.org> <5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com> <20090131110644.1a80ddf5@infradead.org> <4984BC61.3040908@fedoraproject.org> <20090131153457.573762ab@infradead.org> <604aa7910902020825v23bc3687m1151596fa74cb8a5@mail.gmail.com> <20090202101002.4380c005@infradead.org> <1233598383.7493.42.camel@localhost.localdomain> <20090202113524.184e402c@infradead.org> <20090503160827.GA21833@srcf.ucam.org> <1241449115.2766.148.camel@atropine.boston.devel.redhat.com> <49FF0A69.8030609@fedoraproject.org> <1241462009.8638.5.camel@localhost.localdomain> <20090504125251.41e491a6@infradead.org> Message-ID: <4A008946.1080606@fedoraproject.org> On 05/05/2009 01:22 AM, Arjan van de Ven wrote: > it's not very useful if the various upstream maintainers say that they > won't accept it no matter what... at that point... yes people stop > working on it. Intel is the largest contributor to Xorg and only one ahead of Red Hat currently and it is no stranger to the Linux Kernel either. If it cannot get rid of the binary driver (remember your person stand on that?), replace it with a free and open source one and get it merged upstream, that's a damn shame. When anyone asked me about what to look for, I always said, if your system comes with a Intel chipset, you are fine. Now, I cannot say that anymore and that is a disappointment. Rahul From sundaram at fedoraproject.org Tue May 5 18:46:35 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 06 May 2009 00:16:35 +0530 Subject: Preupgrade Icon? In-Reply-To: <8536ef10905050932r6a915b81se9b053ecaf631c88@mail.gmail.com> References: <49FFF823.2040204@gmail.com> <2d319b780905050258x2f366c36m707766eff4618010@mail.gmail.com> <8536ef10905050932r6a915b81se9b053ecaf631c88@mail.gmail.com> Message-ID: <4A00898B.1080104@fedoraproject.org> On 05/05/2009 10:02 PM, Oscar wrote: > :-o that's great!!! So is this a new way to upgrade or just packagekit > running preupgrade?? > Atentamente Oscar: PackageKit has a framework for distribution upgrades and it calls Preupgrade in Fedora. Rahul From smooge at gmail.com Tue May 5 18:53:51 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 5 May 2009 12:53:51 -0600 Subject: Abandon "Default Desktop" In-Reply-To: <1241547497.31208.5.camel@localhost.localdomain> References: <1241490459.6639.115.camel@localhost.localdomain> <200905042315.31519.wm161@wm161.net> <1241495447.6639.129.camel@localhost.localdomain> <1241547497.31208.5.camel@localhost.localdomain> Message-ID: <80d7e4090905051153t1bfdd3ffidc11704d9e5d4b7b@mail.gmail.com> On Tue, May 5, 2009 at 12:18 PM, Callum Lerwick wrote: > On Tue, 2009-05-05 at 19:44 +0200, Kevin Kofler wrote: >> Callum Lerwick wrote: >> > And as Joel's essay points out, no amount of explaining or lecturing is >> > going to make the user care. You can't make them care. They will never >> > care. They want Firefox. They've heard of Firefox. They don't want GNOME >> > or KDE, they don't want Epiphany, they don't want Konqueror, they want >> > Firefox, they want their Myspace, and they want their webmail. >> >> And they want their Window$ and their [insert random Window$-only software, >> no matter whether we have a better equivalent or not]. Trying to target >> that kind of users is a lost cause. > > Those users are irrelevant to this discussion, they're not trying to use > Fedora. > > The last thing we want to do, after finally convincing them to make the > big choice of trying Fedora, is confuse them and scare them off with KDE > vs GNOME politics. Hey I leave the lists for a year??? and we are back to the same discussion with the same people and the same points. Not that this ever works, but could everyone calm down and think for a bit. If things have not changed in the last year, why? Its easy to say its a Red Hat (or insert capitalist corporation logo here) conspiracy but its more likely that the way people are approaching the problem are either not making their case or actually making it worse. Has anyone worked on creating patches to anaconda or firstboot to make these choices easy? The code path would be something where a) someone could say 'I only want X' or 'I want X & Y' or 'I want to show {LONG LIST}?' Is anyone willing to maintain those patches outside of upstream for any length of time? If those questions can be answered then the harder ones can be dealt with How does one present choices that are not biasing? I mean if we are going for equal footing then how do you deal with things like people choosing the first thing predominantly or Left to Right etc? -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From kevin.kofler at chello.at Tue May 5 19:16:26 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 05 May 2009 21:16:26 +0200 Subject: Abandon "Default Desktop" References: <1241490459.6639.115.camel@localhost.localdomain> <200905042315.31519.wm161@wm161.net> <1241495447.6639.129.camel@localhost.localdomain> <1241547497.31208.5.camel@localhost.localdomain> <80d7e4090905051153t1bfdd3ffidc11704d9e5d4b7b@mail.gmail.com> Message-ID: Stephen John Smoogen wrote: > How does one present choices that are not biasing? I mean if we are > going for equal footing then how do you deal with things like people > choosing the first thing predominantly or Left to Right etc? Look, I know perfectly well that there's no perfect solution. Under my proposal, GNOME would be listed first and I'd still be perfectly happy with that because it would still be a lot fairer than the status quo. Just because we can't be perfectly fair doesn't mean we shouldn't stride for fairness at all. Kevin Kofler From kevin.kofler at chello.at Tue May 5 19:20:12 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 05 May 2009 21:20:12 +0200 Subject: Abandon "Default Desktop" References: <49FD51ED.7000906@alexhudson.com> <49FF1F69.1090100@hi.is> <49FF23CA.3000103@gmail.com> <49FF2E09.1010607@hi.is> <1241461591.3570.51.camel@localhost.localdomain> <49FF3DA1.2050801@hi.is> <20090504194148.GA4683@yoda.jdub.homelinux.org> <20090505000507.GA22259@hansolo.jdub.homelinux.org> <2d319b780905051103n26d41e95heb37ac5a9056ef55@mail.gmail.com> Message-ID: Mathieu Bridon (bochecha) wrote: > Make it a checkbox, some people want both. > > Wow, that looks a lot like what we already have in the packages > selection page on the DVD... The point is that it would happen before package selection and it'd influence the whole package selection: selecting e.g. Internet should pick KDE Internet apps, not GNOME ones, by default if KDE was selected as the desktop. Basically, make one simple rough choice first (without getting bothered with details), then get to the finegrained stuff (which should adapt to the coarse-grained choice you made first) or skip it entirely. Kevin Kofler From maxamillion at gmail.com Tue May 5 19:30:32 2009 From: maxamillion at gmail.com (Adam Miller) Date: Tue, 5 May 2009 14:30:32 -0500 Subject: Abandon "Default Desktop" In-Reply-To: References: <49FD51ED.7000906@alexhudson.com> <49FF2E09.1010607@hi.is> <1241461591.3570.51.camel@localhost.localdomain> <49FF3DA1.2050801@hi.is> <20090504194148.GA4683@yoda.jdub.homelinux.org> <20090505000507.GA22259@hansolo.jdub.homelinux.org> <2d319b780905051103n26d41e95heb37ac5a9056ef55@mail.gmail.com> Message-ID: I'm tired of this thread cluttering my inbox. https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html -Adam -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From kevin.kofler at chello.at Tue May 5 19:41:33 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 05 May 2009 21:41:33 +0200 Subject: Abandon "Default Desktop" References: <49FD51ED.7000906@alexhudson.com> <49FF2E09.1010607@hi.is> <1241461591.3570.51.camel@localhost.localdomain> <49FF3DA1.2050801@hi.is> <20090504194148.GA4683@yoda.jdub.homelinux.org> <20090505000507.GA22259@hansolo.jdub.homelinux.org> <2d319b780905051103n26d41e95heb37ac5a9056ef55@mail.gmail.com> Message-ID: Adam Miller wrote: > https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html That's a piece of opinion by one of our X11 developers. I don't agree with the "Linux is not about choice" statement, or at least its implied meaning. (Maybe GNU/Linux is not _about_ choice, but that doesn't mean choice shouldn't be _part_ of the experience.) Kevin Kofler From jspaleta at gmail.com Tue May 5 19:57:09 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 5 May 2009 11:57:09 -0800 Subject: Abandon "Default Desktop" In-Reply-To: References: <49FD51ED.7000906@alexhudson.com> <49FF3DA1.2050801@hi.is> <20090504194148.GA4683@yoda.jdub.homelinux.org> <20090505000507.GA22259@hansolo.jdub.homelinux.org> <2d319b780905051103n26d41e95heb37ac5a9056ef55@mail.gmail.com> Message-ID: <604aa7910905051257q7cc2d2e1s24b028b725e95a0b@mail.gmail.com> On Tue, May 5, 2009 at 11:41 AM, Kevin Kofler wrote: > That's a piece of opinion by one of our X11 developers. I don't agree with the > "Linux is not about choice" statement, or at least its implied meaning. (Maybe > GNU/Linux is not _about_ choice, but that doesn't mean choice shouldn't be > _part_ of the experience.) The underlying issue is how to expose choice. And its a really really tough issue from a user experience and interface design perspective. I don't think anyone has a really good handle on how to do that for the website yet. I can't easily dismiss out of hand the statements that the website was redesigned to minimize confusion. I wasn't confused, but I live in the %0.1 technically literate tail of the general population...my personal experience is by definition abnormal..quite possible not even categorized has a human experience at all. I don't know what the best answer is for the website. I'd love to throw a team of UI experts into a room..lock the door...video tape the discussion..and then not let them out until the come to consensus on how to handle the website spin choice interface...and then we all just live with the result of their consensus opinion. Now I think there might be more hope for the idea of re-engineering comps such that on user selection of DE sets a better set of default package selections in the DVD installer. Sadly I don't know enough about comps conditionals to make a strongly informed statement or to build a toy comps that demonstrates it in action. -jef From mike at cchtml.com Tue May 5 20:24:20 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Tue, 05 May 2009 15:24:20 -0500 Subject: Abandon "Default Desktop" In-Reply-To: <604aa7910905051257q7cc2d2e1s24b028b725e95a0b@mail.gmail.com> References: <49FD51ED.7000906@alexhudson.com> <49FF3DA1.2050801@hi.is> <20090504194148.GA4683@yoda.jdub.homelinux.org> <20090505000507.GA22259@hansolo.jdub.homelinux.org> <2d319b780905051103n26d41e95heb37ac5a9056ef55@mail.gmail.com> <604aa7910905051257q7cc2d2e1s24b028b725e95a0b@mail.gmail.com> Message-ID: <4A00A074.7040903@cchtml.com> -------- Original Message -------- Subject: Re: Abandon "Default Desktop" From: Jeff Spaleta To: Development discussions related to Fedora Date: 05/05/2009 02:57 PM > > The underlying issue is how to expose choice. And its a really really > tough issue from a user experience and interface design perspective. > I don't think anyone has a really good handle on how to do that for > the website yet. I can't easily dismiss out of hand the statements > that the website was redesigned to minimize confusion. I wasn't > confused, but I live in the %0.1 technically literate tail of the > general population...my personal experience is by definition > abnormal..quite possible not even categorized has a human experience > at all. I don't know what the best answer is for the website. I'd > love to throw a team of UI experts into a room..lock the door...video > tape the discussion..and then not let them out until the come to > consensus on how to handle the website spin choice interface...and > then we all just live with the result of their consensus opinion. It sounds like you need to break down the choice based on the type of people making it. 1) Uninformed public Choice: "I'm a newbie, what's Linux?" 2) Informed public Choice: "I know what Gnome and KDE are." 3) Technical person Choice: "I know how to compile a shell." Based on experience level you could create a web site that points you to the correct install DVD for you. Group 1: "I want something like Windows" - KDE spin "... Apple" - Gnome spin Group 2: "I know what I want" - show all spins Group 3: Doesn't need any help, they already bookmarked the torrent page, or are using yum/PackageKit to update. > > Now I think there might be more hope for the idea of re-engineering > comps such that on user selection of DE sets a better set of default > package selections in the DVD installer. Sadly I don't know enough > about comps conditionals to make a strongly informed statement or to > build a toy comps that demonstrates it in action. Instead of torrenting DVD ISOs we should be torrenting the packages themselves. The website could build your customized OS and send you a torrent link that would build you a install DVD just for you. You could tie *all* this together with a username/password so that people could remember the previous install sets and share them with friends. This could be Fedora FAS so that people could start interacting with the mailing lists, bug reporting, and maybe even QA. From sundaram at fedoraproject.org Tue May 5 21:41:53 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 06 May 2009 03:11:53 +0530 Subject: Abandon "Default Desktop" In-Reply-To: References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <49F80664.6010809@robertoragusa.it> <1241037119.3213.2.camel@localhost.localdomain> <6c3f5e6c0904291514n371fa179k1901af657e05a5b5@mail.gmail.com> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <16de708d0904301051r647b9f14qc1fe7d343bdbd778@mail.gmail.com> <1241114354.7846.5.camel@localhost.localdomain> Message-ID: <4A00B2A1.7080006@fedoraproject.org> On 05/02/2009 11:27 PM, Kevin Kofler wrote: > As for DeviceKit: what exactly does this bring to the user? I see only a > limited set of new features. The main point is really that it is new code > and HAL is old, and yes, a DeviceKit backend for Solid is needed. But I > can't see how not having it available now is going to make KDE look bad. For one, HAL is deprecated and is getting replaced by DeviceKit. You need to get off the legacy framework and move into the new one but that is a implementation detail. The real deal is the functionality implemented on top of the new framework. Among other things, look at http://blog.fubar.dk/?p=105 nautilus-gdu extension is another. Rahul From sundaram at fedoraproject.org Tue May 5 21:48:12 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 06 May 2009 03:18:12 +0530 Subject: Abandon "Default Desktop" In-Reply-To: <4A00A074.7040903@cchtml.com> References: <49FD51ED.7000906@alexhudson.com> <49FF3DA1.2050801@hi.is> <20090504194148.GA4683@yoda.jdub.homelinux.org> <20090505000507.GA22259@hansolo.jdub.homelinux.org> <2d319b780905051103n26d41e95heb37ac5a9056ef55@mail.gmail.com> <604aa7910905051257q7cc2d2e1s24b028b725e95a0b@mail.gmail.com> <4A00A074.7040903@cchtml.com> Message-ID: <4A00B41C.4030500@fedoraproject.org> On 05/06/2009 01:54 AM, Michael Cronenworth wrote: > > It sounds like you need to break down the choice based on the type of > people making it. You need to work with the websites team in fedora-websites list. They already have discussed some improvements. > Instead of torrenting DVD ISOs we should be torrenting the packages > themselves. The website could build your customized OS and send you a > torrent link that would build you a install DVD just for you. Torrent in not a efficient method for smaller sizes files which is the case for most of the packages. Also, look at https://fedorahosted.org/wevisor/ Seems to be a inactive project for a while now. Rahul From sundaram at fedoraproject.org Tue May 5 22:25:45 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 06 May 2009 03:55:45 +0530 Subject: Note on man pages Message-ID: <4A00BCE9.3050800@fedoraproject.org> Hi, Debian has a policy that all the commands should have man pages as part of their review process. Unfortunately they don't seem to be sending it upstream. If you are a package maintainer for some application, that is missing a man page, it might be a good to look into the Debian sources for man page patches, add them to your package and send it upstream as well. Note that upstream might require you to clean up the man page in the process. Rahul From kevin.kofler at chello.at Wed May 6 02:39:44 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 06 May 2009 04:39:44 +0200 Subject: Abandon "Default Desktop" References: <49FD51ED.7000906@alexhudson.com> <49FF3DA1.2050801@hi.is> <20090504194148.GA4683@yoda.jdub.homelinux.org> <20090505000507.GA22259@hansolo.jdub.homelinux.org> <2d319b780905051103n26d41e95heb37ac5a9056ef55@mail.gmail.com> <604aa7910905051257q7cc2d2e1s24b028b725e95a0b@mail.gmail.com> <4A00A074.7040903@cchtml.com> Message-ID: Michael Cronenworth wrote: > "I want something like Windows" - KDE spin > "... Apple" - Gnome spin Uh, that's 1. oversimplifying and 2. probably trademark infringement. Kevin Kofler From kevin.kofler at chello.at Wed May 6 02:44:22 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 06 May 2009 04:44:22 +0200 Subject: Abandon "Default Desktop" References: <3adc77210904271504k1e72f370o41f47c7cb0ae67b1@mail.gmail.com> <49F80664.6010809@robertoragusa.it> <1241037119.3213.2.camel@localhost.localdomain> <6c3f5e6c0904291514n371fa179k1901af657e05a5b5@mail.gmail.com> <20090430002417.GA11190@orient.maison.lan> <49F91878.2040609@redhat.com> <1241069621.32113.260.camel@adam.local.net> <49F966D4.5060502@robertoragusa.it> <49F96CE6.5090504@fedoraproject.org> <16de708d0904301051r647b9f14qc1fe7d343bdbd778@mail.gmail.com> <1241114354.7846.5.camel@localhost.localdomain> <4A00B2A1.7080006@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > For one, HAL is deprecated and is getting replaced by DeviceKit. You > need to get off the legacy framework and move into the new one Yes, I know, but... > but that is a implementation detail. ... right, that's what I was saying. ;-) > The real deal is the functionality implemented on top of the new > framework. Among other things, look at > > http://blog.fubar.dk/?p=105 > > nautilus-gdu extension is another. Unfortunately, writing a DeviceKit backend for Solid isn't going to magically give us that stuff, we need either to extend Solid to support the new functionality (as has already been done for other stuff, the Solid API is not set in stone, stuff can get added as long as binary compatibility is kept) or write apps directly against DeviceKit-disks. I think we first need to shoot for a DeviceKit backend to Solid which implements the existing Solid interfaces. Kevin Kofler From kevin.kofler at chello.at Wed May 6 02:47:09 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 06 May 2009 04:47:09 +0200 Subject: Note on man pages References: <4A00BCE9.3050800@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > Debian has a policy that all the commands should have man pages as part > of their review process. Unfortunately they don't seem to be sending it > upstream. If you are a package maintainer for some application, that is > missing a man page, it might be a good to look into the Debian sources > for man page patches, add them to your package and send it upstream as > well. Note that upstream might require you to clean up the man page in > the process. Well, there are many upstreams rejecting Debian's patches outright, saying manpages are obsolete and redundant with any of: * info documentation (those are mostly the GNU projects), * HTML/docbook/GUI documentation (that has long been KDE's position, but recently they have started merging manpages from Debian), * plaintext documentation or * --help or other usage output. Kevin Kofler From mike at cchtml.com Wed May 6 03:19:06 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Tue, 05 May 2009 22:19:06 -0500 Subject: Note on man pages In-Reply-To: References: <4A00BCE9.3050800@fedoraproject.org> Message-ID: <4A0101AA.4010200@cchtml.com> Kevin Kofler wrote: > Rahul Sundaram wrote: > >> Debian has a policy that all the commands should have man pages as part >> of their review process. Unfortunately they don't seem to be sending it >> upstream. If you are a package maintainer for some application, that is >> missing a man page, it might be a good to look into the Debian sources >> for man page patches, add them to your package and send it upstream as >> well. Note that upstream might require you to clean up the man page in >> the process. >> > > Well, there are many upstreams rejecting Debian's patches outright, saying > manpages are obsolete and redundant with any of: > * info documentation (those are mostly the GNU projects), > * HTML/docbook/GUI documentation (that has long been KDE's position, but > recently they have started merging manpages from Debian), > * plaintext documentation or > * --help or other usage output. > Why does this discussion sound so familiar? [1] :) [1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02015.html From smooge at gmail.com Wed May 6 03:21:57 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 5 May 2009 21:21:57 -0600 Subject: Abandon "Default Desktop" In-Reply-To: References: <1241490459.6639.115.camel@localhost.localdomain> <200905042315.31519.wm161@wm161.net> <1241495447.6639.129.camel@localhost.localdomain> <1241547497.31208.5.camel@localhost.localdomain> <80d7e4090905051153t1bfdd3ffidc11704d9e5d4b7b@mail.gmail.com> Message-ID: <80d7e4090905052021s6669b85bl1c0d125ec52b54a4@mail.gmail.com> On Tue, May 5, 2009 at 1:16 PM, Kevin Kofler wrote: > Stephen John Smoogen wrote: >> How does one present choices that are not biasing? I mean if we are >> going for equal footing then how do you deal with things like people >> choosing the first thing predominantly or Left to Right etc? > > Look, I know perfectly well that there's no perfect solution. Under my > proposal, GNOME would be listed first and I'd still be perfectly happy with > that because it would still be a lot fairer than the status quo. Just > because we can't be perfectly fair doesn't mean we shouldn't stride for > fairness at all. Sorry I went a little far with my rhetoric. Could you help me on where this would make more sense for the user to make such a choice? That way I can look to see what an out of band patch might look like? -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From kevin.kofler at chello.at Wed May 6 03:51:16 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 06 May 2009 05:51:16 +0200 Subject: Abandon "Default Desktop" References: <1241490459.6639.115.camel@localhost.localdomain> <200905042315.31519.wm161@wm161.net> <1241495447.6639.129.camel@localhost.localdomain> <1241547497.31208.5.camel@localhost.localdomain> <80d7e4090905051153t1bfdd3ffidc11704d9e5d4b7b@mail.gmail.com> <80d7e4090905052021s6669b85bl1c0d125ec52b54a4@mail.gmail.com> Message-ID: Stephen John Smoogen wrote: > Sorry I went a little far with my rhetoric. Could you help me on > where this would make more sense for the user to make such a choice? > That way I can look to see what an out of band patch might look like? For the installer part? (The web page part doesn't really need a patch...) 1. Before the package selection, present a screen like this: http://files.opensuse.org/opensuse/en/9/95/11_1-install-007.png The wording there leaves much to be desired, and of course there wouldn't be a KDE 3.5 option in Fedora. But it's the general idea. 2. Change the files presented by the package selection so e.g. "Internet applications" will default to KDE packages rather than GNOME ones if KDE is selected. I can see 2 possible ways to implement this: a. have separate comps-f12-gnome.xml.in and comps-f12-kde.xml.in or b. extend the type (e.g. type="default") attribute of the packagereq tag in comps so it can be something like: type="optional" type-gnome="default", type="optional" type-kde="default", type="default" type-kde="optional" etc. I like option b. better as it avoids redundancy and eases maintenance (most stuff will be optional either way). Kevin Kofler From abu_hurayrah at hidayahonline.org Wed May 6 03:52:51 2009 From: abu_hurayrah at hidayahonline.org (Basil Mohamed Gohar) Date: Wed, 06 May 2009 11:52:51 +0800 Subject: Note on man pages In-Reply-To: <4A0101AA.4010200@cchtml.com> References: <4A00BCE9.3050800@fedoraproject.org> <4A0101AA.4010200@cchtml.com> Message-ID: <4A010993.9060004@hidayahonline.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/06/2009 11:19 AM, Michael Cronenworth wrote: > > Why does this discussion sound so familiar? [1] > > :) > > [1] > https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02015.html > Which reminds me that I've done zilch for it other than a few exploratory steps to see what had a manpage already and what didn't. There was some discussion on the fedora-docs list about this (not my failure to do anything, but rather, the steps involved in going forward). - -- Basil Mohamed Gohar abu_hurayrah at hidayahonline.org http://www.basilgohar.com/blog/ basilgohar on irc.freenode.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkoBCY4ACgkQaVgOCFr0s2LJCQCgolRYSbfYhnAljk3aLJW98jT3 fE0AniC92eCBXQsljswnXwmjditCIMKy =twWD -----END PGP SIGNATURE----- From lsof at nodata.co.uk Wed May 6 05:33:55 2009 From: lsof at nodata.co.uk (nodata) Date: Wed, 06 May 2009 07:33:55 +0200 Subject: Note on man pages In-Reply-To: References: <4A00BCE9.3050800@fedoraproject.org> Message-ID: <1241588035.7862.2.camel@prague> Am Mittwoch, den 06.05.2009, 04:47 +0200 schrieb Kevin Kofler: > Rahul Sundaram wrote: > > Debian has a policy that all the commands should have man pages as part > > of their review process. Unfortunately they don't seem to be sending it > > upstream. If you are a package maintainer for some application, that is > > missing a man page, it might be a good to look into the Debian sources > > for man page patches, add them to your package and send it upstream as > > well. Note that upstream might require you to clean up the man page in > > the process. > > Well, there are many upstreams rejecting Debian's patches outright, saying > manpages are obsolete and redundant with any of: > * info documentation (those are mostly the GNU projects), /me still secretly hopes info pages go away. > * HTML/docbook/GUI documentation (that has long been KDE's position, but > recently they have started merging manpages from Debian), > * plaintext documentation or > * --help or other usage output. > > Kevin Kofler > From jussi.lehtola at iki.fi Wed May 6 05:46:31 2009 From: jussi.lehtola at iki.fi (Jussi Lehtola) Date: Wed, 06 May 2009 08:46:31 +0300 Subject: Note on man pages In-Reply-To: <1241588035.7862.2.camel@prague> References: <4A00BCE9.3050800@fedoraproject.org> <1241588035.7862.2.camel@prague> Message-ID: <1241588791.3101.2.camel@localhost.localdomain> On Wed, 2009-05-06 at 07:33 +0200, nodata wrote: > Am Mittwoch, den 06.05.2009, 04:47 +0200 schrieb Kevin Kofler: > > Well, there are many upstreams rejecting Debian's patches outright, saying > > manpages are obsolete and redundant with any of: > > * info documentation (those are mostly the GNU projects), > > /me still secretly hopes info pages go away. +1 >From a usability point of view there's nothing that beats man pages. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From maxamillion at gmail.com Wed May 6 05:51:39 2009 From: maxamillion at gmail.com (Adam Miller) Date: Wed, 6 May 2009 00:51:39 -0500 Subject: Note on man pages In-Reply-To: <1241588791.3101.2.camel@localhost.localdomain> References: <4A00BCE9.3050800@fedoraproject.org> <1241588035.7862.2.camel@prague> <1241588791.3101.2.camel@localhost.localdomain> Message-ID: +1 -Adam (From my G1) On May 6, 2009 12:47 AM, "Jussi Lehtola" wrote: On Wed, 2009-05-06 at 07:33 +0200, nodata wrote: > Am Mittwoch, den 06.05.2009, 04:47 +0200 schrieb ... > > Well, there are many upstreams rejecting Debian's patches outright, saying > > manpages are obso... +1 >From a usability point of view there's nothing that beats man pages. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/list... -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannbg at hi.is Wed May 6 08:35:55 2009 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Wed, 06 May 2009 08:35:55 +0000 Subject: Abandon "Default Desktop" In-Reply-To: References: <1241490459.6639.115.camel@localhost.localdomain> <200905042315.31519.wm161@wm161.net> <1241495447.6639.129.camel@localhost.localdomain> <1241547497.31208.5.camel@localhost.localdomain> <80d7e4090905051153t1bfdd3ffidc11704d9e5d4b7b@mail.gmail.com> <80d7e4090905052021s6669b85bl1c0d125ec52b54a4@mail.gmail.com> Message-ID: <4A014BEB.5070405@hi.is> Kevin Kofler wrote: > Stephen John Smoogen wrote: > >> Sorry I went a little far with my rhetoric. Could you help me on >> where this would make more sense for the user to make such a choice? >> That way I can look to see what an out of band patch might look like? >> > > For the installer part? (The web page part doesn't really need a patch...) > > 1. Before the package selection, present a screen like this: > http://files.opensuse.org/opensuse/en/9/95/11_1-install-007.png > The wording there leaves much to be desired, and of course there wouldn't be > a KDE 3.5 option in Fedora. But it's the general idea. > > The above selection screen in the is something like I had in mind I did file a bug against Anaconda a while back ( #493302 ) where I asked for the ability to select XFCE, LXDE in the "Desktop Environment" section in Anaconda and it got closed as a NOTABUG. In the Desktop option there should be at least 5 options as I see it Gome KDE LXDE SUGAR ( Let's not forget Sugar ) XFCE With regards to http://fedoraproject.org/en/get-fedora There also should be offered 5 Desktop options Fedora $Release Desktop Gnome Fedora $Release Desktop KDE Fedora $Release Desktop LXDE Fedora $Release Desktop Sugar Fedora $Release Desktop XFCE Each DE section should contain brief description of the DE along with a link like "Explorer" which would take the end user to http://fedorarpoject.org/wiki/Desktop/$DE ( Which contains screenshoots etc.. ) along with another link like "Try It x86" and "Try It 64bit" which the end user could click and he would download the live CD. But these are just implementation idea's first we need to reach consciousness that there is not one DESKTOP to rule them all.. JBG -------------- next part -------------- A non-text attachment was scrubbed... Name: johannbg.vcf Type: text/x-vcard Size: 356 bytes Desc: not available URL: From frankly3d at gmail.com Wed May 6 09:03:34 2009 From: frankly3d at gmail.com (Frank Murphy (Frankly3D)) Date: Wed, 06 May 2009 10:03:34 +0100 Subject: Abandon "Default Desktop" In-Reply-To: References: <49F580E2.8090404@hi.is> Message-ID: <4A015266.608@gmail.com> On 28/04/09 22:46, Kevin Kofler wrote: As the NON-Developer. Who installs Fedora on Linux newcomers PC's. Some thoughts. On the http://fedoraproject.org/en/get-fedora Changes: Get Fedora 10 Desktop Edition Now to: Get Fedora 10 Gnome LiveCD Edition Now Get Fedora 10 KDE LiveCD Edition Now. With a brief idea on both, with more info links'. For older PC, or Lightweight Desktop "click here" (XFCE, LXDE) From: Upgrade to Fedora 10 from an older version to: Install Fedora 10 from DVD Gnome pre-picked as default for new users. "change to KDE, XFCE, LXDE, Terminal only click here" No need to change lots of packages, just presentation Everyone wins Frank -- msn: frankly3d skype: frankly3d Still Learning From choeger at cs.tu-berlin.de Wed May 6 09:19:40 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Wed, 06 May 2009 11:19:40 +0200 Subject: what is needed for plymouth to boot with gfx? Message-ID: <1241601580.2711.1.camel@choeger6> Hi, after the latest batch of updates I got pretty KMS-based-shutdown gfx from plymouth, but (still) no bootup gfx. What is needed to get that too? (plugins and stuff are installed, kms works) regards christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From the.masch at gmail.com Wed May 6 10:16:45 2009 From: the.masch at gmail.com (Mario Chacon) Date: Wed, 6 May 2009 07:16:45 -0300 Subject: Intel driver 2.7.99.1 Message-ID: <93d66b780905060316i28593b91wa94e4f55e49937f4@mail.gmail.com> Hello: Is it possible to have the intel 2.7.99.1 snapshot to make some test before the release?? Salu2... masch... -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnocera at redhat.com Wed May 6 10:51:30 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Wed, 06 May 2009 11:51:30 +0100 Subject: The Great Pulseaudio Mixer Debate: a modest (productive) proposal In-Reply-To: <1241430099.6126.42.camel@macbook.infradead.org> References: <1240596206.3955.245.camel@adam.local.net> <200904251714.07573.billcrawford1970@gmail.com> <6d959d480904250934h1fb12465ue60b55866d4a188c@mail.gmail.com> <200904271329.04618.billcrawford1970@gmail.com> <49F5E241.2030603@cchtml.com> <1240964482.2656.8.camel@localhost.localdomain> <49F85255.3090708@hidayahonline.org> <1241373392.2632.65.camel@localhost.localdomain> <1241430099.6126.42.camel@macbook.infradead.org> Message-ID: <1241607090.2535.7302.camel@cookie.hadess.net> On Mon, 2009-05-04 at 10:41 +0100, David Woodhouse wrote: > On Sun, 2009-05-03 at 12:56 -0500, Callum Lerwick wrote: > > Hrm, pulseaudio's logging seems to have changed. You can try running > > "pulseaudio -k;pulseaudio -v" then dig through the spew: > > After I do this, my volume control applet in the panel (actually, for > some bizarre reason it's now in the notification area, rather than in > the place in the panel where I explicitly placed it in F-10) no longer > works. It's a known upstream bug: http://bugzilla.gnome.org/show_bug.cgi?id=564311 From poelstra at redhat.com Wed May 6 12:45:34 2009 From: poelstra at redhat.com (John Poelstra) Date: Wed, 06 May 2009 05:45:34 -0700 Subject: Fedora Release Engineering Meeting Recap - 2009-05-04 In-Reply-To: <20090504200148.GB3699@nostromo.devel.redhat.com> References: <20090504200148.GB3699@nostromo.devel.redhat.com> Message-ID: <4A01866E.8060201@redhat.com> Bill Nottingham said the following on 05/04/2009 01:01 PM Pacific Time: > == Preview Release == > > Known issues: > > * PPC had a variety of issues > o oversized > o installed the wrong kernel > o failed to install a bootloader > * assorted anaconda partitioning issues > > Discussed maybe using a separate config for PPC to keep it under size > constraints, but it was decided to stay with one config. > > == Deltarpm for F11 == > > Work needs done to either compose updates in a chroot (which has the F11 > deltarpm support) or to backport it to the OS release used to generate > updates. Seth Vidal is going to investigate which of these makes more sense. > Given the timeframe, this is tight for F11 final. rawhide will continue to > have deltas, as that's a separate compose process. > > == F12 schedule == > > The schedule proposed by John Poelstra for Fedora 12 in > https://fedorahosted.org/rel-eng/ticket/1271 was reviewed. The following > changes were approved: > > * the alpha milestone was removed entirely Reading the IRC log am I correct in understanding that a more detailed summary is: "Remove all alpha release tasks from the schedule. There will be no alpha release because it does not provide enough value for the effort required to create it. There is little public testing value from it either." ? 1) What dates are we proposing for releasing "development snapshots" before the beta? We should put these on the schedule now. 2) The alpha release has always been a good first opportunity to start marketing our next release, sending out press releases, etc. Basically, drawing attention to the fact with the general public that a new release is in the works. Without an Alpha the first general press releases would be a month later. Is this okay? The Alpha also naturally gets the release notes process and other parts of Fedora going (not development focused tasks) early which is a good thing. We'd be losing that too. 3) If we do away with Alpha as we know it, leaving two test releases, can we simply call them "Alpha" and "Beta"? I've always thought "Preview Release" was a funny name for a test release and I think the terms "Alpha" and "Beta" are more familiar to the general public. Thanks, John > * due to conferences such as the Red Hat Summit, LinuxCon, and Linux > Plumber's Conference, each milestone from 'Final freeze: development' > (2009-09-15) should be shifted out one week. > > This pushes GA from 2009-10-27 to 2009-11-03. The schedule will be presented > for FESCo discussion at the 2009-05-08 meeting. > > For more information on any of these, see the full transcript at: > https://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2009-may-04 > From walters at verbum.org Wed May 6 13:11:36 2009 From: walters at verbum.org (Colin Walters) Date: Wed, 6 May 2009 09:11:36 -0400 Subject: Abandon "Default Desktop" In-Reply-To: <4A014BEB.5070405@hi.is> References: <200905042315.31519.wm161@wm161.net> <1241495447.6639.129.camel@localhost.localdomain> <1241547497.31208.5.camel@localhost.localdomain> <80d7e4090905051153t1bfdd3ffidc11704d9e5d4b7b@mail.gmail.com> <80d7e4090905052021s6669b85bl1c0d125ec52b54a4@mail.gmail.com> <4A014BEB.5070405@hi.is> Message-ID: 2009/5/6 "J?hann B. Gu?mundsson" : > > I did file a bug against Anaconda a while back ( #493302 ) where I asked for > the ability to select XFCE, LXDE in the "Desktop Environment" section in > Anaconda > and it got closed as a NOTABUG. We need to have people installing be spending less time in Anaconda-the-OS (typically run from DVD), not more. Why? The main reason is that in Anaconda-the-OS, you don't have a *web browser*, the most important tool needed for semi-technical people to try to understand the tradeoffs between choices thrown at them. (And also extremely useful for technical people to interact with e.g. bugzilla). Basically we should funnel almost all unmanaged users[1] towards a live image, be that CD or USB based, where you "try before you buy" and most importantly have a functioning network setup and a web browser. > With regards to http://fedoraproject.org/en/get-fedora I don't have a lot to add here on the website aspect that hasn't been covered already. From rawhide at fedoraproject.org Wed May 6 14:03:12 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Wed, 6 May 2009 14:03:12 +0000 (UTC) Subject: rawhide report: 20090506 changes Message-ID: <20090506140312.1A6221F820C@releng2.fedora.phx.redhat.com> Compose started at Wed May 6 06:15:03 UTC 2009 Updated Packages: audio-entropyd-2.0.1-1.fc11 --------------------------- * Tue May 05 2009 Tom "spot" Callaway - 2.0.1-1 - upstream took my alsa patch (improved on it too) control-center-2.26.0-6.fc11 ---------------------------- * Wed Apr 29 2009 Matthias Clasen - 2.26.0-6 - Don't rely on _BACKUP property for xkb initialization fcoe-utils-1.0.7-4.fc11 ----------------------- * Mon Apr 27 2009 Jan Zeleny - 1.0.7-4 - added libhbalinux to Requires (#497605) gdm-2.26.1-7.fc11 ----------------- * Wed Apr 29 2009 Matthias Clasen - 1:2.26.1-7 - Don't rely on _BACKUP property for xkb initialization * Tue Apr 28 2009 Ray Strode - 1:2.26.1-5 - fix crash at shutdown * Tue Apr 28 2009 Matthias Clasen - 1:2.26.1-6 - fix a use-after-free in XDMCP code paths (#496882) gnome-settings-daemon-2.26.1-4.fc11 ----------------------------------- kde-settings-4.2-10.20090430svn.fc11 ------------------------------------ * Thu Apr 30 2009 Rex Dieter - 4.2-10.20090430svn - nepomukserverrc: disable nepomuk libvirt-0.6.2-4.fc11 -------------------- * Tue May 05 2009 Daniel P. Berrange - 0.6.2-4.fc11 - Fix labelling of shared/readonly disks (rhbz #493692) nautilus-sendto-1.1.5-1.fc11 ---------------------------- * Tue May 05 2009 Bastien Nocera 1.1.5-1 - Update to 1.1.5 * Tue Apr 28 2009 Bastien Nocera 1.1.4.1-2 - Build with gajim support (#497975) totem-2.26.2-1.fc11 ------------------- * Sun May 03 2009 Bastien Nocera 2.26.2-1 - Update to 2.26.2 * Tue Apr 28 2009 Bastien Nocera 2.26.1-4 - Add missing pyxdg requires for the OpenSubtitles plugin (#497787) * Thu Apr 23 2009 Bastien Nocera 2.26.1-3 - Add missing gnome-python2-gconf req (#483265) totem-pl-parser-2.26.2-1.fc11 ----------------------------- * Sun May 03 2009 Bastien Nocera 2.26.2-1 - Update to 2.26.2 xorg-x11-drv-ati-6.12.2-11.fc11 ------------------------------- * Tue May 05 2009 Dave Airlie 6.12.2-10 - radeon-modeset-fixes.patch: backport fixes from upstream for rs480 firefox gpu crash * Tue May 05 2009 Dave Airlie 6.12.2-11 - make src/mask prepare access force to GTT. * Tue Apr 28 2009 Dave Airlie 6.12.2-8 - restrict texture coords to 0.0->1.0 explicitly. - enable gamma now kernel is tagged * Tue Apr 28 2009 Dave Airlie 6.12.2-9 - fix gamma code to work properly - bump kernel requires for gamma interface not oopsing xorg-x11-drv-synaptics-1.1.0-5.fc11 ----------------------------------- * Tue May 05 2009 Peter Hutterer 1.1.0-4 - synaptics-1.1.0-edges.patch: Set default edge sizes depending on model (#494766). * Tue May 05 2009 Peter Hutterer 1.1.0-5 - synaptics-1.1.0-nograb-fail.patch: fail if the device cannot be grabbed (#499058) xorg-x11-server-1.6.1-11.fc11 ----------------------------- * Mon May 04 2009 Adam Jackson 1.6.1-10 - xserver-1.6.1-nouveau.patch: Update the autoconfig logic for nv3 and other historical oddities. * Mon May 04 2009 Adam Jackson 1.6.1-11 - xserver-1.6.1-document-fontpath-correctly.patch: Typo fixes. * Thu Apr 23 2009 Dave Airlie 1.6.1-8 - xserver-1.6.1-exa-create-pixmap2.patch - add support for tiling create pixmap hook - need to fix firefox on ati rs690 crashes * Thu Apr 23 2009 Adam Jackson 1.6.1-9 - xserver-1.6.1-avoid-malloc-for-logging.patch: Don't malloc when logging, since that makes it unsafe to do from a signal handler. * Wed Apr 22 2009 Adam Jackson 1.6.1-7 - Conflict with too-old versions of xorg-x11-drivers. (#497144) Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 13 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From walters at verbum.org Wed May 6 14:16:09 2009 From: walters at verbum.org (Colin Walters) Date: Wed, 6 May 2009 10:16:09 -0400 Subject: Annoying screen blanking In-Reply-To: References: <1241190083.7744.54.camel@dimi.lattica.com> <1241191861.2811.10.camel@adam.local.net> <1241192327.7744.59.camel@dimi.lattica.com> <49FB193B.4070101@fedoraproject.org> <1241193267.2811.15.camel@adam.local.net> <1241205568.3570.19.camel@localhost.localdomain> Message-ID: On Fri, May 1, 2009 at 4:34 PM, Avery, David [DENTK] wrote: > My concern is this bug makes Fedora 11 a no-go on systems that are running as display drivers or kiosks where there as a real need for poweroff == never, screeenblank == never. There's a patch existing, and if it doesn't make the release it will likely become an update after. In the meantime it should be relatively straightforward to use the development package from the build system (koji). From naheemzaffar at gmail.com Wed May 6 14:54:33 2009 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Wed, 6 May 2009 15:54:33 +0100 Subject: what is needed for plymouth to boot with gfx? In-Reply-To: <1241601580.2711.1.camel@choeger6> References: <1241601580.2711.1.camel@choeger6> Message-ID: <3adc77210905060754t4b1500a6r14ca0cec909b35e9@mail.gmail.com> "rhgb" in grub as a boot option. 2009/5/6 Christoph H?ger > Hi, > > after the latest batch of updates I got pretty KMS-based-shutdown gfx > from plymouth, but (still) no bootup gfx. > > What is needed to get that too? > (plugins and stuff are installed, kms works) > > > regards > > christoph > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From choeger at cs.tu-berlin.de Wed May 6 15:19:43 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Wed, 06 May 2009 17:19:43 +0200 Subject: what is needed for plymouth to boot with gfx? In-Reply-To: <3adc77210905060754t4b1500a6r14ca0cec909b35e9@mail.gmail.com> References: <1241601580.2711.1.camel@choeger6> <3adc77210905060754t4b1500a6r14ca0cec909b35e9@mail.gmail.com> Message-ID: <1241623183.2646.2.camel@choeger6> Am Mittwoch, den 06.05.2009, 15:54 +0100 schrieb Naheem Zaffar: > "rhgb" in grub as a boot option. I have that: kernel /vmlinuz-2.6.29.2-126.fc11.i586 ro root=/dev/VolGroup00/LogVol01 rhgb quiet Also /usr/lib/plymouth looks like: drwxr-xr-x. 2 root root 4096 6. Mai 00:21 . drwxr-xr-x. 228 root root 135168 6. Mai 03:50 .. lrwxrwxrwx. 1 root root 13 6. Mai 00:20 default.so -> spinfinity.so -rwxr-xr-x. 1 root root 10040 1. Mai 19:50 details.so -rwxr-xr-x. 1 root root 7068 1. Mai 19:50 label.so -rwxr-xr-x. 1 root root 29588 1. Mai 19:50 solar.so -rwxr-xr-x. 1 root root 15256 1. Mai 19:50 spinfinity.so -rwxr-xr-x. 1 root root 11508 1. Mai 19:50 text.so But all I see on boot is that progress bar. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From darrellpf at gmail.com Wed May 6 15:25:22 2009 From: darrellpf at gmail.com (darrell pfeifer) Date: Wed, 6 May 2009 08:25:22 -0700 Subject: what is needed for plymouth to boot with gfx? In-Reply-To: <1241623183.2646.2.camel@choeger6> References: <1241601580.2711.1.camel@choeger6> <3adc77210905060754t4b1500a6r14ca0cec909b35e9@mail.gmail.com> <1241623183.2646.2.camel@choeger6> Message-ID: Christoph, The latest plymouths have been a bit of a regression for me. I see some plymouth related locking errors at boot. I've had success with adding 'nomodeset vga=794' on my boot line, which gets the spin version back again. You might not need nomodeset, and vga=794 seems counter-intuitive but works for me. darrell Am Mittwoch, den 06.05.2009, 15:54 +0100 schrieb Naheem Zaffar: > > "rhgb" in grub as a boot option. > > I have that: > kernel /vmlinuz-2.6.29.2-126.fc11.i586 ro root=/dev/VolGroup00/LogVol01 > rhgb quiet > > Also /usr/lib/plymouth looks like: > drwxr-xr-x. 2 root root 4096 6. Mai 00:21 . > drwxr-xr-x. 228 root root 135168 6. Mai 03:50 .. > lrwxrwxrwx. 1 root root 13 6. Mai 00:20 default.so -> > spinfinity.so > -rwxr-xr-x. 1 root root 10040 1. Mai 19:50 details.so > -rwxr-xr-x. 1 root root 7068 1. Mai 19:50 label.so > -rwxr-xr-x. 1 root root 29588 1. Mai 19:50 solar.so > -rwxr-xr-x. 1 root root 15256 1. Mai 19:50 spinfinity.so > -rwxr-xr-x. 1 root root 11508 1. Mai 19:50 text.so > > But all I see on boot is that progress bar. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgboles at comcast.net Wed May 6 15:33:03 2009 From: dgboles at comcast.net (David) Date: Wed, 06 May 2009 11:33:03 -0400 Subject: what is needed for plymouth to boot with gfx? In-Reply-To: <1241623183.2646.2.camel@choeger6> References: <1241601580.2711.1.camel@choeger6> <3adc77210905060754t4b1500a6r14ca0cec909b35e9@mail.gmail.com> <1241623183.2646.2.camel@choeger6> Message-ID: <4A01ADAF.8020509@comcast.net> On 5/6/2009 11:19 AM, Christoph H?ger wrote: > Am Mittwoch, den 06.05.2009, 15:54 +0100 schrieb Naheem Zaffar: >> "rhgb" in grub as a boot option. > I have that: > kernel /vmlinuz-2.6.29.2-126.fc11.i586 ro root=/dev/VolGroup00/LogVol01 > rhgb quiet > Also /usr/lib/plymouth looks like: > drwxr-xr-x. 2 root root 4096 6. Mai 00:21 . > drwxr-xr-x. 228 root root 135168 6. Mai 03:50 .. > lrwxrwxrwx. 1 root root 13 6. Mai 00:20 default.so -> > spinfinity.so > -rwxr-xr-x. 1 root root 10040 1. Mai 19:50 details.so > -rwxr-xr-x. 1 root root 7068 1. Mai 19:50 label.so > -rwxr-xr-x. 1 root root 29588 1. Mai 19:50 solar.so > -rwxr-xr-x. 1 root root 15256 1. Mai 19:50 spinfinity.so > -rwxr-xr-x. 1 root root 11508 1. Mai 19:50 text.so > But all I see on boot is that progress bar. Google is your friend. http://lmgtfy.com/?q=+How+To+Enable+Graphical+Boot+with+Plymouth+in+Fedora+10+ First hit. :-p -- David From jkeating at redhat.com Wed May 6 15:33:22 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 06 May 2009 08:33:22 -0700 Subject: Abandon "Default Desktop" In-Reply-To: <4A014BEB.5070405@hi.is> References: <1241490459.6639.115.camel@localhost.localdomain> <200905042315.31519.wm161@wm161.net> <1241495447.6639.129.camel@localhost.localdomain> <1241547497.31208.5.camel@localhost.localdomain> <80d7e4090905051153t1bfdd3ffidc11704d9e5d4b7b@mail.gmail.com> <80d7e4090905052021s6669b85bl1c0d125ec52b54a4@mail.gmail.com> <4A014BEB.5070405@hi.is> Message-ID: <1241624002.3030.38.camel@localhost.localdomain> On Wed, 2009-05-06 at 08:35 +0000, "J?hann B. Gu?mundsson" wrote: > I did file a bug against Anaconda a while back ( #493302 ) where I asked > for > the ability to select XFCE, LXDE in the "Desktop Environment" section in > Anaconda > and it got closed as a NOTABUG. There isn't really enough room on the DVD to put the other environments. We already had to cut a lot of stuff this release to keep it DVD sized. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Wed May 6 15:39:02 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 6 May 2009 11:39:02 -0400 Subject: Fedora Release Engineering Meeting Recap - 2009-05-04 In-Reply-To: <4A01866E.8060201@redhat.com> References: <20090504200148.GB3699@nostromo.devel.redhat.com> <4A01866E.8060201@redhat.com> Message-ID: <20090506153902.GA15272@nostromo.devel.redhat.com> John Poelstra (poelstra at redhat.com) said: >> * the alpha milestone was removed entirely > > Reading the IRC log am I correct in understanding that a more detailed > summary is: > "Remove all alpha release tasks from the schedule. > There will be no alpha release because it does not > provide enough value for the effort required to create > it. There is little public testing value from it > either." > ? > > 1) What dates are we proposing for releasing "development snapshots" > before the beta? We should put these on the schedule now. Not yet determined. (Skipping over marketing) > The Alpha also naturally gets the release notes process and other parts > of Fedora going (not development focused tasks) early which is a good > thing. We'd be losing that too. Is there no way for these to be started without a milestone? > 3) If we do away with Alpha as we know it, leaving two test releases, > can we simply call them "Alpha" and "Beta"? I've always thought "Preview > Release" was a funny name for a test release and I think the terms > "Alpha" and "Beta" are more familiar to the general public. Maybe 'beta 1' and 'beta 2'. Given that we're feature frozen, calling the first milestone 'alpha' seems odd; similarly, given the tree is frozen, calling the second one 'beta' doesn't quite fit. Bill From jkeating at redhat.com Wed May 6 15:56:36 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 06 May 2009 08:56:36 -0700 Subject: Fedora Release Engineering Meeting Recap - 2009-05-04 In-Reply-To: <4A01866E.8060201@redhat.com> References: <20090504200148.GB3699@nostromo.devel.redhat.com> <4A01866E.8060201@redhat.com> Message-ID: <1241625397.3030.59.camel@localhost.localdomain> On Wed, 2009-05-06 at 05:45 -0700, John Poelstra wrote: > Reading the IRC log am I correct in understanding that a more detailed > summary is: > "Remove all alpha release tasks from the schedule. > There will be no alpha release because it does not > provide enough value for the effort required to create > it. There is little public testing value from it > either." > ? Not fully known yet. Basically because 12 is such a short cycle, I was looking for ways to maximize uninterrupted development time. The best way I could do that was to drop the Alpha cycle. While already a non-blocking freeze, it still drew too much attention away from ongoing development in order to deliver something that was weeks old and already irrelevant. The alpha has had dubious quality to the development cycle, at least from the developer and tester POV. About the only thing of quality it provided was a "known good starting point" for which to install and then update to rawhide, and even that hasn't been true for large swaths of folks in recent releases. > > 1) What dates are we proposing for releasing "development snapshots" > before the beta? We should put these on the schedule now. I honestly hadn't planned on doing regular snapshots during this period. Instead I was hoping for some test-days to drive the need for live images and/or full media images for a particular test target. For people looking for a good "jumping off" point, they can install the GA of F11 and yum update to rawhide. > > 2) The alpha release has always been a good first opportunity to start > marketing our next release, sending out press releases, etc. Basically, > drawing attention to the fact with the general public that a new > release is in the works. Without an Alpha the first general press > releases would be a month later. Is this okay? I think so. Alpha rarely had any features in a state that we'd want to start showing people anyway. Traditionally Alpha releases are internal only and useful for whitebox testing. We can get Alpha level testing out of the rawhide snapshots. > > The Alpha also naturally gets the release notes process and other parts > of Fedora going (not development focused tasks) early which is a good > thing. We'd be losing that too. Yep, that is indeed something to consider. > 3) If we do away with Alpha as we know it, leaving two test releases, > can we simply call them "Alpha" and "Beta"? I've always thought "Preview > Release" was a funny name for a test release and I think the terms > "Alpha" and "Beta" are more familiar to the general public. Honestly, I don't think Alpha fits there. Our existing Beta release is when we want to start blackbox public testing of our features, and that isn't changing. That's still the point where we want wide public usage and testing of our features and release, to gather bugs and feedback for the second half of development, the bug fixing. I tend to agree that "Preview" is a bit of an odd name, however I refuse to call it "Release Candidate" like some other projects do, as it really isn't such a thing. There is 0 chance that our Preview release could become the final release. So we have to call it something. Maybe Gamma or Delta or Omega or Zenith would fit here, although not as widely used. It's the last snapshot mirrored before release candidates are actually created and a release candidate is picked as is to "release to manufacturing" (which in our case means stage for the mirrors). Frankly we can play with the names a bit as we go or after we pick the dates, but the rough dates are what we're trying to pass through now. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From choeger at cs.tu-berlin.de Wed May 6 15:57:57 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Wed, 06 May 2009 17:57:57 +0200 Subject: what is needed for plymouth to boot with gfx? In-Reply-To: <4A01ADAF.8020509@comcast.net> References: <1241601580.2711.1.camel@choeger6> <3adc77210905060754t4b1500a6r14ca0cec909b35e9@mail.gmail.com> <1241623183.2646.2.camel@choeger6> <4A01ADAF.8020509@comcast.net> Message-ID: <1241625477.2646.3.camel@choeger6> Am Mittwoch, den 06.05.2009, 11:33 -0400 schrieb David: > On 5/6/2009 11:19 AM, Christoph H?ger wrote: > > Am Mittwoch, den 06.05.2009, 15:54 +0100 schrieb Naheem Zaffar: > >> "rhgb" in grub as a boot option. > > > I have that: > > kernel /vmlinuz-2.6.29.2-126.fc11.i586 ro root=/dev/VolGroup00/LogVol01 > > rhgb quiet > > > Also /usr/lib/plymouth looks like: > > drwxr-xr-x. 2 root root 4096 6. Mai 00:21 . > > drwxr-xr-x. 228 root root 135168 6. Mai 03:50 .. > > lrwxrwxrwx. 1 root root 13 6. Mai 00:20 default.so -> > > spinfinity.so > > -rwxr-xr-x. 1 root root 10040 1. Mai 19:50 details.so > > -rwxr-xr-x. 1 root root 7068 1. Mai 19:50 label.so > > -rwxr-xr-x. 1 root root 29588 1. Mai 19:50 solar.so > > -rwxr-xr-x. 1 root root 15256 1. Mai 19:50 spinfinity.so > > -rwxr-xr-x. 1 root root 11508 1. Mai 19:50 text.so > > > But all I see on boot is that progress bar. > > > > Google is your friend. > > http://lmgtfy.com/?q=+How+To+Enable+Graphical+Boot+with+Plymouth+in+Fedora+10+ > > > First hit. > I should have mentioned that I am running rawhide (aka f11 preview), so I wanted to know what needs to be checked to make sure I hit a bug. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From kaie at kuix.de Wed May 6 16:39:05 2009 From: kaie at kuix.de (Kai Engert) Date: Wed, 06 May 2009 18:39:05 +0200 Subject: File conflicts: nss-softokn-freebl and nss In-Reply-To: <3170f42f0904162046q5a5c9ef1wd37194e39556fe10@mail.gmail.com> References: <3170f42f0904122106v7627695fo42dd3c8b5f2f16ff@mail.gmail.com> <3170f42f0904162046q5a5c9ef1wd37194e39556fe10@mail.gmail.com> Message-ID: <4A01BD29.8080702@kuix.de> On 04/17/09 05:46, Debarshi Ray wrote: >> Transaction Check Error: >> file /lib64/libfreebl3.so from install of >> nss-softokn-freebl-3.12.2.99.3-7.fc11.x86_64 conflicts with file from >> package nss-3.12.2.0-4.fc11.x86_64 >> > I am still getting this with nss-softokn-freebl-3.12.3-3.fc11.x86_64. > > Shall I file a bug? > Thanks for your report. I've filed bug https://bugzilla.redhat.com/show_bug.cgi?id=499436 Can you please confirm (in bugzilla) whether my theory is correct, you attempted to update glibc, only? Thanks, Kai -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3514 bytes Desc: S/MIME Cryptographic Signature URL: From kevin at scrye.com Wed May 6 16:35:23 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 6 May 2009 10:35:23 -0600 Subject: Fedora Classroom - New mailing list Message-ID: <20090506103523.3162d312@ohm.scrye.com> Greetings. The Fedora Classroom now has it's own mailing list. See: https://admin.fedoraproject.org/mailman/listinfo/classroom For more information and subscription information. This list is for Discussion, Ideas, feedback, planning and announcement of Fedora Classroom sessions. General information about the Fedora Classroom can be found at: https://fedoraproject.org/wiki/Classroom kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From dgboles at comcast.net Wed May 6 16:52:09 2009 From: dgboles at comcast.net (David) Date: Wed, 06 May 2009 12:52:09 -0400 Subject: what is needed for plymouth to boot with gfx? In-Reply-To: <1241625477.2646.3.camel@choeger6> References: <1241601580.2711.1.camel@choeger6> <3adc77210905060754t4b1500a6r14ca0cec909b35e9@mail.gmail.com> <1241623183.2646.2.camel@choeger6> <4A01ADAF.8020509@comcast.net> <1241625477.2646.3.camel@choeger6> Message-ID: <4A01C039.6050900@comcast.net> On 5/6/2009 11:57 AM, Christoph H?ger wrote: > Am Mittwoch, den 06.05.2009, 11:33 -0400 schrieb David: >> On 5/6/2009 11:19 AM, Christoph H?ger wrote: >>> Am Mittwoch, den 06.05.2009, 15:54 +0100 schrieb Naheem Zaffar: >>>> "rhgb" in grub as a boot option. >>> I have that: >>> kernel /vmlinuz-2.6.29.2-126.fc11.i586 ro root=/dev/VolGroup00/LogVol01 >>> rhgb quiet >>> Also /usr/lib/plymouth looks like: >>> drwxr-xr-x. 2 root root 4096 6. Mai 00:21 . >>> drwxr-xr-x. 228 root root 135168 6. Mai 03:50 .. >>> lrwxrwxrwx. 1 root root 13 6. Mai 00:20 default.so -> >>> spinfinity.so >>> -rwxr-xr-x. 1 root root 10040 1. Mai 19:50 details.so >>> -rwxr-xr-x. 1 root root 7068 1. Mai 19:50 label.so >>> -rwxr-xr-x. 1 root root 29588 1. Mai 19:50 solar.so >>> -rwxr-xr-x. 1 root root 15256 1. Mai 19:50 spinfinity.so >>> -rwxr-xr-x. 1 root root 11508 1. Mai 19:50 text.so >>> But all I see on boot is that progress bar. >> Google is your friend. >> http://lmgtfy.com/?q=+How+To+Enable+Graphical+Boot+with+Plymouth+in+Fedora+10+ >> First hit. > I should have mentioned that I am running rawhide (aka f11 preview), so > I wanted to know what needs to be checked to make sure I hit a bug. I am running Rawhide myself. Have for several years. When Rawhide transforms to a release I reset it and carry on with Rawhide. This did not change. It works the same as in the example. In Rawhide x86 and Rawhide x86_64. I does also depend on if your video card is compatable. Some are. Some are not. Good luck. -- David From bruno at wolff.to Wed May 6 20:17:18 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 6 May 2009 15:17:18 -0500 Subject: Fedora Release Engineering Meeting Recap - 2009-05-04 In-Reply-To: <1241625397.3030.59.camel@localhost.localdomain> References: <20090504200148.GB3699@nostromo.devel.redhat.com> <4A01866E.8060201@redhat.com> <1241625397.3030.59.camel@localhost.localdomain> Message-ID: <20090506201718.GA25097@wolff.to> On Wed, May 06, 2009 at 08:56:36 -0700, Jesse Keating wrote: > > I honestly hadn't planned on doing regular snapshots during this period. > Instead I was hoping for some test-days to drive the need for live > images and/or full media images for a particular test target. For > people looking for a good "jumping off" point, they can install the GA > of F11 and yum update to rawhide. One thing that would help compensate for no alpha, is having usable boot.iso images almost allt of the time. The last couple rawhides there have been significant stretches when there were either no boot.iso images being produced or the current ones weren't usable (or at least not for some types of installs). I think there was talk at one time of keeping usable ones around for a while in case of either failed or unusable builds. From choeger at cs.tu-berlin.de Wed May 6 20:56:42 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Wed, 06 May 2009 22:56:42 +0200 Subject: what is needed for plymouth to boot with gfx? In-Reply-To: <4A01C039.6050900@comcast.net> References: <1241601580.2711.1.camel@choeger6> <3adc77210905060754t4b1500a6r14ca0cec909b35e9@mail.gmail.com> <1241623183.2646.2.camel@choeger6> <4A01ADAF.8020509@comcast.net> <1241625477.2646.3.camel@choeger6> <4A01C039.6050900@comcast.net> Message-ID: <1241643402.3267.1.camel@choeger6> Well, I assumed that /usr/libexec/plymouth/plymouth-update-initrd was run on plymouth updates as %postinstall, but I was wrong. Running this tool fixed everything. Although, I still consider this a little bit unexpected behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From notting at redhat.com Wed May 6 21:02:14 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 6 May 2009 17:02:14 -0400 Subject: Fedora Release Engineering Meeting Recap - 2009-05-04 In-Reply-To: <20090506201718.GA25097@wolff.to> References: <20090504200148.GB3699@nostromo.devel.redhat.com> <4A01866E.8060201@redhat.com> <1241625397.3030.59.camel@localhost.localdomain> <20090506201718.GA25097@wolff.to> Message-ID: <20090506210214.GB21677@nostromo.devel.redhat.com> Bruno Wolff III (bruno at wolff.to) said: > On Wed, May 06, 2009 at 08:56:36 -0700, > Jesse Keating wrote: > > > > I honestly hadn't planned on doing regular snapshots during this period. > > Instead I was hoping for some test-days to drive the need for live > > images and/or full media images for a particular test target. For > > people looking for a good "jumping off" point, they can install the GA > > of F11 and yum update to rawhide. > > One thing that would help compensate for no alpha, is having usable boot.iso > images almost allt of the time. The last couple rawhides there have been > significant stretches when there were either no boot.iso images being produced > or the current ones weren't usable (or at least not for some types of > installs). > > I think there was talk at one time of keeping usable ones around for a while > in case of either failed or unusable builds. Generally?, using the prior release's boot.iso and changing/editing the repos to point at rawhide should work reasonably well. Bill ?: modulo rpm hash changes, etc. From poelstra at redhat.com Wed May 6 23:52:18 2009 From: poelstra at redhat.com (John Poelstra) Date: Wed, 06 May 2009 16:52:18 -0700 Subject: Fedora Release Engineering Meeting Recap - 2009-05-04 In-Reply-To: <1241625397.3030.59.camel@localhost.localdomain> References: <20090504200148.GB3699@nostromo.devel.redhat.com> <4A01866E.8060201@redhat.com> <1241625397.3030.59.camel@localhost.localdomain> Message-ID: <4A0222B2.5020705@redhat.com> Jesse Keating said the following on 05/06/2009 08:56 AM Pacific Time: > On Wed, 2009-05-06 at 05:45 -0700, John Poelstra wrote: >> Reading the IRC log am I correct in understanding that a more detailed >> summary is: >> "Remove all alpha release tasks from the schedule. >> There will be no alpha release because it does not >> provide enough value for the effort required to create >> it. There is little public testing value from it >> either." >> ? > > Not fully known yet. Basically because 12 is such a short cycle, I was > looking for ways to maximize uninterrupted development time. The best The overall Fedora 12 schedule with a GA date of 2009-11-03 is 21 days shorter than Fedora 11 and exactly the same length as Fedora 8 so it is not unusually short. > way I could do that was to drop the Alpha cycle. While already a > non-blocking freeze, it still drew too much attention away from ongoing > development in order to deliver something that was weeks old and already > irrelevant. The alpha has had dubious quality to the development cycle, > at least from the developer and tester POV. About the only thing of > quality it provided was a "known good starting point" for which to > install and then update to rawhide, and even that hasn't been true for > large swaths of folks in recent releases. I'd be curious to see our torrent and download numbers for the F11 Alpha to understand how insignificant it was. Where can we find them? Although it is simple to just "not do the Alpha" it will take more coordination across the other Fedora teams AND good messaging in the press and wider world that no alpha is coming for Fedora 12 along with the reasons why. Have we considered the cost of this trade-off to our brand and community? >> 1) What dates are we proposing for releasing "development snapshots" >> before the beta? We should put these on the schedule now. > > I honestly hadn't planned on doing regular snapshots during this period. > Instead I was hoping for some test-days to drive the need for live > images and/or full media images for a particular test target. For > people looking for a good "jumping off" point, they can install the GA > of F11 and yum update to rawhide. No snapshots at all or just not before Beta? Here was the original draft which I can change to reflect the "no alpha" scenario if it goes forward: http://poelstra.fedorapeople.org/schedules/f-12/f-12-releng-tasks.html If we plan to push out final freeze and corresponding GA by one week are we proposing to start the beta a week later too? Or have one week longer between public beta release and final freeze? Thanks, John From jkeating at redhat.com Thu May 7 00:04:35 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 06 May 2009 17:04:35 -0700 Subject: Fedora Release Engineering Meeting Recap - 2009-05-04 In-Reply-To: <4A0222B2.5020705@redhat.com> References: <20090504200148.GB3699@nostromo.devel.redhat.com> <4A01866E.8060201@redhat.com> <1241625397.3030.59.camel@localhost.localdomain> <4A0222B2.5020705@redhat.com> Message-ID: <1241654675.3030.80.camel@localhost.localdomain> On Wed, 2009-05-06 at 16:52 -0700, John Poelstra wrote: > > The overall Fedora 12 schedule with a GA date of 2009-11-03 is 21 days > shorter than Fedora 11 and exactly the same length as Fedora 8 so it is > not unusually short. Well 21 days is a lot of days to take in, particularly when a lot of them seemed to come between the GA of 11 and the Alpha freeze of 12. > > > way I could do that was to drop the Alpha cycle. While already a > > non-blocking freeze, it still drew too much attention away from ongoing > > development in order to deliver something that was weeks old and already > > irrelevant. The alpha has had dubious quality to the development cycle, > > at least from the developer and tester POV. About the only thing of > > quality it provided was a "known good starting point" for which to > > install and then update to rawhide, and even that hasn't been true for > > large swaths of folks in recent releases. > > I'd be curious to see our torrent and download numbers for the F11 Alpha > to understand how insignificant it was. Where can we find them? Torrent numbers are at http://spins.fedoraproject.org:6969/ but downloads alone don't show the whole picture. By the time people got to the Alpha bits, the general feeling I have is that most of the bugs in alpha were already known, and the solution was to update to rawhide. Even if the bugs weren't fixed, the first suggestion was always update to rawhide, so rawhide is really the target we're after, alpha just appeared to be an easy way to get there. > > Although it is simple to just "not do the Alpha" it will take more > coordination across the other Fedora teams AND good messaging in the > press and wider world that no alpha is coming for Fedora 12 along with > the reasons why. Have we considered the cost of this trade-off to our > brand and community? Hard to judge the cost, however our "three tests and a release" which turned into "Alpha Beta Preview Release" was really designed before we had things such as Test Days and the easily available live images, or the ability to easily compose regular install images with slightly different package sets. The prohibitive cost to doing images on demand has gone down considerably, and combined with test days provides a better harness for gathering feedback as we go than the date based quickly stagnant snapshots. > > >> 1) What dates are we proposing for releasing "development snapshots" > >> before the beta? We should put these on the schedule now. > > > > I honestly hadn't planned on doing regular snapshots during this period. > > Instead I was hoping for some test-days to drive the need for live > > images and/or full media images for a particular test target. For > > people looking for a good "jumping off" point, they can install the GA > > of F11 and yum update to rawhide. > > No snapshots at all or just not before Beta? Just none planned before Beta. > Here was the original > draft which I can change to reflect the "no alpha" scenario if it goes > forward: > http://poelstra.fedorapeople.org/schedules/f-12/f-12-releng-tasks.html > > If we plan to push out final freeze and corresponding GA by one week are > we proposing to start the beta a week later too? Or have one week > longer between public beta release and final freeze? One week longer between public beta release and final release. The dates leading up to the Beta are fine. I'd still like to only have 3 snapshots, so we can start snapshot 1 a week later as well. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bkoz at redhat.com Thu May 7 05:24:15 2009 From: bkoz at redhat.com (Benjamin Kosnik) Date: Wed, 6 May 2009 22:24:15 -0700 Subject: f12 boost-1.39.0 upgrade: notice of intent Message-ID: <20090506222415.0838a072@mcgee.artheist.org> Hey. The boost maintainers are planning to update the boost versions to the current release (1.39.0) in rawhide for F12. Tentative F10/F11 built srpm is here: http://people.redhat.com/bkoz/boost/boost-1.39.0-0.3.fc11.src.rpm Suggested plan is to push this to devel in 24 hrs, which will be announced on fedora-devel-announce at redhat.com. BuildRequires for boost packages must be adjusted as part of this rebase. As always, timely assistance from package maintainers is welcome. best, -benjamin From kedars at marvell.com Thu May 7 06:58:33 2009 From: kedars at marvell.com (Kedar Sovani) Date: Wed, 6 May 2009 23:58:33 -0700 Subject: Fedora-ARM: Koji builds and Contributions Message-ID: <25B60CDC2F704E4E9D88FFD52780CB4C01F19910D1@SC-VEXCH1.marvell.com> FYI, -----Forwarded Message----- From: fedora-arm-bounces at redhat.com [mailto:fedora-arm-bounces at redhat.com] On Behalf Of Kedar Sovani Sent: 06 May 2009 18:21 To: fedora-arm at redhat.com Subject: [fedora-arm] Koji builds and Contributions As mentioned earlier a lot of koji build activity can be seen at the ARM koji server. (http://arm.koji.fedoraproject.org/koji) The goal is to be as close to the Fedora releases as possible. And F-11 is the upcoming release. The set of supported packages is growing. Although we'll try to make sure that the Fedora repositories just build with ARM out of the box, as packages move forward there will be few breakages. Any contributions for this effort are welcome. Currently, the following types of builds are taking place: * Packages are being "shadowed" (using koji-shadow) from dist-f11 upstream * New packages are being built for dist-f10 * New versions are being built for dist-f10-updates As we go through these build iterations, quite a few builds will fail. The failure could be a genuine failure requiring a patch, or a failure because of build ordering. The failed tasks can be looked at from the koji interface. Feel free to send out patches to fedora-arm at redhat.com and then to respective package maintainers for fixing build failures. You could also help in analyzing or fixing build ordering related issues with your Fedora koji accounts. Kedar. From paul at city-fan.org Thu May 7 13:08:16 2009 From: paul at city-fan.org (Paul Howarth) Date: Thu, 07 May 2009 14:08:16 +0100 Subject: Multiple repositories or multiple subdirectories In-Reply-To: <1241469793.3748.21.camel@localhost.localdomain> References: <1241468728.3748.16.camel@localhost.localdomain> <1241469793.3748.21.camel@localhost.localdomain> Message-ID: <4A02DD40.1040809@city-fan.org> Robert Marcano wrote: > On Mon, 2009-05-04 at 15:36 -0500, Rex Dieter wrote: >> Robert Marcano wrote: >> >> mirror tool that is rsync >>> Maybe creating a repository layout like >> ... >>> could make easy for mirrors to tell rsync to ignore some directories. >>> createrepo already support a nested structure, What do you think about >>> that?. >> If space is a concern, have you considered simply using a caching proxy? > > space is not a concern, network usage is. > > Yes, but still it is a problem to make available for installation (not > only updates) groups of packages when network connection is not fast > enough (a common problem in my country, and I think in others too), It > is easier to setup rsync at night time, and leave the little bandwidth > available for daily operations I maintain local mirrors of updates to the packages on the original DVD plus a few selected others (e.g. additional dependencies required by updates but not the original versions of those packages): http://www.city-fan.org/tips/SubsetRepositoriesFedora10 This approach could easily be tweaked to use an arbitrary set of packages rather than the package set on the original install media. Paul. From rawhide at fedoraproject.org Thu May 7 13:55:59 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Thu, 7 May 2009 13:55:59 +0000 (UTC) Subject: rawhide report: 20090507 changes Message-ID: <20090507135559.22B921F820E@releng2.fedora.phx.redhat.com> Compose started at Thu May 7 06:15:04 UTC 2009 Updated Packages: DeviceKit-disks-004-2.fc11 -------------------------- * Fri May 01 2009 David Zeuthen - 004-1.fc11 - Upstream release 004 * Fri May 01 2009 David Zeuthen - 004-2.fc11 - Rebuild anaconda-11.5.0.50-1.fc11 ------------------------- * Wed May 06 2009 Chris Lumens - 11.5.0.50-1 - Use storage objects throughout the partition editing UI code (#491806, - Verify filesystems after the live resize (katzj) - Verify with fsck after resizing filesystems (katzj) - IBM improvements to linuxrc.s390 (#475350) (dcantrell) - Write out correct hostname during LiveCD installs (#492515) (dcantrell) - Enter in hostname entry field advances to next screen (#494135) (dcantrell) - Check if we'll clear a partition after setting its format attr. (#499251) (dlehman) - Don't pass the default clearPartType value to the device tree. (dlehman) - Fix some logic errors in storage.partitioning.shouldClear. (dlehman) - Forward port various iscsi fixes from 5.4 iscsi work (hdegoede) - Avoid writing out NAME= in ifcfg files (#497485) (dcantrell) - Retry network configuration in loader (#492009) (dcantrell) - Make sure /boot ends up on the same disk as Apple Bootstrap (#497390). (clumens) - Handle that the default bootloader entry can sometimes be None (#496618). (clumens) - The PS3 bootloader allows booting from ext4 filesystems (#498539). (clumens) - Support LVM PE sizes > 128MB (#497733) (cristian.ciupitu) - Set ANACONDAVERSION on most livecd installs. (clumens) - getDependentDevices is in devicetree, not storage (#499144). (clumens) file-5.02-1.fc11 ---------------- * Wed May 06 2009 Daniel Novotny 5.02-1 - new upstream version; drop upstreamed patches; this fixes #497913 firstboot-1.106-1.fc11 ---------------------- * Tue May 05 2009 Chris Lumens 1.106-1 - Display an error message when the user doesn't supply a password (#480927). - Lots of translation updates. gnome-bluetooth-2.27.5-1.fc11 ----------------------------- * Wed May 06 2009 Bastien Nocera 2.27.5-1 - Update to 2.27.5 gnome-disk-utility-0.3-1.fc11 ----------------------------- * Fri May 01 2009 David Zeuthen - 0.3-1.fc11 - Upstream release 0.3 gnome-power-manager-2.26.1-3.fc11 --------------------------------- * Wed May 06 2009 Richard Hughes - 2.26.1-3 - Backport a patch from upstream to fix backlight DPMS. - Fixes #498041 gnote-0.3.1-1.fc11 ------------------ * Wed May 06 2009 Rahul Sundaram - 0.3.1-1 - new upstream release. Fixes rhbz #498739. Fix #499227 * Fri May 01 2009 Rahul Sundaram - 0.3.0-1 - new upstream release. Includes applet and more plugins. gvfs-1.2.2-6.fc11 ----------------- * Wed May 06 2009 David Zeuthen - 1.2.2-5 - Don't show drives that are supposed to be hidden (#498649) - Only automount if media or drive was just inserted - this fixes a problem with spurious automounts when partitioning/formatting * Wed May 06 2009 David Zeuthen - 1.2.2-6 - Rebuild libatasmart-0.12-3.fc11 ----------------------- * Wed May 06 2009 Lennart Poettering 0.12-3 - Update handling of one ST drive, add another quirk for a weird FUJITSU drive (rhbz 498284) libvirt-0.6.2-6.fc11 -------------------- * Wed May 06 2009 Mark McLoughlin - 0.6.2-5.fc11 - Fix handling of (bug #499386) * Wed May 06 2009 Cole Robinson - 0.6.2-6.fc11 - Refresh qemu caps when getCapabilities is called (bug #460649) policycoreutils-2.0.62-12.2.fc11 -------------------------------- * Tue May 05 2009 Dan Walsh 2.0.62-12.2 - Fix fixfiles to handle btrfs * Fri Apr 24 2009 Dan Walsh 2.0.62-12.1 - Fix audit2allow -a to read /var/log/messages * Thu Apr 16 2009 Dan Walsh 2.0.62-12 - Add semanage module support pygobject2-2.16.1-4.fc11 ------------------------ * Wed Apr 22 2009 Matthew Barnes - 2.16.1-4.fc11 - Add patch for GNOME bug #566571 (classic vs new-style inheritance crash). python-virtinst-0.400.3-8.fc11 ------------------------------ * Wed May 06 2009 Cole Robinson - 0.400.3-8.fc11 - Fix PCI assignment (bz 499267) seamonkey-1.1.15-4.fc11 ----------------------- * Wed May 06 2009 Martin Stransky 1.1.15-4 - build with -fno-strict-aliasing (#468415) smart-1.2-64.fc11 ----------------- * Thu Apr 16 2009 Axel Thimm - 1.2-64 - Fix premature returns in sha256 patch. * Wed Apr 15 2009 Axel Thimm - 1.2-62 - Fix sha256 and mdclean patches. * Sun Mar 22 2009 Axel Thimm - 1.2-60 - Update to 1.2. xorg-x11-drv-intel-2.7.0-4.fc11 ------------------------------- * Wed May 06 2009 - 2.7.0-4 - Pull in fixes from the 2.7 branch. Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 17 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From dcbw at redhat.com Thu May 7 14:06:14 2009 From: dcbw at redhat.com (Dan Williams) Date: Thu, 07 May 2009 10:06:14 -0400 Subject: Moblin 2 and Fedora In-Reply-To: <20090504125251.41e491a6@infradead.org> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <49844F3B.6060905@fedoraproject.org> <5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com> <20090131110644.1a80ddf5@infradead.org> <4984BC61.3040908@fedoraproject.org> <20090131153457.573762ab@infradead.org> <604aa7910902020825v23bc3687m1151596fa74cb8a5@mail.gmail.com> <20090202101002.4380c005@infradead.org> <1233598383.7493.42.camel@localhost.localdomain> <20090202113524.184e402c@infradead.org> <20090503160827.GA21833@srcf.ucam.org> <1241449115.2766.148.camel@atropine.boston.devel.redhat.com> <49FF0A69.8030609@fedoraproject.org> <1241462009.8638.5.camel@localhost.localdomain> <20090504125251.41e491a6@infradead.org> Message-ID: <1241705174.3088.2.camel@localhost.localdomain> On Mon, 2009-05-04 at 12:52 -0700, Arjan van de Ven wrote: > On Mon, 04 May 2009 14:33:28 -0400 > Dan Williams wrote: > > > On Mon, 2009-05-04 at 21:01 +0530, Rahul Sundaram wrote: > > > On 05/04/2009 08:28 PM, Adam Jackson wrote: > > > > > > > > > > > Just to underline this point, let's look at what the Moblin FAQ > > > > has to say on the subject: > > > > > > > > Q Is Moblin v2.0 based on another distribution? > > > > Moblin v2.0 borrows components from various > > > > distributions, but is not based on another distribution. > > > > > > > > [ source: > > > > http://moblin.org/documentation/moblin-overview/faq ] > > > > > > > > This seems... disingenuous? I guess it all depends on what the > > > > definition of the word "based" is. It's also the sort of > > > > statement that begs immediate deconstruction. If moblin _isn't_ > > > > based on another distribution, why does it feel the need to say > > > > so. On the other hand, if it is, why does it say it isn't. > > > > > > I don't see us accomplishing much by stating the obvious, which is > > > that Moblin is indeed based on Fedora even if Intel does not want to > > > acknowledge that for whatever reasons. Considering that they seem to > > > have moved it over to Linux Foundation, it all might just be > > > political considerations. Let's move beyond that. > > > > > > Now, is there useful patches that we need to push upstream? Are > > > there additional packages, we can import into Fedora? Let's look at > > > that list. We know of sreadahead. Has the kernel portion been > > > upstreamed? Arjan pointed out memuse in > > > http://lwn.net/Articles/331423/. What's the rest? > > > > Yeah, how about Poulsbo support? Is anyone at Intel actually working > > on upstreaming the unencumbered 2D parts of that, including the > > kernel bits and the X driver? Random crack in gregkh's tree doesn't > > count. > > > > it's not very useful if the various upstream maintainers say that they > won't accept it no matter what... at that point... yes people stop > working on it. Nobody has ever said that about the *2D* parts, and I specifically mentioned "unencumbered 2D parts" above. Intel needs to get its head out of its ass WRT Poulsbo and gets out some 2D bits, and stops working in private trees and stop doing code dumps only to Ubuntu. Seriously, is that team even *part* of Intel? Because the Poulsbo Linux team is completely different than any of the other Intel Linux teams I've had the actual pleasure of interacting with. Dan From dcbw at redhat.com Thu May 7 14:08:00 2009 From: dcbw at redhat.com (Dan Williams) Date: Thu, 07 May 2009 10:08:00 -0400 Subject: Moblin 2 and Fedora In-Reply-To: <1241465193.2923.220.camel@adam.local.net> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <49844F3B.6060905@fedoraproject.org> <5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com> <20090131110644.1a80ddf5@infradead.org> <4984BC61.3040908@fedoraproject.org> <20090131153457.573762ab@infradead.org> <604aa7910902020825v23bc3687m1151596fa74cb8a5@mail.gmail.com> <20090202101002.4380c005@infradead.org> <1233598383.7493.42.camel@localhost.localdomain> <20090202113524.184e402c@infradead.org> <20090503160827.GA21833@srcf.ucam.org> <1241449115.2766.148.camel@atropine.boston.devel.redhat.com> <49FF0A69.8030609@fedoraproject.org> <1241462009.8638.5.camel@localhost.localdomain> <1241465193.2923.220.camel@adam.local.net> Message-ID: <1241705280.3088.3.camel@localhost.localdomain> On Mon, 2009-05-04 at 12:26 -0700, Adam Williamson wrote: > On Mon, 2009-05-04 at 14:33 -0400, Dan Williams wrote: > > > Yeah, how about Poulsbo support? Is anyone at Intel actually working on > > upstreaming the unencumbered 2D parts of that, including the kernel bits > > and the X driver? Random crack in gregkh's tree doesn't count. > > Well, on that topic, I notice a huge new pile of crack showed up in the > Ubuntu Mobile special-sauce repositories on April 30, which appears to > be the psb driver for Ubuntu 8.10. At least... > > http://ppa.launchpad.net/ubuntu-mobile/ubuntu/pool/main/x/xserver-xorg-video-psb/ > http://ppa.launchpad.net/ubuntu-mobile/ubuntu/pool/main/x/xpsb-glx/ > http://ppa.launchpad.net/ubuntu-mobile/ubuntu/pool/main/libd/libdrm-poulsbo/ > http://ppa.launchpad.net/ubuntu-mobile/ubuntu/pool/main/p/psb-kernel-source/ > http://ppa.launchpad.net/ubuntu-mobile/ubuntu/pool/main/p/psb-firmware/ > http://ppa.launchpad.net/ubuntu-mobile/ubuntu/pool/main/p/psb-meta/ > > oh, so much crack. Why must there be so much crack?! > > so, yeah, it seems like at least one bit of Intel is still working on > special sauce for Ubuntu (presumably at Dell's behest), not upstreaming. Yeah, and there's the problem. What makes the Poulsbo team so special that they are exempt from the upstreaming policy that every other part of Intel seems to follow so well these days? ... Dan From denis at poolshark.org Thu May 7 15:05:55 2009 From: denis at poolshark.org (Denis Leroy) Date: Thu, 07 May 2009 17:05:55 +0200 Subject: glibc fork ? Message-ID: <4A02F8D3.2010807@poolshark.org> http://www.eglibc.org/home So are we moving to eglibc as well ? :-) So what happened ? Overreaction from Debian guy, or poor community management from RH guy ? -denis From mschwendt at gmail.com Thu May 7 15:26:23 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 7 May 2009 17:26:23 +0200 Subject: Requires: %{_libdir}/pkgconfig Message-ID: <20090507172623.32d7e9ad@faldor.intranet> Dependency chaos. Some packagers have started with adding Requires: %{_libdir}/pkgconfig instead of the good old "Requires: pkgconfig". Not only is this dependency expensive -- the filelists metadata must be loaded and parsed -- it doesn't work correctly either, because 1) package "pkgconfig" is not multilib'ed, so e.g. pkgconfig.i386 is not available in the x86_64 repo, and hence nothing provides the /usr/lib/pkgconfig directory, (and it would be a broken dep) but 2) a couple of other packages include %_libdir/pkgconfig by accident, which violates the packaging guidelines. Namely: openchange-devel 499655 ipod-sharp-devel 499658 sane-backends-devel 499659 libXScrnSaver-devel 499660 freetype-devel 499661 anthy-devel 499663 Since these are multilib'ed, a dependency on /usr/lib/pkgconfig doesn't pull in pkgconfig.i386 but one of these -devel packages instead. [...] Conclusively, neither "Requires: %{_libdir}/pkgconfig" nor "Requires: pkgconfig%{_isa}" will work as expected. From awilliam at redhat.com Thu May 7 15:28:38 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 07 May 2009 08:28:38 -0700 Subject: Moblin 2 and Fedora In-Reply-To: <1241705174.3088.2.camel@localhost.localdomain> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <49844F3B.6060905@fedoraproject.org> <5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com> <20090131110644.1a80ddf5@infradead.org> <4984BC61.3040908@fedoraproject.org> <20090131153457.573762ab@infradead.org> <604aa7910902020825v23bc3687m1151596fa74cb8a5@mail.gmail.com> <20090202101002.4380c005@infradead.org> <1233598383.7493.42.camel@localhost.localdomain> <20090202113524.184e402c@infradead.org> <20090503160827.GA21833@srcf.ucam.org> <1241449115.2766.148.camel@atropine.boston.devel.redhat.com> <49FF0A69.8030609@fedoraproject.org> <1241462009.8638.5.camel@localhost.localdomain> <20090504125251.41e491a6@infradead.org> <1241705174.3088.2.camel@localhost.localdomain> Message-ID: <1241710118.2923.481.camel@adam.local.net> On Thu, 2009-05-07 at 10:06 -0400, Dan Williams wrote: > Seriously, is that team even *part* of Intel? Because the Poulsbo Linux > team is completely different than any of the other Intel Linux teams > I've had the actual pleasure of interacting with. At least originally, no, they weren't. Intel contracted the Poulsbo driver development out to another company (which has since itself been bought out by VMware). Now, however, it isn't clear if it's those guys or guys who really are with Intel or what who are doing whatever development is actually happening. I suspect what may be happening is the original group is continuing to work on the crack-addled drivers that show up in the Ubuntu repos from time to time, while a different group works on creating a non-crack-addled driver that'll be sent through the proper processes. But that's just my guess, as no-one at Intel seems to want to say anything. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From nathanael at gnat.ca Thu May 7 15:38:00 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Thu, 07 May 2009 09:38:00 -0600 Subject: removing KDE removes NetworkManager-gnome?? Message-ID: <4A030058.3020107@gnat.ca> Hello, I ran the following command this morning: sudo yum --disableplugin=remove-with-leaves groupremove "KDE (K Desktop Environment)" I added the remove-with-leaves because when I ran it with that it was removing all sorts of stand alone programs like mysql-server and other stuff completely unrelated to kde... In any case, the command above produced the following list of packages to remove... Removing: NetworkManager-gnome 1:0.7.1-1.fc10 1.1 M amarok 2.0.2-6.fc10 17 M digikam 0.10.0-1.fc10 24 M gstreamer-ffmpeg 0.10.5-1.fc10 384 k gstreamer-plugins-ugly 0.10.10-2.fc10 746 k guidance-power-manager 4.2.0-1.fc10 448 k k3b-extras-freeworld 1.0.5-4.fc10 174 k kaffeine 0.8.7-3.fc10 6.0 M kde-settings-pulseaudio 4.1-6.20090206svn.fc10 0.0 kdeaccessibility 1:4.2.2-1.fc10 8.3 M kdeartwork 4.2.2-3.fc10 1.1 M kdebase 6:4.2.2-3.fc10 13 M kdebase-workspace 4.2.2-5.fc10 26 M kdegames 6:4.2.2-6.fc10 55 M kdegraphics 7:4.2.2-5.fc10 6.6 M kdelibs 6:4.2.2-12.fc10 44 M kdemultimedia 6:4.2.2-2.fc10 3.9 M kdenetwork 7:4.2.2-1.fc10 17 M kdepim 6:4.2.2-3.fc10 24 M kdeplasma-addons 4.2.2-2.fc10 7.5 M kdeutils 6:4.2.2-2.fc10 6.3 M kftpgrabber 0.8.1-6.fc9 2.8 M kipi-plugins 0.2.0-2.fc10 15 M konq-plugins 4.2.2-1.fc10 4.8 M konversation 1.1-1.fc10 11 M kpackagekit 0.3.1-9.fc10 625 k ksshaskpass 0.5.1-3.fc10 32 k ktorrent 3.2.1-1.fc10 11 M libtunepimp-extras-freeworld 0.5.3-5.fc10 293 k pinentry-qt 0.7.4-5.fc9 147 k scim-bridge-qt 0.4.15-8.fc10 112 k scim-qtimm 0.9.4-11.fc10 194 k scribus 1.3.5-0.12.beta.fc10 48 M xine-lib-extras-freeworld 1.1.16.3-1.fc10 914 k zenity 2.24.1-1.fc10 3.2 M Removing for dependencies: PyKDE4 4.2.2-2.fc10 21 M digikam-libs 0.10.0-1.fc10 3.9 M gedit 1:2.24.3-3.fc10 12 M kaffeine-libs 0.8.7-3.fc10 104 k kdebase-libs 6:4.2.2-3.fc10 755 k kdebase-runtime 4.2.2-4.fc10 11 M kdebase-runtime-libs 4.2.2-4.fc10 3.7 M kdebase-workspace-libs 4.2.2-5.fc10 2.0 M kdeedu-marble 4.2.2-1.fc10 28 M kdegames-libs 6:4.2.2-6.fc10 3.6 M kdegraphics-libs 7:4.2.2-5.fc10 2.4 M kdemultimedia-libs 6:4.2.2-2.fc10 867 k kdenetwork-libs 7:4.2.2-1.fc10 5.3 M kdepim-libs 6:4.2.2-3.fc10 22 M kdepimlibs 4.2.2-3.fc10 5.7 M kdepimlibs-akonadi 4.2.2-3.fc10 962 k kdeutils-printer-applet 6:4.2.2-2.fc10 102 k kdm 4.2.2-5.fc10 2.9 M kio_msits 7:4.2.2-5.fc10 24 k kio_sysinfo 20090216-2.fc10 473 k Why are gedit, NetworkManager-gnome, gstreamer-ffmpeg and gstreamer-plugins-ugly being removed? Is this a bug? -- Nathanael d. Noblet T: 403.875.4613 From ol.morgan at telia.com Thu May 7 15:45:53 2009 From: ol.morgan at telia.com (mo) Date: Thu, 07 May 2009 17:45:53 +0200 Subject: removing KDE removes NetworkManager-gnome?? In-Reply-To: <4A030058.3020107@gnat.ca> References: <4A030058.3020107@gnat.ca> Message-ID: <1241711153.4794.2.camel@ubuntu.Belkin> > Why are gedit, NetworkManager-gnome, gstreamer-ffmpeg and > gstreamer-plugins-ugly being removed? Is this a bug? > Well, if it is a feature, I don't like it. From ivazqueznet at gmail.com Thu May 7 15:48:38 2009 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Thu, 07 May 2009 11:48:38 -0400 Subject: removing KDE removes NetworkManager-gnome?? In-Reply-To: <4A030058.3020107@gnat.ca> References: <4A030058.3020107@gnat.ca> Message-ID: <1241711318.12122.326.camel@ignacio.lan> On Thu, 2009-05-07 at 09:38 -0600, Nathanael D. Noblet wrote: > Why are gedit, NetworkManager-gnome, gstreamer-ffmpeg and > gstreamer-plugins-ugly being removed? Is this a bug? It's hard to tell without the dependency resolution information you omitted. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From katzj at redhat.com Thu May 7 15:51:24 2009 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 7 May 2009 11:51:24 -0400 Subject: removing KDE removes NetworkManager-gnome?? In-Reply-To: <4A030058.3020107@gnat.ca> References: <4A030058.3020107@gnat.ca> Message-ID: <20090507155124.GB29606@redhat.com> On Thursday, May 07 2009, Nathanael D. Noblet said: > I ran the following command this morning: > sudo yum --disableplugin=remove-with-leaves groupremove "KDE (K Desktop > Environment)" > > I added the remove-with-leaves because when I ran it with that it was > removing all sorts of stand alone programs like mysql-server and other > stuff completely unrelated to kde... In any case, the command above > produced the following list of packages to remove... [snip] > Why are gedit, NetworkManager-gnome, gstreamer-ffmpeg and > gstreamer-plugins-ugly being removed? Is this a bug? NetworkManager-gnome is listed in the KDE comps group (as the KDE plasmoid isn't ready yet afaik) and thus gets removed when you ask to remove the group. I expect gedit and the gstreamer packages are due to something similar in the group or one of their deps being explicitly listed in the group Jeremy From rjones at redhat.com Thu May 7 15:52:13 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 7 May 2009 16:52:13 +0100 Subject: Note on man pages In-Reply-To: <1241588791.3101.2.camel@localhost.localdomain> References: <4A00BCE9.3050800@fedoraproject.org> <1241588035.7862.2.camel@prague> <1241588791.3101.2.camel@localhost.localdomain> Message-ID: <20090507155213.GA7984@amd.home.annexia.org> On Wed, May 06, 2009 at 08:46:31AM +0300, Jussi Lehtola wrote: > On Wed, 2009-05-06 at 07:33 +0200, nodata wrote: > > Am Mittwoch, den 06.05.2009, 04:47 +0200 schrieb Kevin Kofler: > > > Well, there are many upstreams rejecting Debian's patches outright, saying > > > manpages are obsolete and redundant with any of: > > > * info documentation (those are mostly the GNU projects), > > > > /me still secretly hopes info pages go away. > > +1 > > From a usability point of view there's nothing that beats man pages. +1000 Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 75 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From rjones at redhat.com Thu May 7 15:53:19 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 7 May 2009 16:53:19 +0100 Subject: Note on man pages In-Reply-To: <4A00BCE9.3050800@fedoraproject.org> References: <4A00BCE9.3050800@fedoraproject.org> Message-ID: <20090507155319.GB7984@amd.home.annexia.org> On Wed, May 06, 2009 at 03:55:45AM +0530, Rahul Sundaram wrote: > Debian has a policy that all the commands should have man pages as part > of their review process. Unfortunately they don't seem to be sending it > upstream.[...] Yes yes yes! A very good policy it is too. Not sending the man pages upstream, that's a very bad policy ... Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From bmr at redhat.com Thu May 7 16:06:46 2009 From: bmr at redhat.com (Bryn M. Reeves) Date: Thu, 07 May 2009 17:06:46 +0100 Subject: Note on man pages In-Reply-To: <20090507155213.GA7984@amd.home.annexia.org> References: <4A00BCE9.3050800@fedoraproject.org> <1241588035.7862.2.camel@prague> <1241588791.3101.2.camel@localhost.localdomain> <20090507155213.GA7984@amd.home.annexia.org> Message-ID: <1241712406.13505.262.camel@breeves.fab.redhat.com> On Thu, 2009-05-07 at 16:52 +0100, Richard W.M. Jones wrote: > On Wed, May 06, 2009 at 08:46:31AM +0300, Jussi Lehtola wrote: > > On Wed, 2009-05-06 at 07:33 +0200, nodata wrote: > > > Am Mittwoch, den 06.05.2009, 04:47 +0200 schrieb Kevin Kofler: > > > > Well, there are many upstreams rejecting Debian's patches outright, saying > > > > manpages are obsolete and redundant with any of: > > > > * info documentation (those are mostly the GNU projects), > > > > > > /me still secretly hopes info pages go away. > > > > +1 > > > > From a usability point of view there's nothing that beats man pages. > > +1000 I see your 1000 and raise it 1000000. Personally, I think that Debian have done a great service to the broader community by their insistence on man pages for every package. Regards, Bryn. From emmanuel.seyman at club-internet.fr Thu May 7 16:06:30 2009 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Thu, 7 May 2009 18:06:30 +0200 Subject: Note on man pages In-Reply-To: <1241588035.7862.2.camel@prague> References: <4A00BCE9.3050800@fedoraproject.org> <1241588035.7862.2.camel@prague> Message-ID: <20090507160630.GA11348@orient.maison.lan> * nodata [06/05/2009 07:38] : > > /me still secretly hopes info pages go away. I have this in my .bashrc: function mani () { info $1 --subnodes --output - | less; } Emmanuel From nathanael at gnat.ca Thu May 7 16:12:48 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Thu, 07 May 2009 10:12:48 -0600 Subject: removing KDE removes NetworkManager-gnome?? In-Reply-To: <1241711318.12122.326.camel@ignacio.lan> References: <4A030058.3020107@gnat.ca> <1241711318.12122.326.camel@ignacio.lan> Message-ID: <4A030880.9090400@gnat.ca> Ignacio Vazquez-Abrams wrote: > On Thu, 2009-05-07 at 09:38 -0600, Nathanael D. Noblet wrote: >> Why are gedit, NetworkManager-gnome, gstreamer-ffmpeg and >> gstreamer-plugins-ugly being removed? Is this a bug? > > It's hard to tell without the dependency resolution information you > omitted. > > Resolving Dependencies --> Running transaction check ---> Package NetworkManager-gnome.x86_64 1:0.7.1-1.fc10 set to be erased ---> Package amarok.x86_64 0:2.0.2-6.fc10 set to be erased ---> Package digikam.x86_64 0:0.10.0-1.fc10 set to be erased --> Processing Dependency: digikam = 0.10.0-1.fc10 for package: digikam-libs ---> Package gstreamer-ffmpeg.x86_64 0:0.10.5-1.fc10 set to be erased ---> Package gstreamer-plugins-ugly.x86_64 0:0.10.10-2.fc10 set to be erased ---> Package guidance-power-manager.x86_64 0:4.2.0-1.fc10 set to be erased ---> Package k3b-extras-freeworld.x86_64 0:1.0.5-4.fc10 set to be erased ---> Package kaffeine.x86_64 0:0.8.7-3.fc10 set to be erased --> Processing Dependency: kaffeine = 0.8.7-3.fc10 for package: kaffeine-libs ---> Package kde-settings-pulseaudio.noarch 0:4.1-6.20090206svn.fc10 set to be erased ---> Package kdeaccessibility.x86_64 1:4.2.2-1.fc10 set to be erased ---> Package kdeartwork.x86_64 0:4.2.2-3.fc10 set to be erased ---> Package kdebase.x86_64 6:4.2.2-3.fc10 set to be erased ---> Package kdebase-workspace.x86_64 0:4.2.2-5.fc10 set to be erased --> Processing Dependency: kdebase-workspace = 4.2.2-5.fc10 for package: kdebase-workspace-libs ---> Package kdegames.x86_64 6:4.2.2-6.fc10 set to be erased ---> Package kdegraphics.x86_64 7:4.2.2-5.fc10 set to be erased ---> Package kdelibs.x86_64 6:4.2.2-12.fc10 set to be erased --> Processing Dependency: kdelibs4 >= 4.2.2 for package: kdebase-runtime-libs --> Processing Dependency: kdelibs4 >= 4.2.2 for package: kdepimlibs --> Processing Dependency: kdelibs4 >= 4.2.2 for package: kdebase-libs --> Processing Dependency: kdelibs4 >= 4.2.2 for package: PyKDE4 --> Processing Dependency: kdelibs4(x86-64) >= 4.2.2 for package: kdm --> Processing Dependency: libkde3support.so.4()(64bit) for package: kdepim-libs --> Processing Dependency: libkde3support.so.4()(64bit) for package: kdebase-runtime --> Processing Dependency: libkde3support.so.4()(64bit) for package: kdemultimedia-libs --> Processing Dependency: libkde3support.so.4()(64bit) for package: kdebase-libs --> Processing Dependency: libkde3support.so.4()(64bit) for package: kdebase-runtime-libs --> Processing Dependency: libkde3support.so.4()(64bit) for package: kdegames-libs --> Processing Dependency: libkde3support.so.4()(64bit) for package: kdenetwork-libs --> Processing Dependency: libkde3support.so.4()(64bit) for package: kdm --> Processing Dependency: libkdecore.so.5()(64bit) for package: kdepim-libs --> Processing Dependency: libkdecore.so.5()(64bit) for package: kdebase-runtime --> Processing Dependency: libkdecore.so.5()(64bit) for package: kdegraphics-libs --> Processing Dependency: libkdecore.so.5()(64bit) for package: kdemultimedia-libs --> Processing Dependency: libkdecore.so.5()(64bit) for package: kio_msits --> Processing Dependency: libkdecore.so.5()(64bit) for package: kio_sysinfo --> Processing Dependency: libkdecore.so.5()(64bit) for package: PyKDE4 --> Processing Dependency: libkdecore.so.5()(64bit) for package: kdebase-libs --> Processing Dependency: libkdecore.so.5()(64bit) for package: kdebase-runtime-libs --> Processing Dependency: libkdecore.so.5()(64bit) for package: kdeedu-marble --> Processing Dependency: libkdecore.so.5()(64bit) for package: kdegames-libs --> Processing Dependency: libkdecore.so.5()(64bit) for package: kdenetwork-libs --> Processing Dependency: libkdecore.so.5()(64bit) for package: kdepimlibs-akonadi --> Processing Dependency: libkdecore.so.5()(64bit) for package: kdm --> Processing Dependency: libkdecore.so.5()(64bit) for package: kdepimlibs --> Processing Dependency: libkdesu.so.5()(64bit) for package: kdebase-runtime --> Processing Dependency: libkdeui.so.5()(64bit) for package: kdepim-libs --> Processing Dependency: libkdeui.so.5()(64bit) for package: kdebase-runtime --> Processing Dependency: libkdeui.so.5()(64bit) for package: kdegraphics-libs --> Processing Dependency: libkdeui.so.5()(64bit) for package: kdemultimedia-libs --> Processing Dependency: libkdeui.so.5()(64bit) for package: kio_msits --> Processing Dependency: libkdeui.so.5()(64bit) for package: kio_sysinfo --> Processing Dependency: libkdeui.so.5()(64bit) for package: PyKDE4 --> Processing Dependency: libkdeui.so.5()(64bit) for package: kdebase-libs --> Processing Dependency: libkdeui.so.5()(64bit) for package: kdebase-runtime-libs --> Processing Dependency: libkdeui.so.5()(64bit) for package: kdeedu-marble --> Processing Dependency: libkdeui.so.5()(64bit) for package: kdegames-libs --> Processing Dependency: libkdeui.so.5()(64bit) for package: kdenetwork-libs --> Processing Dependency: libkdeui.so.5()(64bit) for package: kdepimlibs-akonadi --> Processing Dependency: libkdeui.so.5()(64bit) for package: kdm --> Processing Dependency: libkdeui.so.5()(64bit) for package: kdepimlibs --> Processing Dependency: libkdnssd.so.4()(64bit) for package: kdebase-runtime-libs --> Processing Dependency: libkdnssd.so.4()(64bit) for package: kdegames-libs --> Processing Dependency: libkdnssd.so.4()(64bit) for package: kdebase-runtime --> Processing Dependency: libkdnssd.so.4()(64bit) for package: PyKDE4 --> Processing Dependency: libkfile.so.4()(64bit) for package: kdebase-libs --> Processing Dependency: libkfile.so.4()(64bit) for package: kdebase-runtime-libs --> Processing Dependency: libkfile.so.4()(64bit) for package: kdegraphics-libs --> Processing Dependency: libkfile.so.4()(64bit) for package: PyKDE4 --> Processing Dependency: libkhtml.so.5()(64bit) for package: kdepim-libs --> Processing Dependency: libkhtml.so.5()(64bit) for package: kdebase-runtime --> Processing Dependency: libkhtml.so.5()(64bit) for package: PyKDE4 --> Processing Dependency: libkhtml.so.5()(64bit) for package: kio_sysinfo --> Processing Dependency: libkhtml.so.5()(64bit) for package: kdebase-runtime-libs --> Processing Dependency: libkhtml.so.5()(64bit) for package: kdenetwork-libs --> Processing Dependency: libkimproxy.so.4()(64bit) for package: kdepim-libs --> Processing Dependency: libkio.so.5()(64bit) for package: kdepim-libs --> Processing Dependency: libkio.so.5()(64bit) for package: kdebase-runtime --> Processing Dependency: libkio.so.5()(64bit) for package: kdegraphics-libs --> Processing Dependency: libkio.so.5()(64bit) for package: kdemultimedia-libs --> Processing Dependency: libkio.so.5()(64bit) for package: kio_msits --> Processing Dependency: libkio.so.5()(64bit) for package: kio_sysinfo --> Processing Dependency: libkio.so.5()(64bit) for package: PyKDE4 --> Processing Dependency: libkio.so.5()(64bit) for package: kdebase-libs --> Processing Dependency: libkio.so.5()(64bit) for package: kdebase-runtime-libs --> Processing Dependency: libkio.so.5()(64bit) for package: kdeedu-marble --> Processing Dependency: libkio.so.5()(64bit) for package: kdegames-libs --> Processing Dependency: libkio.so.5()(64bit) for package: kdenetwork-libs --> Processing Dependency: libkio.so.5()(64bit) for package: kdepimlibs-akonadi --> Processing Dependency: libkio.so.5()(64bit) for package: kdm --> Processing Dependency: libkio.so.5()(64bit) for package: kdepimlibs --> Processing Dependency: libkjs.so.4()(64bit) for package: kdepim-libs --> Processing Dependency: libkjs.so.4()(64bit) for package: kdebase-runtime --> Processing Dependency: libkjs.so.4()(64bit) for package: PyKDE4 --> Processing Dependency: libkjs.so.4()(64bit) for package: kio_sysinfo --> Processing Dependency: libkjs.so.4()(64bit) for package: kdebase-runtime-libs --> Processing Dependency: libkjs.so.4()(64bit) for package: kdenetwork-libs --> Processing Dependency: libkjsapi.so.4()(64bit) for package: kdegraphics-libs --> Processing Dependency: libkmediaplayer.so.4()(64bit) for package: kdebase-runtime-libs --> Processing Dependency: libknewstuff2.so.4()(64bit) for package: kdepim-libs --> Processing Dependency: libknewstuff2.so.4()(64bit) for package: kdebase-runtime --> Processing Dependency: libknewstuff2.so.4()(64bit) for package: PyKDE4 --> Processing Dependency: libknewstuff2.so.4()(64bit) for package: kdebase-runtime-libs --> Processing Dependency: libknewstuff2.so.4()(64bit) for package: kdeedu-marble --> Processing Dependency: libknewstuff2.so.4()(64bit) for package: kdegames-libs --> Processing Dependency: libknewstuff2.so.4()(64bit) for package: kdm --> Processing Dependency: libknotifyconfig.so.4()(64bit) for package: kdepim-libs --> Processing Dependency: libknotifyconfig.so.4()(64bit) for package: kdebase-runtime --> Processing Dependency: libknotifyconfig.so.4()(64bit) for package: kdebase-runtime-libs --> Processing Dependency: libkparts.so.4()(64bit) for package: kdepim-libs --> Processing Dependency: libkparts.so.4()(64bit) for package: kdebase-runtime --> Processing Dependency: libkparts.so.4()(64bit) for package: kdemultimedia-libs --> Processing Dependency: libkparts.so.4()(64bit) for package: kdegraphics-libs --> Processing Dependency: libkparts.so.4()(64bit) for package: PyKDE4 --> Processing Dependency: libkparts.so.4()(64bit) for package: kio_sysinfo --> Processing Dependency: libkparts.so.4()(64bit) for package: kdebase-runtime-libs --> Processing Dependency: libkparts.so.4()(64bit) for package: kdeedu-marble --> Processing Dependency: libkparts.so.4()(64bit) for package: kdebase-libs --> Processing Dependency: libkparts.so.4()(64bit) for package: kdenetwork-libs --> Processing Dependency: libkpty.so.4()(64bit) for package: kdebase-runtime-libs --> Processing Dependency: libkpty.so.4()(64bit) for package: PyKDE4 --> Processing Dependency: libktexteditor.so.4()(64bit) for package: PyKDE4 --> Processing Dependency: libkutils.so.4()(64bit) for package: kdepim-libs --> Processing Dependency: libkutils.so.4()(64bit) for package: kdebase-runtime --> Processing Dependency: libkutils.so.4()(64bit) for package: kdepimlibs --> Processing Dependency: libkutils.so.4()(64bit) for package: PyKDE4 --> Processing Dependency: libkutils.so.4()(64bit) for package: kdebase-runtime-libs --> Processing Dependency: libkutils.so.4()(64bit) for package: kdenetwork-libs --> Processing Dependency: libnepomuk.so.4()(64bit) for package: kdepim-libs --> Processing Dependency: libnepomuk.so.4()(64bit) for package: kdebase-runtime --> Processing Dependency: libnepomuk.so.4()(64bit) for package: kdegraphics-libs --> Processing Dependency: libnepomuk.so.4()(64bit) for package: PyKDE4 --> Processing Dependency: libnepomuk.so.4()(64bit) for package: kdebase-runtime-libs --> Processing Dependency: libnepomuk.so.4()(64bit) for package: kdebase-libs --> Processing Dependency: libplasma.so.3()(64bit) for package: kdeedu-marble --> Processing Dependency: libplasma.so.3()(64bit) for package: PyKDE4 --> Processing Dependency: libsolid.so.4()(64bit) for package: kdebase-runtime --> Processing Dependency: libsolid.so.4()(64bit) for package: kdemultimedia-libs --> Processing Dependency: libsolid.so.4()(64bit) for package: PyKDE4 --> Processing Dependency: libsolid.so.4()(64bit) for package: kio_sysinfo --> Processing Dependency: libsolid.so.4()(64bit) for package: kdebase-runtime-libs --> Processing Dependency: libsolid.so.4()(64bit) for package: kdepimlibs-akonadi --> Processing Dependency: libsolid.so.4()(64bit) for package: kdenetwork-libs --> Processing Dependency: libthreadweaver.so.4()(64bit) for package: kdepim-libs --> Processing Dependency: libthreadweaver.so.4()(64bit) for package: kdegraphics-libs ---> Package kdemultimedia.x86_64 6:4.2.2-2.fc10 set to be erased ---> Package kdenetwork.x86_64 7:4.2.2-1.fc10 set to be erased ---> Package kdepim.x86_64 6:4.2.2-3.fc10 set to be erased ---> Package kdeplasma-addons.x86_64 0:4.2.2-2.fc10 set to be erased ---> Package kdeutils.x86_64 6:4.2.2-2.fc10 set to be erased ---> Package kftpgrabber.x86_64 0:0.8.1-6.fc9 set to be erased ---> Package kipi-plugins.x86_64 0:0.2.0-2.fc10 set to be erased ---> Package konq-plugins.x86_64 0:4.2.2-1.fc10 set to be erased ---> Package konversation.x86_64 0:1.1-1.fc10 set to be erased ---> Package kpackagekit.x86_64 0:0.3.1-9.fc10 set to be erased ---> Package ksshaskpass.x86_64 0:0.5.1-3.fc10 set to be erased ---> Package ktorrent.x86_64 0:3.2.1-1.fc10 set to be erased ---> Package libtunepimp-extras-freeworld.x86_64 0:0.5.3-5.fc10 set to be erased ---> Package pinentry-qt.x86_64 0:0.7.4-5.fc9 set to be erased ---> Package scim-bridge-qt.x86_64 0:0.4.15-8.fc10 set to be erased ---> Package scim-qtimm.x86_64 0:0.9.4-11.fc10 set to be erased ---> Package scribus.x86_64 0:1.3.5-0.12.beta.fc10 set to be erased ---> Package xine-lib-extras-freeworld.x86_64 0:1.1.16.3-1.fc10 set to be erased ---> Package zenity.x86_64 0:2.24.1-1.fc10 set to be erased --> Processing Dependency: zenity for package: gedit --> Running transaction check ---> Package PyKDE4.x86_64 0:4.2.2-2.fc10 set to be erased --> Processing Dependency: PyKDE4 >= 4.2.2 for package: kdeutils-printer-applet ---> Package digikam-libs.x86_64 0:0.10.0-1.fc10 set to be erased ---> Package gedit.x86_64 1:2.24.3-3.fc10 set to be erased ---> Package kaffeine-libs.x86_64 0:0.8.7-3.fc10 set to be erased ---> Package kdebase-libs.x86_64 6:4.2.2-3.fc10 set to be erased ---> Package kdebase-runtime.x86_64 0:4.2.2-4.fc10 set to be erased ---> Package kdebase-runtime-libs.x86_64 0:4.2.2-4.fc10 set to be erased ---> Package kdebase-workspace-libs.x86_64 0:4.2.2-5.fc10 set to be erased ---> Package kdeedu-marble.x86_64 0:4.2.2-1.fc10 set to be erased ---> Package kdegames-libs.x86_64 6:4.2.2-6.fc10 set to be erased ---> Package kdegraphics-libs.x86_64 7:4.2.2-5.fc10 set to be erased ---> Package kdemultimedia-libs.x86_64 6:4.2.2-2.fc10 set to be erased ---> Package kdenetwork-libs.x86_64 7:4.2.2-1.fc10 set to be erased ---> Package kdepim-libs.x86_64 6:4.2.2-3.fc10 set to be erased ---> Package kdepimlibs.x86_64 0:4.2.2-3.fc10 set to be erased ---> Package kdepimlibs-akonadi.x86_64 0:4.2.2-3.fc10 set to be erased ---> Package kdm.x86_64 0:4.2.2-5.fc10 set to be erased ---> Package kio_msits.x86_64 7:4.2.2-5.fc10 set to be erased ---> Package kio_sysinfo.x86_64 0:20090216-2.fc10 set to be erased --> Running transaction check ---> Package kdeutils-printer-applet.x86_64 6:4.2.2-2.fc10 set to be erased --> Finished Dependency Resolution -- Nathanael d. Noblet T: 403.875.4613 From nathanael at gnat.ca Thu May 7 16:14:02 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Thu, 07 May 2009 10:14:02 -0600 Subject: removing KDE removes NetworkManager-gnome?? In-Reply-To: <20090507155124.GB29606@redhat.com> References: <4A030058.3020107@gnat.ca> <20090507155124.GB29606@redhat.com> Message-ID: <4A0308CA.5060303@gnat.ca> Jeremy Katz wrote: > On Thursday, May 07 2009, Nathanael D. Noblet said: >> I ran the following command this morning: >> sudo yum --disableplugin=remove-with-leaves groupremove "KDE (K Desktop >> Environment)" >> >> I added the remove-with-leaves because when I ran it with that it was >> removing all sorts of stand alone programs like mysql-server and other >> stuff completely unrelated to kde... In any case, the command above >> produced the following list of packages to remove... > [snip] >> Why are gedit, NetworkManager-gnome, gstreamer-ffmpeg and >> gstreamer-plugins-ugly being removed? Is this a bug? > > NetworkManager-gnome is listed in the KDE comps group (as the KDE > plasmoid isn't ready yet afaik) and thus gets removed when you ask to > remove the group. I expect gedit and the gstreamer packages are due to > something similar in the group or one of their deps being explicitly > listed in the group So not a *bug* persay? Does yum not see that NetworkManager-gnome is in more than one group, and since another group requires it to leave it alone? Should it? Basically all I need to know is if this situation warrants a bug report. -- Nathanael d. Noblet T: 403.875.4613 From maxamillion at gmail.com Thu May 7 16:02:26 2009 From: maxamillion at gmail.com (Adam Miller) Date: Thu, 7 May 2009 11:02:26 -0500 Subject: removing KDE removes NetworkManager-gnome?? In-Reply-To: <20090507155124.GB29606@redhat.com> References: <4A030058.3020107@gnat.ca> <20090507155124.GB29606@redhat.com> Message-ID: I'm almost positive that OpenSUSE is shipping the kde plasmoid for network manager. I could be wrong though, but in the case that I'm not ... where are we on this? -Adam -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From henriquecsj at gmail.com Thu May 7 16:20:12 2009 From: henriquecsj at gmail.com (Henrique Junior) Date: Thu, 7 May 2009 13:20:12 -0300 Subject: Maximum and minimum install options Message-ID: <4f629b520905070920h5f24c9a5xc2911aea6482dd29@mail.gmail.com> Hello, folks, Many times in my work I find myself with the need for an installation of Fedora that was as minimal as possible. Something like a text mode with the least amount of fat possible, and if I remember correctly, in the past, Red Hat Linux count with two options to install: the maximum and minimum installation. I'm thinking if there are any chance to have this install options in Fedora in the near future. -- Henrique "LonelySpooky" Junior http://www.lonelyspooky.com ------------------------------------------------------------- "In a world without walls and fences, who needs windows and gates?!" -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdieter at math.unl.edu Thu May 7 16:21:36 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 07 May 2009 11:21:36 -0500 Subject: removing KDE removes NetworkManager-gnome?? References: <4A030058.3020107@gnat.ca> Message-ID: Nathanael D. Noblet wrote: > Hello, > I ran the following command this morning: > sudo yum --disableplugin=remove-with-leaves groupremove "KDE (K Desktop > Environment)" There's currently a lot of overlap between desktop environments. So, removing all of kde may well pull out components otherwise used by other DE's as well. -- Rex From nathanael at gnat.ca Thu May 7 16:27:11 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Thu, 07 May 2009 10:27:11 -0600 Subject: removing KDE removes NetworkManager-gnome?? In-Reply-To: References: <4A030058.3020107@gnat.ca> Message-ID: <4A030BDF.9060903@gnat.ca> Rex Dieter wrote: > Nathanael D. Noblet wrote: > >> Hello, >> I ran the following command this morning: >> sudo yum --disableplugin=remove-with-leaves groupremove "KDE (K Desktop >> Environment)" > > There's currently a lot of overlap between desktop environments. So, > removing all of kde may well pull out components otherwise used by other > DE's as well. Fair enough. Which brings me to my next question, should a bug be filed against whatever yum/rpm component that does group removal? Should it not see that a package exists in multiple groups, and only remove when no other installed group requires it? Wouldn't that be logical? Seems like a good idea... -- Nathanael d. Noblet T: 403.875.4613 From thomas.moschny at gmail.com Thu May 7 16:29:36 2009 From: thomas.moschny at gmail.com (Thomas Moschny) Date: Thu, 7 May 2009 18:29:36 +0200 Subject: removing KDE removes NetworkManager-gnome?? In-Reply-To: <4A0308CA.5060303@gnat.ca> References: <4A030058.3020107@gnat.ca> <20090507155124.GB29606@redhat.com> <4A0308CA.5060303@gnat.ca> Message-ID: 2009/5/7 Nathanael D. Noblet : > So not a *bug* persay? Does yum not see that NetworkManager-gnome is in more > than one group, and since another group requires it to leave it alone? > Should it? Basically all I need to know is if this situation warrants a bug > report. The problem is yum doesn't remember which groups you have installed. Hence it cannot do what you describe. The only reliable information is the rpm database and that does not have any information about the reason a package was installed for (requesting installation of that package itself, installation of a group with that package, installation as a dependency, etc.) - Thomas From skvidal at fedoraproject.org Thu May 7 16:32:57 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 7 May 2009 12:32:57 -0400 (EDT) Subject: removing KDE removes NetworkManager-gnome?? In-Reply-To: <4A030BDF.9060903@gnat.ca> References: <4A030058.3020107@gnat.ca> <4A030BDF.9060903@gnat.ca> Message-ID: On Thu, 7 May 2009, Nathanael D. Noblet wrote: > Rex Dieter wrote: >> Nathanael D. Noblet wrote: >> >>> Hello, >>> I ran the following command this morning: >>> sudo yum --disableplugin=remove-with-leaves groupremove "KDE (K Desktop >>> Environment)" >> >> There's currently a lot of overlap between desktop environments. So, >> removing all of kde may well pull out components otherwise used by other >> DE's as well. > > Fair enough. Which brings me to my next question, should a bug be filed > against whatever yum/rpm component that does group removal? Should it not see > that a package exists in multiple groups, and only remove when no other > installed group requires it? Wouldn't that be logical? Seems like a good > idea... > Logical, but then so is the other view - the user asked us to remove pkgs X Y and Z. This means remove all things depending on them, too. -sv From skvidal at fedoraproject.org Thu May 7 16:33:35 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 7 May 2009 12:33:35 -0400 (EDT) Subject: removing KDE removes NetworkManager-gnome?? In-Reply-To: References: <4A030058.3020107@gnat.ca> <20090507155124.GB29606@redhat.com> <4A0308CA.5060303@gnat.ca> Message-ID: On Thu, 7 May 2009, Thomas Moschny wrote: > 2009/5/7 Nathanael D. Noblet : >> So not a *bug* persay? Does yum not see that NetworkManager-gnome is in more >> than one group, and since another group requires it to leave it alone? >> Should it? Basically all I need to know is if this situation warrants a bug >> report. > > The problem is yum doesn't remember which groups you have installed. > Hence it cannot do what you describe. > > The only reliable information is the rpm database and that does not > have any information about the reason a package was installed for > (requesting installation of that package itself, installation of a > group with that package, installation as a dependency, etc.) > We're working on that - of course we can't link groups/pkgs when the pkg was installed NOT in a group. -sv From ol.morgan at telia.com Thu May 7 16:42:22 2009 From: ol.morgan at telia.com (mo) Date: Thu, 07 May 2009 18:42:22 +0200 Subject: removing KDE removes NetworkManager-gnome?? In-Reply-To: References: <4A030058.3020107@gnat.ca> Message-ID: <1241714543.4794.20.camel@ubuntu.Belkin> On Thu, 2009-05-07 at 11:21 -0500, Rex Dieter wrote: > Nathanael D. Noblet wrote: > > > Hello, > > I ran the following command this morning: > > sudo yum --disableplugin=remove-with-leaves groupremove "KDE (K Desktop > > Environment)" > > There's currently a lot of overlap between desktop environments. So, > removing all of kde may well pull out components otherwise used by other > DE's as well. > For a low tech-graphics-only user, like me, this is no good. I had no idea of what package is doing this or that, so when I had tried KDE, and removed it (and of course just accepted the list of packages to remove), I got very surprised when the system lost network contact and became useless to me. I had to reinstall. Why I am reading this list? Have no friends and likes to get emails. :-) From maxamillion at gmail.com Thu May 7 16:47:19 2009 From: maxamillion at gmail.com (Adam Miller) Date: Thu, 7 May 2009 11:47:19 -0500 Subject: Maximum and minimum install options In-Reply-To: <4f629b520905070920h5f24c9a5xc2911aea6482dd29@mail.gmail.com> References: <4f629b520905070920h5f24c9a5xc2911aea6482dd29@mail.gmail.com> Message-ID: Its a feature of Fedora 11 called "Minimal Platform" https://fedoraproject.org/wiki/Features/MinimalPlatform -Adam -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From adam at spicenitz.org Thu May 7 16:51:34 2009 From: adam at spicenitz.org (Adam Goode) Date: Thu, 07 May 2009 12:51:34 -0400 Subject: crypto consolidation status? Message-ID: <4A031196.606@spicenitz.org> Hi, Some of my colleagues work on an RPC library that will be gaining TLS support. http://minirpc.cs.cmu.edu/ Being familiar with http://fedoraproject.org/wiki/FedoraCryptoConsolidation I of course told them that NSS was the best library to use for this. But there are a few issues with this: * What is the rationale for requiring a shared certificate store? More importantly, we would like to allow an application to temporarily use a private cert (that it may trust for some reason) without spreading that trust to all applications on the system. It seems like the issue of certificate management is separable from the actual crypto part. * We are trying to use TLS from a library. The NSS documentation seems to suggest that calling NSS_Init more than once is bad. It doesn't look like it would be safe to call NSS_Init from a library. Really NSS should be returning a context object that encapsulates all NSS state, yes? * It's not obvious what to pass to NSS_Init. Looking at nss_compat_ossl shows some tricks with getenv("SSL_DIR") and such. Is that practice documented anywhere? I know things are better with NSS 3.12. But it is not entirely clear how to write code to best take advantage of this and future enhancements, as the wiki claims. ("Conversion to NSS will automatically add these features to those applications that convert.") It almost seems like a little more work is needed in NSS before it can really work as the one true crypto library. Thanks, Adam From nathanael at gnat.ca Thu May 7 16:52:39 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Thu, 07 May 2009 10:52:39 -0600 Subject: removing KDE removes NetworkManager-gnome?? In-Reply-To: References: <4A030058.3020107@gnat.ca> <20090507155124.GB29606@redhat.com> <4A0308CA.5060303@gnat.ca> Message-ID: <4A0311D7.8070502@gnat.ca> Seth Vidal wrote: > > > On Thu, 7 May 2009, Thomas Moschny wrote: > >> 2009/5/7 Nathanael D. Noblet : >>> So not a *bug* persay? Does yum not see that NetworkManager-gnome is >>> in more >>> than one group, and since another group requires it to leave it alone? >>> Should it? Basically all I need to know is if this situation warrants >>> a bug >>> report. >> >> The problem is yum doesn't remember which groups you have installed. >> Hence it cannot do what you describe. You mean it doesn't know that a package was installed as part of a group install, vs a package in a group happens to have been installed? I ask because I can do grouplist, and it shows me which groups are installed... I've manually re-installed NetworkManager-gnome, and KDE isn't in the installed groups but ion the Available groups... So I'm not sure what the limitation is I guess. > We're working on that - of course we can't link groups/pkgs when the pkg > was installed NOT in a group. -- Nathanael d. Noblet T: 403.875.4613 From skvidal at fedoraproject.org Thu May 7 16:54:15 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 7 May 2009 12:54:15 -0400 (EDT) Subject: removing KDE removes NetworkManager-gnome?? In-Reply-To: <4A0311D7.8070502@gnat.ca> References: <4A030058.3020107@gnat.ca> <20090507155124.GB29606@redhat.com> <4A0308CA.5060303@gnat.ca> <4A0311D7.8070502@gnat.ca> Message-ID: On Thu, 7 May 2009, Nathanael D. Noblet wrote: > Seth Vidal wrote: >> >> >> On Thu, 7 May 2009, Thomas Moschny wrote: >> >>> 2009/5/7 Nathanael D. Noblet : >>>> So not a *bug* persay? Does yum not see that NetworkManager-gnome is in >>>> more >>>> than one group, and since another group requires it to leave it alone? >>>> Should it? Basically all I need to know is if this situation warrants a >>>> bug >>>> report. >>> >>> The problem is yum doesn't remember which groups you have installed. >>> Hence it cannot do what you describe. > > You mean it doesn't know that a package was installed as part of a group > install, vs a package in a group happens to have been installed? I ask > because I can do grouplist, and it shows me which groups are installed... > > I've manually re-installed NetworkManager-gnome, and KDE isn't in the > installed groups but ion the Available groups... So I'm not sure what the > limitation is I guess. > It is not so much 'knowing' as guessing based on what your comps files say NOW and what you have installed. -sv From nathanael at gnat.ca Thu May 7 16:54:57 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Thu, 07 May 2009 10:54:57 -0600 Subject: removing KDE removes NetworkManager-gnome?? In-Reply-To: References: <4A030058.3020107@gnat.ca> <4A030BDF.9060903@gnat.ca> Message-ID: <4A031261.8080505@gnat.ca> Seth Vidal wrote: > Logical, but then so is the other view - the user asked us to remove > pkgs X Y and Z. This means remove all things depending on them, too. Right, however in this case NetworkManager-gnome, gstreamer-ffmpeg, gedit.. What KDE package requires those? Or are you meaning since I want KDE group gone remove all packages in the group including dependancies on packages in that group is more logical than leaving packages needed by other groups? I guess I can see both cases, so this would be a good place for an option --leave-packages-required-by-other-groups ;) That's not a hard parameter to remember AT ALL... :D -- Nathanael d. Noblet T: 403.875.4613 From skvidal at fedoraproject.org Thu May 7 16:58:47 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 7 May 2009 12:58:47 -0400 (EDT) Subject: removing KDE removes NetworkManager-gnome?? In-Reply-To: <4A031261.8080505@gnat.ca> References: <4A030058.3020107@gnat.ca> <4A030BDF.9060903@gnat.ca> <4A031261.8080505@gnat.ca> Message-ID: On Thu, 7 May 2009, Nathanael D. Noblet wrote: > Seth Vidal wrote: > >> Logical, but then so is the other view - the user asked us to remove pkgs X >> Y and Z. This means remove all things depending on them, too. > > Right, however in this case NetworkManager-gnome, gstreamer-ffmpeg, gedit.. > What KDE package requires those? Or are you meaning since I want KDE group > gone remove all packages in the group including dependancies on packages in > that group is more logical than leaving packages needed by other groups? > > I guess I can see both cases, so this would be a good place for an option > --leave-packages-required-by-other-groups ;) That's not a hard parameter to > remember AT ALL... :D riiiiiiiiiiiiight -sv From henriquecsj at gmail.com Thu May 7 17:06:03 2009 From: henriquecsj at gmail.com (Henrique Junior) Date: Thu, 7 May 2009 14:06:03 -0300 Subject: Maximum and minimum install options In-Reply-To: References: <4f629b520905070920h5f24c9a5xc2911aea6482dd29@mail.gmail.com> Message-ID: <4f629b520905071006re1a5ec8ka353f0c6810aff6e@mail.gmail.com> This will be very helpfull. Thanks 2009/5/7 Adam Miller > Its a feature of Fedora 11 called "Minimal Platform" > > https://fedoraproject.org/wiki/Features/MinimalPlatform > > -Adam > > -- > http://maxamillion.googlepages.com > --------------------------------------------------------- > () ascii ribbon campaign - against html e-mail > /\ www.asciiribbon.org - against proprietary attachments > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Henrique "LonelySpooky" Junior http://www.lonelyspooky.com ------------------------------------------------------------- "In a world without walls and fences, who needs windows and gates?!" -------------- next part -------------- An HTML attachment was scrubbed... URL: From skvidal at fedoraproject.org Thu May 7 17:04:37 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 7 May 2009 13:04:37 -0400 (EDT) Subject: removing KDE removes NetworkManager-gnome?? In-Reply-To: <4A0308CA.5060303@gnat.ca> References: <4A030058.3020107@gnat.ca> <20090507155124.GB29606@redhat.com> <4A0308CA.5060303@gnat.ca> Message-ID: On Thu, 7 May 2009, Nathanael D. Noblet wrote: > Jeremy Katz wrote: >> On Thursday, May 07 2009, Nathanael D. Noblet said: >>> I ran the following command this morning: >>> sudo yum --disableplugin=remove-with-leaves groupremove "KDE (K Desktop >>> Environment)" >>> >>> I added the remove-with-leaves because when I ran it with that it was >>> removing all sorts of stand alone programs like mysql-server and other >>> stuff completely unrelated to kde... In any case, the command above >>> produced the following list of packages to remove... >> [snip] >>> Why are gedit, NetworkManager-gnome, gstreamer-ffmpeg and >>> gstreamer-plugins-ugly being removed? Is this a bug? >> >> NetworkManager-gnome is listed in the KDE comps group (as the KDE >> plasmoid isn't ready yet afaik) and thus gets removed when you ask to >> remove the group. I expect gedit and the gstreamer packages are due to >> something similar in the group or one of their deps being explicitly >> listed in the group > > So not a *bug* persay? Does yum not see that NetworkManager-gnome is in more > than one group, and since another group requires it to leave it alone? Should > it? Basically all I need to know is if this situation warrants a bug report. it'san RFE - and I'm reasonably certain it has already been filed. You're welcome to do it again, though. -sv From nathanael at gnat.ca Thu May 7 17:08:00 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Thu, 07 May 2009 11:08:00 -0600 Subject: removing KDE removes NetworkManager-gnome?? In-Reply-To: References: <4A030058.3020107@gnat.ca> <4A030BDF.9060903@gnat.ca> <4A031261.8080505@gnat.ca> Message-ID: <4A031570.5070007@gnat.ca> Seth Vidal wrote: > > > On Thu, 7 May 2009, Nathanael D. Noblet wrote: > >> Seth Vidal wrote: >> >>> Logical, but then so is the other view - the user asked us to remove >>> pkgs X Y and Z. This means remove all things depending on them, too. >> >> Right, however in this case NetworkManager-gnome, gstreamer-ffmpeg, >> gedit.. What KDE package requires those? Or are you meaning since I >> want KDE group gone remove all packages in the group including >> dependancies on packages in that group is more logical than leaving >> packages needed by other groups? >> >> I guess I can see both cases, so this would be a good place for an >> option --leave-packages-required-by-other-groups ;) That's not a hard >> parameter to remember AT ALL... :D > > riiiiiiiiiiiiight So then... um brings me back full circle, is this an issue worth filing something about, or is it expected behaviour/known issue that one day will change whenever the underlying tools gain that ability and I can patiently wait for that day? I'm happy either way. I was just surprised to see a NetworkManager-gnome in the KDE desktop group... since I installed it to see what 4.x was like and then didn't like a million new apps in my menu so want... anyway who cares why. Do I leave enough alone, or file a bug/feature request with my wonderfully conceived new flag/parameter for groupremove. I'm sure it'll be so loved it'll make the front page of slashdot... ;) -- Nathanael d. Noblet T: 403.875.4613 From nathanael at gnat.ca Thu May 7 17:08:51 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Thu, 07 May 2009 11:08:51 -0600 Subject: removing KDE removes NetworkManager-gnome?? In-Reply-To: References: <4A030058.3020107@gnat.ca> <20090507155124.GB29606@redhat.com> <4A0308CA.5060303@gnat.ca> Message-ID: <4A0315A3.1030600@gnat.ca> Seth Vidal wrote: > > > On Thu, 7 May 2009, Nathanael D. Noblet wrote: > >> Jeremy Katz wrote: >>> On Thursday, May 07 2009, Nathanael D. Noblet said: >>>> I ran the following command this morning: >>>> sudo yum --disableplugin=remove-with-leaves groupremove "KDE (K >>>> Desktop Environment)" >>>> >>>> I added the remove-with-leaves because when I ran it with that it >>>> was removing all sorts of stand alone programs like mysql-server and >>>> other stuff completely unrelated to kde... In any case, the command >>>> above produced the following list of packages to remove... >>> [snip] >>>> Why are gedit, NetworkManager-gnome, gstreamer-ffmpeg and >>>> gstreamer-plugins-ugly being removed? Is this a bug? >>> >>> NetworkManager-gnome is listed in the KDE comps group (as the KDE >>> plasmoid isn't ready yet afaik) and thus gets removed when you ask to >>> remove the group. I expect gedit and the gstreamer packages are due to >>> something similar in the group or one of their deps being explicitly >>> listed in the group >> >> So not a *bug* persay? Does yum not see that NetworkManager-gnome is >> in more than one group, and since another group requires it to leave >> it alone? Should it? Basically all I need to know is if this situation >> warrants a bug report. > > it'san RFE - and I'm reasonably certain it has already been filed. > > You're welcome to do it again, though. No need to pollute bugzilla with a duplicate. Thanks for the info. and ignore the post just before this asking the exact same question ;) -- Nathanael d. Noblet T: 403.875.4613 From awilliam at redhat.com Thu May 7 17:12:25 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 07 May 2009 10:12:25 -0700 Subject: removing KDE removes NetworkManager-gnome?? In-Reply-To: <4A031261.8080505@gnat.ca> References: <4A030058.3020107@gnat.ca> <4A030BDF.9060903@gnat.ca> <4A031261.8080505@gnat.ca> Message-ID: <1241716345.2923.496.camel@adam.local.net> On Thu, 2009-05-07 at 10:54 -0600, Nathanael D. Noblet wrote: > Right, however in this case NetworkManager-gnome, gstreamer-ffmpeg, > gedit.. What KDE package requires those? As already noted, KDE uses NetworkManager-gnome because the KDE NetworkManager plasmoid is currently still, er, a little bit crap. I imagine gstreamer-ffmpeg is pulled for video purposes, and we have Phonon configured to use its gstreamer backend by default. No idea about gedit, though. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From jkeating at redhat.com Thu May 7 17:41:37 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 07 May 2009 10:41:37 -0700 Subject: 182 pending F11 stable updates. WTF? Message-ID: <1241718097.3209.11.camel@localhost.localdomain> How is it we have 182 stable updates pending for F11 already? How have these seen any testing by a wider audience? Are we really just not bothering with updates-testing anymore? Do we not care about distro stability? I know that many of these are newpackages, but many aren't though. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From opensource at till.name Thu May 7 17:59:06 2009 From: opensource at till.name (Till Maas) Date: Thu, 07 May 2009 19:59:06 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241718097.3209.11.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> Message-ID: <200905071959.22508.opensource@till.name> On Do Mai 7 2009, Jesse Keating wrote: > How is it we have 182 stable updates pending for F11 already? How have > these seen any testing by a wider audience? Are we really just not > bothering with updates-testing anymore? Do we not care about distro > stability? Afaik, requests to updates-testing were not processed for F11, e.g. for one or two of my new packages I requested updates-testing for F9, F10 and F11 at the same time, got positive feedback / no negative feedback for F9 or F10 and then moved them all to stable at the same time, resp. canceled the testing request for F11 and made it to a stable one. I guess this affects also other packages, that were updated in F9 or F10 and F11, to have a working update path from FX with updates to FX+1 with updates. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From loganjerry at gmail.com Thu May 7 17:59:38 2009 From: loganjerry at gmail.com (Jerry James) Date: Thu, 7 May 2009 11:59:38 -0600 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241718097.3209.11.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> Message-ID: <870180fe0905071059je82bfb8mad333ebb536e00b8@mail.gmail.com> On Thu, May 7, 2009 at 11:41 AM, Jesse Keating wrote: > How is it we have 182 stable updates pending for F11 already? ?How have > these seen any testing by a wider audience? ?Are we really just not > bothering with updates-testing anymore? ?Do we not care about distro > stability? > > I know that many of these are newpackages, but many aren't though. > > > -- > Jesse Keating > Fedora -- Freedom? is a feature! > identi.ca: http://identi.ca/jkeating Speaking only for the 1 package I contributed to that 182, this was a change in the subpackage structure that was needed in a package that depends on mine. It was a minor change, but I pushed it to -testing for F-10 and F-11 anyway. I tested it for a week in F-10 and in Rawhide with no ill effects, so I pushed it to stable for F-10 and F-11 so that the other packager can go do what he needs to do to his package. If this was the wrong way to address the problem, please educate me on the correct way. -- Jerry James http://www.jamezone.org/ From rdieter at math.unl.edu Thu May 7 18:02:05 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 07 May 2009 13:02:05 -0500 Subject: removing KDE removes NetworkManager-gnome?? References: <4A030058.3020107@gnat.ca> <4A030BDF.9060903@gnat.ca> <4A031261.8080505@gnat.ca> <1241716345.2923.496.camel@adam.local.net> Message-ID: Adam Williamson wrote: > Phonon configured to use its gstreamer backend by default. phonon-backend-xine is (still) the default, though phonon-backend-gstreamer will happily be used instead if it's the only backend installed and available. -- Rex From rayvd at bludgeon.org Thu May 7 18:02:19 2009 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Thu, 7 May 2009 11:02:19 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241718097.3209.11.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> Message-ID: <20090507180219.GA423@bludgeon.org> On Thu, May 07, 2009 at 10:41:37AM -0700, Jesse Keating wrote: > How is it we have 182 stable updates pending for F11 already? How have > these seen any testing by a wider audience? Are we really just not > bothering with updates-testing anymore? Do we not care about distro > stability? > > I know that many of these are newpackages, but many aren't though. > I had tagged one of mine for testing, but it sat there for a couple weeks and nothing happened.... so I requested stable instead. Maybe I should have waited longer or re-requested testing. Ray From choeger at cs.tu-berlin.de Thu May 7 18:05:06 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Thu, 07 May 2009 20:05:06 +0200 Subject: glibc fork ? In-Reply-To: <4A02F8D3.2010807@poolshark.org> References: <4A02F8D3.2010807@poolshark.org> Message-ID: <1241719506.3267.4.camel@choeger6> Am Donnerstag, den 07.05.2009, 17:05 +0200 schrieb Denis Leroy: > http://www.eglibc.org/home > > So are we moving to eglibc as well ? :-) > > So what happened ? Overreaction from Debian guy, or poor community > management from RH guy ? I've discussed this issue with some debian maintainers I work with. It seems they all agree to UD not being a very comfortable upstream maintainer. The question is: What kind of thing does eglibc worse than glibc? I mean it is smaller and compatible so there must be regressions, right? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From kevin at scrye.com Thu May 7 18:11:26 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Thu, 7 May 2009 12:11:26 -0600 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241718097.3209.11.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> Message-ID: <20090507121126.4ebb7f29@ohm.scrye.com> On Thu, 07 May 2009 10:41:37 -0700 Jesse Keating wrote: > How is it we have 182 stable updates pending for F11 already? How > have these seen any testing by a wider audience? Are we really just > not bothering with updates-testing anymore? Do we not care about > distro stability? > > I know that many of these are newpackages, but many aren't though. > Speaking for the 15 Xfce updates: They are an update from 4.6.0 to 4.6.1. These updates are mostly translation fixes, along with a very few minor bug fixes. http://mocha.xfce.org/documentation/changelogs/4.6.1 I have been running them here since the day they came out with no problems at all. Also upstream there are not much in the way of bug reports, so I thought they should be ok to move to stable. I suppose I should have left them in testing for a bit, but also many people will expect a newly released fedora to have the latest version available, especially if they are in a locale that got updated. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From jkeating at redhat.com Thu May 7 18:25:28 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 07 May 2009 11:25:28 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <200905071959.22508.opensource@till.name> References: <1241718097.3209.11.camel@localhost.localdomain> <200905071959.22508.opensource@till.name> Message-ID: <1241720728.3209.12.camel@localhost.localdomain> On Thu, 2009-05-07 at 19:59 +0200, Till Maas wrote: > Afaik, requests to updates-testing were not processed for F11, e.g. for one or > two of my new packages I requested updates-testing for F9, F10 and F11 at the > same time, got positive feedback / no negative feedback for F9 or F10 and then > moved them all to stable at the same time, resp. canceled the testing request > for F11 and made it to a stable one. I guess this affects also other packages, > that were updated in F9 or F10 and F11, to have a working update path from FX > with updates to FX+1 with updates. Upgrade paths are a concern yes, however our upgrade path stuff is so busted anyway when doing upgrades to the next release that... well... *sigh*. Perhaps this is just a case of too many streams, and trying to let people do things ahead of time. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Thu May 7 18:26:18 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 07 May 2009 11:26:18 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <870180fe0905071059je82bfb8mad333ebb536e00b8@mail.gmail.com> References: <1241718097.3209.11.camel@localhost.localdomain> <870180fe0905071059je82bfb8mad333ebb536e00b8@mail.gmail.com> Message-ID: <1241720778.3209.13.camel@localhost.localdomain> On Thu, 2009-05-07 at 11:59 -0600, Jerry James wrote: > Speaking only for the 1 package I contributed to that 182, this was a > change in the subpackage structure that was needed in a package that > depends on mine. It was a minor change, but I pushed it to -testing > for F-10 and F-11 anyway. I tested it for a week in F-10 and in > Rawhide with no ill effects, so I pushed it to stable for F-10 and > F-11 so that the other packager can go do what he needs to do to his > package. > > If this was the wrong way to address the problem, please educate me on > the correct way. For F11 it could have been done as a buildroot override so that the other packager could build against your change, and then the two packages could be pushed to testing/stable together as one update request. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Thu May 7 18:26:44 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 07 May 2009 11:26:44 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <20090507180219.GA423@bludgeon.org> References: <1241718097.3209.11.camel@localhost.localdomain> <20090507180219.GA423@bludgeon.org> Message-ID: <1241720804.3209.14.camel@localhost.localdomain> On Thu, 2009-05-07 at 11:02 -0700, Ray Van Dolson wrote: > > I had tagged one of mine for testing, but it sat there for a couple > weeks and nothing happened.... so I requested stable instead. > > Maybe I should have waited longer or re-requested testing. F11 testing updates aren't going anywhere yet, so there isn't really any possibility of getting feedback on them yet. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Thu May 7 18:27:38 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 07 May 2009 11:27:38 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <20090507121126.4ebb7f29@ohm.scrye.com> References: <1241718097.3209.11.camel@localhost.localdomain> <20090507121126.4ebb7f29@ohm.scrye.com> Message-ID: <1241720858.3209.15.camel@localhost.localdomain> On Thu, 2009-05-07 at 12:11 -0600, Kevin Fenzi wrote: > > They are an update from 4.6.0 to 4.6.1. > These updates are mostly translation fixes, along with a very few minor > bug fixes. > > http://mocha.xfce.org/documentation/changelogs/4.6.1 > > I have been running them here since the day they came out with no > problems at all. Also upstream there are not much in the way of bug > reports, so I thought they should be ok to move to stable. > > I suppose I should have left them in testing for a bit, but also many > people will expect a newly released fedora to have the latest version > available, especially if they are in a locale that got updated. This seems pretty reasonable. I'd be more comfortable if a few more people on F11's rawhide tried them, but *shrug*. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dwinship at redhat.com Thu May 7 18:29:28 2009 From: dwinship at redhat.com (Dan Winship) Date: Thu, 07 May 2009 14:29:28 -0400 Subject: crypto consolidation status? In-Reply-To: <4A031196.606@spicenitz.org> References: <4A031196.606@spicenitz.org> Message-ID: <4A032888.7030403@redhat.com> Adam Goode wrote: > * We are trying to use TLS from a library. The NSS documentation seems > to suggest that calling NSS_Init more than once is bad. It doesn't > look like it would be safe to call NSS_Init from a library. Really > NSS should be returning a context object that encapsulates all NSS > state, yes? Yes. https://bugzilla.redhat.com/show_bug.cgi?id=466313 > It almost seems like a little more work is needed in NSS before it can > really work as the one true crypto library. Agreed. Right now it's really only designed to be used directly by applications, not by other libraries. -- Dan From Jochen at herr-schmitt.de Thu May 7 18:48:53 2009 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 07 May 2009 20:48:53 +0200 Subject: crypto consolidation status? In-Reply-To: <4A032888.7030403@redhat.com> References: <4A031196.606@spicenitz.org> <4A032888.7030403@redhat.com> Message-ID: <4A032D15.6070203@herr-schmitt.de> Dan Winship schrieb: > Agreed. Right now it's really only designed to be used directly by > applications, not by other libraries. > > Even on http://www.pro-linux.de I have read negativ comments about him. Best Regards: Jochen Schmitt From rcritten at redhat.com Thu May 7 18:51:50 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 07 May 2009 14:51:50 -0400 Subject: crypto consolidation status? In-Reply-To: <4A032888.7030403@redhat.com> References: <4A031196.606@spicenitz.org> <4A032888.7030403@redhat.com> Message-ID: <4A032DC6.50501@redhat.com> Dan Winship wrote: > Adam Goode wrote: >> * We are trying to use TLS from a library. The NSS documentation seems >> to suggest that calling NSS_Init more than once is bad. It doesn't >> look like it would be safe to call NSS_Init from a library. Really >> NSS should be returning a context object that encapsulates all NSS >> state, yes? > > Yes. https://bugzilla.redhat.com/show_bug.cgi?id=466313 The thing about NSS_Init is that the first caller wins. Subsequent calls will silently succeed but you'll be using the initial database. It is possible to open multiple NSS databases in a single process you just don't use NSS_Init to open subsequent ones. Per the bug it isn't really expected for people to use the SSL_DIR environment variable. Since this provides compatibility with OpenSSL one can continue to use the same PEM files. NSS has a PKCS#11 module which can load these into an in-memory NSS database for use. I'm not discouraging its use but may simply be easier to use PEM files for now. > >> It almost seems like a little more work is needed in NSS before it can >> really work as the one true crypto library. > > Agreed. Right now it's really only designed to be used directly by > applications, not by other libraries. > > -- Dan > I think some NSS work that is expected to appear in F12 will move things a great deal closer to this goal. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From bruno at wolff.to Thu May 7 19:05:46 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Thu, 7 May 2009 14:05:46 -0500 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241720858.3209.15.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <20090507121126.4ebb7f29@ohm.scrye.com> <1241720858.3209.15.camel@localhost.localdomain> Message-ID: <20090507190546.GA28423@wolff.to> On Thu, May 07, 2009 at 11:27:38 -0700, Jesse Keating wrote: > > This seems pretty reasonable. I'd be more comfortable if a few more > people on F11's rawhide tried them, but *shrug*. If there was a repo set up for these I'd be running them. This time around I felt it was more trouble than it was worth to pull the updates candidates ahead of time. I pull kernels and graphics related stuff from koji, but the other stuff I don't care enough to go to the extra effort for. I still only report problems for things I was actually using or any install conflicts that showed up. But it would get some more coverage. I don't know if there is enough people like me to make it worth doing. From tgl at redhat.com Thu May 7 19:15:30 2009 From: tgl at redhat.com (Tom Lane) Date: Thu, 07 May 2009 15:15:30 -0400 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241718097.3209.11.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> Message-ID: <23753.1241723730@sss.pgh.pa.us> Jesse Keating writes: > How is it we have 182 stable updates pending for F11 already? What do you expect, when the release freeze policy essentially forbids any noncritical updates for a month? People don't stop working just because releng wants to simplify their own lives. The only reason there aren't 184 is I haven't bothered to try to push my pending updates for mysql and postgresql ... but they'll be in the zero-day update queue just like a lot of other things. regards, tom lane From rayvd at bludgeon.org Thu May 7 19:18:34 2009 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Thu, 7 May 2009 12:18:34 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241720804.3209.14.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <20090507180219.GA423@bludgeon.org> <1241720804.3209.14.camel@localhost.localdomain> Message-ID: <20090507191834.GA1419@bludgeon.org> On Thu, May 07, 2009 at 11:26:44AM -0700, Jesse Keating wrote: > On Thu, 2009-05-07 at 11:02 -0700, Ray Van Dolson wrote: > > > > I had tagged one of mine for testing, but it sat there for a couple > > weeks and nothing happened.... so I requested stable instead. > > > > Maybe I should have waited longer or re-requested testing. > > F11 testing updates aren't going anywhere yet, so there isn't really any > possibility of getting feedback on them yet. I'm happy enough to leave my update waiting in "testing" if that's the right thing to do (until after the release I assume). Just didn't know. For some reason I thought f11-updates could be pushed to as this wouldn't affect what was frozen for 11. Ray From dcantrell at redhat.com Thu May 7 19:20:30 2009 From: dcantrell at redhat.com (David Cantrell) Date: Thu, 07 May 2009 09:20:30 -1000 Subject: Note on man pages In-Reply-To: <1241712406.13505.262.camel@breeves.fab.redhat.com> References: <4A00BCE9.3050800@fedoraproject.org> <1241588035.7862.2.camel@prague> <1241588791.3101.2.camel@localhost.localdomain> <20090507155213.GA7984@amd.home.annexia.org> <1241712406.13505.262.camel@breeves.fab.redhat.com> Message-ID: <4A03347E.5060104@redhat.com> On 05/07/2009 06:06 AM, Bryn M. Reeves wrote: > On Thu, 2009-05-07 at 16:52 +0100, Richard W.M. Jones wrote: >> On Wed, May 06, 2009 at 08:46:31AM +0300, Jussi Lehtola wrote: >>> On Wed, 2009-05-06 at 07:33 +0200, nodata wrote: >>>> Am Mittwoch, den 06.05.2009, 04:47 +0200 schrieb Kevin Kofler: >>>>> Well, there are many upstreams rejecting Debian's patches outright, saying >>>>> manpages are obsolete and redundant with any of: >>>>> * info documentation (those are mostly the GNU projects), >>>> /me still secretly hopes info pages go away. >>> +1 >>> >>> From a usability point of view there's nothing that beats man pages. >> +1000 > > I see your 1000 and raise it 1000000. Personally, I think that Debian > have done a great service to the broader community by their insistence > on man pages for every package. So long as it's not a man page that tells you to go read the info page. -- David Cantrell Red Hat / Honolulu, HI From denis at poolshark.org Thu May 7 19:34:37 2009 From: denis at poolshark.org (Denis Leroy) Date: Thu, 07 May 2009 21:34:37 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241718097.3209.11.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> Message-ID: <4A0337CD.5010401@poolshark.org> On 05/07/2009 07:41 PM, Jesse Keating wrote: > How is it we have 182 stable updates pending for F11 already? How have > these seen any testing by a wider audience? Are we really just not > bothering with updates-testing anymore? Do we not care about distro > stability? > > I know that many of these are newpackages, but many aren't though. > The automated testing->stable bodhi upgrades should really be disabled during release freeze. Can we move all 182 pending updates back to testing until F-11 is released ? From dcantrell at redhat.com Thu May 7 19:48:07 2009 From: dcantrell at redhat.com (David Cantrell) Date: Thu, 07 May 2009 09:48:07 -1000 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241718097.3209.11.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> Message-ID: <4A033AF7.3020200@redhat.com> On 05/07/2009 07:41 AM, Jesse Keating wrote: > How is it we have 182 stable updates pending for F11 already? How have > these seen any testing by a wider audience? Are we really just not > bothering with updates-testing anymore? Do we not care about distro > stability? > > I know that many of these are newpackages, but many aren't though. > I do care about Fedora stability, but it's hard to force users to report bugs and help you test out fixes within the Fedora development schedule. I wish we had slightly longer release cycles, but that could just be me. And I'm no koji expert, but: $ koji list-pkgs --tag=f11-final --quiet | wc -l 7622 So, 2.39% of our packages have pending F-11 updates? -- David Cantrell Red Hat / Honolulu, HI From mdehaan at redhat.com Thu May 7 19:50:23 2009 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 07 May 2009 15:50:23 -0400 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241718097.3209.11.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> Message-ID: <4A033B7F.1030801@redhat.com> Jesse Keating wrote: > How is it we have 182 stable updates pending for F11 already? How have > these seen any testing by a wider audience? Are we really just not > bothering with updates-testing anymore? Do we not care about distro > stability? > > I know that many of these are newpackages, but many aren't though. > > > My experience is that most commercial users do not bother with logging into Bhodi or even know it exists. Another problem is that EPEL doesn't /yet/ use bhodi, so it has a different workflow -- meaning EPEL-testing doesn't really test anything, it means "rolls every 30-40 days", and that's about it. So testing has to happen manually, Fedora is the minority use case. Having a way to vote/comment without FAS would probably be enormously helpful in getting more users to use the system, once EPEL uses the same system. --Michael From dcantrell at redhat.com Thu May 7 19:50:47 2009 From: dcantrell at redhat.com (David Cantrell) Date: Thu, 07 May 2009 09:50:47 -1000 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <4A033B7F.1030801@redhat.com> References: <1241718097.3209.11.camel@localhost.localdomain> <4A033B7F.1030801@redhat.com> Message-ID: <4A033B97.508@redhat.com> On 05/07/2009 09:50 AM, Michael DeHaan wrote: > Jesse Keating wrote: >> How is it we have 182 stable updates pending for F11 already? How have >> these seen any testing by a wider audience? Are we really just not >> bothering with updates-testing anymore? Do we not care about distro >> stability? >> >> I know that many of these are newpackages, but many aren't though. >> >> > > My experience is that most commercial users do not bother with logging > into Bhodi or even know it exists. > > Another problem is that EPEL doesn't /yet/ use bhodi, so it has a > different workflow -- meaning EPEL-testing doesn't really test anything, > it means "rolls every 30-40 days", and that's about it. > So testing has to happen manually, Fedora is the minority use case. > > Having a way to vote/comment without FAS would probably be enormously > helpful in getting more users to use the system, once EPEL uses the same > system. Definitely. Whenever I ask users to test an update and then comment in bodhi, the latter never happens. They test the update and 2 weeks later I get a nag mail from bodhi about updates still sitting around. I move them to stable since I at least had the original reporter test it and verify it worked. -- David Cantrell Red Hat / Honolulu, HI From mschwendt at gmail.com Thu May 7 19:52:27 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 7 May 2009 21:52:27 +0200 Subject: crypto consolidation status? In-Reply-To: <4A032D15.6070203@herr-schmitt.de> References: <4A031196.606@spicenitz.org> <4A032888.7030403@redhat.com> <4A032D15.6070203@herr-schmitt.de> Message-ID: <20090507215227.3def8b26@faldor.intranet> On Thu, 07 May 2009 20:48:53 +0200, Jochen wrote: > Dan Winship schrieb: > > Agreed. Right now it's really only designed to be used directly by > > applications, not by other libraries. > > > > > Even on http://www.pro-linux.de I have read negativ comments about him. Doesn't mean much. They permit anonymous comments on news articles. Many trolls and people with really bad attitude (ab)use such platforms for bashing, or use them for other sorts of role-playing. From skvidal at fedoraproject.org Thu May 7 19:53:15 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 7 May 2009 15:53:15 -0400 (EDT) Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <4A033B97.508@redhat.com> References: <1241718097.3209.11.camel@localhost.localdomain> <4A033B7F.1030801@redhat.com> <4A033B97.508@redhat.com> Message-ID: On Thu, 7 May 2009, David Cantrell wrote: > On 05/07/2009 09:50 AM, Michael DeHaan wrote: >> Jesse Keating wrote: >>> How is it we have 182 stable updates pending for F11 already? How have >>> these seen any testing by a wider audience? Are we really just not >>> bothering with updates-testing anymore? Do we not care about distro >>> stability? >>> >>> I know that many of these are newpackages, but many aren't though. >>> >>> >> >> My experience is that most commercial users do not bother with logging >> into Bhodi or even know it exists. >> >> Another problem is that EPEL doesn't /yet/ use bhodi, so it has a >> different workflow -- meaning EPEL-testing doesn't really test anything, >> it means "rolls every 30-40 days", and that's about it. >> So testing has to happen manually, Fedora is the minority use case. >> >> Having a way to vote/comment without FAS would probably be enormously >> helpful in getting more users to use the system, once EPEL uses the same >> system. > > Definitely. Whenever I ask users to test an update and then comment in > bodhi, the latter never happens. They test the update and 2 weeks later I > get a nag mail from bodhi about updates still sitting around. I move them to > stable since I at least had the original reporter test it and verify it > worked. I frequently have the same experience. -sv From jkeating at redhat.com Thu May 7 20:09:52 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 07 May 2009 13:09:52 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <23753.1241723730@sss.pgh.pa.us> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> Message-ID: <1241726992.3209.16.camel@localhost.localdomain> On Thu, 2009-05-07 at 15:15 -0400, Tom Lane wrote: > What do you expect, when the release freeze policy essentially forbids > any noncritical updates for a month? People don't stop working just > because releng wants to simplify their own lives. > > The only reason there aren't 184 is I haven't bothered to try to > push my pending updates for mysql and postgresql ... but they'll > be in the zero-day update queue just like a lot of other things. Updates are fine, but skipping -testing and going straight to stable is a bit irksome. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Thu May 7 20:11:01 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 07 May 2009 13:11:01 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: References: <1241718097.3209.11.camel@localhost.localdomain> <4A033B7F.1030801@redhat.com> <4A033B97.508@redhat.com> Message-ID: <1241727061.3209.17.camel@localhost.localdomain> On Thu, 2009-05-07 at 15:53 -0400, Seth Vidal wrote: > > > > Definitely. Whenever I ask users to test an update and then comment in > > bodhi, the latter never happens. They test the update and 2 weeks later I > > get a nag mail from bodhi about updates still sitting around. I move them to > > stable since I at least had the original reporter test it and verify it > > worked. > > > I frequently have the same experience. I don't see anything wrong with this, as you're getting somebody to test it before you move it. The thing that bothered me was how many packages were going straight into updates without passing -testing. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From maxamillion at gmail.com Thu May 7 20:14:24 2009 From: maxamillion at gmail.com (Adam Miller) Date: Thu, 7 May 2009 15:14:24 -0500 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241727061.3209.17.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <4A033B7F.1030801@redhat.com> <4A033B97.508@redhat.com> <1241727061.3209.17.camel@localhost.localdomain> Message-ID: In respect to the xfce packages, Kevin put up a repo real quick earlier upon my request so that I may test and everything looks quite good and I think the packages are deserving of a +1 if they were in testing, hopefully that helps a little with your level of "irk" :) -Adam -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From poelstra at redhat.com Thu May 7 20:15:45 2009 From: poelstra at redhat.com (John Poelstra) Date: Thu, 07 May 2009 13:15:45 -0700 Subject: Fedora Release Engineering Meeting Recap - 2009-05-04 In-Reply-To: <1241654675.3030.80.camel@localhost.localdomain> References: <20090504200148.GB3699@nostromo.devel.redhat.com> <4A01866E.8060201@redhat.com> <1241625397.3030.59.camel@localhost.localdomain> <4A0222B2.5020705@redhat.com> <1241654675.3030.80.camel@localhost.localdomain> Message-ID: <4A034171.8050803@redhat.com> Jesse Keating said the following on 05/06/2009 05:04 PM Pacific Time: > On Wed, 2009-05-06 at 16:52 -0700, John Poelstra wrote: >> The overall Fedora 12 schedule with a GA date of 2009-11-03 is 21 days >> shorter than Fedora 11 and exactly the same length as Fedora 8 so it is >> not unusually short. > > Well 21 days is a lot of days to take in, particularly when a lot of > them seemed to come between the GA of 11 and the Alpha freeze of 12. I still don't understand why that matters considering the amount of development and changes that happen up until GA no matter where we are in the release process. Even now after final freeze lots of changes are being ACKd on releng-list and very few if any are getting NAKd. >>> way I could do that was to drop the Alpha cycle. While already a >>> non-blocking freeze, it still drew too much attention away from ongoing >>> development in order to deliver something that was weeks old and already >>> irrelevant. The alpha has had dubious quality to the development cycle, >>> at least from the developer and tester POV. About the only thing of >>> quality it provided was a "known good starting point" for which to >>> install and then update to rawhide, and even that hasn't been true for >>> large swaths of folks in recent releases. >> I'd be curious to see our torrent and download numbers for the F11 Alpha >> to understand how insignificant it was. Where can we find them? > > Torrent numbers are at http://spins.fedoraproject.org:6969/ but > downloads alone don't show the whole picture. By the time people got to > the Alpha bits, the general feeling I have is that most of the bugs in > alpha were already known, and the solution was to update to rawhide. > Even if the bugs weren't fixed, the first suggestion was always update > to rawhide, so rawhide is really the target we're after, alpha just > appeared to be an easy way to get there. If I'm reading the information correctly there, 10,000+ people got the Fedora 11 alpha. I would think that giving 10,000 people an easy starting place for a release would be a good thing. How will we measure--not assert or subjectively decide as we are doing here and have done in the past--whether a change we have made helps our releases or if time is better spent somewhere else? It seems that we continue to experiment and tweak the schedule with different durations, freezes, etc. but we rarely collect any hard data to evaluate whether or not past tweaks were beneficial or not. If we can't really measure our progress or lack thereof in tangible terms, how do we really know we should continue to tweak things? >> Although it is simple to just "not do the Alpha" it will take more >> coordination across the other Fedora teams AND good messaging in the >> press and wider world that no alpha is coming for Fedora 12 along with >> the reasons why. Have we considered the cost of this trade-off to our >> brand and community? > > Hard to judge the cost, however our "three tests and a release" which > turned into "Alpha Beta Preview Release" was really designed before we > had things such as Test Days and the easily available live images, or > the ability to easily compose regular install images with slightly > different package sets. The prohibitive cost to doing images on demand > has gone down considerably, and combined with test days provides a > better harness for gathering feedback as we go than the date based > quickly stagnant snapshots. This sounds good, but how do we really know this is true? What data can we point to? Maybe we are focusing on the wrong problem and should instead focus on the amount of churn and changes during development. John From tgl at redhat.com Thu May 7 20:21:57 2009 From: tgl at redhat.com (Tom Lane) Date: Thu, 07 May 2009 16:21:57 -0400 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241727061.3209.17.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <4A033B7F.1030801@redhat.com> <4A033B97.508@redhat.com> <1241727061.3209.17.camel@localhost.localdomain> Message-ID: <25674.1241727717@sss.pgh.pa.us> Jesse Keating writes: > I don't see anything wrong with this, as you're getting somebody to test > it before you move it. The thing that bothered me was how many packages > were going straight into updates without passing -testing. Well, as you just pointed out yourself, F11 testing is nonfunctional as yet. But the bigger problem is that putting stuff into -testing seldom accomplishes anything, at least for my packages. I think I might possibly have gotten one bodhi comment across all the times I let stuff sit in -testing until nagged; I have certainly *never* seen anything pushed by the karma mechanism. If maintainers decide it's a waste of time, there is not a lot you can say against them. regards, tom lane From jspaleta at gmail.com Thu May 7 20:32:00 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 7 May 2009 12:32:00 -0800 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <25674.1241727717@sss.pgh.pa.us> References: <1241718097.3209.11.camel@localhost.localdomain> <4A033B7F.1030801@redhat.com> <4A033B97.508@redhat.com> <1241727061.3209.17.camel@localhost.localdomain> <25674.1241727717@sss.pgh.pa.us> Message-ID: <604aa7910905071332w49626251v2716c3115aee471b@mail.gmail.com> On Thu, May 7, 2009 at 12:21 PM, Tom Lane wrote: > Well, as you just pointed out yourself, F11 testing is nonfunctional as > yet. ?But the bigger problem is that putting stuff into -testing seldom > accomplishes anything, at least for my packages. ?I think I might > possibly have gotten one bodhi comment across all the times I let stuff > sit in -testing until nagged; I have certainly *never* seen anything > pushed by the karma mechanism. ?If maintainers decide it's a waste of > time, there is not a lot you can say against them. I eat testing religiously. I eat so much testing in fact, that I can't easily sort through all the associated bug reports that I could be testing for all the packages that I don't commonly "actively" use. To know what is currently from testing on my system I have to run my own yum/repoqueries with testing disabled looking for packages not from regular updates. That's a real pain..and it still doesn't help me figure out what I should be testing and reporting back on specifically. So basically I end up reporting regressions if anything. What I need to be more helpful is a way for my system to inform me of the current testing packages I have installed...and the specific things I should be testing with regard to them. I todo list of sorts. -jef From a.badger at gmail.com Thu May 7 20:32:41 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 07 May 2009 13:32:41 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <25674.1241727717@sss.pgh.pa.us> References: <1241718097.3209.11.camel@localhost.localdomain> <4A033B7F.1030801@redhat.com> <4A033B97.508@redhat.com> <1241727061.3209.17.camel@localhost.localdomain> <25674.1241727717@sss.pgh.pa.us> Message-ID: <4A034569.7020702@gmail.com> Tom Lane wrote: > Jesse Keating writes: >> I don't see anything wrong with this, as you're getting somebody to test >> it before you move it. The thing that bothered me was how many packages >> were going straight into updates without passing -testing. > > Well, as you just pointed out yourself, F11 testing is nonfunctional as > yet. But the bigger problem is that putting stuff into -testing seldom > accomplishes anything, at least for my packages. I think I might > possibly have gotten one bodhi comment across all the times I let stuff > sit in -testing until nagged; I have certainly *never* seen anything > pushed by the karma mechanism. If maintainers decide it's a waste of > time, there is not a lot you can say against them. > I use updates in -testing. And I use postgresql for development work. So I'm a consumer of the packages you leave in -testing even though I don't comment in bodhi. To me, the real value of the testing repository (or lack of value) is not whether the update ever gets auto-pushed. It's whether showstopper bugs get caught while still in the -testing repo before being pushed out to -stable. I've had a few of those caught and reported a few myself so I'm seeing value there. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From dimi at lattica.com Thu May 7 20:33:29 2009 From: dimi at lattica.com (Dimi Paun) Date: Thu, 07 May 2009 16:33:29 -0400 Subject: Another update, another reboot, no sound! Message-ID: <1241728409.7634.21.camel@dimi.lattica.com> This is getting ridiculous! I had running sound, and today I've updated my system. Right away, my sound was b0rken: - no sound from Skype, in any configuration imaginable (even when ran through pasuspender) - no sound from Flash in Firefox - no sound from VirtualBox, even though I was seeing the stream listed under "Playback" tab in PA's VC - however, I was getting sound from Rhythmbox! So I figure, I'll reboot, what else? Sure enough, after reboot I get no sound at all! And this after fscking around for about 30min(!) to get any sort of sound out of my system. It turns out that I had to run "alsamixer" manually _again_ because the master volume was, logically, set to zero. And this after filling a bug about this: https://bugzilla.redhat.com/show_bug.cgi?id=493790 The bug was marked as fixed. Sure enough, even after fixing the master volume, I still: - have no sound from Skype in any imaginable combination, even if it was working fine before (and I have not changed the version of Skype that I use) - no sound out of VirtualBox, even if it was working before I've tried filing bugs, it doesn't help -- the rate of breakage is way faster than I can file bugs (not to mention that filing bugs is too sluggish for words). Something is Just Plain Wrong (TM). WTH is going on? How can the situation be improved? I've just lost 1h right now trying to deal with this problem, in the middle of my work day -- this is not sustainable. -- Dimi Paun Lattica, Inc. From tmraz at redhat.com Thu May 7 20:38:14 2009 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 07 May 2009 22:38:14 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <25674.1241727717@sss.pgh.pa.us> References: <1241718097.3209.11.camel@localhost.localdomain> <4A033B7F.1030801@redhat.com> <4A033B97.508@redhat.com> <1241727061.3209.17.camel@localhost.localdomain> <25674.1241727717@sss.pgh.pa.us> Message-ID: <1241728695.25946.187.camel@vespa.frost.loc> On Thu, 2009-05-07 at 16:21 -0400, Tom Lane wrote: > Jesse Keating writes: > > I don't see anything wrong with this, as you're getting somebody to test > > it before you move it. The thing that bothered me was how many packages > > were going straight into updates without passing -testing. > > Well, as you just pointed out yourself, F11 testing is nonfunctional as > yet. But the bigger problem is that putting stuff into -testing seldom Actually I don't see any important reason why not make F11 testing functional as soon as F11 is frozen in rawhide. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From rayvd at bludgeon.org Thu May 7 20:43:07 2009 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Thu, 7 May 2009 13:43:07 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241728695.25946.187.camel@vespa.frost.loc> References: <1241718097.3209.11.camel@localhost.localdomain> <4A033B7F.1030801@redhat.com> <4A033B97.508@redhat.com> <1241727061.3209.17.camel@localhost.localdomain> <25674.1241727717@sss.pgh.pa.us> <1241728695.25946.187.camel@vespa.frost.loc> Message-ID: <20090507204306.GA2518@bludgeon.org> On Thu, May 07, 2009 at 10:38:14PM +0200, Tomas Mraz wrote: > On Thu, 2009-05-07 at 16:21 -0400, Tom Lane wrote: > > Jesse Keating writes: > > > I don't see anything wrong with this, as you're getting somebody to test > > > it before you move it. The thing that bothered me was how many packages > > > were going straight into updates without passing -testing. > > > > Well, as you just pointed out yourself, F11 testing is nonfunctional as > > yet. But the bigger problem is that putting stuff into -testing seldom > > Actually I don't see any important reason why not make F11 testing > functional as soon as F11 is frozen in rawhide. That would have been the least confusing thing to do (assuming it was a feasible option to begin with). I *tried* to use -testing, but nothing happened so I went ahead and pushed to stable because I knew my package was fine and it'd been a couple weeks. Ray From johannbg at hi.is Thu May 7 20:36:40 2009 From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=) Date: Thu, 07 May 2009 20:36:40 +0000 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241727061.3209.17.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <4A033B7F.1030801@redhat.com> <4A033B97.508@redhat.com> <1241727061.3209.17.camel@localhost.localdomain> Message-ID: <4A034658.9010007@hi.is> On 05/07/2009 08:11 PM, Jesse Keating wrote: > On Thu, 2009-05-07 at 15:53 -0400, Seth Vidal wrote: > >>> Definitely. Whenever I ask users to test an update and then comment in >>> bodhi, the latter never happens. They test the update and 2 weeks later I >>> get a nag mail from bodhi about updates still sitting around. I move them to >>> stable since I at least had the original reporter test it and verify it >>> worked. >>> >> I frequently have the same experience. >> Reporter depended and goes both way's with regards to reports maintainers not replying back to reporters and yes that's also depends on which maintainer it is. I asked for a reminder for tester to use and vote bodhi in the updates testing reports but apparently add that simple text to the top of those report proved to be too difficult or fell for deaf ears.. > > I don't see anything wrong with this, as you're getting somebody to test > it before you move it. The thing that bothered me was how many packages > were going straight into updates without passing -testing. > > Push this bits to the rawhide repo ( perhaps setup update-testing repo earlier in the process ? ) to get more and wider testing of those bits.... We will never get a good enough testing for all these updates if testers need to hand pick each update from koji. + that will only result in testers hand pick components they favor or depend on and use alot. Anyway perhaps it's time to revisit this process see if it can be improved or approach differently and if solution is found it tried in next release cycle ( F12 ). JBG -- Viking-Ice One of my gods has a hammer your's was nailed to a cross You do the math! -------------- next part -------------- An HTML attachment was scrubbed... URL: From opensource at till.name Thu May 7 20:47:09 2009 From: opensource at till.name (Till Maas) Date: Thu, 07 May 2009 22:47:09 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <604aa7910905071332w49626251v2716c3115aee471b@mail.gmail.com> References: <1241718097.3209.11.camel@localhost.localdomain> <25674.1241727717@sss.pgh.pa.us> <604aa7910905071332w49626251v2716c3115aee471b@mail.gmail.com> Message-ID: <200905072247.19921.opensource@till.name> On Do Mai 7 2009, Jeff Spaleta wrote: > be testing for all the packages that I don't commonly "actively" use. > To know what is currently from testing on my system I have to run my > own yum/repoqueries with testing disabled looking for packages not > from regular updates. That's a real pain..and it still doesn't help me If your Fedora certificates are in place for the current unix user, you can use bodhi to get a list of testable packages afaik: bodhi --testable Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From a.badger at gmail.com Thu May 7 20:47:15 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 07 May 2009 13:47:15 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <4A033B7F.1030801@redhat.com> References: <1241718097.3209.11.camel@localhost.localdomain> <4A033B7F.1030801@redhat.com> Message-ID: <4A0348D3.8000302@gmail.com> Michael DeHaan wrote: > Jesse Keating wrote: >> How is it we have 182 stable updates pending for F11 already? How have >> these seen any testing by a wider audience? Are we really just not >> bothering with updates-testing anymore? Do we not care about distro >> stability? >> >> I know that many of these are newpackages, but many aren't though. >> >> >> > > My experience is that most commercial users do not bother with logging > into Bhodi or even know it exists. > > Another problem is that EPEL doesn't /yet/ use bhodi, so it has a > different workflow -- meaning EPEL-testing doesn't really test anything, > it means "rolls every 30-40 days", and that's about it. > So testing has to happen manually, Fedora is the minority use case. > > Having a way to vote/comment without FAS would probably be enormously > helpful in getting more users to use the system, once EPEL uses the same > system. > You haven't needed a FAS account to leave a comment in bodhi for a long time... possibly from the get-go. Look at a potential update in bodhi without logging in. There's an add comment link that asks you for an email address, comment, and a captcha to fill in. (Although I have found in testing just now that anonymous commenting is currently broken... have to find out from lmacken what's going on there.) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From pmachata at redhat.com Thu May 7 20:56:09 2009 From: pmachata at redhat.com (Petr Machata) Date: Thu, 07 May 2009 22:56:09 +0200 Subject: f12 boost-1.39.0 upgrade: notice of intent In-Reply-To: <20090506222415.0838a072@mcgee.artheist.org> References: <20090506222415.0838a072@mcgee.artheist.org> Message-ID: <4A034AE9.4010402@redhat.com> Benjamin Kosnik wrote: > BuildRequires for boost packages must be adjusted as part of this > rebase. As always, timely assistance from package maintainers > is welcome. In particular, the package was broken down to sub-packages per library (see [1]). I suspect that automatic SONAME-based dependency resolution should pick up the right sub-package for client package in question. The automatic adjustment should really be necessary only if the client package depends on "boost" by name, explicitly (but maybe that's simply all packages). Rebuild is obviously still necessary. [1] https://bugzilla.redhat.com/show_bug.cgi?id=496188 PM -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From jkeating at redhat.com Thu May 7 20:56:19 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 07 May 2009 13:56:19 -0700 Subject: Fedora Release Engineering Meeting Recap - 2009-05-04 In-Reply-To: <4A034171.8050803@redhat.com> References: <20090504200148.GB3699@nostromo.devel.redhat.com> <4A01866E.8060201@redhat.com> <1241625397.3030.59.camel@localhost.localdomain> <4A0222B2.5020705@redhat.com> <1241654675.3030.80.camel@localhost.localdomain> <4A034171.8050803@redhat.com> Message-ID: <1241729779.3209.27.camel@localhost.localdomain> On Thu, 2009-05-07 at 13:15 -0700, John Poelstra wrote: > Jesse Keating said the following on 05/06/2009 05:04 PM Pacific Time: > > On Wed, 2009-05-06 at 16:52 -0700, John Poelstra wrote: > >> The overall Fedora 12 schedule with a GA date of 2009-11-03 is 21 days > >> shorter than Fedora 11 and exactly the same length as Fedora 8 so it is > >> not unusually short. > > > > Well 21 days is a lot of days to take in, particularly when a lot of > > them seemed to come between the GA of 11 and the Alpha freeze of 12. > > I still don't understand why that matters considering the amount of > development and changes that happen up until GA no matter where we are > in the release process. Even now after final freeze lots of changes are > being ACKd on releng-list and very few if any are getting NAKd. It's a sad but true state of things. Just because we freeze doesn't mean people stop finding bugs, and if we have time to take in the bugfixes, we will, as long as they aren't threatening stability. The freeze is there to prevent the unstable things from accidentally making it in. This made even more sense when we didn't branch for the release until just before GA, now we branch a lot earlier and there is less risk of unstable things slipping in, but there are still plenty of builds that we'd rather not see hit the tree. The freeze override process exists to add a filter between developer and repo to catch the obvious and to help maintainers think a moment about what they're doing and whether it's acceptable to do in a freeze period. it would make a lot more sense if developers would treat updates to a release with the same care as they treat updates during a freeze period, but that's a fight for another day. > > >>> way I could do that was to drop the Alpha cycle. While already a > >>> non-blocking freeze, it still drew too much attention away from ongoing > >>> development in order to deliver something that was weeks old and already > >>> irrelevant. The alpha has had dubious quality to the development cycle, > >>> at least from the developer and tester POV. About the only thing of > >>> quality it provided was a "known good starting point" for which to > >>> install and then update to rawhide, and even that hasn't been true for > >>> large swaths of folks in recent releases. > >> I'd be curious to see our torrent and download numbers for the F11 Alpha > >> to understand how insignificant it was. Where can we find them? > > > > Torrent numbers are at http://spins.fedoraproject.org:6969/ but > > downloads alone don't show the whole picture. By the time people got to > > the Alpha bits, the general feeling I have is that most of the bugs in > > alpha were already known, and the solution was to update to rawhide. > > Even if the bugs weren't fixed, the first suggestion was always update > > to rawhide, so rawhide is really the target we're after, alpha just > > appeared to be an easy way to get there. > > If I'm reading the information correctly there, 10,000+ people got the > Fedora 11 alpha. > > I would think that giving 10,000 people an easy starting place for a > release would be a good thing. That's assuming that those 10,000 people couldn't easily use F11 GA and then upgrade to rawhide. I don't think you can draw the conclusion that "10K people got Alpha, if we drop Alpha we'll lose 10K people". > > How will we measure--not assert or subjectively decide as we are doing > here and have done in the past--whether a change we have made helps our > releases or if time is better spent somewhere else? We just have to go on gut feeling, like just about everything else in Fedora. We have to listen to maintainer feedback, and our QA team feedback and make a judgment call. If you have better ideas, I'm all ears. The message I've consistently gotten from our developers is less freeze points, and the non-blocking freeze of alpha wasn't good enough. QA has expressed that Alpha isn't really helpful too. So now we're talking about dropping it, both to save some downtime in F12 schedule and to evaluate if we really need an Alpha snapshot. > > It seems that we continue to experiment and tweak the schedule with > different durations, freezes, etc. but we rarely collect any hard data > to evaluate whether or not past tweaks were beneficial or not. What data is there to collect? So many other things change at the same time, there is really no scientific way to experiment, measure, tweak, and experiment and measure again, showing a difference with only one variable change. > If we can't really measure our progress or lack thereof in tangible > terms, how do we really know we should continue to tweak things? Feedback from maintainers and users. > >> Although it is simple to just "not do the Alpha" it will take more > >> coordination across the other Fedora teams AND good messaging in the > >> press and wider world that no alpha is coming for Fedora 12 along with > >> the reasons why. Have we considered the cost of this trade-off to our > >> brand and community? > > > > Hard to judge the cost, however our "three tests and a release" which > > turned into "Alpha Beta Preview Release" was really designed before we > > had things such as Test Days and the easily available live images, or > > the ability to easily compose regular install images with slightly > > different package sets. The prohibitive cost to doing images on demand > > has gone down considerably, and combined with test days provides a > > better harness for gathering feedback as we go than the date based > > quickly stagnant snapshots. > > This sounds good, but how do we really know this is true? What data can > we point to? Maybe we are focusing on the wrong problem and should > instead focus on the amount of churn and changes during development. > > John Amount of churn and change is something I can't directly change. I can't even get it to change for a stable release, there is no way I can get it to change for rawhide. Given our sharp upward trend in new packages and number of packages, the change and churn is only going to get worse. So I focus on changing the things I can control, which involve schedules, freeze strategies, etc.. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From rjones at redhat.com Thu May 7 21:04:59 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 7 May 2009 22:04:59 +0100 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <23753.1241723730@sss.pgh.pa.us> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> Message-ID: <20090507210459.GA9105@amd.home.annexia.org> On Thu, May 07, 2009 at 03:15:30PM -0400, Tom Lane wrote: > Jesse Keating writes: > > How is it we have 182 stable updates pending for F11 already? > > What do you expect, when the release freeze policy essentially forbids > any noncritical updates for a month? People don't stop working just > because releng wants to simplify their own lives. +1 Roll on rolling development ... Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From johannbg at hi.is Thu May 7 21:00:16 2009 From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=) Date: Thu, 07 May 2009 21:00:16 +0000 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <604aa7910905071332w49626251v2716c3115aee471b@mail.gmail.com> References: <1241718097.3209.11.camel@localhost.localdomain> <4A033B7F.1030801@redhat.com> <4A033B97.508@redhat.com> <1241727061.3209.17.camel@localhost.localdomain> <25674.1241727717@sss.pgh.pa.us> <604aa7910905071332w49626251v2716c3115aee471b@mail.gmail.com> Message-ID: <4A034BE0.60803@hi.is> On 05/07/2009 08:32 PM, Jeff Spaleta wrote: > On Thu, May 7, 2009 at 12:21 PM, Tom Lane wrote: > >> Well, as you just pointed out yourself, F11 testing is nonfunctional as >> yet. But the bigger problem is that putting stuff into -testing seldom >> accomplishes anything, at least for my packages. I think I might >> possibly have gotten one bodhi comment across all the times I let stuff >> sit in -testing until nagged; I have certainly *never* seen anything >> pushed by the karma mechanism. If maintainers decide it's a waste of >> time, there is not a lot you can say against them. >> > > I eat testing religiously. I eat so much testing in fact, that I > can't easily sort through all the associated bug reports that I could > be testing for all the packages that I don't commonly "actively" use. > To know what is currently from testing on my system I have to run my > own yum/repoqueries with testing disabled looking for packages not > from regular updates. That's a real pain..and it still doesn't help me > figure out what I should be testing and reporting back on > specifically. So basically I end up reporting regressions if > anything. > > What I need to be more helpful is a way for my system to inform me of > the current testing packages I have installed...and the specific > things I should be testing with regard to them. I todo list of sorts. > Agreed But... Given the experience from maintainers that give change log entries like "Update to" "Upstream release" etc.. which leave's testers with ? I'm not seeing those maintainers being able to fill in what to specifically check or test ( Good change log entries usually gives us a good hint what to look for or test ) JBG -- Viking-Ice One of my gods has a hammer your's was nailed to a cross You do the math! -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjones at redhat.com Thu May 7 21:09:20 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 7 May 2009 22:09:20 +0100 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241718097.3209.11.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> Message-ID: <20090507210920.GB9105@amd.home.annexia.org> On Thu, May 07, 2009 at 10:41:37AM -0700, Jesse Keating wrote: > How is it we have 182 stable updates pending for F11 already? How have > these seen any testing by a wider audience? Are we really just not > bothering with updates-testing anymore? Do we not care about distro > stability? I'll tell you the three reasons I'm pushing stuff directly to stable: (1) New package. (2) Update to a new package that I know not many people are using. (3) Something depends on this new package. Since I can't build anything against the new package until it goes into stable, and I don't to wait 2+ weeks to trigger the build of the dependent package, I essentially am forced to push packages to stable as soon as possible. Of which item (3) is the most annoying. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From caillon at redhat.com Thu May 7 21:14:58 2009 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 07 May 2009 14:14:58 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <20090507210920.GB9105@amd.home.annexia.org> References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> Message-ID: <4A034F52.1090103@redhat.com> On 05/07/2009 02:09 PM, Richard W.M. Jones wrote: > (3) Something depends on this new package. Since I can't build > anything against the new package until it goes into stable, and I > don't to wait 2+ weeks to trigger the build of the dependent package, > I essentially am forced to push packages to stable as soon as > possible. https://fedorahosted.org/rel-eng/newticket Ask for your package(s) to be added to the buildroot. From nathanael at gnat.ca Thu May 7 21:17:04 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Thu, 07 May 2009 15:17:04 -0600 Subject: OpenOffice 3.1 Message-ID: <4A034FD0.40103@gnat.ca> Hello, Normally I'm quite happy to wait for new releases upstream to trickle into fedora, however in this case, I'd LOVE to know if 3.1 fixes an issue with OO over samba. I tried downloading the srpm and using mock to rebuild it for f10... That was a no go, guessing a chain build would be required to get that working. So are there plans to update f10 OpenOffice to 3.1? I'll pleasantly provide my system and 4 others to test on via koji builds or what not if it is... ;) I couldn't find anything on koji but I'm a relatively noob to koji. -- Nathanael d. Noblet T: 403.875.4613 From jspaleta at gmail.com Thu May 7 21:30:04 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 7 May 2009 13:30:04 -0800 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <4A034BE0.60803@hi.is> References: <1241718097.3209.11.camel@localhost.localdomain> <4A033B7F.1030801@redhat.com> <4A033B97.508@redhat.com> <1241727061.3209.17.camel@localhost.localdomain> <25674.1241727717@sss.pgh.pa.us> <604aa7910905071332w49626251v2716c3115aee471b@mail.gmail.com> <4A034BE0.60803@hi.is> Message-ID: <604aa7910905071430i38452a0dk9195f098b28f5302@mail.gmail.com> 2009/5/7 "J?hann B. Gu?mundsson" : > Agreed But... > > Given the experience from maintainers that give change log entries like > "Update to" "Upstream release" etc.. which leave's testers with? ? > > I'm not seeing those maintainers being able to fill in what to specifically > check or test > ( Good change log entries usually gives us a good hint what to look for or > test ) zeroth order.. i just need an easy way to know what is and what is not currently installed that is from testing and thus could use some love. first order..i need a todo list tool that is going to nag me about testing stuff that has been installed for a few days. Something that is going to sit in my desktop panel and nag the hell out of me to drop a comment in the update system. Like show my five salient annoucement texts for testing crap I have installed and challenge me to write a comment out of that group of 5..every day.. second order...world peace. -jef From jkeating at redhat.com Thu May 7 21:37:21 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 07 May 2009 14:37:21 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <20090507210920.GB9105@amd.home.annexia.org> References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> Message-ID: <1241732241.3209.59.camel@localhost.localdomain> On Thu, 2009-05-07 at 22:09 +0100, Richard W.M. Jones wrote: > > (3) Something depends on this new package. Since I can't build > anything against the new package until it goes into stable, and I > don't to wait 2+ weeks to trigger the build of the dependent package, > I essentially am forced to push packages to stable as soon as > possible. > > Of which item (3) is the most annoying. I could have sworn this was documented in the package update wiki page, but it's not (please somebody wanna throw it in there somewhere?) You can request a buildroot override, which allows you to build your packages against something that hasn't gone stable yet. http://fedoraproject.org/wiki/ReleaseEngineering/SOP/BuildRootOverrides is what releng uses to describe the task, but that's not quite appropriate for end user documentation. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Thu May 7 21:38:24 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 07 May 2009 14:38:24 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <20090507210459.GA9105@amd.home.annexia.org> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <20090507210459.GA9105@amd.home.annexia.org> Message-ID: <1241732304.3209.60.camel@localhost.localdomain> On Thu, 2009-05-07 at 22:04 +0100, Richard W.M. Jones wrote: > Roll on rolling development ... You're missing the point. Rolling development is fine, in rawhide. Rolling development doesn't mean throw every build at a stable release as an update, before the release is even made! -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From xose.vazquez at gmail.com Thu May 7 21:38:57 2009 From: xose.vazquez at gmail.com (Xose Vazquez Perez) Date: Thu, 07 May 2009 23:38:57 +0200 Subject: glibc fork ? Message-ID: <4A0354F1.7030607@gmail.com> Denis Leroy wrote: > http://www.eglibc.org/home > > So are we moving to eglibc as well ? :-) > > So what happened ? Overreaction from Debian guy, or poor community > management from RH guy ? There is NO fork, EGLIBC always will be based on GLIBC. So it will be a step behind GLIBC, and it is oriented to embedded systems. NO gain for Fedora. regards, -- Polycommander, Erkowit, Urquiola, Andros Patria, Cason, Aegean Sea, Prestige, ... From caillon at redhat.com Thu May 7 21:40:33 2009 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 07 May 2009 14:40:33 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241732241.3209.59.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241732241.3209.59.camel@localhost.localdomain> Message-ID: <4A035551.4060004@redhat.com> On 05/07/2009 02:37 PM, Jesse Keating wrote: > On Thu, 2009-05-07 at 22:09 +0100, Richard W.M. Jones wrote: >> (3) Something depends on this new package. Since I can't build >> anything against the new package until it goes into stable, and I >> don't to wait 2+ weeks to trigger the build of the dependent package, >> I essentially am forced to push packages to stable as soon as >> possible. >> >> Of which item (3) is the most annoying. > > I could have sworn this was documented in the package update wiki page, > but it's not (please somebody wanna throw it in there somewhere?) Yeah, the only place I could find it was in http://fedoraproject.org/wiki/PackageMaintainers/Join#Install_the_Client_Tools_.28Koji.29 but that seems like the wrong place for it. From mzerqung at 0pointer.de Thu May 7 21:40:17 2009 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Thu, 7 May 2009 23:40:17 +0200 Subject: Another update, another reboot, no sound! In-Reply-To: <1241728409.7634.21.camel@dimi.lattica.com> References: <1241728409.7634.21.camel@dimi.lattica.com> Message-ID: <20090507214017.GA9824@tango.0pointer.de> On Thu, 07.05.09 16:33, Dimi Paun (dimi at lattica.com) wrote: > This is getting ridiculous! Oh my. > > I had running sound, and today I've updated my system. > Right away, my sound was b0rken: > - no sound from Skype, in any configuration imaginable > (even when ran through pasuspender) > - no sound from Flash in Firefox > - no sound from VirtualBox, even though I was seeing > the stream listed under "Playback" tab in PA's VC > - however, I was getting sound from Rhythmbox! Ah, so closed-source software we don't ship is broken -- Proper Free Software we ship works? Quelle surprise! And it's our fault of course, right? > It turns out that I had to run "alsamixer" manually _again_ > because the master volume was, logically, set to zero. And > this after filling a bug about this: > https://bugzilla.redhat.com/show_bug.cgi?id=493790 > > The bug was marked as fixed. Maybe that specific bug was fixed in the packages. Have you made sure you are running the updated packages? Have you filed a bug about your new issue after you made sure you are running the newest packages? > Sure enough, even after fixing the master volume, I still: > - have no sound from Skype in any imaginable combination, > even if it was working fine before (and I have not > changed the version of Skype that I use) > - no sound out of VirtualBox, even if it was working before We don't ship that software. It's not what I test my stuff with. Also, my interest in working on software that we don't ship or is even is impossible to debug (due to its closed source nature) is rather minimal. Do those programs appear in g-v-c? Are they properly unmuted there? > I've tried filing bugs, it doesn't help -- the rate of breakage > is way faster than I can file bugs (not to mention that filing > bugs is too sluggish for words). Hmm, let me see, that other issue you filed 2009-04-03 and this one is already too fast for you to file? I mean, I really don't want to burden you too much. From now on I'll try to make sure that bugs in software I work on for *development* distributions only appears at a rate of 1 every *two* months, to make sure it doesn't get too fast for you to follow. > Something is Just Plain Wrong (TM). WTH is going on? How can the > situation be improved? I've just lost 1h right now trying to deal > with this problem, in the middle of my work day -- this is not > sustainable. I mean, seriously. You are complaining that you have to file more than one bug per month and are using a development distribution! Calm down! Also, there's always the option to reopen a bug when you think it is not fixed properly. This options was added because sometimes things like this happen. Calm down! Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From craftjml at gmail.com Thu May 7 21:48:56 2009 From: craftjml at gmail.com (Jud Craft) Date: Thu, 7 May 2009 16:48:56 -0500 Subject: Another update, another reboot, no sound! In-Reply-To: <20090507214017.GA9824@tango.0pointer.de> References: <1241728409.7634.21.camel@dimi.lattica.com> <20090507214017.GA9824@tango.0pointer.de> Message-ID: <20d6441a0905071448o10cb4928r4cab031966284aac@mail.gmail.com> Try going into Skype's Options -> Audio Options. Perhaps Skype can't figure out what sound device to use. Make sure it's set to "PulseAudio", and then try a test call. If there are other devices in that list, you could try each one until you get it to work. There's only a few of them. An inconvenience, yes. If this does not work, then you may have deeper troubles. I have no ideas for VirtualBox, don't use it. From what I hear, virtualized sound is an entirely different can of worms, and I'm not surprised it doesn't work. From jonathan.underwood at gmail.com Thu May 7 21:52:00 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 7 May 2009 22:52:00 +0100 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <23753.1241723730@sss.pgh.pa.us> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> Message-ID: <645d17210905071452n7da5f852s8bfc5d808a04c56b@mail.gmail.com> 2009/5/7 Tom Lane : > Jesse Keating writes: >> How is it we have 182 stable updates pending for F11 already? > > What do you expect, when the release freeze policy essentially forbids > any noncritical updates for a month? ?People don't stop working just > because releng wants to simplify their own lives. > > The only reason there aren't 184 is I haven't bothered to try to > push my pending updates for mysql and postgresql ... but they'll > be in the zero-day update queue just like a lot of other things. Related to that, the release freeze essentially prevents bugfix package updates to previous releases, since pushing an updated package with a later version number to eg. F-10 will then break the update path to F-11. Is there a recommended way around this problem I am missing? Jonathan. From jkeating at redhat.com Thu May 7 21:54:47 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 07 May 2009 14:54:47 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <645d17210905071452n7da5f852s8bfc5d808a04c56b@mail.gmail.com> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <645d17210905071452n7da5f852s8bfc5d808a04c56b@mail.gmail.com> Message-ID: <1241733287.3209.61.camel@localhost.localdomain> On Thu, 2009-05-07 at 22:52 +0100, Jonathan Underwood wrote: > > Related to that, the release freeze essentially prevents bugfix > package updates to previous releases, since pushing an updated package > with a later version number to eg. F-10 will then break the update > path to F-11. Is there a recommended way around this problem I am > missing? Frankly I'd ignore it. A week after F11 goes GA the update paths will all be broken anyway. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From rjones at redhat.com Thu May 7 21:57:00 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 7 May 2009 22:57:00 +0100 Subject: glibc fork ? In-Reply-To: <4A0354F1.7030607@gmail.com> References: <4A0354F1.7030607@gmail.com> Message-ID: <20090507215700.GA10303@amd.home.annexia.org> On Thu, May 07, 2009 at 11:38:57PM +0200, Xose Vazquez Perez wrote: > So it will be a step behind GLIBC, Do you have any facts to back up this strong assertion? > and it is oriented to embedded systems. > NO gain for Fedora. Appliances are a sort of embedded system: small memory footprint, limited single use, purpose built. At the same time, Fedora could be useful in other markets like netbooks, which have similarities to embedded systems, such as small memory or disk footprints, and ARM chips. glibc as it stands has a large disk footprint on x86-64 systems, because of particular decisions made by the glibc developers: http://rwmj.wordpress.com/2009/03/20/why-minimal-is-225-mb/ Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From rjones at redhat.com Thu May 7 22:01:35 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 7 May 2009 23:01:35 +0100 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <4A034F52.1090103@redhat.com> References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <4A034F52.1090103@redhat.com> Message-ID: <20090507220135.GB10303@amd.home.annexia.org> On Thu, May 07, 2009 at 02:14:58PM -0700, Christopher Aillon wrote: > On 05/07/2009 02:09 PM, Richard W.M. Jones wrote: >> (3) Something depends on this new package. Since I can't build >> anything against the new package until it goes into stable, and I >> don't to wait 2+ weeks to trigger the build of the dependent package, >> I essentially am forced to push packages to stable as soon as >> possible. > > https://fedorahosted.org/rel-eng/newticket > > Ask for your package(s) to be added to the buildroot. Sure, I know about this. It means getting a real person from rel-eng involved. Why can't it be automated and/or why can't builds happen against packages in updates-testing? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 75 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From johannbg at hi.is Thu May 7 22:07:11 2009 From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=) Date: Thu, 07 May 2009 22:07:11 +0000 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <604aa7910905071430i38452a0dk9195f098b28f5302@mail.gmail.com> References: <1241718097.3209.11.camel@localhost.localdomain> <4A033B7F.1030801@redhat.com> <4A033B97.508@redhat.com> <1241727061.3209.17.camel@localhost.localdomain> <25674.1241727717@sss.pgh.pa.us> <604aa7910905071332w49626251v2716c3115aee471b@mail.gmail.com> <4A034BE0.60803@hi.is> <604aa7910905071430i38452a0dk9195f098b28f5302@mail.gmail.com> Message-ID: <4A035B8F.9020903@hi.is> On 05/07/2009 09:30 PM, Jeff Spaleta wrote: > 2009/5/7 "J?hann B. Gu?mundsson" : > >> Agreed But... >> >> Given the experience from maintainers that give change log entries like >> "Update to" "Upstream release" etc.. which leave's testers with ? >> >> I'm not seeing those maintainers being able to fill in what to specifically >> check or test >> ( Good change log entries usually gives us a good hint what to look for or >> test ) >> > > zeroth order.. i just need an easy way to know what is and what is not > currently installed that is from testing and thus could use some love. > > first order..i need a todo list tool that is going to nag me about > testing stuff that has been installed for a few days. Something that > is going to sit in my desktop panel and nag the hell out of me to drop > a comment in the update system. Like show my five salient annoucement > texts for testing crap I have installed and challenge me to write a > comment out of that group of 5..every day.. > Hum so for all the 1100+ packages that come with the default ( dvd ) install hum mentioning the dvd is not really far so I shall just mention the 182 updates waiting! You want a notification that nags you all day long.. Something like "You just installed 182 updates and have yet not provided feed back for any of them!" End user provides 1 feed back for one component ) Receives a colorful rainbow "Thank you" 5 minutes later.. "You just installed 182 updates and have provided a feed back for 1 of them! This is your friendly reminder that you still have not yet providing feedback for 181 components " End user spents the whole day providing feed back, all the time thinking I must make this notification STOP Obey the notification, obey the notification is all that he can think of.. Through bloods sweat and tears he manages to go through all the updates/components and provide feed back finally the notification stop and he goes to sleep with a piece of mind.. The following morning... "You got 344 updates pending!" I say good for you :) Hey while were at it why don't we let the notification come from a paper clip or a puppy or a white pony on a rainbow.. For me no thanks! :) JBG -- Viking-Ice One of my gods has a hammer your's was nailed to a cross You do the math! -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at fedoraproject.org Thu May 7 22:25:32 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 08 May 2009 03:55:32 +0530 Subject: Moblin 2 and Fedora In-Reply-To: <1241710118.2923.481.camel@adam.local.net> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <49844F3B.6060905@fedoraproject.org> <5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com> <20090131110644.1a80ddf5@infradead.org> <4984BC61.3040908@fedoraproject.org> <20090131153457.573762ab@infradead.org> <604aa7910902020825v23bc3687m1151596fa74cb8a5@mail.gmail.com> <20090202101002.4380c005@infradead.org> <1233598383.7493.42.camel@localhost.localdomain> <20090202113524.184e402c@infradead.org> <20090503160827.GA21833@srcf.ucam.org> <1241449115.2766.148.camel@atropine.boston.devel.redhat.com> <49FF0A69.8030609@fedoraproject.org> <1241462009.8638.5.camel@localhost.localdomain> <20090504125251.41e491a6@infradead.org> <1241705174.3088.2.camel@localhost.localdomain> <1241710118.2923.481.camel@adam.local.net> Message-ID: <4A035FDC.5020903@fedoraproject.org> On 05/07/2009 08:58 PM, Adam Williamson wrote: > > I suspect what may be happening is the original group is continuing to > work on the crack-addled drivers that show up in the Ubuntu repos from > time to time, while a different group works on creating a > non-crack-addled driver that'll be sent through the proper processes. > But that's just my guess, as no-one at Intel seems to want to say > anything. Whatever process that is, it is totally screwed up. The sooner they get off it and start following the successful upstream strategy they have so long, the better it is, for everyone. Rahul From sundaram at fedoraproject.org Thu May 7 22:28:18 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 08 May 2009 03:58:18 +0530 Subject: glibc fork ? In-Reply-To: <4A02F8D3.2010807@poolshark.org> References: <4A02F8D3.2010807@poolshark.org> Message-ID: <4A036082.8000107@fedoraproject.org> On 05/07/2009 08:35 PM, Denis Leroy wrote: > http://www.eglibc.org/home > > So are we moving to eglibc as well ? :-) > > So what happened ? Overreaction from Debian guy, or poor community > management from RH guy ? eglibc FAQ claims that it wants to be binary and source compatible and will rebase regularly with Glibc and that doesn't seem much of a fork. Seems more like a people conflict. Good luck to them. Rahul From jspaleta at gmail.com Thu May 7 22:23:04 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 7 May 2009 14:23:04 -0800 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <4A035B8F.9020903@hi.is> References: <1241718097.3209.11.camel@localhost.localdomain> <4A033B7F.1030801@redhat.com> <4A033B97.508@redhat.com> <1241727061.3209.17.camel@localhost.localdomain> <25674.1241727717@sss.pgh.pa.us> <604aa7910905071332w49626251v2716c3115aee471b@mail.gmail.com> <4A034BE0.60803@hi.is> <604aa7910905071430i38452a0dk9195f098b28f5302@mail.gmail.com> <4A035B8F.9020903@hi.is> Message-ID: <604aa7910905071523h6cdc758apea1cdf5a6e1e071a@mail.gmail.com> 2009/5/7 "J?hann B. Gu?mundsson" : > Hum so for all the 1100+ packages that come with the default ( dvd ) install > hum mentioning the dvd is not really far so I shall just mention the 182 > updates waiting! > > You want a notification that nags you all day long.. you misread... i said give me a list of 5 out of the hundreds and nag me to drop a comment about one of them. have the 5 differ on each notification attempt. Once I drop at least one comment..it stops nagging me for the day. At no point did i say his is something everyone would want. But I know my work patterns and I know I need help taking the pile of testing updates and turning them into bite-sized chunks of information. Really its not that much different than twitter alerts from people interrupting my UI...except instead of messages from people i know..its messages about packages I've installed. -jef From nathanael at gnat.ca Thu May 7 22:33:49 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Thu, 07 May 2009 16:33:49 -0600 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <604aa7910905071523h6cdc758apea1cdf5a6e1e071a@mail.gmail.com> References: <1241718097.3209.11.camel@localhost.localdomain> <4A033B7F.1030801@redhat.com> <4A033B97.508@redhat.com> <1241727061.3209.17.camel@localhost.localdomain> <25674.1241727717@sss.pgh.pa.us> <604aa7910905071332w49626251v2716c3115aee471b@mail.gmail.com> <4A034BE0.60803@hi.is> <604aa7910905071430i38452a0dk9195f098b28f5302@mail.gmail.com> <4A035B8F.9020903@hi.is> <604aa7910905071523h6cdc758apea1cdf5a6e1e071a@mail.gmail.com> Message-ID: <4A0361CD.4040108@gnat.ca> Jeff Spaleta wrote: > 2009/5/7 "J?hann B. Gu?mundsson" : >> Hum so for all the 1100+ packages that come with the default ( dvd ) install >> hum mentioning the dvd is not really far so I shall just mention the 182 >> updates waiting! >> >> You want a notification that nags you all day long.. > > you misread... i said give me a list of 5 out of the hundreds and nag > me to drop a comment about one of them. have the 5 differ on each > notification attempt. Once I drop at least one comment..it stops > nagging me for the day. At no point did i say his is something > everyone would want. But I know my work patterns and I know I need > help taking the pile of testing updates and turning them into > bite-sized chunks of information. Really its not that much different > than twitter alerts from people interrupting my UI...except instead of > messages from people i know..its messages about packages I've > installed. Yeah, I agree, I recently enabled -testing so I could get the crazy new shiny 2.6.29 kernels which I found fixed a bunch of stuff. Also recently a colleague of mine who has since converted to linux but is by no means an expert, were discussing ways to contribute back (particularly because he gets frustrated with regressions in some programs) how to help. I mentioned, turn on the -testing repo and file bugs... If that was easy for them (or me) to do, it would be great. I would most definitely agree that a way to mark the list of packages in testing I'm interested in watching/filling comments for would be great. -- Nathanael d. Noblet T: 403.875.4613 From carl at five-ten-sg.com Thu May 7 23:24:46 2009 From: carl at five-ten-sg.com (Carl Byington) Date: Thu, 07 May 2009 16:24:46 -0700 Subject: Requires: %{_libdir}/pkgconfig In-Reply-To: <20090507172623.32d7e9ad@faldor.intranet> References: <20090507172623.32d7e9ad@faldor.intranet> Message-ID: <1241738686.21520.29.camel@ns.five-ten-sg.com> On Thu, 2009-05-07 at 17:26 +0200, Michael Schwendt Dependency chaos. Some packagers have started with adding > > Requires: %{_libdir}/pkgconfig > > instead of the good old "Requires: pkgconfig". Not only is this dependency > expensive -- the filelists metadata must be loaded and parsed -- it doesn't > work correctly either, because > > 1) package "pkgconfig" is not multilib'ed, so e.g. pkgconfig.i386 is > not available in the x86_64 repo, and hence nothing provides the > /usr/lib/pkgconfig directory, (and it would be a broken dep) but > > 2) a couple of other packages include %_libdir/pkgconfig by accident, > which violates the packaging guidelines. Namely: > > openchange-devel 499655 > ipod-sharp-devel 499658 > sane-backends-devel 499659 > libXScrnSaver-devel 499660 > freetype-devel 499661 > anthy-devel 499663 > > Since these are multilib'ed, a dependency on /usr/lib/pkgconfig > doesn't pull in pkgconfig.i386 but one of these -devel packages > instead. > > [...] > > Conclusively, neither "Requires: %{_libdir}/pkgconfig" nor > "Requires: pkgconfig%{_isa}" will work as expected. > From carl at five-ten-sg.com Thu May 7 23:27:03 2009 From: carl at five-ten-sg.com (Carl Byington) Date: Thu, 07 May 2009 16:27:03 -0700 Subject: Requires: %{_libdir}/pkgconfig In-Reply-To: <20090507172623.32d7e9ad@faldor.intranet> References: <20090507172623.32d7e9ad@faldor.intranet> Message-ID: <1241738823.21520.33.camel@ns.five-ten-sg.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 2009-05-07 at 17:26 +0200, Michael Schwendt wrote: Conclusively, neither "Requires: %{_libdir}/pkgconfig" nor > "Requires: pkgconfig%{_isa}" will work as expected. Is it correct to use: Requires: pkgconfig ... %files devel %defattr(-,root,root,-) %{_libdir}/libpst.so %{_includedir}/%{name}- at LIBPST_SO_MAJOR@/ %{_libdir}/pkgconfig/libpst.pc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFKA249L6j7milTFsERAk6lAJ0XDPz0GKja3EWw/NapiZFw6K7u1wCeN3Ii iVfKeQlvCCDXqdxhDBsEyd4= =+Lmt -----END PGP SIGNATURE----- From johannbg at hi.is Thu May 7 23:20:02 2009 From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=) Date: Thu, 07 May 2009 23:20:02 +0000 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <604aa7910905071523h6cdc758apea1cdf5a6e1e071a@mail.gmail.com> References: <1241718097.3209.11.camel@localhost.localdomain> <4A033B7F.1030801@redhat.com> <4A033B97.508@redhat.com> <1241727061.3209.17.camel@localhost.localdomain> <25674.1241727717@sss.pgh.pa.us> <604aa7910905071332w49626251v2716c3115aee471b@mail.gmail.com> <4A034BE0.60803@hi.is> <604aa7910905071430i38452a0dk9195f098b28f5302@mail.gmail.com> <4A035B8F.9020903@hi.is> <604aa7910905071523h6cdc758apea1cdf5a6e1e071a@mail.gmail.com> Message-ID: <4A036CA2.5080905@hi.is> On 05/07/2009 10:23 PM, Jeff Spaleta wrote: > 2009/5/7 "J?hann B. Gu?mundsson" : > >> Hum so for all the 1100+ packages that come with the default ( dvd ) install >> hum mentioning the dvd is not really far so I shall just mention the 182 >> updates waiting! >> >> You want a notification that nags you all day long.. >> > > you misread... i said give me a list of 5 out of the hundreds and nag > me to drop a comment about one of them. have the 5 differ on each > notification attempt. Once I drop at least one comment..it stops > nagging me for the day. At no point did i say his is something > everyone would want. But I know my work patterns and I know I need > help taking the pile of testing updates and turning them into > bite-sized chunks of information. Really its not that much different > than twitter alerts from people interrupting my UI...except instead of > messages from people i know..its messages about packages I've > installed. > Ok so let's leave notification rainbow and pony's out of it and brainstorm a little.. let's say we have an Bodhi client in Gnome ( gtk ) or Bodhi client ( plasma ) applet in KDE or better yet a Bodhi plugin in packagekit or kpackagekit that you could just vote immediately after you receive the updates from updates-testing. That application would have the thumps up thumps down on the update along with a comment field and perhaps username and a password field depending if we want all or just fas user vote. We cant have maintainer flag an component in updates-testing which would show up on application as a component that needs testing. It goes without saying all maintainers would flag their component hence you end up with everything flagged anyway. So each updated would always ask you for a thumb up, thumb down.. Hum randomly notify just a 5 or 10 components will not work messy algorithms that need to be come up with to deal with various issues like updates chain effect ( updates keep piling up and you would need to keep track of which one had already sent notification ) etc.. This could perhaps be solved with an ignore/silent or hide button that would hide component until the user mark it "show" basically the user selects components which he wants to vote on. Now this application would need to have the ability to exclude some package from requiring voting hum but then again if they need exclusion then the argument can be made that they simply don't need to be in updates-testing anyway.. We would still be faced with the problem of not knowing what to test and i'm not foreseeing that improving given some maintainers changelog track records Along with nobody likes paperwork... ( this is a bit of nugget on the process already ) Skeptical that this might work sound more like a "Great on paper crap on field" idea The biggest obstacle we are facing as I see it is getting the" how and what to test" to the user. /me throws the thinking ball into the air.. -- Viking-Ice One of my gods has a hammer your's was nailed to a cross You do the math! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jspaleta at gmail.com Thu May 7 23:44:42 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 7 May 2009 15:44:42 -0800 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <4A036CA2.5080905@hi.is> References: <1241718097.3209.11.camel@localhost.localdomain> <1241727061.3209.17.camel@localhost.localdomain> <25674.1241727717@sss.pgh.pa.us> <604aa7910905071332w49626251v2716c3115aee471b@mail.gmail.com> <4A034BE0.60803@hi.is> <604aa7910905071430i38452a0dk9195f098b28f5302@mail.gmail.com> <4A035B8F.9020903@hi.is> <604aa7910905071523h6cdc758apea1cdf5a6e1e071a@mail.gmail.com> <4A036CA2.5080905@hi.is> Message-ID: <604aa7910905071644s51dc493bm804504e88c63e3d1@mail.gmail.com> 2009/5/7 "J?hann B. Gu?mundsson" : > On 05/07/2009 10:23 PM, Jeff Spaleta wrote: > That application would have the thumps up thumps down on the update > along with a comment field and perhaps username and a password field > depending if we want all or just fas user vote. I dont need a full bodhi client....i just need to be reminded..sporatically that I have testing stuff installed. I have no problem using the bodhi web interface to drop a comment...i just need to to be reminded what I have installed that could use some love..at some time later than the moment of installation. Th underlying problems are simply these: 1) the only time i get notified with relevant information about testing updates is at the time of install. After installation its harder to know what installed packages need love. Right now I have to be extremely proactive about review packages and noting what I want to test..later..after installation..when I have time. 2)Right now the web interface doesn't present updates in a way that is relevant to my system usage..its just a pile of updates..ordered in time...but not personalized. I can't make good use of the most recent test update notifications on the site and dive into testing something from the list..because it may or may not be relevant to me. Kernels being the exception that makes the rule. If I could register my system somehow so that the bodhi webinterface would know to display the lastest packages relevant to the system I'm connecting from...that would do wonders. I could pick off one or two items from that personalized list of latest testing updates and drop some love. -jef -jef From cmadams at hiwaay.net Fri May 8 00:20:27 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 7 May 2009 19:20:27 -0500 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <4A0361CD.4040108@gnat.ca> References: <4A033B97.508@redhat.com> <1241727061.3209.17.camel@localhost.localdomain> <25674.1241727717@sss.pgh.pa.us> <604aa7910905071332w49626251v2716c3115aee471b@mail.gmail.com> <4A034BE0.60803@hi.is> <604aa7910905071430i38452a0dk9195f098b28f5302@mail.gmail.com> <4A035B8F.9020903@hi.is> <604aa7910905071523h6cdc758apea1cdf5a6e1e071a@mail.gmail.com> <4A0361CD.4040108@gnat.ca> Message-ID: <20090508002027.GC1290624@hiwaay.net> Once upon a time, Nathanael D. Noblet said: > I would most definitely agree that a way to mark the list of packages in > testing I'm interested in watching/filling comments for would be great. I load updates with yum, and I periodically do a run like "--enablerepo=\*testing check-update". I then cherry-pick things I use and might notice an issue with. There was a semi-recent xterm update that broke the bell; I BZed it, Thomas Dickey fixed it, and voila!, no buggy xterm when the update was released. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jkeating at redhat.com Fri May 8 01:05:31 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 07 May 2009 18:05:31 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <20090507220135.GB10303@amd.home.annexia.org> References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <4A034F52.1090103@redhat.com> <20090507220135.GB10303@amd.home.annexia.org> Message-ID: <1241744731.3209.67.camel@localhost.localdomain> On Thu, 2009-05-07 at 23:01 +0100, Richard W.M. Jones wrote: > Sure, I know about this. It means getting a real person from rel-eng > involved. Why can't it be automated We're getting things in place where this could be automated. > and/or why can't builds happen > against packages in updates-testing? Because things in -testing go away or get replaced with something else. This can cause a problem if your package built against something in testing, then you pushed stable and the -testing package went away. This mirrors what happens in RHEL land where pending errata doesn't go into buildroots unless otherwise requested. We could toy with letting updates-testing builds go into buildroots, but we'd have to add a whole lot more logic to the push system that would prevent something from being pushed to -stable unless everything it built against is also being pushed to stable or has already been pushed. All it takes is code. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dcantrell at redhat.com Fri May 8 01:39:31 2009 From: dcantrell at redhat.com (David Cantrell) Date: Thu, 07 May 2009 15:39:31 -1000 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <4A0348D3.8000302@gmail.com> References: <1241718097.3209.11.camel@localhost.localdomain> <4A033B7F.1030801@redhat.com> <4A0348D3.8000302@gmail.com> Message-ID: <4A038D53.7040200@redhat.com> On 05/07/2009 10:47 AM, Toshio Kuratomi wrote: > Michael DeHaan wrote: >> Jesse Keating wrote: >>> How is it we have 182 stable updates pending for F11 already? How have >>> these seen any testing by a wider audience? Are we really just not >>> bothering with updates-testing anymore? Do we not care about distro >>> stability? >>> >>> I know that many of these are newpackages, but many aren't though. >>> >>> >>> >> My experience is that most commercial users do not bother with logging >> into Bhodi or even know it exists. >> >> Another problem is that EPEL doesn't /yet/ use bhodi, so it has a >> different workflow -- meaning EPEL-testing doesn't really test anything, >> it means "rolls every 30-40 days", and that's about it. >> So testing has to happen manually, Fedora is the minority use case. >> >> Having a way to vote/comment without FAS would probably be enormously >> helpful in getting more users to use the system, once EPEL uses the same >> system. >> > You haven't needed a FAS account to leave a comment in bodhi for a long > time... possibly from the get-go. Look at a potential update in bodhi > without logging in. There's an add comment link that asks you for an > email address, comment, and a captcha to fill in. (Although I have > found in testing just now that anonymous commenting is currently > broken... have to find out from lmacken what's going on there.) That still won't make users go and leave comments in the updates system. Once they get an update that works, my experience is they are no longer interested in the "process" that follows or continues. What would be nice is an integration to the bodhi comments/karma system from bugzilla. The users already use bugzilla and read that throughout the process of solving a problem. Having them go to an entirely different site to leave a comment that says, "works for me" is sort of annoying from a user's point of view. If we could make that easier for them, maybe we'd see more automatic updates pushing. Or perhaps a yum plugin or packagekit thing that makes it easier for users to report that a particular update worked for them. -- David Cantrell Red Hat / Honolulu, HI From greno at verizon.net Fri May 8 01:41:25 2009 From: greno at verizon.net (Gerry Reno) Date: Thu, 07 May 2009 21:41:25 -0400 Subject: F11 Preview: cannot start X Message-ID: <4A038DC5.1000803@verizon.net> I've been fiddling with trying to get X running on an F11 Preview upgrade for a couple hours without any luck. Has anyone seen anything like this: ==== messages log ==== May 7 20:45:41 grp-01-10-01 acpid: client connected from 2741[68:68] May 7 20:45:41 grp-01-10-01 acpid: 1 client rule loaded May 7 20:45:42 grp-01-10-01 ntpd[2339]: Listening on interface #7 virbr0, fe80::d4b9:27ff:fe31:8f7c#123 Enabled May 7 20:45:51 grp-01-10-01 gdm-binary[2778]: WARNING: GdmDisplay: display lasted 0.367108 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[2778]: WARNING: GdmDisplay: display lasted 0.020365 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[2778]: WARNING: GdmDisplay: display lasted 0.009410 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[2778]: WARNING: GdmDisplay: display lasted 0.009531 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[2778]: WARNING: GdmDisplay: display lasted 0.010082 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[2778]: WARNING: GdmDisplay: display lasted 0.063729 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[2778]: WARNING: GdmLocalDisplayFactory: maximum number of X display failures reached: check X server log for errors May 7 20:45:51 grp-01-10-01 init: prefdm main process (2778) terminated with status 1 May 7 20:45:51 grp-01-10-01 init: prefdm main process ended, respawning May 7 20:45:51 grp-01-10-01 gdm-binary[2864]: WARNING: GdmDisplay: display lasted 0.009775 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[2864]: WARNING: GdmDisplay: display lasted 0.009336 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[2864]: WARNING: GdmDisplay: display lasted 0.009261 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[2864]: WARNING: GdmDisplay: display lasted 0.009277 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[2864]: WARNING: GdmDisplay: display lasted 0.009798 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[2864]: WARNING: GdmDisplay: display lasted 0.009213 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[2864]: WARNING: GdmLocalDisplayFactory: maximum number of X display failures reached: check X server log for errors May 7 20:45:51 grp-01-10-01 init: prefdm main process (2864) terminated with status 1 May 7 20:45:51 grp-01-10-01 init: prefdm main process ended, respawning May 7 20:45:51 grp-01-10-01 gdm-binary[2910]: WARNING: GdmDisplay: display lasted 0.009024 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[2910]: WARNING: GdmDisplay: display lasted 0.009378 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[2910]: WARNING: GdmDisplay: display lasted 0.009140 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[2910]: WARNING: GdmDisplay: display lasted 0.009054 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[2910]: WARNING: GdmDisplay: display lasted 0.009385 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[2910]: WARNING: GdmDisplay: display lasted 0.009133 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[2910]: WARNING: GdmLocalDisplayFactory: maximum number of X display failures reached: check X server log for errors May 7 20:45:51 grp-01-10-01 init: prefdm main process (2910) terminated with status 1 May 7 20:45:51 grp-01-10-01 init: prefdm main process ended, respawning May 7 20:45:51 grp-01-10-01 gdm-binary[2956]: WARNING: GdmDisplay: display lasted 0.009759 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[2956]: WARNING: GdmDisplay: display lasted 0.010512 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[2956]: WARNING: GdmDisplay: display lasted 0.009426 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[2956]: WARNING: GdmDisplay: display lasted 0.009667 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[2956]: WARNING: GdmDisplay: display lasted 0.009525 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[2956]: WARNING: GdmDisplay: display lasted 0.009641 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[2956]: WARNING: GdmLocalDisplayFactory: maximum number of X display failures reached: check X server log for errors May 7 20:45:51 grp-01-10-01 init: prefdm main process (2956) terminated with status 1 May 7 20:45:51 grp-01-10-01 init: prefdm main process ended, respawning May 7 20:45:51 grp-01-10-01 gdm-binary[3002]: WARNING: GdmDisplay: display lasted 0.009722 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[3002]: WARNING: GdmDisplay: display lasted 0.009195 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[3002]: WARNING: GdmDisplay: display lasted 0.009514 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[3002]: WARNING: GdmDisplay: display lasted 0.009203 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[3002]: WARNING: GdmDisplay: display lasted 0.010057 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[3002]: WARNING: GdmDisplay: display lasted 0.009202 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[3002]: WARNING: GdmLocalDisplayFactory: maximum number of X display failures reached: check X server log for errors May 7 20:45:51 grp-01-10-01 init: prefdm main process (3002) terminated with status 1 May 7 20:45:51 grp-01-10-01 init: prefdm main process ended, respawning May 7 20:45:51 grp-01-10-01 gdm-binary[3048]: WARNING: GdmDisplay: display lasted 0.010478 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[3048]: WARNING: GdmDisplay: display lasted 0.009410 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[3048]: WARNING: GdmDisplay: display lasted 0.009507 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[3048]: WARNING: GdmDisplay: display lasted 0.009452 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[3048]: WARNING: GdmDisplay: display lasted 0.009479 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[3048]: WARNING: GdmDisplay: display lasted 0.009407 seconds May 7 20:45:51 grp-01-10-01 gdm-binary[3048]: WARNING: GdmLocalDisplayFactory: maximum number of X display failures reached: check X server log for errors May 7 20:45:51 grp-01-10-01 init: prefdm main process (3048) terminated with status 1 May 7 20:45:51 grp-01-10-01 init: prefdm main process ended, respawning May 7 20:45:52 grp-01-10-01 gdm-binary[3094]: WARNING: GdmDisplay: display lasted 0.011297 seconds May 7 20:45:52 grp-01-10-01 gdm-binary[3094]: WARNING: GdmDisplay: display lasted 0.009992 seconds May 7 20:45:52 grp-01-10-01 gdm-binary[3094]: WARNING: GdmDisplay: display lasted 0.009810 seconds May 7 20:45:52 grp-01-10-01 gdm-binary[3094]: WARNING: GdmDisplay: display lasted 0.009947 seconds May 7 20:45:52 grp-01-10-01 gdm-binary[3094]: WARNING: GdmDisplay: display lasted 0.009777 seconds May 7 20:45:52 grp-01-10-01 gdm-binary[3094]: WARNING: GdmDisplay: display lasted 0.009462 seconds May 7 20:45:52 grp-01-10-01 gdm-binary[3094]: WARNING: GdmLocalDisplayFactory: maximum number of X display failures reached: check X server log for errors May 7 20:45:52 grp-01-10-01 init: prefdm main process (3094) terminated with status 1 May 7 20:45:52 grp-01-10-01 init: prefdm main process ended, respawning May 7 20:45:52 grp-01-10-01 gdm-binary[3140]: WARNING: GdmDisplay: display lasted 0.009087 seconds May 7 20:45:52 grp-01-10-01 gdm-binary[3140]: WARNING: GdmDisplay: display lasted 0.009175 seconds May 7 20:45:52 grp-01-10-01 gdm-binary[3140]: WARNING: GdmDisplay: display lasted 0.008896 seconds May 7 20:45:52 grp-01-10-01 gdm-binary[3140]: WARNING: GdmDisplay: display lasted 0.009703 seconds May 7 20:45:52 grp-01-10-01 gdm-binary[3140]: WARNING: GdmDisplay: display lasted 0.009135 seconds May 7 20:45:52 grp-01-10-01 gdm-binary[3140]: WARNING: GdmDisplay: display lasted 0.008535 seconds May 7 20:45:52 grp-01-10-01 gdm-binary[3140]: WARNING: GdmLocalDisplayFactory: maximum number of X display failures reached: check X server log for errors May 7 20:45:52 grp-01-10-01 init: prefdm main process (3140) terminated with status 1 May 7 20:45:52 grp-01-10-01 init: prefdm main process ended, respawning May 7 20:45:52 grp-01-10-01 gdm-binary[3186]: WARNING: GdmDisplay: display lasted 0.009273 seconds May 7 20:45:52 grp-01-10-01 gdm-binary[3186]: WARNING: GdmDisplay: display lasted 0.009405 seconds May 7 20:45:52 grp-01-10-01 gdm-binary[3186]: WARNING: GdmDisplay: display lasted 0.009100 seconds May 7 20:45:52 grp-01-10-01 gdm-binary[3186]: WARNING: GdmDisplay: display lasted 0.008997 seconds May 7 20:45:52 grp-01-10-01 gdm-binary[3186]: WARNING: GdmDisplay: display lasted 0.008935 seconds May 7 20:45:52 grp-01-10-01 gdm-binary[3186]: WARNING: GdmDisplay: display lasted 0.009013 seconds May 7 20:45:52 grp-01-10-01 gdm-binary[3186]: WARNING: GdmLocalDisplayFactory: maximum number of X display failures reached: check X server log for errors May 7 20:45:52 grp-01-10-01 init: prefdm main process (3186) terminated with status 1 May 7 20:45:52 grp-01-10-01 init: prefdm main process ended, respawning May 7 20:45:52 grp-01-10-01 gdm-binary[3232]: WARNING: GdmDisplay: display lasted 0.009138 seconds May 7 20:45:52 grp-01-10-01 gdm-binary[3232]: WARNING: GdmDisplay: display lasted 0.009552 seconds May 7 20:45:52 grp-01-10-01 gdm-binary[3232]: WARNING: GdmDisplay: display lasted 0.009375 seconds May 7 20:45:52 grp-01-10-01 gdm-binary[3232]: WARNING: GdmDisplay: display lasted 0.009042 seconds May 7 20:45:52 grp-01-10-01 gdm-binary[3232]: WARNING: GdmDisplay: display lasted 0.009272 seconds May 7 20:45:52 grp-01-10-01 gdm-binary[3232]: WARNING: GdmDisplay: display lasted 0.009150 seconds May 7 20:45:52 grp-01-10-01 gdm-binary[3232]: WARNING: GdmLocalDisplayFactory: maximum number of X display failures reached: check X server log for errors May 7 20:45:52 grp-01-10-01 init: prefdm main process (3232) terminated with status 1 May 7 20:45:52 grp-01-10-01 init: prefdm main process ended, respawning May 7 20:45:52 grp-01-10-01 init: prefdm respawning too fast, stopped May 7 20:49:55 grp-01-10-01 ntpd[2339]: synchronized to 149.20.54.159, stratum 2 May 7 20:49:55 grp-01-10-01 ntpd[2339]: time reset +0.509916 s May 7 20:49:55 grp-01-10-01 ntpd[2339]: kernel time sync status change 0001 May 7 20:54:19 grp-01-10-01 ntpd[2339]: synchronized to 208.75.88.4, stratum 2 May 7 21:02:53 grp-01-10-01 ntpd[2339]: synchronized to 149.20.54.159, stratum 2 ==== Xorg.0.log ==== X.Org X Server 1.5.3 Release Date: 5 November 2008 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.18-128.1.1.el5 i686 Current Operating System: Linux grp-01-10-01 2.6.27.5-117.fc10.x86_64 #1 SMP Tue Nov 18 11:58:53 EST 2008 x86_64 Build Date: 10 March 2009 07:20:48PM Build ID: xorg-x11-server 1.5.3-15.fc10 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Mon May 4 02:41:29 2009 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "single head configuration" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "Videocard0" (**) |-->Input Device "Keyboard0" (==) Automatically adding devices (==) Automatically enabling devices (==) No FontPath specified. Using compiled-in default. (==) FontPath set to: catalogue:/etc/X11/fontpath.d, built-ins (==) ModulePath set to "/usr/lib/xorg/modules" (II) Cannot locate a core pointer device. (II) The server relies on HAL to provide the list of input devices. If no devices become available, reconfigure HAL or disable AllowEmptyInput. (WW) AllowEmptyInput is on, devices using drivers 'kbd' or 'mouse' will be disabled. (WW) Disabling Keyboard0 (II) Open ACPI successful (/var/run/acpid.socket) (II) Loader magic: 0x81f4400 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 4.1 X.Org XInput driver : 2.1 X.Org Server Extension : 1.1 X.Org Font Renderer : 0.6 (II) Loader running on linux (++) using VT number 1 (--) PCI:*(0 at 1:0:0) nVidia Corporation G72 [GeForce 7300 SE] rev 161, Mem @ 0xfa000000/0, 0xd0000000/0, 0xfb000000/0, BIOS @ 0x????????/131072 (II) System resource ranges: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [5] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [6] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [7] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [8] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [9] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [10] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [11] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [12] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [13] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [14] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [15] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [16] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [17] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [18] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [19] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [20] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [21] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [22] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [23] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [24] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [25] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [26] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [27] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [28] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [29] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [30] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [31] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [32] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [33] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [34] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [35] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] (II) LoadModule: "extmod" (II) Loading /usr/lib/xorg/modules/extensions//libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.5.3, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 1.1 (II) Loading extension SELinux (II) Loading extension SHAPE (II) Loading extension MIT-SUNDRY-NONSTANDARD (II) Loading extension BIG-REQUESTS (II) Loading extension SYNC (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XC-MISC (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-Misc (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension TOG-CUP (II) Loading extension Extended-Visual-Information (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "dbe" (II) Loading /usr/lib/xorg/modules/extensions//libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 1.5.3, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 1.1 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "glx" (II) Loading /usr/lib/xorg/modules/extensions//libglx.so (II) Module glx: vendor="X.Org Foundation" compiled for 1.5.3, module version = 1.0.0 ABI class: X.Org Server Extension, version 1.1 (==) AIGLX enabled (==) Exporting typical set of GLX visuals (II) Loading extension GLX (II) LoadModule: "freetype" (II) Loading /usr/lib/xorg/modules/fonts//libfreetype.so (II) Module freetype: vendor="X.Org Foundation & the After X-TT Project" compiled for 1.5.3, module version = 2.1.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.6 (II) Loading font FreeType (II) LoadModule: "dri" (II) Loading /usr/lib/xorg/modules/extensions//libdri.so (II) Module dri: vendor="X.Org Foundation" compiled for 1.5.3, module version = 1.0.0 ABI class: X.Org Server Extension, version 1.1 (II) Loading extension XFree86-DRI (II) LoadModule: "nv" (II) Loading /usr/lib/xorg/modules/drivers//nv_drv.so (II) Module nv: vendor="X.Org Foundation" compiled for 1.5.2, module version = 2.1.12 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 4.1 (II) NV: driver for NVIDIA chipsets: RIVA 128, RIVA TNT, RIVA TNT2, Unknown TNT2, Vanta, RIVA TNT2 Ultra, RIVA TNT2 Model 64, Aladdin TNT2, GeForce 256, GeForce DDR, Quadro, GeForce2 MX/MX 400, GeForce2 MX 100/200, GeForce2 Go, Quadro2 MXR/EX/Go, GeForce2 Integrated GPU, GeForce2 GTS, GeForce2 Ti, GeForce2 Ultra, Quadro2 Pro, GeForce4 MX 460, GeForce4 MX 440, GeForce4 MX 420, GeForce4 MX 440-SE, GeForce4 440 Go, GeForce4 420 Go, GeForce4 420 Go 32M, GeForce4 460 Go, Quadro4 550 XGL, GeForce4 440 Go 64M, Quadro NVS, Quadro4 500 GoGL, GeForce4 410 Go 16M, GeForce4 MX 440 with AGP8X, GeForce4 MX 440SE with AGP8X, GeForce4 MX 420 with AGP8X, GeForce4 MX 4000, GeForce4 448 Go, GeForce4 488 Go, Quadro4 580 XGL, Quadro4 NVS 280 SD, Quadro4 380 XGL, Quadro NVS 50 PCI, GeForce4 448 Go, GeForce4 MX Integrated GPU, GeForce3, GeForce3 Ti 200, GeForce3 Ti 500, Quadro DCC, GeForce4 Ti 4600, GeForce4 Ti 4400, GeForce4 Ti 4200, Quadro4 900 XGL, Quadro4 750 XGL, Quadro4 700 XGL, GeForce4 Ti 4800, GeForce4 Ti 4200 with AGP8X, GeForce4 Ti 4800 SE, GeForce4 4200 Go, Quadro4 700 GoGL, Quadro4 980 XGL, Quadro4 780 XGL, GeForce FX 5800 Ultra, GeForce FX 5800, Quadro FX 2000, Quadro FX 1000, GeForce FX 5600 Ultra, GeForce FX 5600, GeForce FX 5600XT, GeForce FX Go5600, GeForce FX Go5650, Quadro FX Go700, GeForce FX 5200, GeForce FX 5200 Ultra, GeForce FX 5200, GeForce FX 5200LE, GeForce FX Go5200, GeForce FX Go5250, GeForce FX 5500, GeForce FX 5100, GeForce FX Go5200 32M/64M, Quadro NVS 55/280 PCI, Quadro FX 500/600 PCI, GeForce FX Go53xx Series, GeForce FX Go5100, GeForce FX 5900 Ultra, GeForce FX 5900, GeForce FX 5900XT, GeForce FX 5950 Ultra, GeForce FX 5900ZT, Quadro FX 3000, Quadro FX 700, GeForce FX 5700 Ultra, GeForce FX 5700, GeForce FX 5700LE, GeForce FX 5700VE, GeForce FX Go5700, GeForce FX Go5700, Quadro FX Go1000, Quadro FX 1100, GeForce 6800 Ultra, GeForce 6800, GeForce 6800 LE, GeForce 6800 XE, GeForce 6800 XT, GeForce 6800 GT, GeForce 6800 GT, GeForce 6800 GS, GeForce 6800 XT, Quadro FX 4000, GeForce 6800 GS, GeForce 6800, GeForce 6800 LE, GeForce 6800 XT, GeForce Go 6800, GeForce Go 6800 Ultra, Quadro FX Go1400, Quadro FX 3450/4000 SDI, Quadro FX 1400, GeForce 6600 GT, GeForce 6600, GeForce 6600 LE, GeForce 6600 VE, GeForce Go 6600, GeForce 6610 XL, GeForce Go 6600 TE/6200 TE, GeForce 6700 XL, GeForce Go 6600, GeForce Go 6600 GT, Quadro FX 550, Quadro FX 550, Quadro FX 540, GeForce 6200, GeForce 6500, GeForce 6200 TurboCache(TM), GeForce 6200SE TurboCache(TM), GeForce 6200 LE, GeForce Go 6200, Quadro NVS 285, GeForce Go 6400, GeForce Go 6200, GeForce Go 6400, GeForce 6250, GeForce 6800, GeForce 6800 LE, GeForce 6800 GT, GeForce 6800 XT, GeForce 6200, GeForce 6200 A-LE, GeForce 7800 GTX, GeForce 7800 GTX, GeForce 7800 GT, GeForce 7800 GS, GeForce 7800 SLI, GeForce Go 7800, GeForce Go 7800 GTX, Quadro FX 4500, GeForce 7300 LE, GeForce 7300 SE, GeForce Go 7200, GeForce Go 7300, GeForce Go 7400, GeForce Go 7400 GS, Quadro NVS 110M, Quadro NVS 120M, Quadro FX 350M, GeForce 7500 LE, Quadro FX 350, GeForce 7300 GS, GeForce 7600 GT, GeForce 7600 GS, GeForce 7300 GT, GeForce 7600 LE, GeForce 7300 GT, GeForce Go 7700, GeForce Go 7600, GeForce Go 7600 GT, Quadro NVS 300M, GeForce Go 7900 SE, Quadro FX 550M, Quadro FX 560, GeForce 7900 GTX, GeForce 7900 GT, GeForce 7900 GS, GeForce Go 7900 GS, GeForce Go 7900 GTX, Quadro FX 2500M, Quadro FX 1500M, Quadro FX 5500, Quadro FX 3500, Quadro FX 1500, Quadro FX 4500 X2, GeForce 6150, GeForce 6150 LE, GeForce 6100, GeForce Go 6150, GeForce Go 6100, GeForce 8800 GTX, GeForce 8800 GTS, GeForce 8800 Ultra, Quadro FX 5600, Quadro FX 4600, GeForce 8600 GTS, GeForce 8600 GT, GeForce 8600 GT, GeForce 8600 GS, GeForce 8400 GS, GeForce 9500M GS, GeForce 8600M GT, GeForce 9650M GS, GeForce 8700M GT, Quadro FX 370, Quadro NVS 320M, Quadro FX 570M, Quadro FX 1600M, Quadro FX 570, Quadro FX 1700, GeForce 8400 SE, GeForce 8500 GT, GeForce 8400 GS, GeForce 8300 GS, GeForce 8400 GS, GeForce 8600M GS, GeForce 8400M GT, GeForce 8400M GS, GeForce 8400M G, Quadro NVS 140M, Quadro NVS 130M, Quadro NVS 135M, GeForce 9400 GT, Quadro FX 360M, GeForce 9300M G, Quadro NVS 290, GeForce GTX 280, GeForce GTX 260, GeForce 8800 GTS 512, GeForce 8800 GT, GeForce 9800 GX2, GeForce 8800 GS, GeForce 8800M GTS, GeForce 8800M GTX, GeForce 8800 GS, GeForce 9600 GSO, GeForce 8800 GT, GeForce 9800 GTX, GeForce 9800 GTK+, GeForce 9800 GT, Quadro FX 3700, Quadro FX 3600M, GeForce 9600 GT, GeForce 9600 GS, GeForce 9800M GTS, GeForce 9700M GTS, GeForce 9800M GTS, GeForce 9500 GT, GeForce 9600M GT, GeForce 9600M GS, GeForce 9600M GT, GeForce 9500M G, GeForce 9300 GS, GeForce 8400 GS, GeForce 9300M GS, GeForce 9200M GS, GeForce 9300M GS, Quadro NVS 150M, Quadro NVS 160M (II) Primary Device is: PCI 01 at 00:00:0 (--) NV: Found NVIDIA GeForce 7300 SE at 01 at 00:00:0 (II) resource ranges after probing: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [5] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [6] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [7] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [8] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [9] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [10] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [11] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [12] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [13] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [14] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [15] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [16] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [17] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [18] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [19] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [20] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [21] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [22] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [23] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [24] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [25] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [26] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [27] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [28] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [29] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [30] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [31] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [32] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [33] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [34] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [35] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Loading /usr/lib/xorg/modules//libint10.so (II) Module int10: vendor="X.Org Foundation" compiled for 1.5.3, module version = 1.0.0 ABI class: X.Org Video Driver, version 4.1 (II) NV(0): Initializing int10 (II) NV(0): Primary V_BIOS segment is: 0xc000 (--) NV(0): Chipset: "GeForce 7300 SE" (**) NV(0): Depth 24, (--) framebuffer bpp 32 (==) NV(0): RGB weight 888 (==) NV(0): Default visual is TrueColor (II) Loading sub module "vgahw" (II) LoadModule: "vgahw" (II) Loading /usr/lib/xorg/modules//libvgahw.so (II) Module vgahw: vendor="X.Org Foundation" compiled for 1.5.3, module version = 0.1.0 ABI class: X.Org Video Driver, version 4.1 (==) NV(0): Using HW cursor (--) NV(0): Linear framebuffer at 0xD0000000 (--) NV(0): MMIO registers at 0xFA000000 (II) Loading sub module "i2c" (II) LoadModule: "i2c" (II) Module "i2c" already built-in (II) Loading sub module "ddc" (II) LoadModule: "ddc" (II) Module "ddc" already built-in (II) NV(0): I2C bus "DDC" initialized. (II) NV(0): Probing for analog device on output A... (--) NV(0): ...found one (II) NV(0): Probing for analog device on output B... (--) NV(0): ...can't find one (II) NV(0): Probing for EDID on I2C bus A... (II) NV(0): I2C device "DDC:E-EDID segment register" registered at address 0x60. (II) NV(0): I2C device "DDC:ddc2" registered at address 0xA0. (II) NV(0): ... none found (II) NV(0): Probing for EDID on I2C bus B... (--) NV(0): DDC detected a CRT: (II) NV(0): Manufacturer: SAM Model: 225 Serial#: 1212231993 (II) NV(0): Year: 2006 Week: 42 (II) NV(0): EDID Version: 1.3 (II) NV(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V (II) NV(0): Sync: Separate Composite SyncOnGreen (II) NV(0): Max Image Size [cm]: horiz.: 41 vert.: 26 (II) NV(0): Gamma: 2.35 (II) NV(0): DPMS capabilities: StandBy; RGB/Color Display (II) NV(0): First detailed timing is preferred mode (II) NV(0): redX: 0.636 redY: 0.349 greenX: 0.290 greenY: 0.589 (II) NV(0): blueX: 0.143 blueY: 0.080 whiteX: 0.313 whiteY: 0.329 (II) NV(0): Supported VESA Video Modes: (II) NV(0): 720x400 at 70Hz (II) NV(0): 640x480 at 60Hz (II) NV(0): 640x480 at 67Hz (II) NV(0): 640x480 at 72Hz (II) NV(0): 640x480 at 75Hz (II) NV(0): 800x600 at 56Hz (II) NV(0): 800x600 at 60Hz (II) NV(0): 800x600 at 72Hz (II) NV(0): 800x600 at 75Hz (II) NV(0): 832x624 at 75Hz (II) NV(0): 1024x768 at 60Hz (II) NV(0): 1024x768 at 70Hz (II) NV(0): 1024x768 at 75Hz (II) NV(0): 1280x1024 at 75Hz (II) NV(0): 1152x870 at 75Hz (II) NV(0): Manufacturer's mask: 0 (II) NV(0): Supported Future Video Modes: (II) NV(0): #0: hsize: 1440 vsize 900 refresh: 60 vid: 149 (II) NV(0): #1: hsize: 1440 vsize 900 refresh: 75 vid: 3989 (II) NV(0): #2: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) NV(0): #3: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) NV(0): #4: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) NV(0): Supported additional Video Mode: (II) NV(0): clock: 106.5 MHz Image Size: 410 x 257 mm (II) NV(0): h_active: 1440 h_sync: 1520 h_sync_end 1672 h_blank_end 1904 h_border: 0 (II) NV(0): v_active: 900 v_sync: 903 v_sync_end 909 v_blanking: 934 v_border: 0 (II) NV(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz, PixClock max 140 MHz (II) NV(0): Monitor name: SyncMaster (II) NV(0): Serial No: HVELA57665 (II) NV(0): EDID (in hex): (II) NV(0): 00ffffffffffff004c2d250239314148 (II) NV(0): 2a1001030e291a878ad7a5a2594a9624 (II) NV(0): 145054bfef809500950f81808140714f (II) NV(0): 0101010101019a29a0d0518422305098 (II) NV(0): 36009a011100001c000000fd00384b1e (II) NV(0): 510e000a202020202020000000fc0053 (II) NV(0): 796e634d61737465720a2020000000ff (II) NV(0): 004856454c4135373636350a20200095 (--) NV(0): CRTC 0 appears to have a CRT attached (II) NV(0): Using CRT on CRTC 0 (II) NV(0): EDID vendor "SAM", prod id 549 (II) NV(0): Using hsync ranges from config file (II) NV(0): Using vrefresh ranges from config file (II) NV(0): Printing DDC gathered Modelines: (II) NV(0): Modeline "1440x900"x0.0 106.50 1440 1520 1672 1904 900 903 909 934 -hsync +vsync (55.9 kHz) (II) NV(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) NV(0): Modeline "800x600"x0.0 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) NV(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) NV(0): Modeline "640x480"x0.0 31.50 640 664 704 832 480 489 492 520 -hsync -vsync (37.9 kHz) (II) NV(0): Modeline "640x480"x0.0 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) (II) NV(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) NV(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) NV(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (II) NV(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz) (II) NV(0): Modeline "1024x768"x0.0 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (II) NV(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) NV(0): Modeline "832x624"x0.0 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) (II) NV(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) NV(0): Modeline "800x600"x0.0 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (II) NV(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) NV(0): Modeline "1440x900"x0.0 106.50 1440 1520 1672 1904 900 903 909 934 -hsync +vsync (55.9 kHz) (II) NV(0): Modeline "1440x900"x0.0 136.75 1440 1536 1688 1936 900 903 909 942 -hsync +vsync (70.6 kHz) (II) NV(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) (II) NV(0): Modeline "1280x960"x0.0 108.00 1280 1376 1488 1800 960 961 964 1000 +hsync +vsync (60.0 kHz) (II) NV(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (--) NV(0): VideoRAM: 131072 kBytes (==) NV(0): Using gamma correction (1.0, 1.0, 1.0) (II) NV(0): Monitor0: Using hsync range of 31.50-56.00 kHz (II) NV(0): Monitor0: Using vrefresh range of 56.00-65.00 Hz (II) NV(0): Monitor0: Using maximum pixel clock of 140.00 MHz (II) NV(0): Estimated virtual size for aspect ratio 1.5769 is 1440x900 (II) NV(0): Clock range: 12.00 to 400.00 MHz (II) NV(0): Not using default mode "640x350" (vrefresh out of range) (II) NV(0): Not using default mode "320x175" (vrefresh out of range) (II) NV(0): Not using default mode "640x400" (vrefresh out of range) (II) NV(0): Not using default mode "320x200" (vrefresh out of range) (II) NV(0): Not using default mode "720x400" (vrefresh out of range) (II) NV(0): Not using default mode "360x200" (vrefresh out of range) (II) NV(0): Not using default mode "640x480" (vrefresh out of range) (II) NV(0): Not using default mode "320x240" (vrefresh out of range) (II) NV(0): Not using default mode "640x480" (vrefresh out of range) (II) NV(0): Not using default mode "320x240" (vrefresh out of range) (II) NV(0): Not using default mode "640x480" (vrefresh out of range) (II) NV(0): Not using default mode "320x240" (vrefresh out of range) (II) NV(0): Not using default mode "800x600" (vrefresh out of range) (II) NV(0): Not using default mode "400x300" (vrefresh out of range) (II) NV(0): Not using default mode "800x600" (vrefresh out of range) (II) NV(0): Not using default mode "400x300" (vrefresh out of range) (II) NV(0): Not using default mode "800x600" (vrefresh out of range) (II) NV(0): Not using default mode "400x300" (vrefresh out of range) (II) NV(0): Not using default mode "1024x768" (vrefresh out of range) (II) NV(0): Not using default mode "512x384" (vrefresh out of range) (II) NV(0): Not using default mode "1024x768" (vrefresh out of range) (II) NV(0): Not using default mode "512x384" (vrefresh out of range) (II) NV(0): Not using default mode "1024x768" (hsync out of range) (II) NV(0): Not using default mode "512x384" (hsync out of range) (II) NV(0): Not using default mode "1024x768" (hsync out of range) (II) NV(0): Not using default mode "512x384" (hsync out of range) (II) NV(0): Not using default mode "1152x864" (hsync out of range) (II) NV(0): Not using default mode "576x432" (hsync out of range) (II) NV(0): Not using default mode "1280x960" (height too large for virtual size) (II) NV(0): Not using default mode "640x480" (hsync out of range) (II) NV(0): Not using default mode "1280x960" (height too large for virtual size) (II) NV(0): Not using default mode "640x480" (hsync out of range) (II) NV(0): Not using default mode "1280x1024" (height too large for virtual size) (II) NV(0): Not using default mode "640x512" (hsync out of range) (II) NV(0): Not using default mode "1280x1024" (height too large for virtual size) (II) NV(0): Not using default mode "640x512" (hsync out of range) (II) NV(0): Not using default mode "1280x1024" (height too large for virtual size) (II) NV(0): Not using default mode "640x512" (hsync out of range) (II) NV(0): Not using default mode "1600x1200" (width too large for virtual size) (II) NV(0): Not using default mode "800x600" (hsync out of range) (II) NV(0): Not using default mode "1600x1200" (width too large for virtual size) (II) NV(0): Not using default mode "800x600" (hsync out of range) (II) NV(0): Not using default mode "1600x1200" (width too large for virtual size) (II) NV(0): Not using default mode "800x600" (hsync out of range) (II) NV(0): Not using default mode "1600x1200" (width too large for virtual size) (II) NV(0): Not using default mode "800x600" (hsync out of range) (II) NV(0): Not using default mode "1600x1200" (width too large for virtual size) (II) NV(0): Not using default mode "800x600" (hsync out of range) (II) NV(0): Not using default mode "1792x1344" (width too large for virtual size) (II) NV(0): Not using default mode "896x672" (hsync out of range) (II) NV(0): Not using default mode "1792x1344" (width too large for virtual size) (II) NV(0): Not using default mode "896x672" (hsync out of range) (II) NV(0): Not using default mode "1856x1392" (width too large for virtual size) (II) NV(0): Not using default mode "928x696" (hsync out of range) (II) NV(0): Not using default mode "1856x1392" (width too large for virtual size) (II) NV(0): Not using default mode "928x696" (hsync out of range) (II) NV(0): Not using default mode "1920x1440" (width too large for virtual size) (II) NV(0): Not using default mode "960x720" (hsync out of range) (II) NV(0): Not using default mode "1920x1440" (width too large for virtual size) (II) NV(0): Not using default mode "960x720" (hsync out of range) (II) NV(0): Not using default mode "832x624" (vrefresh out of range) (II) NV(0): Not using default mode "416x312" (vrefresh out of range) (II) NV(0): Not using default mode "1400x1050" (height too large for virtual size) (II) NV(0): Not using default mode "700x525" (hsync out of range) (II) NV(0): Not using default mode "1400x1050" (height too large for virtual size) (II) NV(0): Not using default mode "700x525" (hsync out of range) (II) NV(0): Not using default mode "1920x1440" (width too large for virtual size) (II) NV(0): Not using default mode "960x720" (hsync out of range) (II) NV(0): Not using default mode "2048x1536" (width too large for virtual size) (II) NV(0): Not using default mode "1024x768" (hsync out of range) (II) NV(0): Not using default mode "2048x1536" (width too large for virtual size) (II) NV(0): Not using default mode "1024x768" (hsync out of range) (II) NV(0): Not using default mode "2048x1536" (width too large for virtual size) (II) NV(0): Not using default mode "1024x768" (hsync out of range) (II) NV(0): Not using driver mode "640x480" (vrefresh out of range) (II) NV(0): Not using driver mode "640x480" (vrefresh out of range) (II) NV(0): Not using driver mode "640x480" (vrefresh out of range) (II) NV(0): Not using driver mode "720x400" (vrefresh out of range) (II) NV(0): Not using driver mode "1280x1024" (height too large for virtual size) (II) NV(0): Not using driver mode "1024x768" (hsync out of range) (II) NV(0): Not using driver mode "1024x768" (vrefresh out of range) (II) NV(0): Not using driver mode "832x624" (vrefresh out of range) (II) NV(0): Not using driver mode "800x600" (vrefresh out of range) (II) NV(0): Not using driver mode "800x600" (vrefresh out of range) (II) NV(0): Not using driver mode "1152x864" (hsync out of range) (II) NV(0): Not using driver mode "1440x900" (hsync out of range) (II) NV(0): Not using driver mode "1280x1024" (height too large for virtual size) (II) NV(0): Not using driver mode "1280x960" (height too large for virtual size) (II) NV(0): Not using driver mode "1152x864" (hsync out of range) (--) NV(0): Virtual size is 1440x900 (pitch 1440) (**) NV(0): *Driver mode "1440x900": 106.5 MHz, 55.9 kHz, 59.9 Hz (II) NV(0): Modeline "1440x900"x59.9 106.50 1440 1520 1672 1904 900 903 909 934 -hsync +vsync (55.9 kHz) (**) NV(0): *Driver mode "1440x900": 106.5 MHz, 55.9 kHz, 59.9 Hz (II) NV(0): Modeline "1440x900"x59.9 106.50 1440 1520 1672 1904 900 903 909 934 -hsync +vsync (55.9 kHz) (**) NV(0): *Driver mode "1024x768": 65.0 MHz, 48.4 kHz, 60.0 Hz (II) NV(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (**) NV(0): *Default mode "1024x768": 65.0 MHz, 48.4 kHz, 60.0 Hz (II) NV(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (**) NV(0): *Driver mode "800x600": 40.0 MHz, 37.9 kHz, 60.3 Hz (II) NV(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (**) NV(0): *Driver mode "800x600": 36.0 MHz, 35.2 kHz, 56.2 Hz (II) NV(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (**) NV(0): *Default mode "800x600": 40.0 MHz, 37.9 kHz, 60.3 Hz (II) NV(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (**) NV(0): *Default mode "800x600": 36.0 MHz, 35.2 kHz, 56.2 Hz (II) NV(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (**) NV(0): *Driver mode "640x480": 25.2 MHz, 31.5 kHz, 59.9 Hz (II) NV(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (**) NV(0): *Default mode "640x480": 25.2 MHz, 31.5 kHz, 59.9 Hz (II) NV(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (**) NV(0): *Default mode "512x384": 32.5 MHz, 48.4 kHz, 60.0 Hz (D) (II) NV(0): Modeline "512x384"x60.0 32.50 512 524 592 672 384 385 388 403 doublescan -hsync -vsync (48.4 kHz) (**) NV(0): *Default mode "400x300": 20.0 MHz, 37.9 kHz, 60.3 Hz (D) (II) NV(0): Modeline "400x300"x60.3 20.00 400 420 484 528 300 300 302 314 doublescan +hsync +vsync (37.9 kHz) (**) NV(0): *Default mode "400x300": 18.0 MHz, 35.2 kHz, 56.3 Hz (D) (II) NV(0): Modeline "400x300"x56.3 18.00 400 412 448 512 300 300 301 312 doublescan +hsync +vsync (35.2 kHz) (**) NV(0): *Default mode "320x240": 12.6 MHz, 31.5 kHz, 60.1 Hz (D) (II) NV(0): Modeline "320x240"x60.1 12.59 320 328 376 400 240 245 246 262 doublescan -hsync -vsync (31.5 kHz) (**) NV(0): Display dimensions: (410, 260) mm (**) NV(0): DPI set to (89, 87) (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/lib/xorg/modules//libfb.so (II) Module fb: vendor="X.Org Foundation" compiled for 1.5.3, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.4 (II) Loading sub module "xaa" (II) LoadModule: "xaa" (II) Loading /usr/lib/xorg/modules//libxaa.so (II) Module xaa: vendor="X.Org Foundation" compiled for 1.5.3, module version = 1.2.0 ABI class: X.Org Video Driver, version 4.1 (II) Loading sub module "ramdac" (II) LoadModule: "ramdac" (II) Module "ramdac" already built-in (--) Depth 24 pixmap format is 32 bpp (II) do I need RAC? No, I don't. (II) resource ranges after preInit: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [5] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [6] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [7] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [8] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [9] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [10] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [11] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [12] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [13] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [14] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [15] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [16] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [17] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [18] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [19] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [20] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [21] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [22] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [23] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [24] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [25] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [26] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [27] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [28] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [29] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [30] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [31] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [32] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [33] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [34] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [35] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] (II) NV(0): Memory manager initialized to (0,0) (1440,23199) (II) NV(0): Reserved area from (0,900) to (1440,962) (II) NV(0): Using XFree86 Acceleration Architecture (XAA) Screen to screen bit blits Solid filled rectangles 8x8 mono pattern filled rectangles Indirect CPU to Screen color expansion Solid Lines Scanline Image Writes Setting up tile and stipple cache: 32 128x128 slots 32 256x256 slots 16 512x512 slots (==) NV(0): Backing store disabled (==) NV(0): Silken mouse enabled (**) Option "dpms" (**) NV(0): DPMS enabled (==) RandR enabled (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE (II) Initializing built-in extension XEVIE (II) AIGLX: Screen 0 is not DRI capable (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so (II) GLX: Initialized DRISWRAST GL provider for screen 0 (II) config/hal: Adding input device ImPS/2 Generic Wheel Mouse (II) LoadModule: "evdev" (II) Loading /usr/lib/xorg/modules/input//evdev_drv.so (II) Module evdev: vendor="X.Org Foundation" compiled for 1.5.3, module version = 2.1.3 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 2.1 (**) ImPS/2 Generic Wheel Mouse: always reports core events (**) ImPS/2 Generic Wheel Mouse: Device: "/dev/input/event4" (II) ImPS/2 Generic Wheel Mouse: Found 3 mouse buttons (II) ImPS/2 Generic Wheel Mouse: Found x and y relative axes (II) ImPS/2 Generic Wheel Mouse: Configuring as mouse (**) ImPS/2 Generic Wheel Mouse: YAxisMapping: buttons 4 and 5 (**) ImPS/2 Generic Wheel Mouse: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 (II) XINPUT: Adding extended input device "ImPS/2 Generic Wheel Mouse" (type: MOUSE) (II) config/hal: Adding input device Macintosh mouse button emulation (**) Macintosh mouse button emulation: always reports core events (**) Macintosh mouse button emulation: Device: "/dev/input/event2" (II) Macintosh mouse button emulation: Found 3 mouse buttons (II) Macintosh mouse button emulation: Found x and y relative axes (II) Macintosh mouse button emulation: Configuring as mouse (**) Macintosh mouse button emulation: YAxisMapping: buttons 4 and 5 (**) Macintosh mouse button emulation: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 (II) XINPUT: Adding extended input device "Macintosh mouse button emulation" (type: MOUSE) (II) config/hal: Adding input device Power Button (FF) (**) Power Button (FF): always reports core events (**) Power Button (FF): Device: "/dev/input/event0" (II) Power Button (FF): Found keys (II) Power Button (FF): Configuring as keyboard (II) XINPUT: Adding extended input device "Power Button (FF)" (type: KEYBOARD) (**) Option "xkb_rules" "evdev" (**) Option "xkb_model" "pc105+inet" (**) Option "xkb_layout" "us" (II) config/hal: Adding input device AT Translated Set 2 keyboard (**) AT Translated Set 2 keyboard: always reports core events (**) AT Translated Set 2 keyboard: Device: "/dev/input/event3" (II) AT Translated Set 2 keyboard: Found keys (II) AT Translated Set 2 keyboard: Configuring as keyboard (II) XINPUT: Adding extended input device "AT Translated Set 2 keyboard" (type: KEYBOARD) (**) Option "xkb_rules" "evdev" (**) Option "xkb_model" "pc105+inet" (**) Option "xkb_layout" "us" (II) config/hal: Adding input device Power Button (CM) (**) Power Button (CM): always reports core events (**) Power Button (CM): Device: "/dev/input/event1" (II) Power Button (CM): Found keys (II) Power Button (CM): Configuring as keyboard (II) XINPUT: Adding extended input device "Power Button (CM)" (type: KEYBOARD) (**) Option "xkb_rules" "evdev" (**) Option "xkb_model" "pc105+inet" (**) Option "xkb_layout" "us" (II) ImPS/2 Generic Wheel Mouse: Close (II) UnloadModule: "evdev" (II) Macintosh mouse button emulation: Close (II) UnloadModule: "evdev" (II) Power Button (FF): Close (II) UnloadModule: "evdev" (II) AT Translated Set 2 keyboard: Close (II) UnloadModule: "evdev" (II) Power Button (CM): Close (II) UnloadModule: "evdev" ==== xorg.conf ==== # Xorg configuration created by system-config-display Section "ServerLayout" Identifier "single head configuration" Screen 0 "Screen0" 0 0 InputDevice "Keyboard0" "CoreKeyboard" EndSection Section "InputDevice" # keyboard added by rhpxl Identifier "Keyboard0" Driver "kbd" Option "XkbModel" "pc105" Option "XkbLayout" "us+inet" EndSection Section "Monitor" Identifier "Monitor0" ModelName "LCD Panel 1440x900" HorizSync 31.5 - 56.0 VertRefresh 56.0 - 65.0 Option "dpms" EndSection Section "Device" Identifier "Videocard0" Driver "nv" EndSection Section "Screen" Identifier "Screen0" Device "Videocard0" Monitor "Monitor0" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSection ==== /etc/sysconfig/desktop ==== DISPLAYMANAGER=GNOME There are no error lines in the X log and no clues in messages. This machine was running X without a problem before the upgrade. Regards, Gerry From awilliam at redhat.com Thu May 7 19:31:30 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 07 May 2009 12:31:30 -0700 Subject: removing KDE removes NetworkManager-gnome?? In-Reply-To: References: <4A030058.3020107@gnat.ca> <4A030BDF.9060903@gnat.ca> <4A031261.8080505@gnat.ca> <1241716345.2923.496.camel@adam.local.net> Message-ID: <1241724690.2923.502.camel@adam.local.net> On Thu, 2009-05-07 at 13:02 -0500, Rex Dieter wrote: > Adam Williamson wrote: > > > Phonon configured to use its gstreamer backend by default. > > phonon-backend-xine is (still) the default, though phonon-backend-gstreamer > will happily be used instead if it's the only backend installed and > available. OK, then I guess that's not why a gstreamer package is in the KDE dependencies :) do you know why that is? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From rc040203 at freenet.de Fri May 8 02:30:37 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 08 May 2009 04:30:37 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <23753.1241723730@sss.pgh.pa.us> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> Message-ID: <4A03994D.6000004@freenet.de> Tom Lane wrote: > Jesse Keating writes: >> How is it we have 182 stable updates pending for F11 already? > > What do you expect, when the release freeze policy essentially forbids > any noncritical updates for a month? People don't stop working just > because releng wants to simplify their own lives. > > The only reason there aren't 184 is I haven't bothered to try to > push my pending updates for mysql and postgresql ... but they'll > be in the zero-day update queue just like a lot of other things. Exactly, ... Keating's complaint is just a side-effect of the Fedora bureaucracy and the freezes. Unlike before, when the nasty side-effects of the freezes solely hit the packagers they now are hitting him ... One work-around seems obivous to me: Launch updates/f11 and testing/f11 repos now. Ralf From jkeating at redhat.com Fri May 8 02:59:26 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 07 May 2009 19:59:26 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <4A038D53.7040200@redhat.com> References: <1241718097.3209.11.camel@localhost.localdomain> <4A033B7F.1030801@redhat.com> <4A0348D3.8000302@gmail.com> <4A038D53.7040200@redhat.com> Message-ID: <1241751566.3209.69.camel@localhost.localdomain> On Thu, 2009-05-07 at 15:39 -1000, David Cantrell wrote: > What would be nice is an integration to the bodhi comments/karma system > from bugzilla. The users already use bugzilla and read that throughout > the process of solving a problem. Having them go to an entirely > different site to leave a comment that says, "works for me" is sort of > annoying from a user's point of view. If we could make that easier for > them, maybe we'd see more automatic updates pushing. Once I get my message bus in place, interaction between the tools at this level could be possible. A specific keyword or phrase added to a bug that bodhi knows about could be echoed into bodhi karma. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From greno at verizon.net Fri May 8 03:05:08 2009 From: greno at verizon.net (Gerry Reno) Date: Thu, 07 May 2009 23:05:08 -0400 Subject: F11 Preview: cannot start X In-Reply-To: <4A038DC5.1000803@verizon.net> References: <4A038DC5.1000803@verizon.net> Message-ID: <4A03A164.2010403@verizon.net> Removed and reinstalled the nvidia driver and X starts now. Regards, Gerry From rc040203 at freenet.de Fri May 8 03:12:28 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 08 May 2009 05:12:28 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241733287.3209.61.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <645d17210905071452n7da5f852s8bfc5d808a04c56b@mail.gmail.com> <1241733287.3209.61.camel@localhost.localdomain> Message-ID: <4A03A31C.4010003@freenet.de> Jesse Keating wrote: > On Thu, 2009-05-07 at 22:52 +0100, Jonathan Underwood wrote: >> Related to that, the release freeze essentially prevents bugfix >> package updates to previous releases, since pushing an updated package >> with a later version number to eg. F-10 will then break the update >> path to F-11. Is there a recommended way around this problem I am >> missing? > > Frankly I'd ignore it. > A week after F11 goes GA the update paths will > all be broken anyway. 1. It already is 2. It doesn't have to be that way IMO, a significant portion of such issues is caused by rel-eng's freeze and defects in fedora's work-flow. From jkeating at redhat.com Fri May 8 03:42:13 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 07 May 2009 20:42:13 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <4A03A31C.4010003@freenet.de> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <645d17210905071452n7da5f852s8bfc5d808a04c56b@mail.gmail.com> <1241733287.3209.61.camel@localhost.localdomain> <4A03A31C.4010003@freenet.de> Message-ID: <1241754133.3209.71.camel@localhost.localdomain> On Fri, 2009-05-08 at 05:12 +0200, Ralf Corsepius wrote: > 1. It already is > 2. It doesn't have to be that way > > IMO, a significant portion of such issues is caused by rel-eng's freeze > and defects in fedora's work-flow. The cut images will always remain stagnant, the rpms not changing. So long as we allow updates to previous releases to be n-v-r higher than the GA versions of the next release, we will always have a broken upgrade path from N-1+updates to N. Are you suggesting some distro release level super epoch? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bkoz at redhat.com Fri May 8 03:25:50 2009 From: bkoz at redhat.com (Benjamin Kosnik) Date: Thu, 7 May 2009 20:25:50 -0700 Subject: f12 boost-1.39.0 upgrade: pushed Message-ID: <20090507202550.06a92734@mcgee.artheist.org> The boost maintainers have updated the boost package to the current release (1.39.0) in rawhide for F12. Rebuilds for devel packages that require boost are mandatory, as SONAME was bumped. In addition, BuildRequires for boost packages may now be specified with finer granularity. Help from other package maintainerswith rebuilding is appreciated. -benjamin _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From jonstanley at gmail.com Fri May 8 03:43:53 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Thu, 7 May 2009 23:43:53 -0400 Subject: Plan for tomorrow's (20090508) FESCo meeting Message-ID: Sorry for the agenda delay, I was waiting for updates on a brewing topic that I scrapped from this weeks agenda (but look for a special treat next week!) 143 F12 schedule 64 liblvm - https://fedoraproject.org/wiki/Features/liblvm For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor. From rc040203 at freenet.de Fri May 8 04:05:40 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 08 May 2009 06:05:40 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241754133.3209.71.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <645d17210905071452n7da5f852s8bfc5d808a04c56b@mail.gmail.com> <1241733287.3209.61.camel@localhost.localdomain> <4A03A31C.4010003@freenet.de> <1241754133.3209.71.camel@localhost.localdomain> Message-ID: <4A03AF94.60605@freenet.de> Jesse Keating wrote: > On Fri, 2009-05-08 at 05:12 +0200, Ralf Corsepius wrote: >> 1. It already is >> 2. It doesn't have to be that way >> >> IMO, a significant portion of such issues is caused by rel-eng's freeze >> and defects in fedora's work-flow. > > The cut images will always remain stagnant, the rpms not changing. So > long as we allow updates to previous releases to be n-v-r higher than > the GA versions of the next release, we will always have a broken > upgrade path from N-1+updates to N. > > Are you suggesting some distro release level super epoch? I am suggesting that you implement rawhide/testing, f11/testing and f11/updates right now and get rid of "trac" (replace buildroot overrides with button in koji or treat "push to stable" as "buildroot overrides"). This would resolve several issues packagers have been facing (and now hit you) at once. In particular would it help * to prevent packages from queuing up on the packager's side, which would have been released very soon/immediately after GA in any case. * to prevent NEVR issues resulting from F-9, F-10 and F-12 being open, while F-11 is frozen. * rawhide/testing would also help wrt. test rawhide for experimental/unsafe stuff, which would help improving stability when rel-eng brands a rawhide snapshot "Fedora release". There would be one major difference: rel-eng, would have to herry-pick and move around packages between F11 GA and F11/updates before the release. Ralf From jkeating at redhat.com Fri May 8 04:19:35 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 07 May 2009 21:19:35 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <4A03AF94.60605@freenet.de> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <645d17210905071452n7da5f852s8bfc5d808a04c56b@mail.gmail.com> <1241733287.3209.61.camel@localhost.localdomain> <4A03A31C.4010003@freenet.de> <1241754133.3209.71.camel@localhost.localdomain> <4A03AF94.60605@freenet.de> Message-ID: <1241756375.3209.76.camel@localhost.localdomain> On Fri, 2009-05-08 at 06:05 +0200, Ralf Corsepius wrote: > I am suggesting that you implement rawhide/testing, f11/testing and > f11/updates right now and get rid of "trac" (replace buildroot overrides > with button in koji or treat "push to stable" as "buildroot overrides"). I eventually do want to have the ability for maintainers to self service buildroot overrides. We just don't have the code in place, nor enough people to work on the code while we work on other things too. Although while we're trying to finish up a release, I would ask where we should publish the next rawhide, or what you mean by rawhide/testing. > > This would resolve several issues packagers have been facing (and now > hit you) at once. > > In particular would it help > * to prevent packages from queuing up on the packager's side, which > would have been released very soon/immediately after GA in any case. We're going to be pushing an initial set of F11 updates in the next day or so. > * to prevent NEVR issues resulting from F-9, F-10 and F-12 being open, > while F-11 is frozen. Won't help at all, as the F11 release repo doesn't change, nor do the contents of the DVD, so F9/10 will always move ahead of the release. > > * rawhide/testing would also help wrt. test rawhide for > experimental/unsafe stuff, which would help improving stability when > rel-eng brands a rawhide snapshot "Fedora release". So you want a rawhide, and a rawerhide? > > There would be one major difference: rel-eng, would have to herry-pick > and move around packages between F11 GA and F11/updates before the release. We already do that based on maintainers and testers who propose and test packages during freezes. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Fri May 8 04:56:04 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 08 May 2009 06:56:04 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241756375.3209.76.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <645d17210905071452n7da5f852s8bfc5d808a04c56b@mail.gmail.com> <1241733287.3209.61.camel@localhost.localdomain> <4A03A31C.4010003@freenet.de> <1241754133.3209.71.camel@localhost.localdomain> <4A03AF94.60605@freenet.de> <1241756375.3209.76.camel@localhost.localdomain> Message-ID: <4A03BB64.10006@freenet.de> Jesse Keating wrote: > On Fri, 2009-05-08 at 06:05 +0200, Ralf Corsepius wrote: >> I am suggesting that you implement rawhide/testing, f11/testing and >> f11/updates right now and get rid of "trac" (replace buildroot overrides >> with button in koji or treat "push to stable" as "buildroot overrides"). > > I eventually do want to have the ability for maintainers to self service > buildroot overrides. We just don't have the code in place, nor enough > people to work on the code while we work on other things too. > > Although while we're trying to finish up a release, I would ask where we > should publish the next rawhide, or what you mean by rawhide/testing. > >> This would resolve several issues packagers have been facing (and now >> hit you) at once. >> >> In particular would it help >> * to prevent packages from queuing up on the packager's side, which >> would have been released very soon/immediately after GA in any case. > > We're going to be pushing an initial set of F11 updates in the next day > or so. Why has this not be done earlier? I am already facing a pretty nice package queue jam on my part because F11 is frozen and hasn't received any update for some time. None of these updates are critical nevertheless they contain bug fixes and are prerequisites for future development. >> * to prevent NEVR issues resulting from F-9, F-10 and F-12 being open, >> while F-11 is frozen. > > Won't help at all, as the F11 release repo doesn't change, nor do the > contents of the DVD, so F9/10 will always move ahead of the release. You are missing the point: F11 updates would be open NOW! F11 GA development would be decoupled from F11 updates! rel-eng would cherry-pick the packages they want to put on CD/DVD, while F11 updates would move on and would already carry what otherwise would hit GA after "release". >> * rawhide/testing would also help wrt. test rawhide for >> experimental/unsafe stuff, which would help improving stability when >> rel-eng brands a rawhide snapshot "Fedora release". > > So you want a rawhide, and a rawerhide? Neither, all I am saying is that your work flow _is not designed to help stability_, but encourages prematurely shipping broken/untested "crap stuff". This consideration shows, when packages are being added to rawhide or undergo substanticial changes, right before your freeze. You end up with untested/likely broken packages in your release and with Fedora releases which are not much more than "rawhide snapshots", and CD/DVDs which aren't worth using. >> There would be one major difference: rel-eng, would have to herry-pick >> and move around packages between F11 GA and F11/updates before the release. > > We already do that based on maintainers and testers who propose and test > packages during freezes. As having been said many times before: You can't and will never be able to so - You are cheating to yourselves, all you can do is to test for very few, very isolated issues, on packages you are familiar with. Ralf From Fedora at FamilleCollet.com Fri May 8 06:33:32 2009 From: Fedora at FamilleCollet.com (Remi Collet) Date: Fri, 08 May 2009 08:33:32 +0200 Subject: Fedora 11 + rpm 4.7.0 + mock EL5 issue Message-ID: <4A03D23C.8080206@FamilleCollet.com> Hi, I'm used to build a lot of RPM from my Fedora box, especially for EL 5 But if I create the .src.rpm in F11 (rpm 4.7.0), mock is unable to install it (rpm 4.4.2) because it couldn't check new default checksum. A workaround is to first mock for F10 and then use the new .src.rpm I'm searching for a way to build .src.rpm using old checksum behavior, but I don't find any solution Any idea welcome. Remi. From dimi at lattica.com Fri May 8 06:34:16 2009 From: dimi at lattica.com (Dimi Paun) Date: Fri, 08 May 2009 02:34:16 -0400 Subject: Another update, another reboot, no sound! In-Reply-To: <20d6441a0905071448o10cb4928r4cab031966284aac@mail.gmail.com> References: <1241728409.7634.21.camel@dimi.lattica.com> <20090507214017.GA9824@tango.0pointer.de> <20d6441a0905071448o10cb4928r4cab031966284aac@mail.gmail.com> Message-ID: <1241764456.7634.49.camel@dimi.lattica.com> On Thu, 2009-05-07 at 16:48 -0500, Jud Craft wrote: > Try going into Skype's Options -> Audio Options. Thanks, but I've spent hours in that dialog :) > Perhaps Skype can't figure out what sound device to use. Make sure > it's set to "PulseAudio", and then try a test call. If there are > other devices in that list, you could try each one until you get it to > work. There's only a few of them. > > An inconvenience, yes. If this does not work, then you may have > deeper troubles. It never worked properly with "pulse" as a sound device for me. The problem is that it used to work _only_ via my USB headphones, but not anymore... > I have no ideas for VirtualBox, don't use it. From what I hear, > virtualized sound is an entirely different can of worms, and I'm not > surprised it doesn't work. That one I tested a few days ago, it was working just fine. Once again, it broke just now. Isn't F11 close to the official release? Why does the sound keep breaking that late in the game? -- Dimi Paun Lattica, Inc. From lemenkov at gmail.com Fri May 8 07:07:01 2009 From: lemenkov at gmail.com (Peter Lemenkov) Date: Fri, 8 May 2009 11:07:01 +0400 Subject: Another update, another reboot, no sound! In-Reply-To: <1241728409.7634.21.camel@dimi.lattica.com> References: <1241728409.7634.21.camel@dimi.lattica.com> Message-ID: 2009/5/8 Dimi Paun : > This is getting ridiculous! > > I had running sound, and today I've updated my system. > Right away, my sound was b0rken: http://peter.fedorapeople.org/alsa_advicedog.png -- With best regards! From caolanm at redhat.com Fri May 8 07:20:34 2009 From: caolanm at redhat.com (=?ISO-8859-1?Q?Caol=E1n?= McNamara) Date: Fri, 08 May 2009 08:20:34 +0100 Subject: OpenOffice 3.1 In-Reply-To: <4A034FD0.40103@gnat.ca> References: <4A034FD0.40103@gnat.ca> Message-ID: <1241767234.2551.1304.camel@Vain> On Thu, 2009-05-07 at 15:17 -0600, Nathanael D. Noblet wrote: > Hello, > Normally I'm quite happy to wait for new releases upstream to trickle > into fedora, however in this case, I'd LOVE to know if 3.1 fixes an > issue with OO over samba. Without details of the problem its hard to say, though 3.1 does have an alternative file locking implementation grafted on, so if the problem was file-locking related, 3.1 might fix your problem. Though it does matter of course how you're working over samba, whether mounted as a filesystem or through gio/gvfs. i.e. it might even be nothing to do really with OOo, but something else in the stack and it won't matter what version of OOo is used. > So are there plans to update f10 OpenOffice to 3.1? No, no such plans. C. From debarshi.ray at gmail.com Fri May 8 07:21:17 2009 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Fri, 8 May 2009 12:51:17 +0530 Subject: Requires: %{_libdir}/pkgconfig In-Reply-To: <1241738823.21520.33.camel@ns.five-ten-sg.com> References: <20090507172623.32d7e9ad@faldor.intranet> <1241738823.21520.33.camel@ns.five-ten-sg.com> Message-ID: <3170f42f0905080021v1879f66rabec0e486b65dc9e@mail.gmail.com> These days RPM automatically adds a dependency on /usr/bin/pkg-config. So in most cases where a package provides a *.pc file it should not be required to manually add the runtime dependency. Cheerio, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig From pbrobinson at gmail.com Fri May 8 07:52:00 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Fri, 8 May 2009 08:52:00 +0100 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241720858.3209.15.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <20090507121126.4ebb7f29@ohm.scrye.com> <1241720858.3209.15.camel@localhost.localdomain> Message-ID: <5256d0b0905080052q1d303724p6ff88504967a87f4@mail.gmail.com> >> They are an update from 4.6.0 to 4.6.1. >> These updates are mostly translation fixes, along with a very few minor >> bug fixes. >> >> http://mocha.xfce.org/documentation/changelogs/4.6.1 >> >> I have been running them here since the day they came out with no >> problems at all. Also upstream there are not much in the way of bug >> reports, so I thought they should be ok to move to stable. >> >> I suppose I should have left them in testing for a bit, but also many >> people will expect a newly released fedora to have the latest version >> available, especially if they are in a locale that got updated. > > This seems pretty reasonable. ?I'd be more comfortable if a few more > people on F11's rawhide tried them, but *shrug*. Surely that would be a reason to get it tagged into F11 final (the new locale that is) if other than that its only a minor package with little risk. That way it would be available straight up as well as not requiring the package to be downloaded twice. Peter From mschwendt at gmail.com Fri May 8 07:58:14 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 8 May 2009 09:58:14 +0200 Subject: Requires: %{_libdir}/pkgconfig In-Reply-To: <3170f42f0905080021v1879f66rabec0e486b65dc9e@mail.gmail.com> References: <20090507172623.32d7e9ad@faldor.intranet> <1241738823.21520.33.camel@ns.five-ten-sg.com> <3170f42f0905080021v1879f66rabec0e486b65dc9e@mail.gmail.com> Message-ID: <20090508095814.558c61ec@faldor.intranet> On Fri, 8 May 2009 12:51:17 +0530, Debarshi wrote: > These days RPM automatically adds a dependency on /usr/bin/pkg-config. > So in most cases where a package provides a *.pc file it should not be > required to manually add the runtime dependency. > > Cheerio, > Debarshi "These days" translates to "Fedora >= 11". Packagers who push mass-dist-updates should not eliminate their manual "Requires: pkgconfig" yet. The /usr/bin/* file entries can be found in the primary metadata, so dependencies on them are not as expensive as other file paths. From debarshi.ray at gmail.com Fri May 8 08:08:05 2009 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Fri, 8 May 2009 13:38:05 +0530 Subject: Requires: %{_libdir}/pkgconfig In-Reply-To: <20090508095814.558c61ec@faldor.intranet> References: <20090507172623.32d7e9ad@faldor.intranet> <1241738823.21520.33.camel@ns.five-ten-sg.com> <3170f42f0905080021v1879f66rabec0e486b65dc9e@mail.gmail.com> <20090508095814.558c61ec@faldor.intranet> Message-ID: <3170f42f0905080108m26a8b93bgadca9f64e3c08d01@mail.gmail.com> > "These days" translates to "Fedora >= 11". Packagers who push mass-dist-updates > should not eliminate their manual "Requires: pkgconfig" yet. That is why I enclose the pkg-config related lines in a conditional block that evaluates to true only for Fedora 9 and Fedora 10. Cheers, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig From pbrobinson at gmail.com Fri May 8 08:21:30 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Fri, 8 May 2009 09:21:30 +0100 Subject: Moblin 2 and Fedora In-Reply-To: <1241710118.2923.481.camel@adam.local.net> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <1233598383.7493.42.camel@localhost.localdomain> <20090202113524.184e402c@infradead.org> <20090503160827.GA21833@srcf.ucam.org> <1241449115.2766.148.camel@atropine.boston.devel.redhat.com> <49FF0A69.8030609@fedoraproject.org> <1241462009.8638.5.camel@localhost.localdomain> <20090504125251.41e491a6@infradead.org> <1241705174.3088.2.camel@localhost.localdomain> <1241710118.2923.481.camel@adam.local.net> Message-ID: <5256d0b0905080121l78175c2ehb9e6e15e23f46386@mail.gmail.com> >> Seriously, is that team even *part* of Intel? ?Because the Poulsbo Linux >> team is completely different than any of the other Intel Linux teams >> I've had the actual pleasure of interacting with. > > At least originally, no, they weren't. Intel contracted the Poulsbo > driver development out to another company (which has since itself been > bought out by VMware). Now, however, it isn't clear if it's those guys > or guys who really are with Intel or what who are doing whatever > development is actually happening. > > I suspect what may be happening is the original group is continuing to > work on the crack-addled drivers that show up in the Ubuntu repos from > time to time, while a different group works on creating a > non-crack-addled driver that'll be sent through the proper processes. > But that's just my guess, as no-one at Intel seems to want to say > anything. Isn't the Poulsbo GPU based on a powerVR core that Intel licensed? That might explain some of the crack. Peter From paul at city-fan.org Fri May 8 08:49:57 2009 From: paul at city-fan.org (Paul Howarth) Date: Fri, 08 May 2009 09:49:57 +0100 Subject: Fedora 11 + rpm 4.7.0 + mock EL5 issue In-Reply-To: <4A03D23C.8080206@FamilleCollet.com> References: <4A03D23C.8080206@FamilleCollet.com> Message-ID: <4A03F235.6090006@city-fan.org> Remi Collet wrote: > Hi, > > I'm used to build a lot of RPM from my Fedora box, especially for EL 5 > > But if I create the .src.rpm in F11 (rpm 4.7.0), mock is unable to > install it (rpm 4.4.2) because it couldn't check new default checksum. > > A workaround is to first mock for F10 and then use the new .src.rpm > > I'm searching for a way to build .src.rpm using old checksum behavior, > but I don't find any solution > > Any idea welcome. Try adding this to your ~/.rpmmacros # Use MD5 hashes for cross-release compatibility %_source_filedigest_algorithm 0 %_binary_filedigest_algorithm 0 Paul. From mhlavink at redhat.com Fri May 8 08:59:19 2009 From: mhlavink at redhat.com (Michal Hlavinka) Date: Fri, 8 May 2009 10:59:19 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <23753.1241723730@sss.pgh.pa.us> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> Message-ID: <200905081059.20191.mhlavink@redhat.com> On Thursday 07 May 2009 21:15:30 Tom Lane wrote: > Jesse Keating writes: > > How is it we have 182 stable updates pending for F11 already? > > What do you expect, when the release freeze policy essentially forbids > any noncritical updates for a month? People don't stop working just > because releng wants to simplify their own lives. > > The only reason there aren't 184 is I haven't bothered to try to > push my pending updates for mysql and postgresql ... but they'll > be in the zero-day update queue just like a lot of other things. > > regards, tom lane I really agree with this. I think we need F11/updates and F11/updates-testing soon after devel freeze. You get bugs reported for snapshots, previews,... but fixing these bugs and especially delivering them to users is too much difficult imho. In my dreamworld we have rawhide -> F11, F11/updates, F11/updates-testing in a few days after devel freeze. I think at least F11/updates-testing (without F11/updates available before day or two ago F11 GA) would be really appreciated by developers. Regards, Michal Hlavinka From mhlavink at redhat.com Fri May 8 09:19:23 2009 From: mhlavink at redhat.com (Michal Hlavinka) Date: Fri, 8 May 2009 11:19:23 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <200905081059.20191.mhlavink@redhat.com> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <200905081059.20191.mhlavink@redhat.com> Message-ID: <200905081119.24124.mhlavink@redhat.com> On Friday 08 May 2009 10:59:19 Michal Hlavinka wrote: > On Thursday 07 May 2009 21:15:30 Tom Lane wrote: > > Jesse Keating writes: > > > How is it we have 182 stable updates pending for F11 already? > > > > What do you expect, when the release freeze policy essentially forbids > > any noncritical updates for a month? People don't stop working just > > because releng wants to simplify their own lives. > > > > The only reason there aren't 184 is I haven't bothered to try to > > push my pending updates for mysql and postgresql ... but they'll > > be in the zero-day update queue just like a lot of other things. > > > > regards, tom lane > > I really agree with this. I think we need F11/updates and > F11/updates-testing soon after devel freeze. You get bugs reported for > snapshots, previews,... but fixing these bugs and especially delivering > them to users is too much difficult imho. > > In my dreamworld we have rawhide -> F11, F11/updates, F11/updates-testing > in a few days after devel freeze. I think at least F11/updates-testing > (without F11/updates available before day or two ago F11 GA) would be > really appreciated by developers. > > Regards, > Michal Hlavinka and one real life experience: I'd like to upgrade to F11 snapshost / preview /... but when I'll found some bug, it'll be fixed in F10 sooner than in F11. Not only this, but I'll have to wait *one month* before I get these fixes! (Yes, I can download them from koji, but I'd like to have fixed also bugs reported by other users/testers.) /me thinks there is something wrong here... From Fedora at FamilleCollet.com Fri May 8 10:39:45 2009 From: Fedora at FamilleCollet.com (Remi Collet) Date: Fri, 08 May 2009 12:39:45 +0200 Subject: Fedora 11 + rpm 4.7.0 + mock EL5 issue In-Reply-To: <4A03F235.6090006@city-fan.org> References: <4A03D23C.8080206@FamilleCollet.com> <4A03F235.6090006@city-fan.org> Message-ID: <4A040BF1.9060908@FamilleCollet.com> Le 08/05/2009 10:49, Paul Howarth a ?crit : > Try adding this to your ~/.rpmmacros > > # Use MD5 hashes for cross-release compatibility > %_source_filedigest_algorithm 0 > %_binary_filedigest_algorithm 0 Thanks for this :) I will use (to not change my F11 rpm, but only my .src.rpm) rpmbuild -bs \ --define "_source_filedigest_algorithm 0" \ --define "_binary_filedigest_algorithm 0" \ foo.spec And yes, it's work. Thanks again. Remi From erik at vanpienbroek.nl Fri May 8 10:57:48 2009 From: erik at vanpienbroek.nl (Erik van Pienbroek) Date: Fri, 08 May 2009 12:57:48 +0200 Subject: Fedora 11 + rpm 4.7.0 + mock EL5 issue In-Reply-To: <4A03D23C.8080206@FamilleCollet.com> References: <4A03D23C.8080206@FamilleCollet.com> Message-ID: <1241780269.7012.12.camel@alguno.terneuzen.openftd.org> Op vrijdag 08-05-2009 om 08:33 uur [tijdzone +0200], schreef Remi Collet: > I'm searching for a way to build .src.rpm using old checksum behavior, > but I don't find any solution Speaking of which, yum repositories created with the latest version of createrepo can't be used by CentOS 5. When trying to install packages from such a repo it will always fail due to a failed checksum verification. On closer inspection, I've found out that the repodata/primary.xml.gz file now contains SHA256 hashes while previously it was regular SHA. The 'createrepo' tool has an option to use a different checksum method (-s SUMTYPE / --checksum=SUMTYPE), but it doesn't seem to have any effect nowadays. I've read somewhere that this option has been deprecated. Does anybody know how to create a yum repository containing SHA hashes for verification using the tools from F11 ? Thanks in advance, Erik van Pienbroek From Fedora at FamilleCollet.com Fri May 8 11:14:48 2009 From: Fedora at FamilleCollet.com (Remi Collet) Date: Fri, 08 May 2009 13:14:48 +0200 Subject: Fedora 11 + rpm 4.7.0 + mock EL5 issue In-Reply-To: <1241780269.7012.12.camel@alguno.terneuzen.openftd.org> References: <4A03D23C.8080206@FamilleCollet.com> <1241780269.7012.12.camel@alguno.terneuzen.openftd.org> Message-ID: <4A041428.7030508@FamilleCollet.com> Le 08/05/2009 12:57, Erik van Pienbroek a ?crit : > Does anybody know how to create a yum repository containing SHA hashes > for verification using the tools from F11 ? You must use the latest createrepo-0.9.7-7.fc12 See : https://bugzilla.redhat.com/show_bug.cgi?id=498767 https://bugzilla.redhat.com/show_bug.cgi?id=494951 Remi. From jonathan.underwood at gmail.com Fri May 8 11:17:17 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 8 May 2009 12:17:17 +0100 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241754133.3209.71.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <645d17210905071452n7da5f852s8bfc5d808a04c56b@mail.gmail.com> <1241733287.3209.61.camel@localhost.localdomain> <4A03A31C.4010003@freenet.de> <1241754133.3209.71.camel@localhost.localdomain> Message-ID: <645d17210905080417v4b82870akf9c00bb1009a1607@mail.gmail.com> 2009/5/8 Jesse Keating : > On Fri, 2009-05-08 at 05:12 +0200, Ralf Corsepius wrote: >> 1. It already is >> 2. It doesn't have to be that way >> >> IMO, a significant portion of such issues is caused by rel-eng's freeze >> and defects in fedora's work-flow. > > The cut images will always remain stagnant, the rpms not changing. ?So > long as we allow updates to previous releases to be n-v-r higher than > the GA versions of the next release, we will always have a broken > upgrade path from N-1+updates to N. > I've always assumed that we're supposed to try and not break the upgrade path for (N-1+updatesForN-1) to (N+updatesForN). Is that not the case? > Are you suggesting some distro release level super epoch? > I've often wondered why we don't have such a thing, but I've always noticed that discussions around these sorts of ideas usually become a bit of a flame fest. J. From markmc at redhat.com Fri May 8 12:24:05 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 08 May 2009 13:24:05 +0100 Subject: Fedora Release Engineering Meeting Recap - 2009-05-04 In-Reply-To: <1241729779.3209.27.camel@localhost.localdomain> References: <20090504200148.GB3699@nostromo.devel.redhat.com> <4A01866E.8060201@redhat.com> <1241625397.3030.59.camel@localhost.localdomain> <4A0222B2.5020705@redhat.com> <1241654675.3030.80.camel@localhost.localdomain> <4A034171.8050803@redhat.com> <1241729779.3209.27.camel@localhost.localdomain> Message-ID: <1241785445.16904.13.camel@blaa> On Thu, 2009-05-07 at 13:56 -0700, Jesse Keating wrote: > The freeze override process exists to add a filter between developer and > repo to catch the obvious and to help maintainers think a moment about > what they're doing and whether it's acceptable to do in a freeze period. I think this works well. It forces one briefly explain the benefit, and justify the risk, of the update. That alone makes it less likely you're going to screw things up with a hugely risky, or low value, update. I'd still like to make the process a little more visible, though. These freeze break requests are fairly central to the development process in the lead up to GA. It should be easier for folks to follow what's going on than running a trac query. > it would make a lot more sense if developers would treat updates to a > release with the same care as they treat updates during a freeze period, > but that's a fight for another day. Agreed. It seems logical that post-GA updates would go through a similar process. It could be as simple as two new fields in bodhi - "Benefit to users" and "Risk of regressions" - and the ability for folks to jump in and say "wait, that doesn't make sense" before an update gets pushed. Cheers, Mark. From markmc at redhat.com Fri May 8 12:31:31 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 08 May 2009 13:31:31 +0100 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <20090507210920.GB9105@amd.home.annexia.org> References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> Message-ID: <1241785891.16904.19.camel@blaa> On Thu, 2009-05-07 at 22:09 +0100, Richard W.M. Jones wrote: > On Thu, May 07, 2009 at 10:41:37AM -0700, Jesse Keating wrote: > > How is it we have 182 stable updates pending for F11 already? How have > > these seen any testing by a wider audience? Are we really just not > > bothering with updates-testing anymore? Do we not care about distro > > stability? > > I'll tell you the three reasons I'm pushing stuff directly to stable: > > (1) New package. > > (2) Update to a new package that I know not many people are using. This (2) is something we should try and figure out, IMHO. Trying to apply the same rules and guidelines to 8k+ packages doesn't work. There is a large set of packages which always should spend some time in updates-testing, but there's an even larger set of packages which it probably doesn't help at all. The same goes for the pre-GA development freeze. Cheers, Mark. From ssorce at redhat.com Fri May 8 12:50:47 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 08 May 2009 08:50:47 -0400 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241785891.16904.19.camel@blaa> References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241785891.16904.19.camel@blaa> Message-ID: <1241787047.10366.2.camel@localhost.localdomain> On Fri, 2009-05-08 at 13:31 +0100, Mark McLoughlin wrote: > On Thu, 2009-05-07 at 22:09 +0100, Richard W.M. Jones wrote: > > On Thu, May 07, 2009 at 10:41:37AM -0700, Jesse Keating wrote: > > > How is it we have 182 stable updates pending for F11 already? How have > > > these seen any testing by a wider audience? Are we really just not > > > bothering with updates-testing anymore? Do we not care about distro > > > stability? > > > > I'll tell you the three reasons I'm pushing stuff directly to stable: > > > > (1) New package. > > > > (2) Update to a new package that I know not many people are using. > > This (2) is something we should try and figure out, IMHO. Trying to > apply the same rules and guidelines to 8k+ packages doesn't work. > > There is a large set of packages which always should spend some time in > updates-testing, but there's an even larger set of packages which it > probably doesn't help at all. The same goes for the pre-GA development > freeze. Fedora Core vs Fedora Extras ... Simo. -- Simo Sorce * Red Hat, Inc * New York From caolanm at redhat.com Fri May 8 12:52:02 2009 From: caolanm at redhat.com (=?ISO-8859-1?Q?Caol=E1n?= McNamara) Date: Fri, 08 May 2009 13:52:02 +0100 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241785891.16904.19.camel@blaa> References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241785891.16904.19.camel@blaa> Message-ID: <1241787122.2551.1309.camel@Vain> On Fri, 2009-05-08 at 13:31 +0100, Mark McLoughlin wrote: > On Thu, 2009-05-07 at 22:09 +0100, Richard W.M. Jones wrote: > > (2) Update to a new package that I know not many people are using. > > This (2) is something we should try and figure out, IMHO. Trying to > apply the same rules and guidelines to 8k+ packages doesn't work. A rough metric of risk = package size * 10 * is in default install * number of packages that depend on it * their size would probably be good enough in most cases to get a feel for how much misery a bad update might trigger and force over a thresh-hold into testing before stable C. From rawhide at fedoraproject.org Fri May 8 12:57:49 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Fri, 8 May 2009 12:57:49 +0000 (UTC) Subject: rawhide report: 20090508 changes Message-ID: <20090508125749.D6E211B8006@releng2.fedora.phx.redhat.com> Compose started at Fri May 8 06:15:05 UTC 2009 Updated Packages: anaconda-11.5.0.51-1.fc11 ------------------------- * Thu May 07 2009 David Cantrell - 11.5.0.51-1 - Don't clear the first partition on any disk with a Mac disk label (#492154). (clumens) - Add detailedMessageWindow to the cmdline class (#499700). (clumens) - Don't traceback when a freespace partition is present (#499662). (clumens) - Do nomodeset when doing xdriver=vesa (ajax) - Fix calculation of smallest PV's size in the lvm dialog. (#493753) (dlehman) - Fix KeyError when partition numbers change during allocation. (#497911) (dlehman) - Update EFI CD booting code in mk-images (pjones) bittorrent-4.4.0-12.fc11 ------------------------ * Fri Apr 24 2009 Paul Howarth 4.4.0-12 - Add icon back in menu entry fedora-logos-11.0.5-1.fc11 -------------------------- * Wed May 06 2009 Ray Strode 11.0.5-1 - Add plymouth "Charge" theme artwork fprintd-0.1-9.git04fd09cfa.fc11 ------------------------------- * Thu May 07 2009 Bastien Nocera 0.1-9.git04fd09cfa - Add /var/lib/fprint to the RPM to avoid SELinux errors (#499513) gcc-4.4.0-4 ----------- * Wed May 06 2009 Jakub Jelinek 4.4.0-4 - update from gcc-4_4-branch - PRs c++/40013, libgcj/39899, libstdc++/39868, libstdc++/39880, libstdc++/39881, libstdc++/39882, libstdc++/39909, middle-end/39937, rtl-optimization/39914, target/39565, testsuite/39769, testsuite/39776, testsuite/39790, testsuite/39807, tree-optimization/39941 - fix phiprop tuplification (#496400, PR tree-optimization/40022) - don't add artificial default case label if switch labels already cover the whole range (PR middle-end/39666) - fix DSE with block reads (PR middle-end/40035) - fix debuginfo for C++ typedef struct {...} T (PR debug/35463) - remove some unnecessary padding on x86_64/i386 added for >= 4 control flow insns in a 16-byte block (PR target/39942) - don't create invalid DWARF location lists containing DW_OP_reg* followed by DW_OP_deref*, instead use DW_OP_breg* 0 (#481675) - add libstdc++-docs subpackage, move html manual to it, add doxygen generated html and man pages gvfs-1.2.2-7.fc11 ----------------- livecd-tools-024-1.fc11 ----------------------- * Wed May 06 2009 Jeremy Katz - 024-1 - Fix ppc image creation (#497193, help from jwboyer) - Fixes for using ext[23] usb stick (wtogami) - Check filesystem after resizing and raise an error if there are problems (#497377) rubygem-rails-2.3.2-2.fc11 -------------------------- * Wed May 06 2009 David Lutterkort - 2.3.2-2 - Fix replacement of shebang lines; broke scripts/generate (bz 496480) trousers-0.3.1-16.fc11 ---------------------- * Wed May 06 2009 Milos Jakubicek - 0.3.1-16 - Fix a typo in groupadd causing the %pre scriptlet to fail (resolves BZ#486155). xorg-x11-drv-nouveau-0.0.12-34.20090507git1072103.fc11 ------------------------------------------------------ * Thu May 07 2009 Ben Skeggs 0.0.12-34.20090507git1072103 - upstream update, fix issues that occured from recent exa abi change Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 10 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From katzj at redhat.com Fri May 8 13:22:10 2009 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 8 May 2009 09:22:10 -0400 Subject: Fedora Release Engineering Meeting Recap - 2009-05-04 In-Reply-To: <1241785445.16904.13.camel@blaa> References: <20090504200148.GB3699@nostromo.devel.redhat.com> <4A01866E.8060201@redhat.com> <1241625397.3030.59.camel@localhost.localdomain> <4A0222B2.5020705@redhat.com> <1241654675.3030.80.camel@localhost.localdomain> <4A034171.8050803@redhat.com> <1241729779.3209.27.camel@localhost.localdomain> <1241785445.16904.13.camel@blaa> Message-ID: <20090508132209.GA30906@redhat.com> On Friday, May 08 2009, Mark McLoughlin said: > On Thu, 2009-05-07 at 13:56 -0700, Jesse Keating wrote: > > The freeze override process exists to add a filter between developer and > > repo to catch the obvious and to help maintainers think a moment about > > what they're doing and whether it's acceptable to do in a freeze period. > > I think this works well. It forces one briefly explain the benefit, and > justify the risk, of the update. That alone makes it less likely you're > going to screw things up with a hugely risky, or low value, update. > > I'd still like to make the process a little more visible, though. These > freeze break requests are fairly central to the development process in > the lead up to GA. It should be easier for folks to follow what's going > on than running a trac query. > > > it would make a lot more sense if developers would treat updates to a > > release with the same care as they treat updates during a freeze period, > > but that's a fight for another day. > > Agreed. It seems logical that post-GA updates would go through a similar > process. > > It could be as simple as two new fields in bodhi - "Benefit to users" > and "Risk of regressions" - and the ability for folks to jump in and say > "wait, that doesn't make sense" before an update gets pushed. This makes a fair bit of sense to me. Although in theory, the benefit should be captured by the description, having it be more explicit can't hurt. Another nice thing is that might then be a step in the direction of having bodhi used to propose freeze updates which has been something that has been talked about off and on for a while. And perhaps that helps to kill two threads with one stone. This one and also it then would change "stable" updates for an unreleased release be the release stream... and by making testing available and using bodhi, it would help with your visibility point above. Jeremy From markmc at redhat.com Fri May 8 14:15:03 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 08 May 2009 15:15:03 +0100 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241787047.10366.2.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241785891.16904.19.camel@blaa> <1241787047.10366.2.camel@localhost.localdomain> Message-ID: <1241792103.16904.23.camel@blaa> On Fri, 2009-05-08 at 08:50 -0400, Simo Sorce wrote: > On Fri, 2009-05-08 at 13:31 +0100, Mark McLoughlin wrote: > > On Thu, 2009-05-07 at 22:09 +0100, Richard W.M. Jones wrote: > > > On Thu, May 07, 2009 at 10:41:37AM -0700, Jesse Keating wrote: > > > > How is it we have 182 stable updates pending for F11 already? How have > > > > these seen any testing by a wider audience? Are we really just not > > > > bothering with updates-testing anymore? Do we not care about distro > > > > stability? > > > > > > I'll tell you the three reasons I'm pushing stuff directly to stable: > > > > > > (1) New package. > > > > > > (2) Update to a new package that I know not many people are using. > > > > This (2) is something we should try and figure out, IMHO. Trying to > > apply the same rules and guidelines to 8k+ packages doesn't work. > > > > There is a large set of packages which always should spend some time in > > updates-testing, but there's an even larger set of packages which it > > probably doesn't help at all. The same goes for the pre-GA development > > freeze. > > Fedora Core vs Fedora Extras ... Your point? That because we've merged Core and Extras we should never differentiate between packages based on "coreness" for anything ever again? Cheers, Mark. From skvidal at fedoraproject.org Fri May 8 14:16:37 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Fri, 8 May 2009 10:16:37 -0400 (EDT) Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241792103.16904.23.camel@blaa> References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241785891.16904.19.camel@blaa> <1241787047.10366.2.camel@localhost.localdomain> <1241792103.16904.23.camel@blaa> Message-ID: On Fri, 8 May 2009, Mark McLoughlin wrote: > On Fri, 2009-05-08 at 08:50 -0400, Simo Sorce wrote: >> On Fri, 2009-05-08 at 13:31 +0100, Mark McLoughlin wrote: >>> On Thu, 2009-05-07 at 22:09 +0100, Richard W.M. Jones wrote: >>>> On Thu, May 07, 2009 at 10:41:37AM -0700, Jesse Keating wrote: >>>>> How is it we have 182 stable updates pending for F11 already? How have >>>>> these seen any testing by a wider audience? Are we really just not >>>>> bothering with updates-testing anymore? Do we not care about distro >>>>> stability? >>>> >>>> I'll tell you the three reasons I'm pushing stuff directly to stable: >>>> >>>> (1) New package. >>>> >>>> (2) Update to a new package that I know not many people are using. >>> >>> This (2) is something we should try and figure out, IMHO. Trying to >>> apply the same rules and guidelines to 8k+ packages doesn't work. >>> >>> There is a large set of packages which always should spend some time in >>> updates-testing, but there's an even larger set of packages which it >>> probably doesn't help at all. The same goes for the pre-GA development >>> freeze. >> >> Fedora Core vs Fedora Extras ... > > Your point? > > That because we've merged Core and Extras we should never differentiate > between packages based on "coreness" for anything ever again? > I think we shouldn't differentiate on 'coreness' b/c of how arbitrary that distinction is. -sv From tcallawa at redhat.com Fri May 8 14:20:11 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 08 May 2009 10:20:11 -0400 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241792103.16904.23.camel@blaa> References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241785891.16904.19.camel@blaa> <1241787047.10366.2.camel@localhost.localdomain> <1241792103.16904.23.camel@blaa> Message-ID: <4A043F9B.5000905@redhat.com> On 05/08/2009 10:15 AM, Mark McLoughlin wrote: > On Fri, 2009-05-08 at 08:50 -0400, Simo Sorce wrote: >> Fedora Core vs Fedora Extras ... > > Your point? > > That because we've merged Core and Extras we should never differentiate > between packages based on "coreness" for anything ever again? No, I think he may have been suggesting that the old "line in the sand" might be a good starting point for such differentiation. ~spot From ssorce at redhat.com Fri May 8 14:41:50 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 08 May 2009 10:41:50 -0400 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <4A043F9B.5000905@redhat.com> References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241785891.16904.19.camel@blaa> <1241787047.10366.2.camel@localhost.localdomain> <1241792103.16904.23.camel@blaa> <4A043F9B.5000905@redhat.com> Message-ID: <1241793710.10366.25.camel@localhost.localdomain> On Fri, 2009-05-08 at 10:20 -0400, Tom "spot" Callaway wrote: > On 05/08/2009 10:15 AM, Mark McLoughlin wrote: > > On Fri, 2009-05-08 at 08:50 -0400, Simo Sorce wrote: > >> Fedora Core vs Fedora Extras ... > > > > Your point? > > > > That because we've merged Core and Extras we should never differentiate > > between packages based on "coreness" for anything ever again? > > No, I think he may have been suggesting that the old "line in the sand" > might be a good starting point for such differentiation. Right on the "spot" :-) Simo. -- Simo Sorce * Red Hat, Inc * New York From hedayat at grad.com Fri May 8 14:51:51 2009 From: hedayat at grad.com (Hedayat Vatankhah) Date: Fri, 08 May 2009 19:21:51 +0430 Subject: f12 boost-1.39.0 upgrade: pushed In-Reply-To: <20090507202550.06a92734@mcgee.artheist.org> References: <20090507202550.06a92734@mcgee.artheist.org> Message-ID: <4A044707.2020504@grad.com> Hi, I've tried rebuilding my packages on the devel branch. But one of them failed, I wonder if I should do anything to solve it: http://koji.fedoraproject.org/koji/getfile?taskID=1343210&name=root.log (yum is unable to resolve dependency on boost libraries!) Thanks, Hedayat /*Benjamin Kosnik */ wrote on ????? ?? ?? ??? ??:??:???: > The boost maintainers have updated the boost package > to the current release (1.39.0) in rawhide for F12. > > Rebuilds for devel packages that require boost are mandatory, as SONAME > was bumped. In addition, BuildRequires for boost packages may now be > specified with finer granularity. > > Help from other package maintainerswith rebuilding is appreciated. > > -benjamin > > _______________________________________________ > Fedora-devel-announce mailing list > Fedora-devel-announce at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-announce > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathanael at gnat.ca Fri May 8 14:53:21 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Fri, 08 May 2009 08:53:21 -0600 Subject: OpenOffice 3.1 In-Reply-To: <1241767234.2551.1304.camel@Vain> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> Message-ID: <4A044761.8000906@gnat.ca> Caol?n McNamara wrote: > On Thu, 2009-05-07 at 15:17 -0600, Nathanael D. Noblet wrote: >> Hello, >> Normally I'm quite happy to wait for new releases upstream to trickle >> into fedora, however in this case, I'd LOVE to know if 3.1 fixes an >> issue with OO over samba. > > Without details of the problem its hard to say, though 3.1 does have an > alternative file locking implementation grafted on, so if the problem > was file-locking related, 3.1 might fix your problem. Though it does > matter of course how you're working over samba, whether mounted as a > filesystem or through gio/gvfs. i.e. it might even be nothing to do > really with OOo, but something else in the stack and it won't matter > what version of OOo is used. mounted via an entry in fstab, not gio/gvfs... Files opened over the network are opened read-only no matter what mount options I give. Currently these are what we have... cifs rw,username=guest,noperm,noacl,defaults,pass='' > >> So are there plans to update f10 OpenOffice to 3.1? > > No, no such plans. Ok, thanks for the info. -- Nathanael d. Noblet T: 403.875.4613 From jonathan.underwood at gmail.com Fri May 8 14:55:30 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 8 May 2009 15:55:30 +0100 Subject: OpenOffice 3.1 In-Reply-To: <4A044761.8000906@gnat.ca> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <4A044761.8000906@gnat.ca> Message-ID: <645d17210905080755p55216818h6d89c77e5ab12013@mail.gmail.com> 2009/5/8 Nathanael D. Noblet : > Caol?n McNamara wrote: >> >> On Thu, 2009-05-07 at 15:17 -0600, Nathanael D. Noblet wrote: >>> >>> Hello, >>> ? Normally I'm quite happy to wait for new releases upstream to trickle >>> into fedora, however in this case, I'd LOVE to know if 3.1 fixes an issue >>> with OO over samba. >> >> Without details of the problem its hard to say, though 3.1 does have an >> alternative file locking implementation grafted on, so if the problem >> was file-locking related, 3.1 might fix your problem. Though it does >> matter of course how you're working over samba, whether mounted as a >> filesystem or through gio/gvfs. i.e. it might even be nothing to do >> really with OOo, but something else in the stack and it won't matter >> what version of OOo is used. > > mounted via an entry in fstab, not gio/gvfs... Files opened over the network > are opened read-only no matter what mount options I give. Currently these > are what we have... > > cifs ? ?rw,username=guest,noperm,noacl,defaults,pass='' > FWIW, I see the same thing for files mounted via sshfs. From caolanm at redhat.com Fri May 8 15:04:05 2009 From: caolanm at redhat.com (=?ISO-8859-1?Q?Caol=E1n?= McNamara) Date: Fri, 08 May 2009 16:04:05 +0100 Subject: OpenOffice 3.1 In-Reply-To: <4A044761.8000906@gnat.ca> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <4A044761.8000906@gnat.ca> Message-ID: <1241795045.2551.1313.camel@Vain> On Fri, 2009-05-08 at 08:53 -0600, Nathanael D. Noblet wrote: > mounted via an entry in fstab, not gio/gvfs... Files opened over the > network are opened read-only no matter what mount options I give. Probably file locking, probably not OOo's fault I'd hazard. If its locking then see if commenting out... SAL_ENABLE_FILE_LOCKING=1 export SAL_ENABLE_FILE_LOCKING in /usr/lib/openoffice.org3/program/soffice make a difference. C. From mschwendt at gmail.com Fri May 8 15:07:15 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 8 May 2009 17:07:15 +0200 Subject: f12 boost-1.39.0 upgrade: pushed In-Reply-To: <4A044707.2020504@grad.com> References: <20090507202550.06a92734@mcgee.artheist.org> <4A044707.2020504@grad.com> Message-ID: <20090508170715.4d6435a5@faldor.intranet> On Fri, 08 May 2009 19:21:51 +0430, Hedayat wrote: > Hi, > I've tried rebuilding my packages on the devel branch. But one of them > failed, I wonder if I should do anything to solve it: > http://koji.fedoraproject.org/koji/getfile?taskID=1343210&name=root.log > (yum is unable to resolve dependency on boost libraries!) "simspark" needs a rebuild against the new boost libs. From jkeating at redhat.com Fri May 8 15:12:43 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 08 May 2009 08:12:43 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <4A03BB64.10006@freenet.de> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <645d17210905071452n7da5f852s8bfc5d808a04c56b@mail.gmail.com> <1241733287.3209.61.camel@localhost.localdomain> <4A03A31C.4010003@freenet.de> <1241754133.3209.71.camel@localhost.localdomain> <4A03AF94.60605@freenet.de> <1241756375.3209.76.camel@localhost.localdomain> <4A03BB64.10006@freenet.de> Message-ID: <1241795563.3209.83.camel@localhost.localdomain> On Fri, 2009-05-08 at 06:56 +0200, Ralf Corsepius wrote: > > We're going to be pushing an initial set of F11 updates in the next day > > or so. > Why has this not be done earlier? Partly due to attention spent elsewhere, and partly because we'd rather our tester base focused on the bits we're proposing for the release, rather than the bits we're proposing to replace the release. > > I am already facing a pretty nice package queue jam on my part because > F11 is frozen and hasn't received any update for some time. None of > these updates are critical nevertheless they contain bug fixes and are > prerequisites for future development. > > >> * to prevent NEVR issues resulting from F-9, F-10 and F-12 being open, > >> while F-11 is frozen. > > > > Won't help at all, as the F11 release repo doesn't change, nor do the > > contents of the DVD, so F9/10 will always move ahead of the release. > You are missing the point: F11 updates would be open NOW! Which doesn't help the DVD at all. > > F11 GA development would be decoupled from F11 updates! Which doesn't help the situation where F10 updates will quickly grow NVR higher than the F11 release. > > rel-eng would cherry-pick the packages they want to put on CD/DVD, while > F11 updates would move on and would already carry what otherwise would > hit GA after "release". releng is a terrible place to "cherry pick". We can't watch each and every build and decide what is good and what is bad to have in the release. We have to rely on the informed maintainer proposing a package break the freeze and be brought into the release. > > > >> * rawhide/testing would also help wrt. test rawhide for > >> experimental/unsafe stuff, which would help improving stability when > >> rel-eng brands a rawhide snapshot "Fedora release". > > > > So you want a rawhide, and a rawerhide? > Neither, all I am saying is that your work flow _is not designed to help > stability_, but encourages prematurely shipping broken/untested "crap > stuff". That's only if maintainers don't actually take the schedule and development effort into consideration, completely ignoring the cycle and only having "crap" packages in rawhide at the time of the freeze. If they actually used good development practices, the packages in rawhide at the time of the freeze would not be "crap", they would be the packages they want in the release, and any changes would be to fix unexpected bugs in those packages. > This consideration shows, when packages are being added to rawhide or > undergo substanticial changes, right before your freeze. And how is this releng fault, when the maintainers are just plain not following good development practices? > You end up with untested/likely broken packages in your release and > with Fedora releases which are not much more than "rawhide snapshots", > and CD/DVDs which aren't worth using. Untested... that's why we compose rawhide from the frozen bits, rawhide that is used by large numbers of people who are testing the software in their every day use... That's why we find and fix numerous bugs that improve the release. That's why good maintainers slow down their changes prior to the freeze to lessen the risk and to increase the chance that the release has good quality packages. > > >> There would be one major difference: rel-eng, would have to herry-pick > >> and move around packages between F11 GA and F11/updates before the release. > > > > We already do that based on maintainers and testers who propose and test > > packages during freezes. > > As having been said many times before: You can't and will never be able > to so - You are cheating to yourselves, all you can do is to test for > very few, very isolated issues, on packages you are familiar with. Perhaps you're just not willing to use good development practices, and are trying to find a reason to blame our development cycle when this doesn't work out for you. I can't help but not agree with you. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Fri May 8 15:14:40 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 08 May 2009 08:14:40 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <645d17210905080417v4b82870akf9c00bb1009a1607@mail.gmail.com> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <645d17210905071452n7da5f852s8bfc5d808a04c56b@mail.gmail.com> <1241733287.3209.61.camel@localhost.localdomain> <4A03A31C.4010003@freenet.de> <1241754133.3209.71.camel@localhost.localdomain> <645d17210905080417v4b82870akf9c00bb1009a1607@mail.gmail.com> Message-ID: <1241795680.3209.85.camel@localhost.localdomain> On Fri, 2009-05-08 at 12:17 +0100, Jonathan Underwood wrote: > I've always assumed that we're supposed to try and not break the > upgrade path for (N-1+updatesForN-1) to (N+updatesForN). Is that not > the case? It's the only case we can realistically try for. > > > Are you suggesting some distro release level super epoch? > > > > I've often wondered why we don't have such a thing, but I've always > noticed that discussions around these sorts of ideas usually become a > bit of a flame fest. Yeah, I haven't put a lot of effort into such a thing myself. It'd be far easier if we didn't have multiple active releases at any time, or didn't allow version bumps in N-* releases. Of course, those are even more "flamey" topics. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Fri May 8 15:17:58 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 08 May 2009 08:17:58 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <200905081059.20191.mhlavink@redhat.com> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <200905081059.20191.mhlavink@redhat.com> Message-ID: <1241795878.3209.88.camel@localhost.localdomain> On Fri, 2009-05-08 at 10:59 +0200, Michal Hlavinka wrote: > > I really agree with this. I think we need F11/updates and F11/updates-testing > soon after devel freeze. You get bugs reported for snapshots, previews,... but > fixing these bugs and especially delivering them to users is too much difficult > imho. Erm, it's too hard to do the build, then propose a freeze break to fix the bug? If the bug is important enough that you're getting reports on it, why not propose that the final release has the bug fixed? > > In my dreamworld we have rawhide -> F11, F11/updates, F11/updates-testing in a > few days after devel freeze. I think at least F11/updates-testing (without > F11/updates available before day or two ago F11 GA) would be really > appreciated by developers. I'm not sure what you mean by rawhide -> F11, however you do bring up an interesting idea. Shortly after the freeze, if we did start releasing updates-testing, then the things that pass -testing could indeed go to the release rather than updates. That's not a terrible idea, I'll have to think some on it and talk with the bodhi developer. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Fri May 8 15:18:58 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 08 May 2009 08:18:58 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <200905081119.24124.mhlavink@redhat.com> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <200905081059.20191.mhlavink@redhat.com> <200905081119.24124.mhlavink@redhat.com> Message-ID: <1241795938.3209.89.camel@localhost.localdomain> On Fri, 2009-05-08 at 11:19 +0200, Michal Hlavinka wrote: > I'd like to upgrade to F11 snapshost / preview /... but when I'll found some > bug, it'll be fixed in F10 sooner than in F11. Not only this, but I'll have to > wait *one month* before I get these fixes! (Yes, I can download them from koji, > but I'd like to have fixed also bugs reported by other users/testers.) > > /me thinks there is something wrong here... If you find a bug and it's bad enough, why can't you ask the maintainer to request a freeze break for the bug fix? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Fri May 8 15:20:13 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 08 May 2009 08:20:13 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241793710.10366.25.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241785891.16904.19.camel@blaa> <1241787047.10366.2.camel@localhost.localdomain> <1241792103.16904.23.camel@blaa> <4A043F9B.5000905@redhat.com> <1241793710.10366.25.camel@localhost.localdomain> Message-ID: <1241796013.3209.90.camel@localhost.localdomain> On Fri, 2009-05-08 at 10:41 -0400, Simo Sorce wrote: > > No, I think he may have been suggesting that the old "line in the sand" > > might be a good starting point for such differentiation. > > Right on the "spot" :-) Unfortunately that line was pretty darn arbitrary, and nobody has put forth a serious effort to draw a real logical line. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Fri May 8 15:34:05 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 08 May 2009 21:04:05 +0530 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241795680.3209.85.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <645d17210905071452n7da5f852s8bfc5d808a04c56b@mail.gmail.com> <1241733287.3209.61.camel@localhost.localdomain> <4A03A31C.4010003@freenet.de> <1241754133.3209.71.camel@localhost.localdomain> <645d17210905080417v4b82870akf9c00bb1009a1607@mail.gmail.com> <1241795680.3209.85.camel@localhost.localdomain> Message-ID: <4A0450ED.4060608@fedoraproject.org> On 05/08/2009 08:44 PM, Jesse Keating wrote: > > Yeah, I haven't put a lot of effort into such a thing myself. It'd be > far easier if we didn't have multiple active releases at any time, or > didn't allow version bumps in N-* releases. Of course, those are even > more "flamey" topics. If we don't maintain two general releases in parallel, we are cutting short to a six month release *and* update cycle instead of a release cycle of six months and update cycle of 13 months, approx. Do you have an alternative? Rahul From rayvd at bludgeon.org Fri May 8 15:31:02 2009 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Fri, 8 May 2009 08:31:02 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241795878.3209.88.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <200905081059.20191.mhlavink@redhat.com> <1241795878.3209.88.camel@localhost.localdomain> Message-ID: <20090508153102.GA15821@bludgeon.org> On Fri, May 08, 2009 at 08:17:58AM -0700, Jesse Keating wrote: > On Fri, 2009-05-08 at 10:59 +0200, Michal Hlavinka wrote: > > > > I really agree with this. I think we need F11/updates and F11/updates-testing > > soon after devel freeze. You get bugs reported for snapshots, previews,... but > > fixing these bugs and especially delivering them to users is too much difficult > > imho. > > Erm, it's too hard to do the build, then propose a freeze break to fix > the bug? If the bug is important enough that you're getting reports on > it, why not propose that the final release has the bug fixed? Many bugs are not worth breaking the freeze for, but nor should the freeze bring development to a standstill. If upstream releases a new package, adds features or what-not (not necessarily fixing some critical bug) should I delay releasing an update for F10 because I don't want to conflict with the EVR of the package that was frozen for F11? I don't think you guys would be too happy if we all started requesting exceptions to the freeze for feature enhancements, etc. > > > > > In my dreamworld we have rawhide -> F11, F11/updates, F11/updates-testing in a > > few days after devel freeze. I think at least F11/updates-testing (without > > F11/updates available before day or two ago F11 GA) would be really > > appreciated by developers. > > I'm not sure what you mean by rawhide -> F11, however you do bring up an > interesting idea. Shortly after the freeze, if we did start releasing > updates-testing, then the things that pass -testing could indeed go to > the release rather than updates. That's not a terrible idea, I'll have > to think some on it and talk with the bodhi developer. Ray From rjones at redhat.com Fri May 8 15:45:39 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 8 May 2009 16:45:39 +0100 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241795563.3209.83.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <645d17210905071452n7da5f852s8bfc5d808a04c56b@mail.gmail.com> <1241733287.3209.61.camel@localhost.localdomain> <4A03A31C.4010003@freenet.de> <1241754133.3209.71.camel@localhost.localdomain> <4A03AF94.60605@freenet.de> <1241756375.3209.76.camel@localhost.localdomain> <4A03BB64.10006@freenet.de> <1241795563.3209.83.camel@localhost.localdomain> Message-ID: <20090508154539.GA14376@amd.home.annexia.org> On Fri, May 08, 2009 at 08:12:43AM -0700, Jesse Keating wrote: > That's only if maintainers don't actually take the schedule and > development effort into consideration, completely ignoring the cycle and > only having "crap" packages in rawhide at the time of the freeze. If > they actually used good development practices, the packages in rawhide > at the time of the freeze would not be "crap", they would be the > packages they want in the release, and any changes would be to fix > unexpected bugs in those packages. Yes, for gcc, the kernel, glibc and other major components I'd agree. For new packages, it's surely better to have a new crap package than no package at all. After all, a new crap package *might* work for someone, but a missing package definitely won't. For packages that not many people use, and the sort of packages I'm doing (which are for developers who really should know what's what), a 6-month cycle of organized around delivery of a circular piece of plastic is fairly irrelevant. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From che666 at gmail.com Fri May 8 15:53:14 2009 From: che666 at gmail.com (Rudolf Kastl) Date: Fri, 8 May 2009 17:53:14 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <20090508153102.GA15821@bludgeon.org> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <200905081059.20191.mhlavink@redhat.com> <1241795878.3209.88.camel@localhost.localdomain> <20090508153102.GA15821@bludgeon.org> Message-ID: i do not understand how this is sane anyways: actually why not just draw a baseline and continue to upgrade rawhide. why does it have to be frozen? the freeze is all about making sure installation works properly and that is beeing tested with using the released betas/rcs of the installer. there is no sane way currently to test the f11 updates and that means while we keep on freezing and testing an old state we are also pushing out updates on releaseday that have seen no real testing at all. -> process problem in my eyes a sane approach would be to atleast have a seperate updates-f11-prelease repo that is going to be moved to f11-updates once the final is released. those that want to coverage check the blocker bugs can actually do so while others can actually test the updates in a sane way. is there any problem with that? seems pretty trivial to me actually. anyone from rel-eng going to comment on that? why is it done that way when above issues are rather obvious and present since a whole while kind regards, Rudolf Kastl From jkeating at redhat.com Fri May 8 15:59:17 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 08 May 2009 08:59:17 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <20090508154539.GA14376@amd.home.annexia.org> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <645d17210905071452n7da5f852s8bfc5d808a04c56b@mail.gmail.com> <1241733287.3209.61.camel@localhost.localdomain> <4A03A31C.4010003@freenet.de> <1241754133.3209.71.camel@localhost.localdomain> <4A03AF94.60605@freenet.de> <1241756375.3209.76.camel@localhost.localdomain> <4A03BB64.10006@freenet.de> <1241795563.3209.83.camel@localhost.localdomain> <20090508154539.GA14376@amd.home.annexia.org> Message-ID: <1241798357.3209.92.camel@localhost.localdomain> On Fri, 2009-05-08 at 16:45 +0100, Richard W.M. Jones wrote: > Yes, for gcc, the kernel, glibc and other major components I'd agree. > > For new packages, it's surely better to have a new crap package than > no package at all. After all, a new crap package *might* work for > someone, but a missing package definitely won't. > > For packages that not many people use, and the sort of packages I'm > doing (which are for developers who really should know what's what), a > 6-month cycle of organized around delivery of a circular piece of > plastic is fairly irrelevant. I agree to an extent. However no matter how fringe the package, an improper requires or inadvertent provides can wreak havoc. I'd rather not see those go directly into the pending release. If these packages really don't care about the release, then perhaps the answer is to somehow figure out a way to have two rawhide streams. The rawhide of the pending release, and the rawhide of next, just like we do with CVS branches. That way your work can continue on the next rawhide, just ignoring the release all together. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Fri May 8 16:01:29 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 08 May 2009 09:01:29 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <4A0450ED.4060608@fedoraproject.org> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <645d17210905071452n7da5f852s8bfc5d808a04c56b@mail.gmail.com> <1241733287.3209.61.camel@localhost.localdomain> <4A03A31C.4010003@freenet.de> <1241754133.3209.71.camel@localhost.localdomain> <645d17210905080417v4b82870akf9c00bb1009a1607@mail.gmail.com> <1241795680.3209.85.camel@localhost.localdomain> <4A0450ED.4060608@fedoraproject.org> Message-ID: <1241798489.3209.94.camel@localhost.localdomain> On Fri, 2009-05-08 at 21:04 +0530, Rahul Sundaram wrote: > > If we don't maintain two general releases in parallel, we are cutting > short to a six month release *and* update cycle instead of a release > cycle of six months and update cycle of 13 months, approx. Do you have > an alternative? Not really, I just said it would be easier. No matter how long our development or support cycle is, I don't think we'd ever be able to "shut down" N-1 as soon as N is released. Too many people will want more time to move from N-1 to N so we'll always have multiple streams going. Things would be easier if we could enforce that no N-1(+updates) package is NVR higher than the packages in N, but that involves doing some unsavory things to package n-v-rs or epochs. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Fri May 8 16:04:07 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 08 May 2009 09:04:07 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <20090508153102.GA15821@bludgeon.org> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <200905081059.20191.mhlavink@redhat.com> <1241795878.3209.88.camel@localhost.localdomain> <20090508153102.GA15821@bludgeon.org> Message-ID: <1241798647.3209.95.camel@localhost.localdomain> On Fri, 2009-05-08 at 08:31 -0700, Ray Van Dolson wrote: > Many bugs are not worth breaking the freeze for, but nor should the > freeze bring development to a standstill. If upstream releases a new > package, adds features or what-not (not necessarily fixing some > critical bug) should I delay releasing an update for F10 because I > don't want to conflict with the EVR of the package that was frozen for > F11? There is no reason to delay the F10 update. Trying to avoid NVR breakage is a lost cause, it'll be broken between F10 updates and F11 GA almost immediately. So push the F10 updates. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From nathanael at gnat.ca Fri May 8 16:07:35 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Fri, 08 May 2009 10:07:35 -0600 Subject: OpenOffice 3.1 In-Reply-To: <1241795045.2551.1313.camel@Vain> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <4A044761.8000906@gnat.ca> <1241795045.2551.1313.camel@Vain> Message-ID: <4A0458C7.2070207@gnat.ca> Caol?n McNamara wrote: > On Fri, 2009-05-08 at 08:53 -0600, Nathanael D. Noblet wrote: > >> mounted via an entry in fstab, not gio/gvfs... Files opened over the >> network are opened read-only no matter what mount options I give. > > Probably file locking, probably not OOo's fault I'd hazard. > > If its locking then see if commenting out... > > SAL_ENABLE_FILE_LOCKING=1 > export SAL_ENABLE_FILE_LOCKING It is enabled... Disabling it doesn't change the behaviour. I can create/save a file, but I can't open it and save it. -- Nathanael d. Noblet T: 403.875.4613 From twaugh at redhat.com Fri May 8 16:14:08 2009 From: twaugh at redhat.com (Tim Waugh) Date: Fri, 08 May 2009 17:14:08 +0100 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <20090508154539.GA14376@amd.home.annexia.org> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <645d17210905071452n7da5f852s8bfc5d808a04c56b@mail.gmail.com> <1241733287.3209.61.camel@localhost.localdomain> <4A03A31C.4010003@freenet.de> <1241754133.3209.71.camel@localhost.localdomain> <4A03AF94.60605@freenet.de> <1241756375.3209.76.camel@localhost.localdomain> <4A03BB64.10006@freenet.de> <1241795563.3209.83.camel@localhost.localdomain> <20090508154539.GA14376@amd.home.annexia.org> Message-ID: <1241799248.3197.238.camel@worm> On Fri, 2009-05-08 at 16:45 +0100, Richard W.M. Jones wrote: > For new packages, it's surely better to have a new crap package than > no package at all. When a package claims to do something but is actually no good at it, it can cause real frustration to those who just want to use the computer and not develop for it. I would much rather the software that goes into a Fedora release be of release quality, starting from the time the package review is finished, or not be in it at all. Is it just me? Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jlaska at redhat.com Fri May 8 16:26:32 2009 From: jlaska at redhat.com (James Laska) Date: Fri, 08 May 2009 12:26:32 -0400 Subject: Fedora Release Engineering Meeting Recap - 2009-05-04 In-Reply-To: <1241729779.3209.27.camel@localhost.localdomain> References: <20090504200148.GB3699@nostromo.devel.redhat.com> <4A01866E.8060201@redhat.com> <1241625397.3030.59.camel@localhost.localdomain> <4A0222B2.5020705@redhat.com> <1241654675.3030.80.camel@localhost.localdomain> <4A034171.8050803@redhat.com> <1241729779.3209.27.camel@localhost.localdomain> Message-ID: <1241799992.2601.135.camel@flatline.devel.redhat.com> On Thu, 2009-05-07 at 13:56 -0700, Jesse Keating wrote: > > > > How will we measure--not assert or subjectively decide as we are > doing > > here and have done in the past--whether a change we have made helps > our > > releases or if time is better spent somewhere else? > > We just have to go on gut feeling, like just about everything else in > Fedora. We have to listen to maintainer feedback, and our QA team > feedback and make a judgment call. If you have better ideas, I'm all > ears. The message I've consistently gotten from our developers is > less > freeze points, and the non-blocking freeze of alpha wasn't good > enough. > QA has expressed that Alpha isn't really helpful too. From a QA perspective, I don't know if I would say that the Alpha isn't helpful. I do think that each milestone puts a stake in the ground and provides project-wide focus around a shared goal that daily rawhide doesn't demand now. > So now we're > talking about dropping it, both to save some downtime in F12 schedule > and to evaluate if we really need an Alpha snapshot. I'm uncertain as to whether removing the Alpha milestone will result in improved quality without some thinking/planning on how we should invest the extra time. One thought was ... in the absence of an Alpha, QA can schedule several test days. However, experience shows that not all test days have the same starting conditions. During F10 and F11, several test days experienced 'launch failure'. That is, we either couldn't generate a usable live image, or the steps required to prepare the test environment required enough forks in the road that it became a barrier to participation. Another investment for QA would be to provide more data on the health of rawhide. This doesn't directly influence quality, but more a foot in the door when it comes to measuring quality. Without the Alpha, how do we entice the distro to come together? How do we ensure that we aren't shifting the bugs we find in an Alpha now, to the Beta? Should we hold the F12 beta to the same/higher/lower standards that we hold the current Beta? Thanks, James -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From rayvd at bludgeon.org Fri May 8 16:46:13 2009 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Fri, 8 May 2009 09:46:13 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241799248.3197.238.camel@worm> References: <645d17210905071452n7da5f852s8bfc5d808a04c56b@mail.gmail.com> <1241733287.3209.61.camel@localhost.localdomain> <4A03A31C.4010003@freenet.de> <1241754133.3209.71.camel@localhost.localdomain> <4A03AF94.60605@freenet.de> <1241756375.3209.76.camel@localhost.localdomain> <4A03BB64.10006@freenet.de> <1241795563.3209.83.camel@localhost.localdomain> <20090508154539.GA14376@amd.home.annexia.org> <1241799248.3197.238.camel@worm> Message-ID: <20090508164612.GA16878@bludgeon.org> On Fri, May 08, 2009 at 05:14:08PM +0100, Tim Waugh wrote: > On Fri, 2009-05-08 at 16:45 +0100, Richard W.M. Jones wrote: > > For new packages, it's surely better to have a new crap package than > > no package at all. > > When a package claims to do something but is actually no good at it, it > can cause real frustration to those who just want to use the computer > and not develop for it. > > I would much rather the software that goes into a Fedora release be of > release quality, starting from the time the package review is finished, > or not be in it at all. > > Is it just me? > I think there should be enough trust in the packagers to make the decision as to whether or not a "new" package is ready or not for consumption. Ray From jkeating at redhat.com Fri May 8 16:46:36 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 08 May 2009 09:46:36 -0700 Subject: Fedora Release Engineering Meeting Recap - 2009-05-04 In-Reply-To: <1241799992.2601.135.camel@flatline.devel.redhat.com> References: <20090504200148.GB3699@nostromo.devel.redhat.com> <4A01866E.8060201@redhat.com> <1241625397.3030.59.camel@localhost.localdomain> <4A0222B2.5020705@redhat.com> <1241654675.3030.80.camel@localhost.localdomain> <4A034171.8050803@redhat.com> <1241729779.3209.27.camel@localhost.localdomain> <1241799992.2601.135.camel@flatline.devel.redhat.com> Message-ID: <1241801196.3209.98.camel@localhost.localdomain> On Fri, 2009-05-08 at 12:26 -0400, James Laska wrote: > One thought was ... in the absence of an Alpha, QA can schedule several > test days. However, experience shows that not all test days have the > same starting conditions. During F10 and F11, several test days > experienced 'launch failure'. That is, we either couldn't generate a > usable live image, or the steps required to prepare the test environment > required enough forks in the road that it became a barrier to > participation. Having more visibility and more coordinated planning on upcoming test days can help us focus to get the required bits in good shape for those days, be it anaconda, be it livecd-tools, whatever. These are lower cost then grinding everything to a halt (as far as the freeze is concerned) for a week or more. > > Another investment for QA would be to provide more data on the health of > rawhide. This doesn't directly influence quality, but more a foot in > the door when it comes to measuring quality. > > Without the Alpha, how do we entice the distro to come together? How do > we ensure that we aren't shifting the bugs we find in an Alpha now, to > the Beta? Should we hold the F12 beta to the same/higher/lower > standards that we hold the current Beta? Yes, we should hold Beta to the same or higher standard. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Fri May 8 16:52:04 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 08 May 2009 22:22:04 +0530 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241799248.3197.238.camel@worm> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <645d17210905071452n7da5f852s8bfc5d808a04c56b@mail.gmail.com> <1241733287.3209.61.camel@localhost.localdomain> <4A03A31C.4010003@freenet.de> <1241754133.3209.71.camel@localhost.localdomain> <4A03AF94.60605@freenet.de> <1241756375.3209.76.camel@localhost.localdomain> <4A03BB64.10006@freenet.de> <1241795563.3209.83.camel@localhost.localdomain> <20090508154539.GA14376@amd.home.annexia.org> <1241799248.3197.238.camel@worm> Message-ID: <4A046334.4060809@fedoraproject.org> On 05/08/2009 09:44 PM, Tim Waugh wrote: > On Fri, 2009-05-08 at 16:45 +0100, Richard W.M. Jones wrote: >> For new packages, it's surely better to have a new crap package than >> no package at all. > > When a package claims to do something but is actually no good at it, it > can cause real frustration to those who just want to use the computer > and not develop for it. > > I would much rather the software that goes into a Fedora release be of > release quality, starting from the time the package review is finished, > or not be in it at all. > > Is it just me? Not just you. Rahul From jkeating at redhat.com Fri May 8 16:47:20 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 08 May 2009 09:47:20 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241799248.3197.238.camel@worm> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <645d17210905071452n7da5f852s8bfc5d808a04c56b@mail.gmail.com> <1241733287.3209.61.camel@localhost.localdomain> <4A03A31C.4010003@freenet.de> <1241754133.3209.71.camel@localhost.localdomain> <4A03AF94.60605@freenet.de> <1241756375.3209.76.camel@localhost.localdomain> <4A03BB64.10006@freenet.de> <1241795563.3209.83.camel@localhost.localdomain> <20090508154539.GA14376@amd.home.annexia.org> <1241799248.3197.238.camel@worm> Message-ID: <1241801240.3209.99.camel@localhost.localdomain> On Fri, 2009-05-08 at 17:14 +0100, Tim Waugh wrote: > > Is it just me? No, it's not just you. However I think many will disagree on the definition of "release quality". -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From opensource at till.name Fri May 8 17:12:21 2009 From: opensource at till.name (Till Maas) Date: Fri, 08 May 2009 19:12:21 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241799248.3197.238.camel@worm> References: <1241718097.3209.11.camel@localhost.localdomain> <20090508154539.GA14376@amd.home.annexia.org> <1241799248.3197.238.camel@worm> Message-ID: <200905081912.32065.opensource@till.name> On Fr Mai 8 2009, Tim Waugh wrote: > On Fri, 2009-05-08 at 16:45 +0100, Richard W.M. Jones wrote: > > For new packages, it's surely better to have a new crap package than > > no package at all. > > When a package claims to do something but is actually no good at it, it > can cause real frustration to those who just want to use the computer > and not develop for it. > > I would much rather the software that goes into a Fedora release be of > release quality, starting from the time the package review is finished, > or not be in it at all. > > Is it just me? If some software has a unique feature that I need to use right now, then it is always more frustating to have to create a rpm by myself than to just install it with yum from Fedora. But in general it is always nicer to already have a package, than to have to create on by myself, especially if I find the software not useful enough after I tried it. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From rjones at redhat.com Fri May 8 17:29:42 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 8 May 2009 18:29:42 +0100 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241798357.3209.92.camel@localhost.localdomain> References: <645d17210905071452n7da5f852s8bfc5d808a04c56b@mail.gmail.com> <1241733287.3209.61.camel@localhost.localdomain> <4A03A31C.4010003@freenet.de> <1241754133.3209.71.camel@localhost.localdomain> <4A03AF94.60605@freenet.de> <1241756375.3209.76.camel@localhost.localdomain> <4A03BB64.10006@freenet.de> <1241795563.3209.83.camel@localhost.localdomain> <20090508154539.GA14376@amd.home.annexia.org> <1241798357.3209.92.camel@localhost.localdomain> Message-ID: <20090508172942.GA14812@amd.home.annexia.org> On Fri, May 08, 2009 at 08:59:17AM -0700, Jesse Keating wrote: > On Fri, 2009-05-08 at 16:45 +0100, Richard W.M. Jones wrote: > > Yes, for gcc, the kernel, glibc and other major components I'd agree. > > > > For new packages, it's surely better to have a new crap package than > > no package at all. After all, a new crap package *might* work for > > someone, but a missing package definitely won't. > > > > For packages that not many people use, and the sort of packages I'm > > doing (which are for developers who really should know what's what), a > > 6-month cycle of organized around delivery of a circular piece of > > plastic is fairly irrelevant. > > I agree to an extent. However no matter how fringe the package, an > improper requires or inadvertent provides can wreak havoc. I'd rather > not see those go directly into the pending release. Yes, this is a problem, a rogue package that has 'Provides: glibc', but I tend to think this is a problem with RPM or Fedora itself, which should (somehow!) prevent that. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw From db at zigo.dhs.org Fri May 8 17:44:37 2009 From: db at zigo.dhs.org (=?utf-8?B?RGVubmlzIEJqw7Zya2x1bmQ=?=) Date: Fri, 8 May 2009 19:44:37 +0200 (CEST) Subject: OpenOffice 3.1 In-Reply-To: <4A0458C7.2070207@gnat.ca> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <4A044761.8000906@gnat.ca> <1241795045.2551.1313.camel@Vain> <4A0458C7.2070207@gnat.ca> Message-ID: <99691e8b395e896e633ea732b18acb38.squirrel@zigo.org> >>> mounted via an entry in fstab, not gio/gvfs... Files opened over the >>> network are opened read-only no matter what mount options I give. > > It is enabled... Disabling it doesn't change the behaviour. I can > create/save a file, but I can't open it and save it. This problem is most likely caused by the samba server. New linux kernels (2.6.25+) can't properly talk to old (buggy) samba servers. However, kernel 2.6.28 and later has a workaround with a new mount parameter (nodfs) that will make it work again. Kernel 2.6.29 is almost here for F10 I believe. /Dennis From awilliam at redhat.com Fri May 8 18:03:13 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 08 May 2009 11:03:13 -0700 Subject: Moblin 2 and Fedora In-Reply-To: <5256d0b0905080121l78175c2ehb9e6e15e23f46386@mail.gmail.com> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <1233598383.7493.42.camel@localhost.localdomain> <20090202113524.184e402c@infradead.org> <20090503160827.GA21833@srcf.ucam.org> <1241449115.2766.148.camel@atropine.boston.devel.redhat.com> <49FF0A69.8030609@fedoraproject.org> <1241462009.8638.5.camel@localhost.localdomain> <20090504125251.41e491a6@infradead.org> <1241705174.3088.2.camel@localhost.localdomain> <1241710118.2923.481.camel@adam.local.net> <5256d0b0905080121l78175c2ehb9e6e15e23f46386@mail.gmail.com> Message-ID: <1241805793.2923.508.camel@adam.local.net> On Fri, 2009-05-08 at 09:21 +0100, Peter Robinson wrote: > > I suspect what may be happening is the original group is continuing to > > work on the crack-addled drivers that show up in the Ubuntu repos from > > time to time, while a different group works on creating a > > non-crack-addled driver that'll be sent through the proper processes. > > But that's just my guess, as no-one at Intel seems to want to say > > anything. > > Isn't the Poulsbo GPU based on a powerVR core that Intel licensed? > That might explain some of the crack. Yes, it more or less does; that's why they sub-contracted the development, the hardware is substantially different from previous Intel chips, and the existing Linux development team within Intel didn't have much familiarity with it, and was too busy to drop everything and learn about this new hardware. So they contracted development out to a group who are very familiar with the PowerVR hardware, but apparently think a driver which relies on a libdrm branch and three separate chunks of proprietary code (not to mention a badly-written kernel module just to make 2D work) is a sensible design. I've been told, though, that the GMA500 is actually a Frankenstein design, with the PowerVR 3D (and hardware video playback acceleration) core glued on to a standard Intel 2D core, so if that's accurate, it should be reasonably easy to come with at least a basic native accelerated 2D driver which doesn't depend on all the horrible proprietary crack, which would be fine for a lot of people. The 3D and video playback acceleration features are nice, but not essential. It'd be nice if Intel would just kick out a driver like that, at least. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From awilliam at redhat.com Fri May 8 18:08:33 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 08 May 2009 11:08:33 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <4A038D53.7040200@redhat.com> References: <1241718097.3209.11.camel@localhost.localdomain> <4A033B7F.1030801@redhat.com> <4A0348D3.8000302@gmail.com> <4A038D53.7040200@redhat.com> Message-ID: <1241806113.2923.512.camel@adam.local.net> On Thu, 2009-05-07 at 15:39 -1000, David Cantrell wrote: > Or perhaps a yum plugin or packagekit thing that makes it easier for > users to report that a particular update worked for them. I think PackageKit / yum integration would definitely be the way to go. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From rrelyea at redhat.com Fri May 8 18:09:04 2009 From: rrelyea at redhat.com (Robert Relyea) Date: Fri, 08 May 2009 11:09:04 -0700 Subject: crypto consolidation status? In-Reply-To: <4A031196.606@spicenitz.org> References: <4A031196.606@spicenitz.org> Message-ID: <4A047540.5070700@REDHAT.COM> Adam Goode wrote: > Hi, > > Some of my colleagues work on an RPC library that will be gaining TLS > support. http://minirpc.cs.cmu.edu/ > > Being familiar with > http://fedoraproject.org/wiki/FedoraCryptoConsolidation > I of course told them that NSS was the best library to use for this. > > But there are a few issues with this: > > * What is the rationale for requiring a shared certificate > store? The main rational is to put the trust control back in the hands of the user and the administrators. > More importantly, we would like to allow an application to > temporarily use a private cert (that it may trust for some reason) > without spreading that trust to all applications on the system. > It seems like the issue of certificate management is separable > from the actual crypto part. In NSS trust is handled in terms of types. That is a certificate is trusted for SSL or S/MIME or Code Signing. It's possible for an application to trust additional certs which aren't in the normal NSS database temporarily (Firefox uses this when you accept an override, for instance). Applications are also allowed to open multiple private databases as well, though this feature is seldom used at the current time. Note that many of these types of actions on the part of the application makes it more difficult to centrally manage crypto on your machine. So while they are available to you as an application, I suggest making it configurable to turn these options off so that admins can still control the security options on a box. > > * We are trying to use TLS from a library. The NSS documentation seems > to suggest that calling NSS_Init more than once is bad. It doesn't > look like it would be safe to call NSS_Init from a library. Really > NSS should be returning a context object that encapsulates all NSS > state, yes? There is an internal state for NSS called a trust domain. This trust domain is not yet surfaced, mainly because the use case for running multiple separate trust domains in a single application has never truly surfaced. With a single view of the trusted certs per user, it still does not come into full view. There are is the issue of the first NSS_Init wins that Rob pointed out. I'm hoping to fix that issue in the next month or two and send out recommendations on how libraries should initialize NSS. > > * It's not obvious what to pass to NSS_Init. Looking at nss_compat_ossl > shows some tricks with getenv("SSL_DIR") and such. Is that practice > documented anywhere? We're trying to converge on a single rule for all applications. You can find that here https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX I'll update that with library information as well. bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3420 bytes Desc: S/MIME Cryptographic Signature URL: From craftjml at gmail.com Fri May 8 18:10:36 2009 From: craftjml at gmail.com (Jud Craft) Date: Fri, 8 May 2009 13:10:36 -0500 Subject: Another update, another reboot, no sound! In-Reply-To: <1241764456.7634.49.camel@dimi.lattica.com> References: <1241728409.7634.21.camel@dimi.lattica.com> <20090507214017.GA9824@tango.0pointer.de> <20d6441a0905071448o10cb4928r4cab031966284aac@mail.gmail.com> <1241764456.7634.49.camel@dimi.lattica.com> Message-ID: <20d6441a0905081110j60e31bf1p6cc1089061d22f7a@mail.gmail.com> On Fri, May 8, 2009 at 1:34 AM, Dimi Paun wrote: > The problem is that it used to work _only_ via my USB headphones, > but not anymore... Sounds like you've got more than one output device. Which device is Skype (when set to "pulse") sending its output to? When you do a testcall, you can pull up pavucontrol (Pulseaudio Volume Control, I believe it's under Sound & Video in the Applications menu in F11) and go to Output. Right-click on the Skype application, and make sure it outputs to the right device. I switch between laptop speakers and a USB soundcard built into my dock, and Pulse wasn't that good at remember which played out of which. When out of dock, apps would still be trying to use the USB output, and I couldn't hear them until I manually moved them back to my laptop's soundcard. Now if this (proper output device) isn't the problem, then I'm truly out of ideas. But you sound like you've probably already considered this. From awilliam at redhat.com Fri May 8 18:19:36 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 08 May 2009 11:19:36 -0700 Subject: Another update, another reboot, no sound! In-Reply-To: References: <1241728409.7634.21.camel@dimi.lattica.com> Message-ID: <1241806776.2923.513.camel@adam.local.net> On Fri, 2009-05-08 at 11:07 +0400, Peter Lemenkov wrote: > 2009/5/8 Dimi Paun : > > This is getting ridiculous! > > > > I had running sound, and today I've updated my system. > > Right away, my sound was b0rken: > > http://peter.fedorapeople.org/alsa_advicedog.png Look, isn't being juvenile fun! http://www.happyassassin.net/extras/alsa_advicedog_2.png -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From jkeating at redhat.com Fri May 8 18:23:56 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 08 May 2009 11:23:56 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <20090508172942.GA14812@amd.home.annexia.org> References: <645d17210905071452n7da5f852s8bfc5d808a04c56b@mail.gmail.com> <1241733287.3209.61.camel@localhost.localdomain> <4A03A31C.4010003@freenet.de> <1241754133.3209.71.camel@localhost.localdomain> <4A03AF94.60605@freenet.de> <1241756375.3209.76.camel@localhost.localdomain> <4A03BB64.10006@freenet.de> <1241795563.3209.83.camel@localhost.localdomain> <20090508154539.GA14376@amd.home.annexia.org> <1241798357.3209.92.camel@localhost.localdomain> <20090508172942.GA14812@amd.home.annexia.org> Message-ID: <1241807036.2886.0.camel@localhost.localdomain> On Fri, 2009-05-08 at 18:29 +0100, Richard W.M. Jones wrote: > > Yes, this is a problem, a rogue package that has 'Provides: glibc', > but I tend to think this is a problem with RPM or Fedora itself, which > should (somehow!) prevent that. In the future, we could be running post-build tests that would catch something like this and prevent the build from being tagged without maintainer forcing it. However we don't have that right now, so suggestions on how to accomplish your goal with today's resources? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From awilliam at redhat.com Fri May 8 18:27:09 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 08 May 2009 11:27:09 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241796013.3209.90.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241785891.16904.19.camel@blaa> <1241787047.10366.2.camel@localhost.localdomain> <1241792103.16904.23.camel@blaa> <4A043F9B.5000905@redhat.com> <1241793710.10366.25.camel@localhost.localdomain> <1241796013.3209.90.camel@localhost.localdomain> Message-ID: <1241807229.2923.514.camel@adam.local.net> On Fri, 2009-05-08 at 08:20 -0700, Jesse Keating wrote: > On Fri, 2009-05-08 at 10:41 -0400, Simo Sorce wrote: > > > No, I think he may have been suggesting that the old "line in the sand" > > > might be a good starting point for such differentiation. > > > > Right on the "spot" :-) > > Unfortunately that line was pretty darn arbitrary, and nobody has put > forth a serious effort to draw a real logical line. We were kicking around, in QA, using the same definition currently used for release-critical bugs: anything that can feasibly stop the system booting, stop X working, stop networking working, or stop you being able to update the system (i.e. yum+dependencies) would be 'core'. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From jkeating at redhat.com Fri May 8 18:36:19 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 08 May 2009 11:36:19 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241807229.2923.514.camel@adam.local.net> References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241785891.16904.19.camel@blaa> <1241787047.10366.2.camel@localhost.localdomain> <1241792103.16904.23.camel@blaa> <4A043F9B.5000905@redhat.com> <1241793710.10366.25.camel@localhost.localdomain> <1241796013.3209.90.camel@localhost.localdomain> <1241807229.2923.514.camel@adam.local.net> Message-ID: <1241807779.2886.2.camel@localhost.localdomain> On Fri, 2009-05-08 at 11:27 -0700, Adam Williamson wrote: > > We were kicking around, in QA, using the same definition currently used > for release-critical bugs: anything that can feasibly stop the system > booting, stop X working, stop networking working, or stop you being able > to update the system (i.e. yum+dependencies) would be 'core'. And anything those depend on, both runtime and build, and anything /those/ depend on, and anything that could disrupt one of those things, and... -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From hedayat at grad.com Fri May 8 19:03:17 2009 From: hedayat at grad.com (Hedayat Vatankhah) Date: Fri, 08 May 2009 23:33:17 +0430 Subject: f12 boost-1.39.0 upgrade: pushed In-Reply-To: <20090508170715.4d6435a5@faldor.intranet> References: <20090507202550.06a92734@mcgee.artheist.org> <4A044707.2020504@grad.com> <20090508170715.4d6435a5@faldor.intranet> Message-ID: <4A0481F5.8030802@grad.com> On ??/??/?? 07:37, Michael Schwendt wrote: > On Fri, 08 May 2009 19:21:51 +0430, Hedayat wrote: > > >> Hi, >> I've tried rebuilding my packages on the devel branch. But one of them >> failed, I wonder if I should do anything to solve it: >> http://koji.fedoraproject.org/koji/getfile?taskID=1343210&name=root.log >> (yum is unable to resolve dependency on boost libraries!) >> > > "simspark" needs a rebuild against the new boost libs. > > Yes, this is exactly what I did just before building rcssserver3d. (http://koji.fedoraproject.org/koji/taskinfo?taskID=1343154) Well, it built fine now. It was just a matter of time! Good luck, Hedayat -------------- next part -------------- An HTML attachment was scrubbed... URL: From dimi at lattica.com Fri May 8 19:04:10 2009 From: dimi at lattica.com (Dimi Paun) Date: Fri, 08 May 2009 15:04:10 -0400 Subject: Another update, another reboot, no sound! In-Reply-To: <1241806776.2923.513.camel@adam.local.net> References: <1241728409.7634.21.camel@dimi.lattica.com> <1241806776.2923.513.camel@adam.local.net> Message-ID: <1241809450.7634.70.camel@dimi.lattica.com> On Fri, 2009-05-08 at 11:19 -0700, Adam Williamson wrote: > Look, isn't being juvenile fun! > > http://www.happyassassin.net/extras/alsa_advicedog_2.png It's freaking hilarious, but it seems that nobody takes it serious that we're breaking essential parts of the distribution (like sound) on a regular basis, and moreover, just before release! Just as I was writing this email, I did another update, sound stared working again from VirtualBox! No reboot, not even restarting X... This thing is like a yoyo. Weeeee! -- Dimi Paun Lattica, Inc. From lemenkov at gmail.com Fri May 8 19:17:16 2009 From: lemenkov at gmail.com (Peter Lemenkov) Date: Fri, 8 May 2009 23:17:16 +0400 Subject: Another update, another reboot, no sound! In-Reply-To: <1241809450.7634.70.camel@dimi.lattica.com> References: <1241728409.7634.21.camel@dimi.lattica.com> <1241806776.2923.513.camel@adam.local.net> <1241809450.7634.70.camel@dimi.lattica.com> Message-ID: 2009/5/8 Dimi Paun : > On Fri, 2009-05-08 at 11:19 -0700, Adam Williamson wrote: >> Look, isn't being juvenile fun! >> >> http://www.happyassassin.net/extras/alsa_advicedog_2.png > > It's freaking hilarious, but it seems that nobody takes > it serious that we're breaking essential parts of the > distribution (like sound) on a regular basis, and moreover, > just before release! It seems, that it affects only those poor guys, who are pointlessly trying to use pulseaudio. Everyone knows that PA is doomed, and that's why nobody cares. -- With best regards! From nathanael at gnat.ca Fri May 8 19:22:51 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Fri, 08 May 2009 13:22:51 -0600 Subject: OpenOffice 3.1 In-Reply-To: <99691e8b395e896e633ea732b18acb38.squirrel@zigo.org> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <4A044761.8000906@gnat.ca> <1241795045.2551.1313.camel@Vain> <4A0458C7.2070207@gnat.ca> <99691e8b395e896e633ea732b18acb38.squirrel@zigo.org> Message-ID: <4A04868B.2080105@gnat.ca> Dennis Bj?rklund wrote: >>>> mounted via an entry in fstab, not gio/gvfs... Files opened over the >>>> network are opened read-only no matter what mount options I give. >> It is enabled... Disabling it doesn't change the behaviour. I can >> create/save a file, but I can't open it and save it. > > This problem is most likely caused by the samba server. New linux kernels > (2.6.25+) can't properly talk to old (buggy) samba servers. > > However, kernel 2.6.28 and later has a workaround with a new mount > parameter (nodfs) that will make it work again. > > Kernel 2.6.29 is almost here for F10 I believe. Hmm even crappier then... the samba server is CentOS 5... or are you saying that with 2.6.29 on F10, if I mount with nodfs it should work? If that is the case, then 2.6.29 doesn't fix it. I added nodfs to my mount point on a F10 machine with the updates-testing 2.6.29 kernel. OO behaves even more oddly, opening it I can't see the document at all. It says read-only as well. If I were to grab a newer samba and mock build it for EPEL 5... and that build succeeded, should that fix the issue then? (CentOS being at 3.0.33, and F10 at 3.2.11) ? -- Nathanael d. Noblet T: 403.875.4613 From ajax at redhat.com Fri May 8 19:34:25 2009 From: ajax at redhat.com (Adam Jackson) Date: Fri, 08 May 2009 15:34:25 -0400 Subject: Moblin 2 and Fedora In-Reply-To: <1241805793.2923.508.camel@adam.local.net> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <1233598383.7493.42.camel@localhost.localdomain> <20090202113524.184e402c@infradead.org> <20090503160827.GA21833@srcf.ucam.org> <1241449115.2766.148.camel@atropine.boston.devel.redhat.com> <49FF0A69.8030609@fedoraproject.org> <1241462009.8638.5.camel@localhost.localdomain> <20090504125251.41e491a6@infradead.org> <1241705174.3088.2.camel@localhost.localdomain> <1241710118.2923.481.camel@adam.local.net> <5256d0b0905080121l78175c2ehb9e6e15e23f46386@mail.gmail.com> <1241805793.2923.508.camel@adam.local.net> Message-ID: <1241811265.5583.52.camel@atropine.boston.devel.redhat.com> On Fri, 2009-05-08 at 11:03 -0700, Adam Williamson wrote: > Yes, it more or less does; that's why they sub-contracted the > development, the hardware is substantially different from previous Intel > chips, and the existing Linux development team within Intel didn't have > much familiarity with it, and was too busy to drop everything and learn > about this new hardware. So they contracted development out to a group > who are very familiar with the PowerVR hardware, but apparently think a > driver which relies on a libdrm branch and three separate chunks of > proprietary code (not to mention a badly-written kernel module just to > make 2D work) is a sensible design. More accurately, that's what Tungsten _had_ to implement, because Imagination (the PowerVR people) were unwilling or unable to allow open code. > I've been told, though, that the GMA500 is actually a Frankenstein > design, with the PowerVR 3D (and hardware video playback acceleration) > core glued on to a standard Intel 2D core, so if that's accurate, it > should be reasonably easy to come with at least a basic native > accelerated 2D driver which doesn't depend on all the horrible > proprietary crack, which would be fine for a lot of people. The 3D and > video playback acceleration features are nice, but not essential. It'd > be nice if Intel would just kick out a driver like that, at least. IIRC it's an Intel-ish output block, but PVR acceleration blocks (both 2D and 3D). Not quite the same thing. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From stickster at gmail.com Fri May 8 19:54:50 2009 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 8 May 2009 15:54:50 -0400 Subject: Fedora Release Engineering Meeting Recap - 2009-05-04 In-Reply-To: <1241801196.3209.98.camel@localhost.localdomain> References: <20090504200148.GB3699@nostromo.devel.redhat.com> <4A01866E.8060201@redhat.com> <1241625397.3030.59.camel@localhost.localdomain> <4A0222B2.5020705@redhat.com> <1241654675.3030.80.camel@localhost.localdomain> <4A034171.8050803@redhat.com> <1241729779.3209.27.camel@localhost.localdomain> <1241799992.2601.135.camel@flatline.devel.redhat.com> <1241801196.3209.98.camel@localhost.localdomain> Message-ID: <20090508195450.GG4080@localhost.localdomain> On Fri, May 08, 2009 at 09:46:36AM -0700, Jesse Keating wrote: > On Fri, 2009-05-08 at 12:26 -0400, James Laska wrote: > > One thought was ... in the absence of an Alpha, QA can schedule several > > test days. However, experience shows that not all test days have the > > same starting conditions. During F10 and F11, several test days > > experienced 'launch failure'. That is, we either couldn't generate a > > usable live image, or the steps required to prepare the test environment > > required enough forks in the road that it became a barrier to > > participation. > > Having more visibility and more coordinated planning on upcoming test > days can help us focus to get the required bits in good shape for those > days, be it anaconda, be it livecd-tools, whatever. These are lower > cost then grinding everything to a halt (as far as the freeze is > concerned) for a week or more. > > > > > Another investment for QA would be to provide more data on the health of > > rawhide. This doesn't directly influence quality, but more a foot in > > the door when it comes to measuring quality. > > > > Without the Alpha, how do we entice the distro to come together? How do > > we ensure that we aren't shifting the bugs we find in an Alpha now, to > > the Beta? Should we hold the F12 beta to the same/higher/lower > > standards that we hold the current Beta? > > Yes, we should hold Beta to the same or higher standard. What standard should that be? Are there some metrics we could use to measure against that standard? There must be some factors we can identify that constitute a "successful" Alpha vs. Beta (or Beta vs. Preview, or...). For instance, you could say a successful test release results in filing of bugs. When it comes to those bugs, what would interest us to know about their distribution between one test phase and the next, or from test release to GA? -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From jkeating at redhat.com Fri May 8 20:25:07 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 08 May 2009 13:25:07 -0700 Subject: Fedora Release Engineering Meeting Recap - 2009-05-04 In-Reply-To: <20090508195450.GG4080@localhost.localdomain> References: <20090504200148.GB3699@nostromo.devel.redhat.com> <4A01866E.8060201@redhat.com> <1241625397.3030.59.camel@localhost.localdomain> <4A0222B2.5020705@redhat.com> <1241654675.3030.80.camel@localhost.localdomain> <4A034171.8050803@redhat.com> <1241729779.3209.27.camel@localhost.localdomain> <1241799992.2601.135.camel@flatline.devel.redhat.com> <1241801196.3209.98.camel@localhost.localdomain> <20090508195450.GG4080@localhost.localdomain> Message-ID: <1241814307.2886.7.camel@localhost.localdomain> On Fri, 2009-05-08 at 15:54 -0400, Paul W. Frields wrote: > What standard should that be? Is installable by the majority of people who try it. Is capable of being upgraded. Is useful for meaningful testing of the proposed features. Is released in a timely manner without (too much) delay. Is "well received". > > Are there some metrics we could use to measure against that standard? Some are measurable, some aren't. We've been making judgment calls on "success/failure" of test releases since long before Fedora existed. We continue to make those judgment calls based on reception and perception. > There must be some factors we can identify that constitute a > "successful" Alpha vs. Beta (or Beta vs. Preview, or...). For > instance, you could say a successful test release results in filing of > bugs. When it comes to those bugs, what would interest us to know > about their distribution between one test phase and the next, or from > test release to GA? That's really tough to measure. Finding bugs in a alpha or beta is a good and bad thing. Good that they were found, bad that they existed or weren't found in rawhide earlier. Definitely bad at GA but then again Fedora is a bleeding edge distro where things are tested out in a wide fashion, so finding bugs in a Fedora GA release is actually a good thing for upstreams and later downstreams. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From awilliam at redhat.com Fri May 8 20:32:17 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 08 May 2009 13:32:17 -0700 Subject: Moblin 2 and Fedora In-Reply-To: <1241811265.5583.52.camel@atropine.boston.devel.redhat.com> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <1233598383.7493.42.camel@localhost.localdomain> <20090202113524.184e402c@infradead.org> <20090503160827.GA21833@srcf.ucam.org> <1241449115.2766.148.camel@atropine.boston.devel.redhat.com> <49FF0A69.8030609@fedoraproject.org> <1241462009.8638.5.camel@localhost.localdomain> <20090504125251.41e491a6@infradead.org> <1241705174.3088.2.camel@localhost.localdomain> <1241710118.2923.481.camel@adam.local.net> <5256d0b0905080121l78175c2ehb9e6e15e23f46386@mail.gmail.com> <1241805793.2923.508.camel@adam.local.net> <1241811265.5583.52.camel@atropine.boston.devel.redhat.com> Message-ID: <1241814737.2923.525.camel@adam.local.net> On Fri, 2009-05-08 at 15:34 -0400, Adam Jackson wrote: > More accurately, that's what Tungsten _had_ to implement, because > Imagination (the PowerVR people) were unwilling or unable to allow open > code. ... > IIRC it's an Intel-ish output block, but PVR acceleration blocks (both > 2D and 3D). Not quite the same thing. Thanks for the clarifications. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From mhlavink at redhat.com Fri May 8 20:48:11 2009 From: mhlavink at redhat.com (Michal Hlavinka) Date: Fri, 8 May 2009 22:48:11 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241795938.3209.89.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <200905081119.24124.mhlavink@redhat.com> <1241795938.3209.89.camel@localhost.localdomain> Message-ID: <200905082248.11550.mhlavink@redhat.com> On Friday 08 May 2009 17:18:58 Jesse Keating wrote: > On Fri, 2009-05-08 at 11:19 +0200, Michal Hlavinka wrote: > > I'd like to upgrade to F11 snapshost / preview /... but when I'll found > > some bug, it'll be fixed in F10 sooner than in F11. Not only this, but > > I'll have to wait *one month* before I get these fixes! (Yes, I can > > download them from koji, but I'd like to have fixed also bugs reported by > > other users/testers.) > > > > /me thinks there is something wrong here... > > If you find a bug and it's bad enough, why can't you ask the maintainer > to request a freeze break for the bug fix? yes,but even if you have ten not bad enough bugs in ten packages, it's still really annoying... and I don't think maintainers are willing to ask releng for pushing that not bad enough bug fix From jkeating at redhat.com Fri May 8 20:58:01 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 08 May 2009 13:58:01 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <200905082248.11550.mhlavink@redhat.com> References: <1241718097.3209.11.camel@localhost.localdomain> <200905081119.24124.mhlavink@redhat.com> <1241795938.3209.89.camel@localhost.localdomain> <200905082248.11550.mhlavink@redhat.com> Message-ID: <1241816281.2886.8.camel@localhost.localdomain> On Fri, 2009-05-08 at 22:48 +0200, Michal Hlavinka wrote: > yes,but even if you have ten not bad enough bugs in ten packages, it's still > really annoying... and I don't think maintainers are willing to ask releng for > pushing that not bad enough bug fix It's easier to get it into a freeze than it is to issue an update to the release... if they won't go through the effort of a freeze request, why would they push an update? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mhlavink at redhat.com Fri May 8 20:58:30 2009 From: mhlavink at redhat.com (Michal Hlavinka) Date: Fri, 8 May 2009 22:58:30 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241795878.3209.88.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <200905081059.20191.mhlavink@redhat.com> <1241795878.3209.88.camel@localhost.localdomain> Message-ID: <200905082258.30864.mhlavink@redhat.com> On Friday 08 May 2009 17:17:58 Jesse Keating wrote: > On Fri, 2009-05-08 at 10:59 +0200, Michal Hlavinka wrote: > > I really agree with this. I think we need F11/updates and > > F11/updates-testing soon after devel freeze. You get bugs reported for > > snapshots, previews,... but fixing these bugs and especially delivering > > them to users is too much difficult imho. > > Erm, it's too hard to do the build, then propose a freeze break to fix > the bug? If the bug is important enough that you're getting reports on > it, why not propose that the final release has the bug fixed? Yes, but it doesn't have to be just one really important bug. What is more important? One bad bug in one package or twenty small bugs in twenty packages? If I want to try rawhide, sometimes I have no other way than just upgrade my system. For one bug I can use alternative app or apply update from koji, but I don't want to do this for twenty or more packages. > > In my dreamworld we have rawhide -> F11, F11/updates, F11/updates-testing > > in a few days after devel freeze. I think at least F11/updates-testing > > (without F11/updates available before day or two ago F11 GA) would be > > really appreciated by developers. > > I'm not sure what you mean by rawhide -> F11, however you do bring up an > interesting idea. Shortly after the freeze, if we did start releasing > updates-testing, then the things that pass -testing could indeed go to > the release rather than updates. That's not a terrible idea, I'll have > to think some on it and talk with the bodhi developer. rawhide -> F11 = just create branch in the cvs (development for next rawhide can continue, developers are not affected by freeze). This already happens, but it could be sooner. and with F11/updates-testing users will still be able to test the release, but they'd be able to receive some updates. From jspaleta at gmail.com Fri May 8 21:17:14 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 8 May 2009 13:17:14 -0800 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241806113.2923.512.camel@adam.local.net> References: <1241718097.3209.11.camel@localhost.localdomain> <4A033B7F.1030801@redhat.com> <4A0348D3.8000302@gmail.com> <4A038D53.7040200@redhat.com> <1241806113.2923.512.camel@adam.local.net> Message-ID: <604aa7910905081417l4bd77c74l60d4631d76b4ddf1@mail.gmail.com> On Fri, May 8, 2009 at 10:08 AM, Adam Williamson wrote: > I think PackageKit / yum integration would definitely be the way to go. Goes back to the underlying issue... how do you notify the user that package foo came from updates-testing X number of minutes/hours/days of testing..after system installation..so they can report back after those X number of minutes/hourse/days of testing? We don't record from which repository a package was installed from. To know what maybe installed from testing you have to be clever and do something like yum --disablerepo=updates-testing list extras diffed against yum list extras. -jef From poelstra at redhat.com Fri May 8 21:13:33 2009 From: poelstra at redhat.com (John Poelstra) Date: Fri, 08 May 2009 14:13:33 -0700 Subject: Fedora 11 Blocker Bug Day on 2009-05-11 Message-ID: <4A04A07D.1060607@redhat.com> Release Engineering will be hosting a blocker review day on Monday, May 11, 2009. The purpose of this meeting will be to: 1) review all of the bugs on the Fedora 11 Blocker list to see if they belong there 2) assess how things are looking for shipping Fedora 11 on time based on what remains on the list It would be helpful if lead package maintainers for each of the groups could join us or be in the channel should questions arise. WHEN: Monday, May 11, 2009 @ 14:00 UTC (10 AM EDT) and going as long as we need to WHERE: irc.freenode.net #fedora-bugzappers Fedora 11 Blocker: https://bugzilla.redhat.com/showdependencytree.cgi?id=446452&hide_resolved=1 Other tracker bugs of interest for Fedora 11 are here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers See you Monday! John _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From awilliam at redhat.com Fri May 8 23:20:54 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 08 May 2009 16:20:54 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <604aa7910905081417l4bd77c74l60d4631d76b4ddf1@mail.gmail.com> References: <1241718097.3209.11.camel@localhost.localdomain> <4A033B7F.1030801@redhat.com> <4A0348D3.8000302@gmail.com> <4A038D53.7040200@redhat.com> <1241806113.2923.512.camel@adam.local.net> <604aa7910905081417l4bd77c74l60d4631d76b4ddf1@mail.gmail.com> Message-ID: <1241824854.2923.526.camel@adam.local.net> On Fri, 2009-05-08 at 13:17 -0800, Jeff Spaleta wrote: > On Fri, May 8, 2009 at 10:08 AM, Adam Williamson wrote: > > I think PackageKit / yum integration would definitely be the way to go. > > Goes back to the underlying issue... how do you notify the user that > package foo came from updates-testing X number of minutes/hours/days > of testing..after system installation..so they can report back after > those X number of minutes/hourse/days of testing? > > We don't record from which repository a package was installed from. To > know what maybe installed from testing you have to be clever and do > something like yum --disablerepo=updates-testing list extras diffed > against yum list extras. That sounds extremely ugly. I think if we want to have more metadata about packages, we should start tracking it at the appropriate level - rpm or yum should track that information. If we're not willing to do that, we shouldn't try and implement ugly hacks to generate the metadata some other way. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From dwmw2 at infradead.org Fri May 8 23:33:17 2009 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 09 May 2009 00:33:17 +0100 Subject: crypto consolidation status? In-Reply-To: <4A031196.606@spicenitz.org> References: <4A031196.606@spicenitz.org> Message-ID: <1241825597.2910.1.camel@macbook.infradead.org> On Thu, 2009-05-07 at 12:51 -0400, Adam Goode wrote: > It almost seems like a little more work is needed in NSS before it can > really work as the one true crypto library. Before I can switch the OpenConnect VPN client to use it, NSS would need to grow DTLS support as well as support for using a certificate from a TPM. Lacking the former doesn't surprise me much -- but the latter is a fairly basic requirement, surely? -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation From kevin.kofler at chello.at Fri May 8 23:50:55 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 09 May 2009 01:50:55 +0200 Subject: removing KDE removes NetworkManager-gnome?? References: <4A030058.3020107@gnat.ca> <20090507155124.GB29606@redhat.com> Message-ID: Adam Miller wrote: > I'm almost positive that OpenSUSE is shipping the kde plasmoid for > network manager. I could be wrong though, but in the case that I'm not > ... where are we on this? We have kde-plasma-networkmanagement in updates-testing now, it seems to work well for me, but previous snapshots (which were what we had to base our decision what to ship by default in F11 on) had serious issues (e.g. WPA not working) and the current one still lacks testing for things like VPN (so I have no idea whether that works or not). It will be available from the repository though, and I hope we can make it the default for KDE in F12. Kevin Kofler From awilliam at redhat.com Fri May 8 23:58:06 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 08 May 2009 16:58:06 -0700 Subject: removing KDE removes NetworkManager-gnome?? In-Reply-To: References: <4A030058.3020107@gnat.ca> <20090507155124.GB29606@redhat.com> Message-ID: <1241827086.2923.549.camel@adam.local.net> On Sat, 2009-05-09 at 01:50 +0200, Kevin Kofler wrote: > Adam Miller wrote: > > I'm almost positive that OpenSUSE is shipping the kde plasmoid for > > network manager. I could be wrong though, but in the case that I'm not > > ... where are we on this? > > We have kde-plasma-networkmanagement in updates-testing now, it seems to > work well for me, but previous snapshots (which were what we had to base > our decision what to ship by default in F11 on) had serious issues (e.g. > WPA not working) and the current one still lacks testing for things like > VPN (so I have no idea whether that works or not). > > It will be available from the repository though, and I hope we can make it > the default for KDE in F12. I'll try and find a bit of time to test the VPN stuff, as I use it to log in to the Red Hat VPN so I know I have it working properly in GNOME on this system. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From kevin.kofler at chello.at.redhat.com Sat May 9 00:11:19 2009 From: kevin.kofler at chello.at.redhat.com (Kevin Kofler) Date: Sat, 09 May 2009 02:11:19 +0200 Subject: 182 pending F11 stable updates. WTF? References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <645d17210905071452n7da5f852s8bfc5d808a04c56b@mail.gmail.com> Message-ID: Jonathan Underwood wrote: > Related to that, the release freeze essentially prevents bugfix > package updates to previous releases, since pushing an updated package > with a later version number to eg. F-10 will then break the update > path to F-11. Is there a recommended way around this problem I am > missing? Well, you can try getting the package tagged if it's really a bugfix. Where that doesn't make sense, just queue it as a 0-day update for F11, it's the best you can do. Kevin Kofler From kevin.kofler at chello.at.redhat.com Sat May 9 00:23:48 2009 From: kevin.kofler at chello.at.redhat.com (Kevin Kofler) Date: Sat, 09 May 2009 02:23:48 +0200 Subject: 182 pending F11 stable updates. WTF? References: <1241718097.3209.11.camel@localhost.localdomain> <200905081119.24124.mhlavink@redhat.com> <1241795938.3209.89.camel@localhost.localdomain> <200905082248.11550.mhlavink@redhat.com> <1241816281.2886.8.camel@localhost.localdomain> Message-ID: Jesse Keating wrote: > It's easier to get it into a freeze than it is to issue an update to the > release... >From a maintainer's perspective, it's actually not, and this is probably one of the issues with our processes at hand here. Freeze break: file a ticket with rel-eng, in an interface not explicitly designed for package updates (which makes it clear you're talking to actual humans and requires you to actually explain what you want in some form of sentence), justify the change, explain why it doesn't break anything, wait for 2 rel-eng members to explicitly approve it, and expect to be questioned if your justifications are insufficient. Update: fill it in in Bodhi, no explanation required at all (people file updates even with blank descriptions and get away with it!), wait for the next push. Only occasionally you or mschwendt will ask what the point of the update is, or somebody (often mschwendt) will point out some broken dependencies, and even in those cases it often ends up getting pushed anyway. If nobody notices, it gets pushed by default (quite the opposite as for the freeze breaks). And no, I don't think requiring the same amount of bureaucracy for updates as for freeze breaks will scale. (Updates already take too long to go out, and I also think the workload would be too high for rel-eng.) I do think blank or uninformative (e.g. "new upstream release") descriptions ought to be banned though. Most likely a common process with some sort of middle ground is needed, though I'm not sure how exactly it should look. Kevin Kofler From rc040203 at freenet.de Sat May 9 00:50:24 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 09 May 2009 02:50:24 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241795563.3209.83.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <645d17210905071452n7da5f852s8bfc5d808a04c56b@mail.gmail.com> <1241733287.3209.61.camel@localhost.localdomain> <4A03A31C.4010003@freenet.de> <1241754133.3209.71.camel@localhost.localdomain> <4A03AF94.60605@freenet.de> <1241756375.3209.76.camel@localhost.localdomain> <4A03BB64.10006@freenet.de> <1241795563.3209.83.camel@localhost.localdomain> Message-ID: <4A04D350.1000904@freenet.de> Jesse Keating wrote: > On Fri, 2009-05-08 at 06:56 +0200, Ralf Corsepius wrote: >>> We're going to be pushing an initial set of F11 updates in the next day >>> or so. >> Why has this not be done earlier? > > Partly due to attention spent elsewhere, and partly because we'd rather > our tester base focused on the bits we're proposing for the release, > rather than the bits we're proposing to replace the release. > >> I am already facing a pretty nice package queue jam on my part because >> F11 is frozen and hasn't received any update for some time. None of >> these updates are critical nevertheless they contain bug fixes and are >> prerequisites for future development. >> >>>> * to prevent NEVR issues resulting from F-9, F-10 and F-12 being open, >>>> while F-11 is frozen. >>> Won't help at all, as the F11 release repo doesn't change, nor do the >>> contents of the DVD, so F9/10 will always move ahead of the release. >> You are missing the point: F11 updates would be open NOW! > > Which doesn't help the DVD at all. Pardon, but composing the DVD is solely YOUR problem, YOU need to find a solution for. >> F11 GA development would be decoupled from F11 updates! > > Which doesn't help the situation where F10 updates will quickly grow NVR > higher than the F11 release. > >> rel-eng would cherry-pick the packages they want to put on CD/DVD, while >> F11 updates would move on and would already carry what otherwise would >> hit GA after "release". > > releng is a terrible place to "cherry pick". We can't watch each and > every build and decide what is good and what is bad to have in the > release. We have to rely on the informed maintainer proposing a package > break the freeze and be brought into the release. ... the informed "maintainers" did "submit packages through koji/bodhi" ... >>>> * rawhide/testing would also help wrt. test rawhide for >>>> experimental/unsafe stuff, which would help improving stability when >>>> rel-eng brands a rawhide snapshot "Fedora release". >>> So you want a rawhide, and a rawerhide? >> Neither, all I am saying is that your work flow _is not designed to help >> stability_, but encourages prematurely shipping broken/untested "crap >> stuff". > > That's only if maintainers don't actually take the schedule and > development effort into consideration, completely ignoring the cycle and > only having "crap" packages in rawhide at the time of the freeze. If > they actually used good development practices, the packages in rawhide > at the time of the freeze would not be "crap", they would be the > packages they want in the release, and any changes would be to fix > unexpected bugs in those packages. > >> This consideration shows, when packages are being added to rawhide or >> undergo substanticial changes, right before your freeze. > > And how is this releng fault, when the maintainers are just plain not > following good development practices? Quite simple: Your schedules and practices are widely irrelevant to contributors. It's you who needs to synchronize your job with what contributors, upstreams and the rest of the worlds provides to you. It's naive of you to expect the rest of the world to synchronize with you! >> You end up with untested/likely broken packages in your release and >> with Fedora releases which are not much more than "rawhide snapshots", >> and CD/DVDs which aren't worth using. > > Untested... that's why we compose rawhide from the frozen bits, rawhide > that is used by large numbers of people who are testing the software in > their every day use... That's why we find and fix numerous bugs that > improve the release. That's why good maintainers slow down their > changes prior to the freeze to lessen the risk and to increase the > chance that the release has good quality packages. Well, F11-Preview spoke a different language. Even elementary key features were/are simply plain "unusable" and didn't even survive basic test. Examples: anaconda, preupgrade, dbus, ... >>>> There would be one major difference: rel-eng, would have to herry-pick >>>> and move around packages between F11 GA and F11/updates before the release. >>> We already do that based on maintainers and testers who propose and test >>> packages during freezes. >> As having been said many times before: You can't and will never be able >> to so - You are cheating to yourselves, all you can do is to test for >> very few, very isolated issues, on packages you are familiar with. > > Perhaps you're just not willing to use good development practices, Rubbish - Perhaps your development practices are far from being "good"? Perhaps you're too close to be able to comprehend this? Perhaps your ego is in your way to comprehend? > and > are trying to find a reason to blame our development cycle when this > doesn't work out for you. I can't help but not agree with you. No, I want you to understand that there are other demands but yours and that your are better off taking them into account. Ralf From rc040203 at freenet.de Sat May 9 01:00:10 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 09 May 2009 03:00:10 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241798647.3209.95.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <200905081059.20191.mhlavink@redhat.com> <1241795878.3209.88.camel@localhost.localdomain> <20090508153102.GA15821@bludgeon.org> <1241798647.3209.95.camel@localhost.localdomain> Message-ID: <4A04D59A.20006@freenet.de> Jesse Keating wrote: > On Fri, 2009-05-08 at 08:31 -0700, Ray Van Dolson wrote: >> Many bugs are not worth breaking the freeze for, but nor should the >> freeze bring development to a standstill. If upstream releases a new >> package, adds features or what-not (not necessarily fixing some >> critical bug) should I delay releasing an update for F10 because I >> don't want to conflict with the EVR of the package that was frozen for >> F11? > > There is no reason to delay the F10 update. Trying to avoid NVR > breakage is a lost cause, it'll be broken between F10 updates and F11 GA > almost immediately. They are only broken, because your practices force them to be broken. This is a defect of your approach to preparing Fedora releases. From kevin.kofler at chello.at Sat May 9 01:02:38 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 09 May 2009 03:02:38 +0200 Subject: OpenOffice 3.1 References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> Message-ID: Caol?n McNamara wrote: > On Thu, 2009-05-07 at 15:17 -0600, Nathanael D. Noblet wrote: >> So are there plans to update f10 OpenOffice to 3.1? > > No, no such plans. Uhm, why? Kevin Kofler From awilliam at redhat.com Sat May 9 01:13:41 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 08 May 2009 18:13:41 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <4A04D59A.20006@freenet.de> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <200905081059.20191.mhlavink@redhat.com> <1241795878.3209.88.camel@localhost.localdomain> <20090508153102.GA15821@bludgeon.org> <1241798647.3209.95.camel@localhost.localdomain> <4A04D59A.20006@freenet.de> Message-ID: <1241831621.2923.552.camel@adam.local.net> On Sat, 2009-05-09 at 03:00 +0200, Ralf Corsepius wrote: > > There is no reason to delay the F10 update. Trying to avoid NVR > > breakage is a lost cause, it'll be broken between F10 updates and F11 GA > > almost immediately. > They are only broken, because your practices force them to be broken. > > This is a defect of your approach to preparing Fedora releases. Please explain how Jesse could possibly build the release discs such that it would ever work to upgrade from F10+updates to F11 GA. This has nothing to do with the release prep process, but how we version update packages (we version them in such a way that an update shipped for Fedora N-1 can often become versioned higher than the version of that package in Fedora N release repos, and that's not a problem you can ever 'fix' in the ISO generation process). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From rc040203 at freenet.de Sat May 9 01:25:33 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 09 May 2009 03:25:33 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241795938.3209.89.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <200905081059.20191.mhlavink@redhat.com> <200905081119.24124.mhlavink@redhat.com> <1241795938.3209.89.camel@localhost.localdomain> Message-ID: <4A04DB8D.6070709@freenet.de> Jesse Keating wrote: > On Fri, 2009-05-08 at 11:19 +0200, Michal Hlavinka wrote: >> I'd like to upgrade to F11 snapshost / preview /... but when I'll found some >> bug, it'll be fixed in F10 sooner than in F11. Not only this, but I'll have to >> wait *one month* before I get these fixes! (Yes, I can download them from koji, >> but I'd like to have fixed also bugs reported by other users/testers.) >> >> /me thinks there is something wrong here... > > If you find a bug and it's bad enough, why can't you ask the maintainer > to request a freeze break for the bug fix? That's the wrong question. From maintainer's view a more accurate question would be: Why do I have to request a freeze break? From kevin.kofler at chello.at Sat May 9 01:30:42 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 09 May 2009 03:30:42 +0200 Subject: 182 pending F11 stable updates. WTF? References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241785891.16904.19.camel@blaa> <1241787047.10366.2.camel@localhost.localdomain> <1241792103.16904.23.camel@blaa> <4A043F9B.5000905@redhat.com> <1241793710.10366.25.camel@localhost.localdomain> <1241796013.3209.90.camel@localhost.localdomain> <1241807229.2923.514.camel@adam.local.net> Message-ID: Adam Williamson wrote: > We were kicking around, in QA, using the same definition currently used > for release-critical bugs: anything that can feasibly stop the system > booting, stop X working, stop networking working, or stop you being able > to update the system (i.e. yum+dependencies) would be 'core'. Under that definition, everything is core. Name: foo Provides: glibc = 999:9 Obsoletes: glibc < 999:9 (plus some assorted fake soname provides to make the depsolving happy) breaks your system pretty fast. ^^ Kevin Kofler From rc040203 at freenet.de Sat May 9 01:32:32 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 09 May 2009 03:32:32 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241831621.2923.552.camel@adam.local.net> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <200905081059.20191.mhlavink@redhat.com> <1241795878.3209.88.camel@localhost.localdomain> <20090508153102.GA15821@bludgeon.org> <1241798647.3209.95.camel@localhost.localdomain> <4A04D59A.20006@freenet.de> <1241831621.2923.552.camel@adam.local.net> Message-ID: <4A04DD30.5010805@freenet.de> Adam Williamson wrote: > On Sat, 2009-05-09 at 03:00 +0200, Ralf Corsepius wrote: > >>> There is no reason to delay the F10 update. Trying to avoid NVR >>> breakage is a lost cause, it'll be broken between F10 updates and F11 GA >>> almost immediately. >> They are only broken, because your practices force them to be broken. >> >> This is a defect of your approach to preparing Fedora releases. > > Please explain how Jesse could possibly build the release discs such > that it would ever work to upgrade from F10+updates to F11 GA. I did so on many occastion (last time previous mails within this thread) > This has > nothing to do with the release prep process, but how we version update > packages (we version them in such a way that an update shipped for > Fedora N-1 can often become versioned higher than the version of that > package in Fedora N release repos, and that's not a problem you can ever > 'fix' in the ISO generation process). The trick would be to decouple "DVD-preparations" from "F11-release". One way to achieve this would be rel-eng to start with a copy/snapshot of rawhide, but to let F11-release "roll on", e.g. by spawning "F11-updates". When encountering issues with their set of packages, they would have to try fixing their issues by adding packages from "updates" to their set of packages. Ralf From jkeating at redhat.com Sat May 9 01:32:51 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 08 May 2009 18:32:51 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <4A04D350.1000904@freenet.de> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <645d17210905071452n7da5f852s8bfc5d808a04c56b@mail.gmail.com> <1241733287.3209.61.camel@localhost.localdomain> <4A03A31C.4010003@freenet.de> <1241754133.3209.71.camel@localhost.localdomain> <4A03AF94.60605@freenet.de> <1241756375.3209.76.camel@localhost.localdomain> <4A03BB64.10006@freenet.de> <1241795563.3209.83.camel@localhost.localdomain> <4A04D350.1000904@freenet.de> Message-ID: <1241832771.2886.15.camel@localhost.localdomain> On Sat, 2009-05-09 at 02:50 +0200, Ralf Corsepius wrote: > Rubbish - Perhaps your development practices are far from being "good"? > Perhaps you're too close to be able to comprehend this? Perhaps your ego > is in your way to comprehend? > > > and > > are trying to find a reason to blame our development cycle when this > > doesn't work out for you. I can't help but not agree with you. > No, I want you to understand that there are other demands but yours and > that your are better off taking them into account. I'm always open to constructive feedback, but so far all I seem to be getting, from you, is "You're doing it wrong." Nothing other than that which would make it constructive. I don't get this from anybody else. So I really have to wonder... -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Sat May 9 01:39:04 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 08 May 2009 18:39:04 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: References: <1241718097.3209.11.camel@localhost.localdomain> <200905081119.24124.mhlavink@redhat.com> <1241795938.3209.89.camel@localhost.localdomain> <200905082248.11550.mhlavink@redhat.com> <1241816281.2886.8.camel@localhost.localdomain> Message-ID: <1241833144.2886.20.camel@localhost.localdomain> On Sat, 2009-05-09 at 02:23 +0200, Kevin Kofler wrote: > > Freeze break: file a ticket with rel-eng, in an interface not explicitly > designed for package updates (which makes it clear you're talking to actual > humans and requires you to actually explain what you want in some form of > sentence), justify the change, explain why it doesn't break anything, wait > for 2 rel-eng members to explicitly approve it, and expect to be questioned > if your justifications are insufficient. > > Update: fill it in in Bodhi, no explanation required at all (people file > updates even with blank descriptions and get away with it!), wait for the > next push. Only occasionally you or mschwendt will ask what the point of > the update is, or somebody (often mschwendt) will point out some broken > dependencies, and even in those cases it often ends up getting pushed > anyway. If nobody notices, it gets pushed by default (quite the opposite as > for the freeze breaks). > > And no, I don't think requiring the same amount of bureaucracy for updates > as for freeze breaks will scale. (Updates already take too long to go out, > and I also think the workload would be too high for rel-eng.) I do think > blank or uninformative (e.g. "new upstream release") descriptions ought to > be banned though. Most likely a common process with some sort of middle > ground is needed, though I'm not sure how exactly it should look. You're right. The work flow is less than ideal, and I have plans to make it better. The idea of using bodhi and updates-testing to propose and stage freeze breaks is an interesting one, but would require a lot of bodhi work. We may be in a place where we can do that now though. I've also got in the works some code that would let you do "make freeze-request" or something like that to echo "make update" in functionality. I also agree that our update system is just a little too free form. It's fairly obvious that left to their own devices, many of our developers won't do the right thing. Of course there are also many developers who feel the use of bodhi at all is an affront to their sensibilities. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Sat May 9 01:40:05 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 08 May 2009 18:40:05 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <4A04DB8D.6070709@freenet.de> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <200905081059.20191.mhlavink@redhat.com> <200905081119.24124.mhlavink@redhat.com> <1241795938.3209.89.camel@localhost.localdomain> <4A04DB8D.6070709@freenet.de> Message-ID: <1241833205.2886.21.camel@localhost.localdomain> On Sat, 2009-05-09 at 03:25 +0200, Ralf Corsepius wrote: > That's the wrong question. > > From maintainer's view a more accurate question would be: Why do I have > to request a freeze break? Because often maintainers aren't paying attention to the development process of the distribution and don't realize we're in a freeze to begin with, and would just land their new upstream release potentially breaking things without second thought, in other words "rawhide as usual". -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From awilliam at redhat.com Sat May 9 01:41:38 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 08 May 2009 18:41:38 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241785891.16904.19.camel@blaa> <1241787047.10366.2.camel@localhost.localdomain> <1241792103.16904.23.camel@blaa> <4A043F9B.5000905@redhat.com> <1241793710.10366.25.camel@localhost.localdomain> <1241796013.3209.90.camel@localhost.localdomain> <1241807229.2923.514.camel@adam.local.net> Message-ID: <1241833298.2923.554.camel@adam.local.net> On Sat, 2009-05-09 at 03:30 +0200, Kevin Kofler wrote: > Adam Williamson wrote: > > We were kicking around, in QA, using the same definition currently used > > for release-critical bugs: anything that can feasibly stop the system > > booting, stop X working, stop networking working, or stop you being able > > to update the system (i.e. yum+dependencies) would be 'core'. > > Under that definition, everything is core. > > Name: foo > Provides: glibc = 999:9 > Obsoletes: glibc < 999:9 > (plus some assorted fake soname provides to make the depsolving happy) > breaks your system pretty fast. ^^ I wouldn't consider that a reasonable interpretation. glibc itself should be part of core, but we can't consider *every* package part of core just because it could provide glibc. (On a tangent - can anyone think of any reason why we shouldn't enforce a rule that no package could provide the actual name of another package? I can't envisage any scenario where (ab)using Provides in that manner would be useful, but I may be missing something). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From awilliam at redhat.com Sat May 9 01:42:29 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 08 May 2009 18:42:29 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <4A04DD30.5010805@freenet.de> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <200905081059.20191.mhlavink@redhat.com> <1241795878.3209.88.camel@localhost.localdomain> <20090508153102.GA15821@bludgeon.org> <1241798647.3209.95.camel@localhost.localdomain> <4A04D59A.20006@freenet.de> <1241831621.2923.552.camel@adam.local.net> <4A04DD30.5010805@freenet.de> Message-ID: <1241833349.2923.555.camel@adam.local.net> On Sat, 2009-05-09 at 03:32 +0200, Ralf Corsepius wrote: > > This has > > nothing to do with the release prep process, but how we version update > > packages (we version them in such a way that an update shipped for > > Fedora N-1 can often become versioned higher than the version of that > > package in Fedora N release repos, and that's not a problem you can ever > > 'fix' in the ISO generation process). > > The trick would be to decouple "DVD-preparations" from "F11-release". > > One way to achieve this would be rel-eng to start with a copy/snapshot > of rawhide, but to let F11-release "roll on", e.g. by spawning > "F11-updates". > > When encountering issues with their set of packages, they would have to > try fixing their issues by adding packages from "updates" to their set > of packages. That doesn't help at all, because in the end, they're still building a static image. As soon as someone ships an F10 update *after* the F11 images are released, things start breaking. It's just in the nature of a) static release images and b) how we version updates. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From ricky at fedoraproject.org Sat May 9 00:40:57 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Fri, 8 May 2009 20:40:57 -0400 Subject: Outage Notification - 2009-05-09 00:00 UTC Message-ID: <20090509004057.GB27647@alpha.rzhou.org> Outage Notification - 2009-05-09 00:00 UTC There was an unplanned outage starting at 2009-05-09 00:00 UTC. PHX people have been notified and are currently looking into the issue. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2009-05-09 00:00 UTC' Affected Services: Buildsystem CVS / Source Control Database Mail Translation Services Websites Unaffected Services: DNS Fedora Hosted Fedora People Fedora Talk Mirror System Torrent Ticket Link: Can't make one, since DB is down :-) Reason for Outage: Unknown PHX network outage. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From ricky at fedoraproject.org Sat May 9 01:22:00 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Fri, 8 May 2009 21:22:00 -0400 Subject: Outage Notification - 2009-05-09 00:00 UTC In-Reply-To: <20090509004057.GB27647@alpha.rzhou.org> References: <20090509004057.GB27647@alpha.rzhou.org> Message-ID: <20090509012200.GC27647@alpha.rzhou.org> On 2009-05-08 08:40:57 PM, Ricky Zhou wrote: > Outage Notification - 2009-05-09 00:00 UTC > > There was an unplanned outage starting at 2009-05-09 00:00 UTC. PHX > people have been notified and are currently looking into the issue. > > To convert UTC to your local time, take a look at > http://fedoraproject.org/wiki/Infrastructure/UTCHowto > or run: > > date -d '2009-05-09 00:00 UTC' > > Affected Services: > > Buildsystem > CVS / Source Control > Database > Mail > Translation Services > Websites > > Unaffected Services: > DNS > Fedora Hosted > Fedora People > Fedora Talk > Mirror System > Torrent > > Ticket Link: > Can't make one, since DB is down :-) > > Reason for Outage: > Unknown PHX network outage. > > Contact Information: > > Please join #fedora-admin in irc.freenode.net or respond to this email to track > the status of this outage. Everything should be back up now. Apparently, there was a loose wire somewhere :-) Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From jkeating at redhat.com Sat May 9 01:59:30 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 08 May 2009 18:59:30 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241833298.2923.554.camel@adam.local.net> References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241785891.16904.19.camel@blaa> <1241787047.10366.2.camel@localhost.localdomain> <1241792103.16904.23.camel@blaa> <4A043F9B.5000905@redhat.com> <1241793710.10366.25.camel@localhost.localdomain> <1241796013.3209.90.camel@localhost.localdomain> <1241807229.2923.514.camel@adam.local.net> <1241833298.2923.554.camel@adam.local.net> Message-ID: <1241834370.2886.26.camel@localhost.localdomain> On Fri, 2009-05-08 at 18:41 -0700, Adam Williamson wrote: > > (On a tangent - can anyone think of any reason why we shouldn't enforce > a rule that no package could provide the actual name of another package? > I can't envisage any scenario where (ab)using Provides in that manner > would be useful, but I may be missing something). We do pseudo enforce that at review time. However packaging accidents can lead to strange things, often not intended but undiscovered until its too late. This is one of the things I'd like to solve with automated qa. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From greno at verizon.net Sat May 9 02:05:53 2009 From: greno at verizon.net (Gerry Reno) Date: Fri, 08 May 2009 22:05:53 -0400 Subject: preupgrade arch exception Message-ID: <4A04E501.9040905@verizon.net> We're seeing preupgrade failures tonight on a couple upgrades: # preupgrade Loading "fastestmirror" plugin Loading "installonlyn" plugin Loading mirror speeds from cached hostfile * anaconda-upgrade: mirror.hiwaay.net Loading mirror speeds from cached hostfile * anaconda-upgrade: mirror.hiwaay.net Traceback (most recent call last): File "/usr/share/preupgrade/preupgrade-gtk.py", line 198, in on_assistant_apply self._do_main() File "/usr/share/preupgrade/preupgrade-gtk.py", line 206, in _do_main self.main_preupgrade() File "/usr/share/preupgrade/preupgrade-gtk.py", line 349, in main_preupgrade self.pu.retrieve_treeinfo() File "/usr/lib/python2.5/site-packages/preupgrade/__init__.py", line 390, in retrieve_treeinfo raise PUError, "Cannot find any kernel/initrd section for this arch in treeinfo" preupgrade.PUError: Cannot find any kernel/initrd section for this arch in treeinfo # cat /etc/rpm/platform athlon-redhat-linux ???? Regards, Gerry From kevin.kofler at chello.at Sat May 9 02:27:58 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 09 May 2009 04:27:58 +0200 Subject: 182 pending F11 stable updates. WTF? References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241785891.16904.19.camel@blaa> <1241787047.10366.2.camel@localhost.localdomain> <1241792103.16904.23.camel@blaa> <4A043F9B.5000905@redhat.com> <1241793710.10366.25.camel@localhost.localdomain> <1241796013.3209.90.camel@localhost.localdomain> <1241807229.2923.514.camel@adam.local.net> <1241833298.2923.554.camel@adam.local.net> Message-ID: Adam Williamson wrote: > (On a tangent - can anyone think of any reason why we shouldn't enforce > a rule that no package could provide the actual name of another package? > I can't envisage any scenario where (ab)using Provides in that manner > would be useful, but I may be missing something). It can be useful for compat packages. E.g. kdelibs3 has: Provides: kdelibs = 6:%{version}-%{release} (and yes, the actual kdelibs also has Epoch 6). Kevin Kofler From rc040203 at freenet.de Sat May 9 02:30:06 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 09 May 2009 04:30:06 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241832771.2886.15.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <645d17210905071452n7da5f852s8bfc5d808a04c56b@mail.gmail.com> <1241733287.3209.61.camel@localhost.localdomain> <4A03A31C.4010003@freenet.de> <1241754133.3209.71.camel@localhost.localdomain> <4A03AF94.60605@freenet.de> <1241756375.3209.76.camel@localhost.localdomain> <4A03BB64.10006@freenet.de> <1241795563.3209.83.camel@localhost.localdomain> <4A04D350.1000904@freenet.de> <1241832771.2886.15.camel@localhost.localdomain> Message-ID: <4A04EAAE.50907@freenet.de> Jesse Keating wrote: > On Sat, 2009-05-09 at 02:50 +0200, Ralf Corsepius wrote: >> Rubbish - Perhaps your development practices are far from being "good"? >> Perhaps you're too close to be able to comprehend this? Perhaps your ego >> is in your way to comprehend? >> >>> and >>> are trying to find a reason to blame our development cycle when this >>> doesn't work out for you. I can't help but not agree with you. >> No, I want you to understand that there are other demands but yours and >> that your are better off taking them into account. > > I'm always open to constructive feedback, Are you deaf or what? > but so far all I seem to be > getting, from you, is "You're doing it wrong." How many times do I have to reiterate my proposals until you finally start listening? Short summary: * Open F11 updates/testing NOW * Decouple cuttings DVDs from F11 development * Implement rawhide/testing From greno at verizon.net Sat May 9 02:29:52 2009 From: greno at verizon.net (Gerry Reno) Date: Fri, 08 May 2009 22:29:52 -0400 Subject: preupgrade arch exception In-Reply-To: <4A04E501.9040905@verizon.net> References: <4A04E501.9040905@verizon.net> Message-ID: <4A04EAA0.5050806@verizon.net> Removed all downloaded packages, found a couple rpm macro files that we moved out of the way, did 'yum clean all' and now it seems to be running ok. Regards, Gerry From jkeating at redhat.com Sat May 9 02:32:59 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 08 May 2009 19:32:59 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <4A04EAAE.50907@freenet.de> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <645d17210905071452n7da5f852s8bfc5d808a04c56b@mail.gmail.com> <1241733287.3209.61.camel@localhost.localdomain> <4A03A31C.4010003@freenet.de> <1241754133.3209.71.camel@localhost.localdomain> <4A03AF94.60605@freenet.de> <1241756375.3209.76.camel@localhost.localdomain> <4A03BB64.10006@freenet.de> <1241795563.3209.83.camel@localhost.localdomain> <4A04D350.1000904@freenet.de> <1241832771.2886.15.camel@localhost.localdomain> <4A04EAAE.50907@freenet.de> Message-ID: <1241836379.2886.30.camel@localhost.localdomain> On Sat, 2009-05-09 at 04:30 +0200, Ralf Corsepius wrote: > Short summary: > * Open F11 updates/testing NOW We've been trying to push F11 updates for a couple days now. > * Decouple cuttings DVDs from F11 development I honestly don't understand what you're proposing here. No DVD from the release? What do we have people download to get the release? What do we hand out at events? > * Implement rawhide/testing Is this a full time thing, you always want a rawhide, and a rawhide-testing, which is driven by bodhi? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kevin.kofler at chello.at Sat May 9 02:30:17 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 09 May 2009 04:30:17 +0200 Subject: 182 pending F11 stable updates. WTF? References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241785891.16904.19.camel@blaa> <1241787047.10366.2.camel@localhost.localdomain> <1241792103.16904.23.camel@blaa> <4A043F9B.5000905@redhat.com> <1241793710.10366.25.camel@localhost.localdomain> <1241796013.3209.90.camel@localhost.localdomain> <1241807229.2923.514.camel@adam.local.net> <1241833298.2923.554.camel@adam.local.net> Message-ID: Adam Williamson wrote: > I wouldn't consider that a reasonable interpretation. glibc itself > should be part of core, but we can't consider *every* package part of > core just because it could provide glibc. But any package can install an initscript which runs "reboot", good luck booting that system without going into interactive boot. Kevin Kofler From greno at verizon.net Sat May 9 02:45:17 2009 From: greno at verizon.net (Gerry Reno) Date: Fri, 08 May 2009 22:45:17 -0400 Subject: preupgrade arch exception In-Reply-To: <4A04EAA0.5050806@verizon.net> References: <4A04E501.9040905@verizon.net> <4A04EAA0.5050806@verizon.net> Message-ID: <4A04EE3D.6000508@verizon.net> Gerry Reno wrote: > Removed all downloaded packages, found a couple rpm macro files that > we moved out of the way, did 'yum clean all' and now it seems to be > running ok. > > Regards, > Gerry > Spoke too soon. The exception's back. Right at the end when it says "Downloading installer metadata". Anyone know why this is happening? Regards, Gerry From greno at verizon.net Sat May 9 03:07:05 2009 From: greno at verizon.net (Gerry Reno) Date: Fri, 08 May 2009 23:07:05 -0400 Subject: preupgrade arch exception In-Reply-To: <4A04EE3D.6000508@verizon.net> References: <4A04E501.9040905@verizon.net> <4A04EAA0.5050806@verizon.net> <4A04EE3D.6000508@verizon.net> Message-ID: <4A04F359.9090105@verizon.net> Gerry Reno wrote: > Gerry Reno wrote: >> Removed all downloaded packages, found a couple rpm macro files that >> we moved out of the way, did 'yum clean all' and now it seems to be >> running ok. >> >> Regards, >> Gerry >> > Spoke too soon. The exception's back. Right at the end when it says > "Downloading installer metadata". Anyone know why this is happening? > > Regards, > Gerry > We are trying to preupgrade some F7 and F8 machines which we've been doing the past few weeks. But now all these preupgrades hit this exception for F7 and F8. I'm assuming some path has changed on the repo. How can we get these going again? Regards, Gerry From rc040203 at freenet.de Sat May 9 03:31:17 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 09 May 2009 05:31:17 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241833349.2923.555.camel@adam.local.net> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <200905081059.20191.mhlavink@redhat.com> <1241795878.3209.88.camel@localhost.localdomain> <20090508153102.GA15821@bludgeon.org> <1241798647.3209.95.camel@localhost.localdomain> <4A04D59A.20006@freenet.de> <1241831621.2923.552.camel@adam.local.net> <4A04DD30.5010805@freenet.de> <1241833349.2923.555.camel@adam.local.net> Message-ID: <4A04F905.7020708@freenet.de> Adam Williamson wrote: > On Sat, 2009-05-09 at 03:32 +0200, Ralf Corsepius wrote: > >>> This has >>> nothing to do with the release prep process, but how we version update >>> packages (we version them in such a way that an update shipped for >>> Fedora N-1 can often become versioned higher than the version of that >>> package in Fedora N release repos, and that's not a problem you can ever >>> 'fix' in the ISO generation process). >> The trick would be to decouple "DVD-preparations" from "F11-release". >> >> One way to achieve this would be rel-eng to start with a copy/snapshot >> of rawhide, but to let F11-release "roll on", e.g. by spawning >> "F11-updates". >> >> When encountering issues with their set of packages, they would have to >> try fixing their issues by adding packages from "updates" to their set >> of packages. > > That doesn't help at all, because in the end, they're still building a > static image. It does. > As soon as someone ships an F10 update *after* the F11 > images are released, things start breaking. It's just in the nature of > a) static release images and b) how we version updates. Well, of it doesn't solve all issues, but it would allow package maintainers to continue their work during the "DVD-composition phase", which would allow them to minimize NEVR conflicts and other side-effects the "freeze" has, e.g. being unable to update F11 packages because prerequisite package deps are not available in F11. Ralf From awilliam at redhat.com Sat May 9 03:38:49 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 08 May 2009 20:38:49 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241785891.16904.19.camel@blaa> <1241787047.10366.2.camel@localhost.localdomain> <1241792103.16904.23.camel@blaa> <4A043F9B.5000905@redhat.com> <1241793710.10366.25.camel@localhost.localdomain> <1241796013.3209.90.camel@localhost.localdomain> <1241807229.2923.514.camel@adam.local.net> <1241833298.2923.554.camel@adam.local.net> Message-ID: <1241840329.2923.557.camel@adam.local.net> On Sat, 2009-05-09 at 04:30 +0200, Kevin Kofler wrote: > Adam Williamson wrote: > > I wouldn't consider that a reasonable interpretation. glibc itself > > should be part of core, but we can't consider *every* package part of > > core just because it could provide glibc. > > But any package can install an initscript which runs "reboot", good luck > booting that system without going into interactive boot. well, like I said, we really can't consider egregious abuse in this idea, but that doesn't shoot it down entirely. The idea is not that it's bulletproof, just better. Anyone can cite ways to vandalize just about anything, but that's not an excuse not to try. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From awilliam at redhat.com Sat May 9 03:39:54 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 08 May 2009 20:39:54 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241785891.16904.19.camel@blaa> <1241787047.10366.2.camel@localhost.localdomain> <1241792103.16904.23.camel@blaa> <4A043F9B.5000905@redhat.com> <1241793710.10366.25.camel@localhost.localdomain> <1241796013.3209.90.camel@localhost.localdomain> <1241807229.2923.514.camel@adam.local.net> <1241833298.2923.554.camel@adam.local.net> Message-ID: <1241840394.2923.558.camel@adam.local.net> On Sat, 2009-05-09 at 04:27 +0200, Kevin Kofler wrote: > Adam Williamson wrote: > > (On a tangent - can anyone think of any reason why we shouldn't enforce > > a rule that no package could provide the actual name of another package? > > I can't envisage any scenario where (ab)using Provides in that manner > > would be useful, but I may be missing something). > > It can be useful for compat packages. E.g. kdelibs3 has: > Provides: kdelibs = 6:%{version}-%{release} > (and yes, the actual kdelibs also has Epoch 6). I don't quite see how that works...what does it achieve? Are there things which can work happily with either the KDE 3 or KDE 4 versions of kdelibs? Even so, I think it'd be more correct to have a virtual provides that both packages provide, but maybe I'm missing the point here. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From jspaleta at gmail.com Sat May 9 03:49:43 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 8 May 2009 19:49:43 -0800 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241824854.2923.526.camel@adam.local.net> References: <1241718097.3209.11.camel@localhost.localdomain> <4A033B7F.1030801@redhat.com> <4A0348D3.8000302@gmail.com> <4A038D53.7040200@redhat.com> <1241806113.2923.512.camel@adam.local.net> <604aa7910905081417l4bd77c74l60d4631d76b4ddf1@mail.gmail.com> <1241824854.2923.526.camel@adam.local.net> Message-ID: <604aa7910905082049n2af2a647l3c55c6fbdb0b3426@mail.gmail.com> On Fri, May 8, 2009 at 3:20 PM, Adam Williamson wrote: > That sounds extremely ugly. It is ugly...that's my point. That little ugly hack is the best way I know to make a review list of relevant testing updates installed on my system when I need it..at some time later after package installation. >From that list I can then go into bodhi and review relevant info about a package to see if I'm able to make a useful comment. If I'm going to be more effective as a tester..and more active as a commenter..i'm going to need help getting info about things on my system that were installed from testing. The chronological list of updates on bodhi's main site isn't that effective for me ..as there's no guarantee or likelihood that the latest updates listed there are things I've installed..even though i have updates-testing active. The first step in making me more effective is either teach client tools about what it means for a package to be installed from updates-testing..or teach bodhi to personalize its view of the update space conditioned on my system. For example an optional tie-in between smolt and bodhi would be keen. A service I can choose to opt into as a tester..which would let me upload my system's packaging info into smolt (after each yum update) and then bodhi's interface could access that via the smolt id for my system ( as browser cookie?) would be perfectly fine for me. I'm willing to leak the package list from some of my systems into smolt in order to get a better contributor experience in return. I'd like to be more helpful than I am..but I need help organizing the firehose. Help me, help you. And yes. I know I'm asking for a lot and I'm not stepping up to write that interface code. I know exactly what that sounds like...it sounds like whining. I apologize. I really want to be more effective at providing feedback for the testing packages I'm consuming and I just can't seem to string enough spare minutes together to be very effective at it. Cutting down the time it takes for me to organize what I'm looking for would be a step forward. This is as much a criticism of my own inability to be effective as it is about the toolset not being able to help me surpass my own shortcomings. But knowing what I know... I'm far more hopeful that the right people can make the tools better than I am about the chances that I'll become inherently more productive...though I'm sure the pharmaceutical industry will rise to the challenge. -jef From awilliam at redhat.com Sat May 9 03:58:09 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 08 May 2009 20:58:09 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <604aa7910905082049n2af2a647l3c55c6fbdb0b3426@mail.gmail.com> References: <1241718097.3209.11.camel@localhost.localdomain> <4A033B7F.1030801@redhat.com> <4A0348D3.8000302@gmail.com> <4A038D53.7040200@redhat.com> <1241806113.2923.512.camel@adam.local.net> <604aa7910905081417l4bd77c74l60d4631d76b4ddf1@mail.gmail.com> <1241824854.2923.526.camel@adam.local.net> <604aa7910905082049n2af2a647l3c55c6fbdb0b3426@mail.gmail.com> Message-ID: <1241841489.2923.562.camel@adam.local.net> On Fri, 2009-05-08 at 19:49 -0800, Jeff Spaleta wrote: > On Fri, May 8, 2009 at 3:20 PM, Adam Williamson wrote: > > That sounds extremely ugly. > > It is ugly...that's my point. That little ugly hack is the best way I Sorry, I meant *that implementation* would be an ugly way to do it for everybody. My point is that AFAICT the right place for this is in yum or even the RPM database, but that's quite an invasive change, so there may be some resistance to that. So kinda just pointing out the implications of doing it properly, I guess. Personally I think it'd be a great feature to have. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From db at zigo.dhs.org Sat May 9 04:48:32 2009 From: db at zigo.dhs.org (=?utf-8?B?RGVubmlzIEJqw7Zya2x1bmQ=?=) Date: Sat, 9 May 2009 06:48:32 +0200 (CEST) Subject: OpenOffice 3.1 In-Reply-To: <4A04868B.2080105@gnat.ca> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <4A044761.8000906@gnat.ca> <1241795045.2551.1313.camel@Vain> <4A0458C7.2070207@gnat.ca> <99691e8b395e896e633ea732b18acb38.squirrel@zigo.org> <4A04868B.2080105@gnat.ca> Message-ID: <865f63e11d78586d1b0a764d0ef9ae5e.squirrel@zigo.org> > Hmm even crappier then... the samba server is CentOS 5... or are you > saying that with 2.6.29 on F10, if I mount with nodfs it should work? > > If I were to grab a newer samba and mock build it for EPEL 5... and that > build succeeded, should that fix the issue then? (CentOS being at > 3.0.33, and F10 at 3.2.11) ? I thought it would have solved it. Your problem description sounded just like it was that nodfs issue. Too bad. I don't know if updating samba would help. If it was what I thought then nodfs would have solved it just as good as updating samba would have solved it. Now I don't know why it doesn't work in your setup. /Dennis From mhlavink at redhat.com Sat May 9 06:44:16 2009 From: mhlavink at redhat.com (Michal Hlavinka) Date: Sat, 9 May 2009 08:44:16 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241833205.2886.21.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <4A04DB8D.6070709@freenet.de> <1241833205.2886.21.camel@localhost.localdomain> Message-ID: <200905090844.16794.mhlavink@redhat.com> On Saturday 09 May 2009 03:40:05 Jesse Keating wrote: > On Sat, 2009-05-09 at 03:25 +0200, Ralf Corsepius wrote: > > That's the wrong question. > > > > From maintainer's view a more accurate question would be: Why do I have > > to request a freeze break? > > Because often maintainers aren't paying attention to the development > process of the distribution and don't realize we're in a freeze to begin > with, and would just land their new upstream release potentially > breaking things without second thought, in other words "rawhide as > usual". What about allowing only update push that has the same version and only changed release number, (rel-eng request for other updates) ? From mhlavink at redhat.com Sat May 9 06:48:24 2009 From: mhlavink at redhat.com (Michal Hlavinka) Date: Sat, 9 May 2009 08:48:24 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241816281.2886.8.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <200905082248.11550.mhlavink@redhat.com> <1241816281.2886.8.camel@localhost.localdomain> Message-ID: <200905090848.24574.mhlavink@redhat.com> On Friday 08 May 2009 22:58:01 Jesse Keating wrote: > On Fri, 2009-05-08 at 22:48 +0200, Michal Hlavinka wrote: > > yes,but even if you have ten not bad enough bugs in ten packages, it's > > still really annoying... and I don't think maintainers are willing to ask > > releng for pushing that not bad enough bug fix > > It's easier to get it into a freeze than it is to issue an update to the > release... if they won't go through the effort of a freeze request, why > would they push an update? starting bureaucracy process it's not that simple - they are afraid rel-eng (or others) would answer with something like "Why are you wasting our time with such a small bug?" But as I've already said: twenty small bugs can be more annoying than one big bug. From opensource at till.name Sat May 9 08:38:00 2009 From: opensource at till.name (Till Maas) Date: Sat, 09 May 2009 10:38:00 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241816281.2886.8.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <200905082248.11550.mhlavink@redhat.com> <1241816281.2886.8.camel@localhost.localdomain> Message-ID: <200905091038.16055.opensource@till.name> On Fr Mai 8 2009, Jesse Keating wrote: > On Fri, 2009-05-08 at 22:48 +0200, Michal Hlavinka wrote: > > yes,but even if you have ten not bad enough bugs in ten packages, it's > > still really annoying... and I don't think maintainers are willing to ask > > releng for pushing that not bad enough bug fix > > It's easier to get it into a freeze than it is to issue an update to the > release... if they won't go through the effort of a freeze request, why > would they push an update? If the same NVR update is also pushed to F10 and F9 updates, then adding F11 only requires pasting an additional package name into bodhi to create an update for all three releases at once. In this case it is therefore a lot easier to just create an update for F11, than to get it into a freeze. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From snecklifter at gmail.com Sat May 9 08:39:39 2009 From: snecklifter at gmail.com (Christopher Brown) Date: Sat, 9 May 2009 09:39:39 +0100 Subject: preupgrade arch exception In-Reply-To: <4A04F359.9090105@verizon.net> References: <4A04E501.9040905@verizon.net> <4A04EAA0.5050806@verizon.net> <4A04EE3D.6000508@verizon.net> <4A04F359.9090105@verizon.net> Message-ID: <364d303b0905090139sf7232afs7f5d3a24fe0ea557@mail.gmail.com> 2009/5/9 Gerry Reno : > Gerry Reno wrote: >> >> Gerry Reno wrote: >>> >>> Removed all downloaded packages, found a couple rpm macro files that we >>> moved out of the way, did 'yum clean all' and now it seems to be running ok. >>> >>> Regards, >>> Gerry >>> >> Spoke too soon. ?The exception's back. ?Right at the end when it says >> "Downloading installer metadata". ?Anyone know why this is happening? >> >> Regards, >> Gerry >> > We are trying to preupgrade some F7 and F8 machines which we've been doing > the past few weeks. ?But now all these preupgrades hit this exception for F7 > and F8. ?I'm assuming some path has changed on the repo. ?How can we get > these going again? Sorry to hear of your problems but this is not a support list, as you will have noticed when you subscribed. http://www.redhat.com/mailman/listinfo/fedora-devel-list You can prevent these kind of problems by upgrading before a product reaches the end of its life. I would suggest asking in #fedora on IRC. Regards -- Christopher Brown From pmatilai at laiskiainen.org Sat May 9 08:58:52 2009 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Sat, 9 May 2009 11:58:52 +0300 (EEST) Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241824854.2923.526.camel@adam.local.net> References: <1241718097.3209.11.camel@localhost.localdomain> <4A033B7F.1030801@redhat.com> <4A0348D3.8000302@gmail.com> <4A038D53.7040200@redhat.com> <1241806113.2923.512.camel@adam.local.net> <604aa7910905081417l4bd77c74l60d4631d76b4ddf1@mail.gmail.com> <1241824854.2923.526.camel@adam.local.net> Message-ID: On Fri, 8 May 2009, Adam Williamson wrote: > On Fri, 2009-05-08 at 13:17 -0800, Jeff Spaleta wrote: >> On Fri, May 8, 2009 at 10:08 AM, Adam Williamson wrote: >>> I think PackageKit / yum integration would definitely be the way to go. >> >> Goes back to the underlying issue... how do you notify the user that >> package foo came from updates-testing X number of minutes/hours/days >> of testing..after system installation..so they can report back after >> those X number of minutes/hourse/days of testing? >> >> We don't record from which repository a package was installed from. To >> know what maybe installed from testing you have to be clever and do >> something like yum --disablerepo=updates-testing list extras diffed >> against yum list extras. > > That sounds extremely ugly. I think if we want to have more metadata > about packages, we should start tracking it at the appropriate level - > rpm or yum should track that information. If we're not willing to do > that, we shouldn't try and implement ugly hacks to generate the metadata > some other way. There already is an accurate way of tracking this: package signatures. For example, this'll give you the packages that came from F10 testing: rpm -qa --qf "%{name}-%{version}-%{release}\t%{dsaheader:pgpsig}\n"|grep "Key ID 92a1023d0b86274e"|cut -f1 It doesn't tell you if/when the package gets moved from testing to updates of course, but it does tell you where a given package *originated* from. - Panu - From kevin.kofler at chello.at Sat May 9 10:42:39 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 09 May 2009 12:42:39 +0200 Subject: 182 pending F11 stable updates. WTF? References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <200905081059.20191.mhlavink@redhat.com> <1241795878.3209.88.camel@localhost.localdomain> <20090508153102.GA15821@bludgeon.org> <1241798647.3209.95.camel@localhost.localdomain> <4A04D59A.20006@freenet.de> <1241831621.2923.552.camel@adam.local.net> <4A04DD30.5010805@freenet.de> <1241833349.2923.555.camel@adam.local.net> <4A04F905.7020708@freenet.de> Message-ID: Ralf Corsepius wrote: > e.g. being unable to update F11 packages because > prerequisite package deps are not available in F11. That's what buildroot overrides are for. Kevin Kofler From kevin.kofler at chello.at Sat May 9 10:43:55 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 09 May 2009 12:43:55 +0200 Subject: 182 pending F11 stable updates. WTF? References: <1241718097.3209.11.camel@localhost.localdomain> <4A033B7F.1030801@redhat.com> <4A0348D3.8000302@gmail.com> <4A038D53.7040200@redhat.com> <1241806113.2923.512.camel@adam.local.net> <604aa7910905081417l4bd77c74l60d4631d76b4ddf1@mail.gmail.com> <1241824854.2923.526.camel@adam.local.net> Message-ID: Panu Matilainen wrote: > There already is an accurate way of tracking this: package signatures. For > example, this'll give you the packages that came from F10 testing: But hasn't this distinction be dropped in F11? AFAIK everything is signed with the same key now. Kevin Kofler From mschwendt at gmail.com Sat May 9 10:45:14 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sat, 9 May 2009 12:45:14 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <20090508164612.GA16878@bludgeon.org> References: <645d17210905071452n7da5f852s8bfc5d808a04c56b@mail.gmail.com> <1241733287.3209.61.camel@localhost.localdomain> <4A03A31C.4010003@freenet.de> <1241754133.3209.71.camel@localhost.localdomain> <4A03AF94.60605@freenet.de> <1241756375.3209.76.camel@localhost.localdomain> <4A03BB64.10006@freenet.de> <1241795563.3209.83.camel@localhost.localdomain> <20090508154539.GA14376@amd.home.annexia.org> <1241799248.3197.238.camel@worm> <20090508164612.GA16878@bludgeon.org> Message-ID: <20090509124514.2df487b9@faldor.intranet> On Fri, 8 May 2009 09:46:13 -0700, Ray wrote: > On Fri, May 08, 2009 at 05:14:08PM +0100, Tim Waugh wrote: > > On Fri, 2009-05-08 at 16:45 +0100, Richard W.M. Jones wrote: > > > For new packages, it's surely better to have a new crap package than > > > no package at all. > > > > When a package claims to do something but is actually no good at it, it > > can cause real frustration to those who just want to use the computer > > and not develop for it. > > > > I would much rather the software that goes into a Fedora release be of > > release quality, starting from the time the package review is finished, > > or not be in it at all. > > > > Is it just me? > > I think there should be enough trust in the packagers to make the > decision as to whether or not a "new" package is ready or not for > consumption. > > Ray > We're back at where we've been long ago. It's good to not take away the freedom. It's good to trust the packagers. It's good that packagers may decide for themselves whether to skip updates-testing. Unfortunately, if they skip updates-testing actually, this reduces the community's opportunity to contribute testing. They exclude the few people who are willing to enable updates-testing or who cherry-pick test updates. These people need a few days for mirrors to sync, a few days to evaluate updates, and additional time to decide on what feedback to give. [1] Instead, updates marked as stable immediately are unleashed onto users who may not want to be guinea pigs. Users, who might be actual users of your packages, but who might not be familiar with the Fedora Updates System website and its karma system. Users, who expect package maintainers to not release broken updates. Don't expect such users to search for the bodhi website and to hunt down broken updates in a flood of tickets. Hope that they take the time to report problems in bugzilla instead of rolling on with their own builds, downgrades, or a different dist. What happens in bodhi is that packagers give +1 on their own updates, not noticing broken deps, not noticing other packaging problems, in some cases not even trying to install an update prior to marking it stable. Other packagers, for example, are not familiar with the releng procedures. They push ABI-incompatible upgrades into stable in order to rebuild dependencies. One cannot say the Fedora Project Wiki is easy to navigate. It's really easy to miss such details and to miss changes on pages and in procedures. With regard to new packages added to the collection, Fedora is focused on quantity instead of quality. The fight against the review-queue leads to metrics (who does the most reviews per week?) while nobody measures the quality of the reviews and the quality of the released packages. One can only hope that poor reviews of simple packages like bug 494852 will be avoided in the future. [1] Skipping updates-testing also removes the opportunity to run scripts that check remote repositories. The excuse that the build system should run such tests at the end of a build-job is lame. From dwmw2 at infradead.org Sat May 9 10:46:43 2009 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 09 May 2009 11:46:43 +0100 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241831621.2923.552.camel@adam.local.net> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <200905081059.20191.mhlavink@redhat.com> <1241795878.3209.88.camel@localhost.localdomain> <20090508153102.GA15821@bludgeon.org> <1241798647.3209.95.camel@localhost.localdomain> <4A04D59A.20006@freenet.de> <1241831621.2923.552.camel@adam.local.net> Message-ID: <1241866003.2910.80.camel@macbook.infradead.org> On Fri, 2009-05-08 at 18:13 -0700, Adam Williamson wrote: > Please explain how Jesse could possibly build the release discs such > that it would ever work to upgrade from F10+updates to F11 GA. By including the option to add the F11 updates repo at install time. Er, can't we already do that?? -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation ? As long as the repo isn't on NFS, that is. From kevin.kofler at chello.at Sat May 9 10:50:20 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 09 May 2009 12:50:20 +0200 Subject: 182 pending F11 stable updates. WTF? References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241785891.16904.19.camel@blaa> <1241787047.10366.2.camel@localhost.localdomain> <1241792103.16904.23.camel@blaa> <4A043F9B.5000905@redhat.com> <1241793710.10366.25.camel@localhost.localdomain> <1241796013.3209.90.camel@localhost.localdomain> <1241807229.2923.514.camel@adam.local.net> <1241833298.2923.554.camel@adam.local.net> <1241840394.2923.558.camel@adam.local.net> Message-ID: Adam Williamson wrote: > I don't quite see how that works...what does it achieve? Are there > things which can work happily with either the KDE 3 or KDE 4 versions of > kdelibs? It allows doing things like Requires: kdelibs = 6:3.5.10, but I agree it isn't all that useful and packages shouldn't be using that (but use Requires: kdelibs3 = 3.5.10 if that's what they need, and more likely they want kdelibs3 >= 3.5.n for some n, which is not encodable in a good way with the kdelibs Provides). But the idea is to make the package suitable as a drop-in replacement for the original unrenamed package, and I've seen this idiom also in other compat packages. I wouldn't lose any sleep over it if it got dropped from kdelibs3 though, packages should have fixed Requires already by now, if they still try requiring kdelibs when they actually want kdelibs3, they need to be fixed. Kevin Kofler From mschwendt at gmail.com Sat May 9 10:53:02 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sat, 09 May 2009 10:53:02 -0000 Subject: Broken dependencies in Fedora 11 - 2009-05-09 Message-ID: <20090509105302.4990.17442@faldor.intranet> ====================================================================== The results in this summary consider Test Updates! ====================================================================== Summary of broken packages (by src.rpm name): cabal2spec plplot qbittorrent Summary of broken packages (by primary owner): leigh123linux AT googlemail com qbittorrent orion AT cora.nwra com plplot petersen AT redhat com cabal2spec (1 co-owner) ====================================================================== Broken packages in fedora-development-i386: plplot-gnome-devel-5.9.2-4.fc11.i586 requires plplot-devel = 0:5.9.2-4.fc11 plplot-gnome-devel-5.9.2-4.fc11.i586 requires plplot = 0:5.9.2-4.fc11 ====================================================================== Broken packages in fedora-development-ppc: plplot-gnome-devel-5.9.2-4.fc11.ppc requires plplot-devel = 0:5.9.2-4.fc11 plplot-gnome-devel-5.9.2-4.fc11.ppc requires plplot = 0:5.9.2-4.fc11 plplot-gnome-devel-5.9.2-4.fc11.ppc64 requires plplot-devel = 0:5.9.2-4.fc11 plplot-gnome-devel-5.9.2-4.fc11.ppc64 requires plplot = 0:5.9.2-4.fc11 ====================================================================== Broken packages in fedora-development-ppc64: cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 plplot-gnome-devel-5.9.2-4.fc11.ppc64 requires plplot-devel = 0:5.9.2-4.fc11 plplot-gnome-devel-5.9.2-4.fc11.ppc64 requires plplot = 0:5.9.2-4.fc11 ====================================================================== Broken packages in fedora-development-x86_64: plplot-gnome-devel-5.9.2-4.fc11.i586 requires plplot-devel = 0:5.9.2-4.fc11 plplot-gnome-devel-5.9.2-4.fc11.i586 requires plplot = 0:5.9.2-4.fc11 plplot-gnome-devel-5.9.2-4.fc11.x86_64 requires plplot-devel = 0:5.9.2-4.fc11 plplot-gnome-devel-5.9.2-4.fc11.x86_64 requires plplot = 0:5.9.2-4.fc11 ====================================================================== Broken packages in fedora-updates-11-i386: qbittorrent-1.3.3-4.fc11.i586 requires libtorrent-rasterbar.so.3 ====================================================================== Broken packages in fedora-updates-11-ppc: qbittorrent-1.3.3-4.fc11.ppc requires libtorrent-rasterbar.so.3 ====================================================================== Broken packages in fedora-updates-11-ppc64: qbittorrent-1.3.3-4.fc11.ppc64 requires libtorrent-rasterbar.so.3()(64bit) ====================================================================== Broken packages in fedora-updates-11-x86_64: qbittorrent-1.3.3-4.fc11.x86_64 requires libtorrent-rasterbar.so.3()(64bit) From kevin.kofler at chello.at Sat May 9 10:51:18 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 09 May 2009 12:51:18 +0200 Subject: preupgrade arch exception References: <4A04E501.9040905@verizon.net> Message-ID: Gerry Reno wrote: > # cat /etc/rpm/platform > athlon-redhat-linux Delete that file. Kevin Kofler From rjones at redhat.com Sat May 9 11:23:14 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Sat, 9 May 2009 12:23:14 +0100 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <20090509124514.2df487b9@faldor.intranet> References: <4A03A31C.4010003@freenet.de> <1241754133.3209.71.camel@localhost.localdomain> <4A03AF94.60605@freenet.de> <1241756375.3209.76.camel@localhost.localdomain> <4A03BB64.10006@freenet.de> <1241795563.3209.83.camel@localhost.localdomain> <20090508154539.GA14376@amd.home.annexia.org> <1241799248.3197.238.camel@worm> <20090508164612.GA16878@bludgeon.org> <20090509124514.2df487b9@faldor.intranet> Message-ID: <20090509112314.GA18864@amd.home.annexia.org> On Sat, May 09, 2009 at 12:45:14PM +0200, Michael Schwendt wrote: > With regard to new packages added to the collection, Fedora is focused on > quantity instead of quality. Is it? I'm a member of the Fedora community, and I think we should be inclusive about the packages we take, allowing anything which isn't illegal and which follows the guidelines. This may mean that packages duplicate functionality and so forth, so be it. > The fight against the review-queue leads to metrics (who does the > most reviews per week?) while nobody measures the quality of the > reviews and the quality of the released packages. This is entirely a problem of the Fedora process, that Debian (as an example) does not have. We could easily measure the quality of reviewed packages using mass rebuilds and automated tests, as Debian's QA team do routinely. > One can only hope that poor reviews of simple packages like bug > 494852 will be avoided in the future. https://bugzilla.redhat.com/show_bug.cgi?id=494852 That is indeed a poor review. I have no doubt that many other packages already in Fedora have problems or are inconsistent with the guidelines. Debian does much better here by **routine automated testing of the packages which are in the distribution**. Relying on the review as the single hurdle over which all packages must jump, and then having a complete free-for-all in the distribution -- that's simply bad process, and not a necessary factor for a Linux distribution. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From rjones at redhat.com Sat May 9 11:25:00 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Sat, 9 May 2009 12:25:00 +0100 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <20090509112314.GA18864@amd.home.annexia.org> References: <1241754133.3209.71.camel@localhost.localdomain> <4A03AF94.60605@freenet.de> <1241756375.3209.76.camel@localhost.localdomain> <4A03BB64.10006@freenet.de> <1241795563.3209.83.camel@localhost.localdomain> <20090508154539.GA14376@amd.home.annexia.org> <1241799248.3197.238.camel@worm> <20090508164612.GA16878@bludgeon.org> <20090509124514.2df487b9@faldor.intranet> <20090509112314.GA18864@amd.home.annexia.org> Message-ID: <20090509112500.GB18864@amd.home.annexia.org> On Sat, May 09, 2009 at 12:23:14PM +0100, Richard W.M. Jones wrote: > On Sat, May 09, 2009 at 12:45:14PM +0200, Michael Schwendt wrote: > > With regard to new packages added to the collection, Fedora is focused on > > quantity instead of quality. > > Is it? I'm a member of the Fedora community, and I think we should be > inclusive about the packages we take, allowing anything which isn't > illegal and which follows the guidelines. This may mean that packages > duplicate functionality and so forth, so be it. I misread Michael Schwendt's original sentence, so disregard this paragraph. We seem to be agreed. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From caolanm at redhat.com Sat May 9 11:51:18 2009 From: caolanm at redhat.com (=?ISO-8859-1?Q?Caol=E1n?= McNamara) Date: Sat, 09 May 2009 12:51:18 +0100 Subject: OpenOffice 3.1 In-Reply-To: References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> Message-ID: <1241869878.2551.1439.camel@Vain> On Sat, 2009-05-09 at 03:02 +0200, Kevin Kofler wrote: > Caol?n McNamara wrote: > > > On Thu, 2009-05-07 at 15:17 -0600, Nathanael D. Noblet wrote: > >> So are there plans to update f10 OpenOffice to 3.1? > > > > No, no such plans. > > Uhm, why? Well, in this case updating F-10 3.1 properly would require updating a load of other stuff as well with all the risks and work that entails. But even if that wasn't the case I generally don't bump major versions of OOo in a released product. I see our fedora release cycle as ones of iterative stable complete releases, rather than one which has an always-open pool of stable packages which always contains the latest stable version of a package. i.e. F-10 was history as soon as it was released, and F-11 is likewise almost dead to me already :-) Not that I won't fix bugs in them, just that I don't see them as live development releases. C. From denis at poolshark.org Sat May 9 12:07:27 2009 From: denis at poolshark.org (Denis Leroy) Date: Sat, 09 May 2009 14:07:27 +0200 Subject: glibc fork ? In-Reply-To: <4A036082.8000107@fedoraproject.org> References: <4A02F8D3.2010807@poolshark.org> <4A036082.8000107@fedoraproject.org> Message-ID: <4A0571FF.4050400@poolshark.org> On 05/08/2009 12:28 AM, Rahul Sundaram wrote: > On 05/07/2009 08:35 PM, Denis Leroy wrote: >> http://www.eglibc.org/home >> >> So are we moving to eglibc as well ? :-) >> >> So what happened ? Overreaction from Debian guy, or poor community >> management from RH guy ? > > eglibc FAQ claims that it wants to be binary and source compatible and > will rebase regularly with Glibc and that doesn't seem much of a fork. > Seems more like a people conflict. Good luck to them. Indeed good luck to them. But if the eglibc fork stands (unlikely IMO) and Canonical switches as well, I'd like to see RH fire Drepper. From sundaram at fedoraproject.org Sat May 9 12:28:40 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 09 May 2009 17:58:40 +0530 Subject: glibc fork ? In-Reply-To: <4A0571FF.4050400@poolshark.org> References: <4A02F8D3.2010807@poolshark.org> <4A036082.8000107@fedoraproject.org> <4A0571FF.4050400@poolshark.org> Message-ID: <4A0576F8.6070009@fedoraproject.org> On 05/09/2009 05:37 PM, Denis Leroy wrote: > But if the eglibc fork stands (unlikely IMO) and Canonical switches as > well, I'd like to see RH fire Drepper. If eglibc has to continously rebase from glibc, glibc has to continue it's development. Considering that Ubuntu is heavily based on Debian, it is rather odd to connect Canonical's dependencies to your desire for someone to lose their job. At this point, this doesn't appear to much of a community discussion. Rahul From rawhide at fedoraproject.org Sat May 9 12:52:43 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Sat, 9 May 2009 12:52:43 +0000 (UTC) Subject: rawhide report: 20090509 changes Message-ID: <20090509125243.C115A1B8003@releng2.fedora.phx.redhat.com> Compose started at Sat May 9 06:15:03 UTC 2009 Updated Packages: NetworkManager-0.7.1-4.git20090414.fc11 --------------------------------------- * Tue May 05 2009 Adam Jackson 1:0.7.1-4.git20090414 - nm-save-the-leases.patch: Use per-connection lease files, and don't delete them on interface deactivate. Terminal-0.2.12-1.fc11 ---------------------- * Sun Apr 19 2009 Kevin Fenzi - 0.2.12-1 - Update to 0.2.12 Thunar-1.0.1-1.fc11 ------------------- * Sun Apr 19 2009 Kevin Fenzi - 1.0.1-1 - Update to 1.0.1 astronomy-backgrounds-1.0-2.fc11 -------------------------------- * Fri May 08 2009 Michael Schwendt - 1.0-2 - Fix installation of all files. - Fix file/dir conflict (#496905). cups-1.4-0.b2.16.fc11 --------------------- * Thu May 07 2009 Ville Skytt?? - 1:1.4-0.b2.16 - Avoid stripping binaries before rpmbuild creates the -debuginfo subpackage. exo-0.3.101-1.fc11 ------------------ * Sun Apr 19 2009 Kevin Fenzi - 0.3.101-1 - Update to 0.3.101 fontconfig-2.6.99.behdad.20090508-1.fc11 ---------------------------------------- * Fri May 08 2009 Behdad Esfahbod - 2.6.99.behdad.20090508-1 - Update to 2.6.99.behdad.20090508 - Resolves #497984 libxfce4menu-4.6.1-1.fc11 ------------------------- * Sun Apr 19 2009 Kevin Fenzi - 4.6.1-1 - Update to 4.6.1 libxfce4util-4.6.1-1.fc11 ------------------------- * Sun Apr 19 2009 Kevin Fenzi - 4.6.1-1 - Update to 4.6.1 libxfcegui4-4.6.1-1.fc11 ------------------------ * Sun Apr 19 2009 Kevin Fenzi - 4.6.1-1 - Update to 4.6.1 parted-1.8.8-17.fc11 -------------------- * Fri May 08 2009 Joel Granados - 1.8.8-17 - Be consistent in the creation of metadata partitions for msdos labels (#498137) plymouth-0.7.0-0.2009.05.08.1.fc11 ---------------------------------- * Fri May 08 2009 Ray Strode 0.7.0-0.2009.05.08.1 - Update to "plugin-rework" branch from git xfce-utils-4.6.1-1.fc11 ----------------------- * Sun Apr 19 2009 Kevin Fenzi - 4.6.1-1 - Update to 4.6.1 xfce4-appfinder-4.6.1-1.fc11 ---------------------------- * Sun Apr 19 2009 Kevin Fenzi - 4.6.1-1 - Update to 4.6.1 xfce4-mixer-4.6.1-1.fc11 ------------------------ * Sun Apr 19 2009 Kevin Fenzi - 4.6.1-1 - Update to 4.6.1 xfce4-panel-4.6.1-1.fc11 ------------------------ * Sun Apr 19 2009 Kevin Fenzi - 4.6.1-1 - Update to 4.6.1 xfce4-settings-4.6.1-1.fc11 --------------------------- * Sun Apr 19 2009 Kevin Fenzi - 4.6.1-1 - Update to 4.6.1 xfconf-4.6.1-1.fc11 ------------------- * Sun Apr 19 2009 Kevin Fenzi - 4.6.1-1 - Update to 4.6.1 xfdesktop-4.6.1-1.fc11 ---------------------- * Sun Apr 19 2009 Kevin Fenzi - 4.6.1-1 - Update to 4.6.1 xfwm4-4.6.1-1.fc11 ------------------ * Sun Apr 19 2009 Kevin Fenzi - 4.6.1-1 - Update to 4.6.1 xorg-x11-drv-ati-6.12.2-13.fc11 ------------------------------- * Thu May 07 2009 Adam Jackson 6.12.2-13 - radeon-6.12.2-lvds-default-modes.patch: Add default modes to the LVDS mode list if we got no EDID from the kernel. * Wed May 06 2009 Dave Airlie 6.12.2-12 - radeon-6.12.2-rs690-hack.patch - workaround rs690 hangs with firefox safely xorg-x11-drv-savage-2.2.1-1.fc11 -------------------------------- * Fri May 08 2009 Adam Jackson 2.2.1-1 - savage 2.2.1 Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 22 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From christoph.wickert at googlemail.com Sat May 9 13:12:31 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Sat, 09 May 2009 15:12:31 +0200 Subject: More broen deps in rawhide (Re: rawhide report: 20090509 changes) In-Reply-To: <20090509125243.C115A1B8003@releng2.fedora.phx.redhat.com> References: <20090509125243.C115A1B8003@releng2.fedora.phx.redhat.com> Message-ID: <1241874751.3534.62.camel@localhost.localdomain> Am Samstag, den 09.05.2009, 12:52 +0000 schrieb Rawhide Report: > > Broken deps for ppc64 > ---------------------------------------------------------- > cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 Is this supposed to be all? In koji I also see this one for days now: > DEBUG util.py:256: webkitgtk-1.1.4-1.fc12.x86_64 from build has depsolving problems > DEBUG util.py:256: --> Missing Dependency: libicuuc.so.40()(64bit) is needed by package webkitgtk-1.1.4-1.fc12.x86_64 (build) > DEBUG util.py:256: webkitgtk-1.1.4-1.fc12.x86_64 from build has depsolving problems > DEBUG util.py:256: --> Missing Dependency: libicudata.so.40()(64bit) is needed by package webkitgtk-1.1.4-1.fc12.x86_64 (build) > DEBUG util.py:256: webkitgtk-1.1.4-1.fc12.x86_64 from build has depsolving problems > DEBUG util.py:256: --> Missing Dependency: libicui18n.so.40()(64bit) is needed by package webkitgtk-1.1.4-1.fc12.x86_64 (build) > DEBUG util.py:256: Error: Missing Dependency: libicui18n.so.40()(64bit) is needed by package webkitgtk-1.1.4-1.fc12.x86_64 (build) > DEBUG util.py:256: Error: Missing Dependency: libicuuc.so.40()(64bit) is needed by package webkitgtk-1.1.4-1.fc12.x86_64 (build) > DEBUG util.py:256: You could try using --skip-broken to work around the problem > DEBUG util.py:256: Error: Missing Dependency: libicudata.so.40()(64bit) is needed by package webkitgtk-1.1.4-1.fc12.x86_64 (build) Task Info: http://koji.fedoraproject.org/koji/taskinfo?taskID=1344911 Build Info: http://koji.fedoraproject.org/koji/buildinfo?buildID=101144 From mtasaka at ioa.s.u-tokyo.ac.jp Sat May 9 13:20:34 2009 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sat, 09 May 2009 22:20:34 +0900 Subject: More broen deps in rawhide (Re: rawhide report: 20090509 changes) In-Reply-To: <1241874751.3534.62.camel@localhost.localdomain> References: <20090509125243.C115A1B8003@releng2.fedora.phx.redhat.com> <1241874751.3534.62.camel@localhost.localdomain> Message-ID: <4A058322.6000605@ioa.s.u-tokyo.ac.jp> Christoph Wickert wrote, at 05/09/2009 10:12 PM +9:00: > Am Samstag, den 09.05.2009, 12:52 +0000 schrieb Rawhide Report: > >> Broken deps for ppc64 >> ---------------------------------------------------------- >> cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 > > Is this supposed to be all? In koji I also see this one for days now: > >> DEBUG util.py:256: webkitgtk-1.1.4-1.fc12.x86_64 from build has depsolving problems >> DEBUG util.py:256: --> Missing Dependency: libicuuc.so.40()(64bit) is needed by package webkitgtk-1.1.4-1.fc12.x86_64 (build) > > Task Info: http://koji.fedoraproject.org/koji/taskinfo?taskID=1344911 > Build Info: http://koji.fedoraproject.org/koji/buildinfo?buildID=101144 Currently rawhide = F-11 i.e. not dist-f12. Regards, Mamoru From debarshi.ray at gmail.com Sat May 9 13:27:14 2009 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Sat, 9 May 2009 18:57:14 +0530 Subject: glibc fork ? In-Reply-To: <20090507215700.GA10303@amd.home.annexia.org> References: <4A0354F1.7030607@gmail.com> <20090507215700.GA10303@amd.home.annexia.org> Message-ID: <3170f42f0905090627qfe0c078qb2dbb223cb4a6cdd@mail.gmail.com> > At the same time, Fedora could be useful in other markets like > netbooks, which have similarities to embedded systems, such as small > memory or disk footprints, and ARM chips. I am tempted to ask how this affects the fedora-arm effort? A couple of years ago, I had seen a presentation where uclibc was mentioned as the choice for fedora-arm. I don't know what the current status is, though. Cheers, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig From mtasaka at ioa.s.u-tokyo.ac.jp Sat May 9 14:32:51 2009 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sat, 09 May 2009 23:32:51 +0900 Subject: More broen deps in rawhide (Re: rawhide report: 20090509 changes) In-Reply-To: <4A058322.6000605@ioa.s.u-tokyo.ac.jp> References: <20090509125243.C115A1B8003@releng2.fedora.phx.redhat.com> <1241874751.3534.62.camel@localhost.localdomain> <4A058322.6000605@ioa.s.u-tokyo.ac.jp> Message-ID: <4A059413.3020107@ioa.s.u-tokyo.ac.jp> Mamoru Tasaka wrote, at 05/09/2009 10:20 PM +9:00: > Christoph Wickert wrote, at 05/09/2009 10:12 PM +9:00: >> Am Samstag, den 09.05.2009, 12:52 +0000 schrieb Rawhide Report: >> >>> Broken deps for ppc64 >>> ---------------------------------------------------------- >>> cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 >> Is this supposed to be all? In koji I also see this one for days now: >> >>> DEBUG util.py:256: webkitgtk-1.1.4-1.fc12.x86_64 from build has depsolving problems >>> DEBUG util.py:256: --> Missing Dependency: libicuuc.so.40()(64bit) is needed by package webkitgtk-1.1.4-1.fc12.x86_64 (build) >> Task Info: http://koji.fedoraproject.org/koji/taskinfo?taskID=1344911 >> Build Info: http://koji.fedoraproject.org/koji/buildinfo?buildID=101144 > > Currently rawhide = F-11 i.e. not dist-f12. Anyway I rebuilt webkitgtk against new icu on F-12. Regards, Mamoru From chris at tylers.info Sat May 9 15:05:14 2009 From: chris at tylers.info (Chris Tyler) Date: Sat, 09 May 2009 11:05:14 -0400 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241866003.2910.80.camel@macbook.infradead.org> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <200905081059.20191.mhlavink@redhat.com> <1241795878.3209.88.camel@localhost.localdomain> <20090508153102.GA15821@bludgeon.org> <1241798647.3209.95.camel@localhost.localdomain> <4A04D59A.20006@freenet.de> <1241831621.2923.552.camel@adam.local.net> <1241866003.2910.80.camel@macbook.infradead.org> Message-ID: <1241881514.30126.2.camel@concord3.proximity.on.ca> On Sat, 2009-05-09 at 11:46 +0100, David Woodhouse wrote: > By including the option to add the F11 updates repo at install time. > > Er, can't we already do that?? > ? As long as the repo isn't on NFS, that is. And as long as you're using a wired (and not wireless) connection (tested yesterday). -Chris From jkeating at redhat.com Sat May 9 15:28:22 2009 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 09 May 2009 08:28:22 -0700 Subject: OpenOffice 3.1 In-Reply-To: <1241869878.2551.1439.camel@Vain> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> Message-ID: <1241882902.2886.50.camel@localhost.localdomain> On Sat, 2009-05-09 at 12:51 +0100, Caol?n McNamara wrote: > Well, in this case updating F-10 3.1 properly would require updating a > load of other stuff as well with all the risks and work that entails. > But even if that wasn't the case I generally don't bump major versions > of OOo in a released product. I see our fedora release cycle as ones of > iterative stable complete releases, rather than one which has an > always-open pool of stable packages which always contains the latest > stable version of a package. i.e. F-10 was history as soon as it was > released, and F-11 is likewise almost dead to me already :-) Not that I > won't fix bugs in them, just that I don't see them as live development > releases. I thank you for this! -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Sat May 9 15:34:40 2009 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 09 May 2009 08:34:40 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241866003.2910.80.camel@macbook.infradead.org> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <200905081059.20191.mhlavink@redhat.com> <1241795878.3209.88.camel@localhost.localdomain> <20090508153102.GA15821@bludgeon.org> <1241798647.3209.95.camel@localhost.localdomain> <4A04D59A.20006@freenet.de> <1241831621.2923.552.camel@adam.local.net> <1241866003.2910.80.camel@macbook.infradead.org> Message-ID: <1241883280.2886.52.camel@localhost.localdomain> On Sat, 2009-05-09 at 11:46 +0100, David Woodhouse wrote: > By including the option to add the F11 updates repo at install time. > > Er, can't we already do that?? Not if you're installing from DVD or split media. There is still peril there with the installation ordering due to each piece of media needing to be a single transaction, and the network stuff is added later which causes very strange install orders if say coreutils is updated and on the network. Also it requires network during install which not everybody has, and a fast mirror which not everybody has. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Sat May 9 15:35:52 2009 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 09 May 2009 08:35:52 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: References: <1241718097.3209.11.camel@localhost.localdomain> <4A033B7F.1030801@redhat.com> <4A0348D3.8000302@gmail.com> <4A038D53.7040200@redhat.com> <1241806113.2923.512.camel@adam.local.net> <604aa7910905081417l4bd77c74l60d4631d76b4ddf1@mail.gmail.com> <1241824854.2923.526.camel@adam.local.net> Message-ID: <1241883352.2886.53.camel@localhost.localdomain> On Sat, 2009-05-09 at 12:43 +0200, Kevin Kofler wrote: > Panu Matilainen wrote: > > There already is an accurate way of tracking this: package signatures. For > > example, this'll give you the packages that came from F10 testing: > > But hasn't this distinction be dropped in F11? AFAIK everything is signed > with the same key now. > > Kevin Kofler Yes, we dropped the difference. Part of the reason is that while the key may change on the rpm as it goes from testing to stable, if you installed it from testing the key /won't/ change on your rpm database. So it would still look like you have a ton of 'testing' packages when in reality they may have been moved to stable. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kevin.kofler at chello.at Sat May 9 15:58:00 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 09 May 2009 17:58:00 +0200 Subject: 182 pending F11 stable updates. WTF? References: <1241718097.3209.11.camel@localhost.localdomain> <200905071959.22508.opensource@till.name> <1241720728.3209.12.camel@localhost.localdomain> Message-ID: Jesse Keating wrote: > On Thu, 2009-05-07 at 19:59 +0200, Till Maas wrote: >> Afaik, requests to updates-testing were not processed for F11, e.g. for >> one or two of my new packages I requested updates-testing for F9, F10 and >> F11 at the same time, got positive feedback / no negative feedback for F9 >> or F10 and then moved them all to stable at the same time, resp. canceled >> the testing request for F11 and made it to a stable one. I guess this >> affects also other packages, that were updated in F9 or F10 and F11, to >> have a working update path from FX with updates to FX+1 with updates. > > Upgrade paths are a concern yes, however our upgrade path stuff is so > busted anyway when doing upgrades to the next release that... well... > *sigh*. Perhaps this is just a case of too many streams, and trying to > let people do things ahead of time. But really, what's the problem there? If the exact same package built from the exact same specfile worked fine on F9 and F10, chances are high it'll also work fine on F11. Of course it's not 100% as there can be things like GCC miscompilations, bugs in libraries or screwed-up specfile conditionals, but in general what works on Fn also works on Fm. Kevin Kofler From menthos at menthos.com Sat May 9 15:58:50 2009 From: menthos at menthos.com (Christian Rose) Date: Sat, 9 May 2009 17:58:50 +0200 Subject: OpenOffice 3.1 In-Reply-To: <1241882902.2886.50.camel@localhost.localdomain> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> Message-ID: <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> On 5/9/09, Jesse Keating wrote: > On Sat, 2009-05-09 at 12:51 +0100, Caol?n McNamara wrote: > > Well, in this case updating F-10 3.1 properly would require updating a > > load of other stuff as well with all the risks and work that entails. > > But even if that wasn't the case I generally don't bump major versions > > of OOo in a released product. I see our fedora release cycle as ones of > > iterative stable complete releases, rather than one which has an > > always-open pool of stable packages which always contains the latest > > stable version of a package. i.e. F-10 was history as soon as it was > > released, and F-11 is likewise almost dead to me already :-) Not that I > > won't fix bugs in them, just that I don't see them as live development > > releases. > > I thank you for this! +1 IMHO, Fedora needs more maintainers who think of whole releases as stable release sets. Christian From kevin.kofler at chello.at Sat May 9 15:59:51 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 09 May 2009 17:59:51 +0200 Subject: OpenOffice 3.1 References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> Message-ID: Caol?n McNamara wrote: > But even if that wasn't the case I generally don't bump major versions > of OOo in a released product. Is 3.0 -> 3.1 really that major? I must say I prefer the way packages like the kernel or KDE are handled, where this kind of updates are pushed. Kevin Kofler From kevin.kofler at chello.at Sat May 9 16:05:59 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 09 May 2009 18:05:59 +0200 Subject: OpenOffice 3.1 References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> Message-ID: Christian Rose wrote: > IMHO, Fedora needs more maintainers who think of whole releases as > stable release sets. "Stable release sets" doesn't mean "no updates", it means "no updates which break things". Normally, 3.0->3.1 type upgrades aren't the kind of updates which cause regressions or compatibility issues. If you don't want to ever get new versions, there are plenty of distros with such a policy. Kevin Kofler From xose.vazquez at gmail.com Sat May 9 16:15:46 2009 From: xose.vazquez at gmail.com (Xose Vazquez Perez) Date: Sat, 09 May 2009 18:15:46 +0200 Subject: glibc fork ? Message-ID: <4A05AC32.7090600@gmail.com> Denis Leroy wrote: > Indeed good luck to them. > > But if the eglibc fork stands (unlikely IMO) and Canonical switches as > well, I'd like to see RH fire Drepper. *THIS IS NOT A FORK* ! only is a variant optimised for embedded devices. and Debian *already* did it, on 05 May 2009: ---cut--- eglibc (2.9-11) unstable; urgency=low * Switch to Embedded GLIBC (EGLIBC), sources taken from the 2.9 branch. - Update all/submitted-readme-version.diff. - Update any/local-bashisms.diff. - Update any/cvs-bz9697-posix-regcomp.diff. - Update any/cvs-binutils_2.20.diff. - Drop any/local-makeconfig.diff. - Drop any/submitted-getcwd-sys_param_h.diff (merged in eglibc). - Add any/submitted-cross-zic.diff to fix biarch builds. - Add any/submitted-nss-nsswitch.diff to fix linuxthreads builds. - Add any/submitted-install-map-files.diff to fix GNU/Hurd builds. - More tests of flavour/biarch builds are run, update the expected testsuite results accordingly. - Rename glibc-source package into eglibc-source. -- Aurelien Jarno Tue, 05 May 2009 09:54:14 +0200 glibc (2.9-10) unstable; urgency=low [ Samuel Thibault ] * hurd-i386/local-pthread_posix-option.diff: Set _POSIX_TIMEOUTS to 200112 too, to fix gthread compilation in gcc-4.4 [ Petr Salinger ] * fix up GNU/kFreeBSD specific macro LIST_FOREACH_SAFE. [ Aurelien Jarno ] * any/cvs-broken-dns.diff: backport more parts from upstream. * any/submitted-broken-dns.diff: new patch to not raise an error if one query returns NOTIMP or FORMERR and the other NOERROR. Closes: #526823. -- Aurelien Jarno Tue, 05 May 2009 01:39:50 +0200 ---end--- regards, -- Polycommander, Erkowit, Urquiola, Andros Patria, Cason, Aegean Sea, Prestige, ... From fedora at leemhuis.info Sat May 9 16:41:24 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 09 May 2009 18:41:24 +0200 Subject: best practices for updates in stable releases (was: Re: OpenOffice 3.1) In-Reply-To: <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> Message-ID: <4A05B234.2020608@leemhuis.info> On 09.05.2009 17:58, Christian Rose wrote: > On 5/9/09, Jesse Keating wrote: >> On Sat, 2009-05-09 at 12:51 +0100, Caol?n McNamara wrote: >> > Well, in this case updating F-10 3.1 properly would require updating a >> > load of other stuff as well with all the risks and work that entails. >> > But even if that wasn't the case I generally don't bump major versions >> > of OOo in a released product. I see our fedora release cycle as ones of >> > iterative stable complete releases, rather than one which has an >> > always-open pool of stable packages which always contains the latest >> > stable version of a package. i.e. F-10 was history as soon as it was >> > released, and F-11 is likewise almost dead to me already :-) Not that I >> > won't fix bugs in them, just that I don't see them as live development >> > releases. >> I thank you for this! > +1 > > IMHO, Fedora needs more maintainers who think of whole releases as > stable release sets. What Fedora IMHO needs way more is a written document "best practices for updates in stable releases" that people actually follow. Right now some packages in Fedora get often updated while others don't. That makes no side happy, as those that prefer to get updates to the latest version will sometimes miss them (e.g. the OpenOffice case discussed here might be such a case) while those that don't want them sometimes can't avoid them (e.g. major kernel updates from 2.6.27 to 2.6.29 that fix security bugs). That sucks. Chose a side and then try to stick to it. And sure, the decision when to update or not in the end needs to be done by the package maintainers. There always will be special cases where updates/not to update is the better decision even if the guidelines say something else. CU knurd From lists at sapience.com Sat May 9 17:12:29 2009 From: lists at sapience.com (Mail Llists) Date: Sat, 09 May 2009 13:12:29 -0400 Subject: OpenOffice 3.1 In-Reply-To: <1241882902.2886.50.camel@localhost.localdomain> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> Message-ID: <4A05B97D.9010705@sapience.com> On 05/09/2009 11:28 AM, Jesse Keating wrote: > On Sat, 2009-05-09 at 12:51 +0100, Caol?n McNamara wrote: > >> Well, in this case updating F-10 3.1 properly would require updating a >> load of other stuff as well with all the risks and work that entails. >> But even if that wasn't the case I generally don't bump major versions >> of OOo in a released product. I see our fedora release cycle as ones of >> iterative stable complete releases, rather than one which has an >> always-open pool of stable packages which always contains the latest >> stable version of a package. i.e. F-10 was history as soon as it was >> released, and F-11 is likewise almost dead to me already :-) Not that I >> won't fix bugs in them, just that I don't see them as live development >> releases. >> > I thank you for this! > > -2 - I dont thank you at all. That is silly. We are happy to have kernel updates, and a minor but useful openoffice update is hardly a huge risk ... put it in testing and let people see if any issues arise - i'd be happy to try it from testing. I might agree that we shud leave openoffice 4.1 for fedora 12 ... but 3.0 to 3.1 .. sighs ... g/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis at poolshark.org Sat May 9 17:19:18 2009 From: denis at poolshark.org (Denis Leroy) Date: Sat, 09 May 2009 19:19:18 +0200 Subject: glibc fork ? In-Reply-To: <4A05AC32.7090600@gmail.com> References: <4A05AC32.7090600@gmail.com> Message-ID: <4A05BB16.5070005@poolshark.org> On 05/09/2009 06:15 PM, Xose Vazquez Perez wrote: > Denis Leroy wrote: > >> Indeed good luck to them. >> >> But if the eglibc fork stands (unlikely IMO) and Canonical switches as >> well, I'd like to see RH fire Drepper. > > *THIS IS NOT A FORK* ! only is a variant optimised for embedded devices. No it's clearly meant to be more than that. Just read the original announcement blog post : http://blog.aurel32.net/?p=47 -denis From jonstanley at gmail.com Sat May 9 17:24:24 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Sat, 9 May 2009 13:24:24 -0400 Subject: FESco meeting summary for 20090507 Message-ID: FESCo meeting summary for 2009/05/08 == Members Present == * Jon Stanley (jds2001) * Kevin Fenzi (nirik) * Dan Horak (sharkcz) * Josh Boyer (jwb) * Brian Pepple (bpepple) * Bill Nottingham (notting) * David Woodhouse (dwmw2) * Jarod Wilson (j-rod) == Members Absent == * Dennis Gilmore (dgilmore) == Fedora 12 Schedule == FESCo approved the Fedora 12 schedule proposal by rel-eng, which includes dropping the Alpha milestone, and a final release date of 11/3/09 == liblvm == FESCo approved this feature, on the basis that it is a new capability developed by Fedora and first present in Fedora. == Deactivated maintainers == FESCo approved orphaning packages owned by deactivated maintainers == Maven upgrade == Rel-eng brought a proposal during the open floor to allow the inclusion of packages in a special tag (something like dist-f12-maven) in preparation for the maven upgrade that had yet to be through a formal package review. These packages are not yet in a state suitable for inclusion in Fedora, and the Java team would prefer to get them functional prior to cleaning up the packaging. FESCo approved this propsal, with the caveat that the packages have to go through a mini-review prior to inclusiion in this tag and therefore being used in buildroots. This mini-review will be defined by FPC, and will include things such as checking for lack of binaries, and legal concerns. == Allow all packagers to commit to specific packages == This was briefly discussed, will be brought up for a vote next week. FESCo is generally fine with the idea, however, some security measures will need to be put in place prior to actual implementation == PPC strawman == FESCo conducted a brief discussion of moving PowerPC to a secondary architecture for Fedora 12. The general consensus is that since Fedora 12 development cycle has already begun, it is not appropriate for Fedora 12. However, for Fedora 13, FESCo is in favor of the idea. NB: THIS IS NOT AN OFFICIAL VOTE OR POSISTION, THAT WILL COME NEXT WEEK. From jkeating at redhat.com Sat May 9 17:31:51 2009 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 09 May 2009 10:31:51 -0700 Subject: best practices for updates in stable releases (was: Re: OpenOffice 3.1) In-Reply-To: <4A05B234.2020608@leemhuis.info> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <4A05B234.2020608@leemhuis.info> Message-ID: <1241890311.2886.63.camel@localhost.localdomain> On Sat, 2009-05-09 at 18:41 +0200, Thorsten Leemhuis wrote: > > What Fedora IMHO needs way more is a written document "best practices > for updates in stable releases" that people actually follow. > > Right now some packages in Fedora get often updated while others don't. > That makes no side happy, as those that prefer to get updates to the > latest version will sometimes miss them (e.g. the OpenOffice case > discussed here might be such a case) while those that don't want them > sometimes can't avoid them (e.g. major kernel updates from 2.6.27 to > 2.6.29 that fix security bugs). That sucks. Chose a side and then try to > stick to it. > > And sure, the decision when to update or not in the end needs to be done > by the package maintainers. There always will be special cases where > updates/not to update is the better decision even if the guidelines say > something else. http://fedoraproject.org/wiki/PackageMaintainers/Package_update_guidelines we have this. What we don't seem to have is everybody following it. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Sat May 9 17:33:43 2009 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 09 May 2009 10:33:43 -0700 Subject: OpenOffice 3.1 In-Reply-To: <4A05B97D.9010705@sapience.com> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <4A05B97D.9010705@sapience.com> Message-ID: <1241890423.2886.65.camel@localhost.localdomain> On Sat, 2009-05-09 at 13:12 -0400, Mail Llists wrote: > -2 - I dont thank you at all. > > That is silly. We are happy to have kernel updates, and a minor but > useful openoffice update is hardly a huge risk ... put it in testing and > let people see if any issues arise - i'd be happy to try it from testing. > > I might agree that we shud leave openoffice 4.1 for fedora 12 ... > but 3.0 to 3.1 .. sighs ... Numbers are generally meaningless. What's "3.0" to "3.1" for one project could be a completely different kind of change in another project. More to the point, the maintainer knew that such an update would require updating many other things, greatly increasing the risk of introduced bugs. The maintainer made a decision which correctly follows http://fedoraproject.org/wiki/PackageMaintainers/Package_update_guidelines . -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From drago01 at gmail.com Sat May 9 17:34:38 2009 From: drago01 at gmail.com (drago01) Date: Sat, 9 May 2009 19:34:38 +0200 Subject: FESco meeting summary for 20090507 In-Reply-To: References: Message-ID: On Sat, May 9, 2009 at 7:24 PM, Jon Stanley wrote: > FESCo meeting summary for 2009/05/08 What happened to this https://fedorahosted.org/fesco/ticket/142 ? From jkeating at redhat.com Sat May 9 17:35:41 2009 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 09 May 2009 10:35:41 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: References: <1241718097.3209.11.camel@localhost.localdomain> <200905071959.22508.opensource@till.name> <1241720728.3209.12.camel@localhost.localdomain> Message-ID: <1241890541.2886.66.camel@localhost.localdomain> On Sat, 2009-05-09 at 17:58 +0200, Kevin Kofler wrote: > Of course it's not 100% as there can be things like > GCC miscompilations, bugs in libraries or screwed-up specfile conditionals, > but in general what works on Fn also works on Fm. You hit upon some of them. Fn is not Fm, the contents, particularly the buildroot contents, can be vastly different. The package interactions can be different as well. Without actually testing on Fm you can't reasonably assume that if it worked on Fn it'll work on Fm. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From xjakub at fi.muni.cz Sat May 9 17:36:03 2009 From: xjakub at fi.muni.cz (Milos Jakubicek) Date: Sat, 09 May 2009 19:36:03 +0200 Subject: FESco meeting summary for 20090507 In-Reply-To: References: Message-ID: <4A05BF03.6070508@fi.muni.cz> Hi, Dne 9.5.2009 19:24, Jon Stanley wrote: > FESCo meeting summary for 2009/05/08 ... > > == Deactivated maintainers == > > FESCo approved orphaning packages owned by deactivated maintainers > Could you please send then a list of packages that are going to be orphaned? Thanks, Milos From christoph.wickert at googlemail.com Sat May 9 17:46:50 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Sat, 09 May 2009 19:46:50 +0200 Subject: FESco meeting summary for 20090507 In-Reply-To: <4A05BF03.6070508@fi.muni.cz> References: <4A05BF03.6070508@fi.muni.cz> Message-ID: <1241891211.9577.0.camel@localhost.localdomain> Am Samstag, den 09.05.2009, 19:36 +0200 schrieb Milos Jakubicek: > > == Deactivated maintainers == > > > > FESCo approved orphaning packages owned by deactivated maintainers > > > > Could you please send then a list of packages that are going to be orphaned? Most likely: http://toshio.fedorapeople.org/pkg-orphans.txt > Thanks, > Milos Regards, Christoph From christoph.wickert at googlemail.com Sat May 9 17:52:41 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Sat, 09 May 2009 19:52:41 +0200 Subject: FESco meeting summary for 20090507 In-Reply-To: <4A05BF03.6070508@fi.muni.cz> References: <4A05BF03.6070508@fi.muni.cz> Message-ID: <1241891561.9577.3.camel@localhost.localdomain> Am Samstag, den 09.05.2009, 19:36 +0200 schrieb Milos Jakubicek: > > == Deactivated maintainers == > > > > FESCo approved orphaning packages owned by deactivated maintainers > > > > Could you please send then a list of packages that are going to be orphaned? Most likely: http://toshio.fedorapeople.org/pkg-orphans.txt >From this list: > audacious-plugins-docklet yufan [] This package never existed. Upstream disappeared, maintainer is AWOL and it was never built, see http://koji.fedoraproject.org/koji/packageinfo?packageID=4520 How to get rid of this zombie? Regards, Christoph From lists at sapience.com Sat May 9 17:59:35 2009 From: lists at sapience.com (Mail Lists) Date: Sat, 09 May 2009 13:59:35 -0400 Subject: best practices for updates in stable releases In-Reply-To: <1241890311.2886.63.camel@localhost.localdomain> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <4A05B234.2020608@leemhuis.info> <1241890311.2886.63.camel@localhost.localdomain> Message-ID: <4A05C487.9010401@sapience.com> On 05/09/2009 01:31 PM, Jesse Keating wrote: > On Sat, 2009-05-09 at 18:41 +0200, Thorsten Leemhuis wrote: >> >> What Fedora IMHO needs way more is a written document "best practices >> for updates in stable releases" that people actually follow. >> >> Right now some packages in Fedora get often updated while others don't. >> That makes no side happy, as those that prefer to get updates to the >> latest version will sometimes miss them (e.g. the OpenOffice case >> discussed here might be such a case) while those that don't want them >> sometimes can't avoid them (e.g. major kernel updates from 2.6.27 to >> 2.6.29 that fix security bugs). That sucks. Chose a side and then try to >> stick to it. >> >> And sure, the decision when to update or not in the end needs to be done >> by the package maintainers. There always will be special cases where >> updates/not to update is the better decision even if the guidelines say >> something else. > > http://fedoraproject.org/wiki/PackageMaintainers/Package_update_guidelines we have this. What we don't seem to have is everybody following it. > > I read this - openoffice 3.0 to 3.1 has been a long time in the works ... updating or not would both be consistent with those guidelines .. so what is your point exactly ? Or are trying to argue by obtuse reference? The point is, in this case, it may well be a reasonable update .. just as reasonable decisions have been made for many others. It is the maintainers decision - we just don't all have to agree ... ... reasonable people may disagree - but not with pedantry however. From fedora at leemhuis.info Sat May 9 18:05:07 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 09 May 2009 20:05:07 +0200 Subject: best practices for updates in stable releases In-Reply-To: <1241890311.2886.63.camel@localhost.localdomain> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <4A05B234.2020608@leemhuis.info> <1241890311.2886.63.camel@localhost.localdomain> Message-ID: <4A05C5D3.1030509@leemhuis.info> On 09.05.2009 19:31, Jesse Keating wrote: > On Sat, 2009-05-09 at 18:41 +0200, Thorsten Leemhuis wrote: >> What Fedora IMHO needs way more is a written document "best >> practices for updates in stable releases" that people actually >> follow. >> >> Right now some packages in Fedora get often updated while others >> don't. That makes no side happy, as those that prefer to get >> updates to the latest version will sometimes miss them (e.g. the >> OpenOffice case discussed here might be such a case) while those >> that don't want them sometimes can't avoid them (e.g. major kernel >> updates from 2.6.27 to 2.6.29 that fix security bugs). That sucks. >> Chose a side and then try to stick to it. >> >> And sure, the decision when to update or not in the end needs to be >> done by the package maintainers. There always will be special cases >> where updates/not to update is the better decision even if the >> guidelines say something else. > > http://fedoraproject.org/wiki/PackageMaintainers/Package_update_guidelines > we have this. What we don't seem to have is everybody following it. Maybe that is - because the text is to vague - because lot of packagers don't agree with it and don't care much what some commitee decided - because updates of popular packages (like kernel or KDE) give users and packagers the impression that updating to the latest and greatest is normal - because there is no coordination/benevolent Dictator or packager education to bring people in line IMHO it's all of the above. CU knurd From jkeating at redhat.com Sat May 9 18:11:35 2009 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 09 May 2009 11:11:35 -0700 Subject: best practices for updates in stable releases In-Reply-To: <4A05C5D3.1030509@leemhuis.info> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <4A05B234.2020608@leemhuis.info> <1241890311.2886.63.camel@localhost.localdomain> <4A05C5D3.1030509@leemhuis.info> Message-ID: <1241892695.2886.69.camel@localhost.localdomain> On Sat, 2009-05-09 at 20:05 +0200, Thorsten Leemhuis wrote: > Maybe that is > > - because the text is to vague > > - because lot of packagers don't agree with it and don't care much what > some commitee decided > > - because updates of popular packages (like kernel or KDE) give users > and packagers the impression that updating to the latest and greatest is > normal > > - because there is no coordination/benevolent Dictator or packager > education to bring people in line > > IMHO it's all of the above. That may be true. However we've long maintained that maintainers should be the ones to make the decision, and we've tried to avoid such things as benevolent dictators. I think it would cause more harm than good. Perhaps a better strategy is more general education and gentle guiding, and redirecting of people that disagree with the Fedora policies. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Sat May 9 18:12:34 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 09 May 2009 11:12:34 -0700 Subject: FESco meeting summary for 20090507 In-Reply-To: References: Message-ID: <4A05C792.6010808@gmail.com> drago01 wrote: > On Sat, May 9, 2009 at 7:24 PM, Jon Stanley wrote: >> FESCo meeting summary for 2009/05/08 > > What happened to this https://fedorahosted.org/fesco/ticket/142 ? > The best way to get something on FESCo's docket with the current agenda planner seems to be to add the meeting keyword to the ticket. I've done this now so he should see it for next week's meeting. With something like this I'd suggest trying to show up for the meeting as well to answer questions and etc. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From fedora at leemhuis.info Sat May 9 18:21:06 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 09 May 2009 20:21:06 +0200 Subject: best practices for updates in stable releases In-Reply-To: <1241892695.2886.69.camel@localhost.localdomain> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <4A05B234.2020608@leemhuis.info> <1241890311.2886.63.camel@localhost.localdomain> <4A05C5D3.1030509@leemhuis.info> <1241892695.2886.69.camel@localhost.localdomain> Message-ID: <4A05C992.2080109@leemhuis.info> On 09.05.2009 20:11, Jesse Keating wrote: > On Sat, 2009-05-09 at 20:05 +0200, Thorsten Leemhuis wrote: >> Maybe that is >> >> - because the text is to vague >> >> - because lot of packagers don't agree with it and don't care much what >> some commitee decided >> >> - because updates of popular packages (like kernel or KDE) give users >> and packagers the impression that updating to the latest and greatest is >> normal >> >> - because there is no coordination/benevolent Dictator or packager >> education to bring people in line >> >> IMHO it's all of the above. > > That may be true. However we've long maintained that maintainers should > be the ones to make the decision, and we've tried to avoid such things > as benevolent dictators. I think it would cause more harm than good. > > Perhaps a better strategy is more general education and gentle guiding, > and redirecting of people that disagree with the Fedora policies. That basically what I meant and IMHO even what I said -- I didn't say it has to be a benevolent dictator. Or, IOW: There is a reason why there is a "/" between coordination and benevolent Dictator; maybe I should have made it a "|" to be more clear ;-) CU knurd From drago01 at gmail.com Sat May 9 18:23:23 2009 From: drago01 at gmail.com (drago01) Date: Sat, 9 May 2009 20:23:23 +0200 Subject: FESco meeting summary for 20090507 In-Reply-To: <4A05C792.6010808@gmail.com> References: <4A05C792.6010808@gmail.com> Message-ID: On Sat, May 9, 2009 at 8:12 PM, Toshio Kuratomi wrote: > drago01 wrote: >> On Sat, May 9, 2009 at 7:24 PM, Jon Stanley wrote: >>> FESCo meeting summary for 2009/05/08 >> >> What happened to this https://fedorahosted.org/fesco/ticket/142 ? >> > The best way to get something on FESCo's docket with the current agenda > planner seems to be to add the meeting keyword to the ticket. OK, will remember this for future tickets. >I've done > this now so he should see it for next week's meeting. Thanks. >?With something > like this I'd suggest trying to show up for the meeting as well to > answer questions and etc. Sure, if nothing unplanned comes up I should have time and will attend the meeting. From email.ahmedkamal at googlemail.com Sat May 9 18:36:00 2009 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sat, 9 May 2009 21:36:00 +0300 Subject: Guaranteeing running code is signed Message-ID: <3da3b5b40905091136s3dd92954kffde00706905a850@mail.gmail.com> Hi, Is there any technology in fedora, that enables me to ensure that ALL running code on a certain server (even code not installed from RPMs, such as say by a legacy admin), has been signed by redhat, and to warn me about un-signed code that is running or about to run. I am interested to verify a server is in a "known-good" state Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.badger at gmail.com Sat May 9 18:54:52 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 09 May 2009 11:54:52 -0700 Subject: FESco meeting summary for 20090507 In-Reply-To: <1241891561.9577.3.camel@localhost.localdomain> References: <4A05BF03.6070508@fi.muni.cz> <1241891561.9577.3.camel@localhost.localdomain> Message-ID: <4A05D17C.8030305@gmail.com> Christoph Wickert wrote: > Am Samstag, den 09.05.2009, 19:36 +0200 schrieb Milos Jakubicek: > >>> == Deactivated maintainers == >>> >>> FESCo approved orphaning packages owned by deactivated maintainers >>> >> Could you please send then a list of packages that are going to be orphaned? > > Most likely: http://toshio.fedorapeople.org/pkg-orphans.txt > I've updated this list. We're down to 91 packages. I'll perform the orphaning tomorrow. >>From this list: >> audacious-plugins-docklet yufan [] > > This package never existed. Upstream disappeared, maintainer is AWOL and > it was never built, see > http://koji.fedoraproject.org/koji/packageinfo?packageID=4520 > > How to get rid of this zombie? > If a package hasn't been built I can get rid of it by manually taking it out of pkgdb, koji, and cvs. This one, however, looks like it was actually built under a different name: https://koji.fedoraproject.org/koji/packageinfo?packageID=1350 Looks like the review didn't catch that the package name and Name: in the spec file didn't match. And it looks like you've applied the Package EOL Guidelines http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife to this so I think we're all set now. Note, the packagedb will have a way to retire packages soon. I'm presently working out bugs in the new version so that we can deploy it. We might have to figure out some new processes to make use of retiring and write some supplemental code (like code for pkgdb/cvs to do the dead.package dance) to make this fully effective. Thanks! -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From a.badger at gmail.com Sat May 9 19:10:35 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 09 May 2009 12:10:35 -0700 Subject: FESco meeting summary for 20090507 In-Reply-To: References: Message-ID: <4A05D52B.7050100@gmail.com> Jon Stanley wrote: > == Allow all packagers to commit to specific packages == > > This was briefly discussed, will be brought up for a vote next week. > FESCo is generally fine with the idea, however, some security measures > will need to be put in place prior to actual implementation > I updated the ticket with notes from teh meeting: https://fedorahosted.org/fesco/ticket/108#comment:9 One thing that was mentioned was the lack of fs acls at the moment. After looking at what we have now, I'm not sure that fs acls fix anything that's not also broken currently. Currently: * the cvs repository has no fs acls * unix group for all directories is set to packager with a sticky group bit. * the cvs acl script limits who can actually commit to packages to @provenpackager and the specific people involved. Implementation-wise, the proposal would allow the cvs acl script to have @packager as another allowed group so people who are just in the packager group can commit to a specific package. I can see fs acls being used to lock down our repo against bugs in the cvs acl script or being used to replace the cvs acl script. But that seems to be somewhat separate from the proposal. I don't think it would solve anything specific to the proposal but could make things more secure for both the current and proposed method. notting, do you see something that I don't? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From bochecha at fedoraproject.org Sat May 9 19:12:00 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Sat, 9 May 2009 21:12:00 +0200 Subject: Guaranteeing running code is signed In-Reply-To: <3da3b5b40905091136s3dd92954kffde00706905a850@mail.gmail.com> References: <3da3b5b40905091136s3dd92954kffde00706905a850@mail.gmail.com> Message-ID: <2d319b780905091212x531acea1v837e28429d901601@mail.gmail.com> Hi, > Is there any technology in fedora, that enables me to ensure that ALL > running code on a certain server (even code not installed from RPMs, such as > say by a legacy admin), has been signed by redhat, and to warn me about > un-signed code that is running or about to run. I am interested to verify a > server is in a "known-good" state I don't know of any ? One True Solution ?, but you could use things like : $ rpm -qaV -> this will list all files modified _after_ they were installed via RPM $ rpm -qf -> this will tell you the package that this file belongs to You can then use the ? --queryformat ? option of RPM to get various informations about a package, for example where did it come from. For files installed not using RPM, I'm not sure how to verify this, but as Fedora only provides files in RPMs, I'm pretty confident that no file outside a RPM will be signed by Fedora. For RedHat, I have no idea, but you are on a Fedora mailing-list ;) ---------- Mathieu Bridon (bochecha) From Fedora at FamilleCollet.com Sat May 9 19:15:09 2009 From: Fedora at FamilleCollet.com (Remi Collet) Date: Sat, 09 May 2009 21:15:09 +0200 Subject: FESco meeting summary for 20090507 In-Reply-To: <4A05D17C.8030305@gmail.com> References: <4A05BF03.6070508@fi.muni.cz> <1241891561.9577.3.camel@localhost.localdomain> <4A05D17C.8030305@gmail.com> Message-ID: <4A05D63D.1050400@FamilleCollet.com> Le 09/05/2009 20:54, Toshio Kuratomi a ?crit : >>> Could you please send then a list of packages that are going to be orphaned? >> Most likely: http://toshio.fedorapeople.org/pkg-orphans.txt >> > I've updated this list. We're down to 91 packages. I'll perform the > orphaning tomorrow. > => php-pecl-apc - chabotc I could take this one. Remi. From email.ahmedkamal at googlemail.com Sat May 9 19:28:58 2009 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sat, 9 May 2009 22:28:58 +0300 Subject: Guaranteeing running code is signed In-Reply-To: <2d319b780905091212x531acea1v837e28429d901601@mail.gmail.com> References: <3da3b5b40905091136s3dd92954kffde00706905a850@mail.gmail.com> <2d319b780905091212x531acea1v837e28429d901601@mail.gmail.com> Message-ID: <3da3b5b40905091228s1acfcfa2s91d53fed72a56504@mail.gmail.com> while rpm's verify options are useful in many cases, they are not in this one. The use case is, Admin A takes ownership of server-C from admin B, admin-B might have infested server-C with all kinds of "custom" code (and even worse, scripts executing as root). How does admin-A ensure no custom code (scripts are probably even harder?) is running on server-C.This looks to me like it needs collaboration from the auditing subsystem (whenever a process starts), and selinux (detecting/blocking) executables not meeting signing requests, or at least logging what happened Does fedora have the tools to accomplish such a task today, if not what's missing Regards On Sat, May 9, 2009 at 10:12 PM, Mathieu Bridon (bochecha) < bochecha at fedoraproject.org> wrote: > Hi, > > > Is there any technology in fedora, that enables me to ensure that ALL > > running code on a certain server (even code not installed from RPMs, such > as > > say by a legacy admin), has been signed by redhat, and to warn me about > > un-signed code that is running or about to run. I am interested to verify > a > > server is in a "known-good" state > > I don't know of any ? One True Solution ?, but you could use things like : > $ rpm -qaV > -> this will list all files modified _after_ they were installed via RPM > $ rpm -qf > -> this will tell you the package that this file belongs to > > You can then use the ? --queryformat ? option of RPM to get various > informations about a package, for example where did it come from. > > For files installed not using RPM, I'm not sure how to verify this, > but as Fedora only provides files in RPMs, I'm pretty confident that > no file outside a RPM will be signed by Fedora. > > For RedHat, I have no idea, but you are on a Fedora mailing-list ;) > > > ---------- > > Mathieu Bridon (bochecha) > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.badger at gmail.com Sat May 9 19:29:51 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 09 May 2009 12:29:51 -0700 Subject: FESco meeting summary for 20090507 In-Reply-To: <4A05D63D.1050400@FamilleCollet.com> References: <4A05BF03.6070508@fi.muni.cz> <1241891561.9577.3.camel@localhost.localdomain> <4A05D17C.8030305@gmail.com> <4A05D63D.1050400@FamilleCollet.com> Message-ID: <4A05D9AF.4030401@gmail.com> Remi Collet wrote: > > => php-pecl-apc - chabotc > > I could take this one. > done. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From bruno at wolff.to Sat May 9 19:40:47 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Sat, 9 May 2009 14:40:47 -0500 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241836379.2886.30.camel@localhost.localdomain> References: <4A03A31C.4010003@freenet.de> <1241754133.3209.71.camel@localhost.localdomain> <4A03AF94.60605@freenet.de> <1241756375.3209.76.camel@localhost.localdomain> <4A03BB64.10006@freenet.de> <1241795563.3209.83.camel@localhost.localdomain> <4A04D350.1000904@freenet.de> <1241832771.2886.15.camel@localhost.localdomain> <4A04EAAE.50907@freenet.de> <1241836379.2886.30.camel@localhost.localdomain> Message-ID: <20090509194047.GA9976@wolff.to> On Fri, May 08, 2009 at 19:32:59 -0700, Jesse Keating wrote: > > * Implement rawhide/testing > > Is this a full time thing, you always want a rawhide, and a > rawhide-testing, which is driven by bodhi? It is probably worth considering. It might be a way to get more people using rawhide. Having a testing repository could smooth over some of the bumps. I think once you start having freezes there definitely should be one. This allows some people to test the frozen state, some people to test the latest development. Once final freeze has started having updates available as well so that people can test what the initial release plus updates is going to look like is useful. From caolanm at redhat.com Sat May 9 19:44:50 2009 From: caolanm at redhat.com (=?ISO-8859-1?Q?Caol=E1n?= McNamara) Date: Sat, 09 May 2009 20:44:50 +0100 Subject: OpenOffice 3.1 In-Reply-To: References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> Message-ID: <1241898290.2551.1481.camel@Vain> On Sat, 2009-05-09 at 17:59 +0200, Kevin Kofler wrote: > Caol?n McNamara wrote: > > But even if that wasn't the case I generally don't bump major versions > > of OOo in a released product. > > Is 3.0 -> 3.1 really that major? I must say I prefer the way packages like > the kernel or KDE are handled, where this kind of updates are pushed. I've a different view on that though, I really don't like the constant kernel update train. From my perspective every update that goes out is like an admission of failure that we didn't get it right at the time of release :-) I'm a little puzzled that people appear a little disappointed that OOo 3.1 isn't intended to be pushed back to F-10. This is the devel list, so presumably everyone here has it looking at them on their rawhide boxes already. F-11 is only a couple of weeks away from release, and so everyone can move from stable F-10 to stable F-11 and get it then. I mean, its a perfectly fine position to take that there should be a "stable" distribution that consists of a rolling set of constant stable updates and upgrades, but if Fedora is one of those why do F-10/F-11/etc releases at all ? And if the Fedora cycle was so long that the time between releases meant that applications got very stale between releases then I'd be all in favour of some sort of means of getting OOo 3.1 out to the people, but its a fairly short cycle of roughly equal length to the OOo one. C. From drago01 at gmail.com Sat May 9 19:52:14 2009 From: drago01 at gmail.com (drago01) Date: Sat, 9 May 2009 21:52:14 +0200 Subject: OpenOffice 3.1 In-Reply-To: <1241898290.2551.1481.camel@Vain> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241898290.2551.1481.camel@Vain> Message-ID: On Sat, May 9, 2009 at 9:44 PM, Caol?n McNamara wrote: > On Sat, 2009-05-09 at 17:59 +0200, Kevin Kofler wrote: >> Caol?n McNamara wrote: >> > But even if that wasn't the case I generally don't bump major versions >> > of OOo in a released product. >> >> Is 3.0 -> 3.1 really that major? I must say I prefer the way packages like >> the kernel or KDE are handled, where this kind of updates are pushed. > > I've a different view on that though, I really don't like the constant > kernel update train. Well newer kernels provide support for new hardware and telling people to wait until the next release to use the hardware they own _now_ isn't really an option. As for OO and KDE I really see no reason why they should be updated to major versions in a release, but if the maintainers (who should know their packages) think that the risk is low or think that it is not worth the risk so be it. We have maintainers for a reason, if we don't trust them we could aswell have automated builds of the newest upstream stuff and put it into the stable repo. From dimi at lattica.com Sat May 9 21:37:18 2009 From: dimi at lattica.com (Dimi Paun) Date: Sat, 09 May 2009 17:37:18 -0400 Subject: Update -> b0rken eclipse Message-ID: <1241905038.3147.13.camel@dimi.lattica.com> Another update today, another significant breakage. My Eclipse stopped working. I have my private version of Eclipse (non-native, so it was not affected by the update), and I'm running java 1.6.0_04-b12 from Sun, so again that was not affected by the update. Problem is that now Eclipse refuses to start by displaying a completely empty dialog (right at the end of the loading sequence). I've been running this combination of Sun's Java + Eclipse for some time without a problem. I'm trying to figure out what changed, and the only things that seem relevant are: May 07 13:54:25 Installed: kernel-2.6.29.2-126.fc11.i586 May 08 14:55:16 Updated: libgcc-4.4.0-4.i586 May 08 14:55:17 Updated: libstdc++-4.4.0-4.i586 Here is the full list of updates since the last reboot: May 07 13:51:05 Updated: totem-pl-parser-2.26.2-1.fc11.i586 May 07 13:51:14 Updated: initscripts-8.95-1.i586 May 07 13:51:15 Updated: file-libs-5.02-1.fc11.i586 May 07 13:51:19 Updated: policycoreutils-2.0.62-12.2.fc11.i586 May 07 13:51:20 Updated: brasero-libs-2.26.1-3.fc11.i586 May 07 13:51:21 Updated: plymouth-libs-0.7.0-0.2009.03.10.4.fc11.i586 May 07 13:51:22 Updated: gnutls-2.6.6-1.fc11.i586 May 07 13:51:23 Updated: libatasmart-0.12-3.fc11.i586 May 07 13:51:23 Updated: 1:control-center-filesystem-2.26.0-6.fc11.i586 May 07 13:51:23 Updated: xorg-x11-server-common-1.6.1-11.fc11.i586 May 07 13:51:26 Updated: kernel-firmware-2.6.29.2-126.fc11.noarch May 07 13:51:53 Updated: selinux-policy-3.6.12-28.fc11.noarch May 07 13:51:53 Updated: pygobject2-codegen-2.16.1-4.fc11.i586 May 07 13:51:54 Updated: pygobject2-doc-2.16.1-4.fc11.noarch May 07 13:51:54 Updated: plymouth-scripts-0.7.0-0.2009.03.10.4.fc11.i586 May 07 13:52:09 Updated: selinux-policy-targeted-3.6.12-28.fc11.noarch May 07 13:52:37 Updated: policycoreutils-python-2.0.62-12.2.fc11.i586 May 07 13:52:37 Updated: fedora-bookmarks-11-1.noarch May 07 13:52:38 Updated: kde-settings-4.2-10.20090430svn.fc11.noarch May 07 13:52:46 Updated: kernel-headers-2.6.29.2-126.fc11.i586 May 07 13:52:49 Updated: firstboot-1.106-1.fc11.i586 May 07 13:53:40 Installed: kernel-PAE-devel-2.6.29.2-126.fc11.i686 May 07 13:53:43 Updated: xorg-x11-server-Xorg-1.6.1-11.fc11.i586 May 07 13:54:25 Installed: kernel-2.6.29.2-126.fc11.i586 May 07 13:55:16 Updated: gnome-settings-daemon-2.26.1-4.fc11.i586 May 07 13:55:17 Updated: plymouth-0.7.0-0.2009.03.10.4.fc11.i586 May 07 13:55:18 Updated: plymouth-utils-0.7.0-0.2009.03.10.4.fc11.i586 May 07 13:55:22 Updated: DeviceKit-disks-004-2.fc11.i586 May 07 13:55:24 Updated: gnome-disk-utility-libs-0.3-1.fc11.i586 May 07 13:55:27 Updated: gvfs-1.2.2-6.fc11.i586 May 07 13:55:27 Updated: gvfs-fuse-1.2.2-6.fc11.i586 May 07 13:55:27 Updated: gvfs-obexftp-1.2.2-6.fc11.i586 May 07 13:55:28 Updated: pygobject2-2.16.1-4.fc11.i586 May 07 13:55:29 Updated: 2:qemu-img-0.10-16.fc11.i586 May 07 13:55:33 Updated: libvirt-0.6.2-6.fc11.i586 May 07 13:55:34 Updated: libvirt-python-0.6.2-6.fc11.i586 May 07 13:56:11 Updated: 1:control-center-2.26.0-6.fc11.i586 May 07 13:56:12 Updated: xorg-x11-drv-intel-2.7.0-4.fc11.i586 May 07 13:56:13 Updated: file-5.02-1.fc11.i586 May 07 13:56:13 Updated: python-magic-5.02-1.fc11.i586 May 07 13:56:14 Updated: xorg-x11-drv-ati-6.12.2-11.fc11.i586 May 07 13:56:15 Updated: 1:xorg-x11-drv-nouveau-0.0.12-33.20090501gitf69b34a.fc11.i586 May 07 13:56:15 Updated: xorg-x11-drv-synaptics-1.1.0-5.fc11.i586 May 07 13:56:50 Installed: kernel-PAE-2.6.29.2-126.fc11.i686 May 07 13:57:08 Updated: brasero-2.26.1-3.fc11.i586 May 07 13:57:09 Updated: tigervnc-0.0.90-0.7.20090427svn3789.fc11.i586 May 07 13:57:14 Updated: smart-1.2-64.fc11.i586 May 07 13:57:15 Updated: xsane-gimp-0.996-7.fc11.i586 May 07 13:57:17 Updated: xsane-0.996-7.fc11.i586 May 07 13:57:41 Updated: gnome-power-manager-2.26.1-3.fc11.i586 May 07 13:57:44 Updated: python-virtinst-0.400.3-8.fc11.noarch May 07 13:57:44 Updated: pygobject2-devel-2.16.1-4.fc11.i586 May 07 13:57:45 Updated: totem-gstreamer-2.26.2-1.fc11.i586 May 07 13:58:05 Updated: 1:gdm-2.26.1-7.fc11.i586 May 07 13:58:30 Updated: totem-2.26.2-1.fc11.i586 May 07 13:58:31 Updated: gnome-bluetooth-libs-2.27.5-1.fc11.i586 May 07 13:58:52 Updated: gnome-media-libs-2.26.0-6.fc11.i586 May 07 13:59:08 Updated: gnome-bluetooth-2.27.5-1.fc11.i586 May 07 13:59:20 Updated: gnome-media-2.26.0-6.fc11.i586 May 07 13:59:20 Updated: plymouth-gdm-hooks-0.7.0-0.2009.03.10.4.fc11.i586 May 07 13:59:21 Updated: totem-xine-2.26.2-1.fc11.i586 May 07 13:59:22 Updated: totem-nautilus-2.26.2-1.fc11.i586 May 07 13:59:22 Updated: 1:gdm-user-switch-applet-2.26.1-7.fc11.i586 May 07 13:59:23 Updated: totem-mozplugin-2.26.2-1.fc11.i586 May 07 13:59:24 Updated: totem-youtube-2.26.2-1.fc11.i586 May 08 14:55:16 Updated: libgcc-4.4.0-4.i586 May 08 14:55:17 Updated: libstdc++-4.4.0-4.i586 May 08 14:55:22 Updated: gvfs-1.2.2-7.fc11.i586 May 08 14:55:29 Updated: libgcj-4.4.0-4.i586 May 08 14:55:30 Updated: libgomp-4.4.0-4.i586 May 08 14:55:31 Updated: libgfortran-4.4.0-4.i586 May 08 14:55:32 Updated: cpp-4.4.0-4.i586 May 08 14:55:38 Updated: gcc-4.4.0-4.i586 May 08 14:55:39 Updated: gvfs-obexftp-1.2.2-7.fc11.i586 May 08 14:55:39 Updated: gvfs-fuse-1.2.2-7.fc11.i586 May 08 14:55:39 Updated: 1:xorg-x11-drv-nouveau-0.0.12-34.20090507git1072103.fc11.i586 May 08 14:55:50 Updated: libstdc++-devel-4.4.0-4.i586 May 08 14:56:30 Updated: libgcj-devel-4.4.0-4.i586 May 08 14:56:30 Updated: gcc-c++-4.4.0-4.i586 May 08 14:56:42 Updated: fedora-logos-11.0.5-1.fc11.noarch May 09 16:57:59 Updated: plymouth-scripts-0.7.0-0.2009.05.08.1.fc11.i586 May 09 16:58:00 Updated: fontconfig-2.6.99.behdad.20090508-1.fc11.i586 May 09 16:58:01 Updated: 1:NetworkManager-glib-0.7.1-4.git20090414.fc11.i586 May 09 16:58:02 Updated: plymouth-libs-0.7.0-0.2009.05.08.1.fc11.i586 May 09 16:58:05 Updated: 1:cups-libs-1.4-0.b2.16.fc11.i586 May 09 16:58:06 Updated: plymouth-0.7.0-0.2009.05.08.1.fc11.i586 May 09 16:58:07 Updated: plymouth-utils-0.7.0-0.2009.05.08.1.fc11.i586 May 09 16:58:11 Updated: 1:NetworkManager-0.7.1-4.git20090414.fc11.i586 May 09 16:58:13 Updated: parted-1.8.8-17.fc11.i586 May 09 16:58:13 Updated: plymouth-gdm-hooks-0.7.0-0.2009.05.08.1.fc11.i586 May 09 16:58:14 Updated: xorg-x11-drv-savage-2.2.1-1.fc11.i586 May 09 16:58:14 Updated: xorg-x11-drv-ati-6.12.2-13.fc11.i586 May 09 16:58:18 Updated: fontconfig-devel-2.6.99.behdad.20090508-1.fc11.i586 May 09 16:58:23 Updated: 1:NetworkManager-gnome-0.7.1-4.git20090414.fc11.i586 May 09 16:58:34 Updated: 1:cups-1.4-0.b2.16.fc11.i586 -- Dimi Paun Lattica, Inc. From darrellpf at gmail.com Sat May 9 21:54:02 2009 From: darrellpf at gmail.com (darrell pfeifer) Date: Sat, 9 May 2009 14:54:02 -0700 Subject: Update -> b0rken eclipse In-Reply-To: <1241905038.3147.13.camel@dimi.lattica.com> References: <1241905038.3147.13.camel@dimi.lattica.com> Message-ID: On Sat, May 9, 2009 at 14:37, Dimi Paun wrote: > Another update today, another significant breakage. > > My Eclipse stopped working. > > I have my private version of Eclipse (non-native, so it was not > affected by the update), and I'm running java 1.6.0_04-b12 from Sun, > so again that was not affected by the update. > > Problem is that now Eclipse refuses to start by displaying a > completely empty dialog (right at the end of the loading > sequence). > > I've been running this combination of Sun's Java + Eclipse > for some time without a problem. > > I'm trying to figure out what changed, and the only things > that seem relevant are: > > May 07 13:54:25 Installed: kernel-2.6.29.2-126.fc11.i586 > May 08 14:55:16 Updated: libgcc-4.4.0-4.i586 > May 08 14:55:17 Updated: libstdc++-4.4.0-4.i586 > > Here is the full list of updates since the last reboot: > Are you starting eclipse with a brand new workspace? If so the empty dialog problem has been around for a long time. I think it is actually due to a gtk update. An empty workspace displays the big-buttoned welcome screen, which is what I think is having problems. The workaround for me is to copy an existing workspace, then delete everything to get an empty workspace. I haven't seen a fix for the problem yet. I'm using Eclipse 3.4 with newest Sun java and a completely updated rawhide. If it is happening on an existing workspace then I haven't seen that one yet (though I guess if you operate from the big-button welcome/task screen) I can see it happening all the time. darrell -------------- next part -------------- An HTML attachment was scrubbed... URL: From darrellpf at gmail.com Sat May 9 22:00:56 2009 From: darrellpf at gmail.com (darrell pfeifer) Date: Sat, 9 May 2009 15:00:56 -0700 Subject: Update -> b0rken eclipse In-Reply-To: <1241905038.3147.13.camel@dimi.lattica.com> References: <1241905038.3147.13.camel@dimi.lattica.com> Message-ID: On Sat, May 9, 2009 at 14:37, Dimi Paun wrote: > Another update today, another significant breakage. > > My Eclipse stopped working. > > I have my private version of Eclipse (non-native, so it was not > affected by the update), and I'm running java 1.6.0_04-b12 from Sun, > so again that was not affected by the update. > > Problem is that now Eclipse refuses to start by displaying a > completely empty dialog (right at the end of the loading > sequence). > > I've been running this combination of Sun's Java + Eclipse > for some time without a problem. > http://wiki.eclipse.org/IRC_FAQ#Eclipse_gets_past_the_splash_screen_but_then_an_empty_window_appears_.2F_Eclipse_is_crashing_on_me_whenever_I_initiate_a_browser_component_such_as_hovering_over_Java_methods_for_javadoc_tooltips. .. darrell -------------- next part -------------- An HTML attachment was scrubbed... URL: From zaitcev at redhat.com Sat May 9 22:04:28 2009 From: zaitcev at redhat.com (Pete Zaitcev) Date: Sat, 9 May 2009 16:04:28 -0600 Subject: glibc fork ? In-Reply-To: <4A036082.8000107@fedoraproject.org> References: <4A02F8D3.2010807@poolshark.org> <4A036082.8000107@fedoraproject.org> Message-ID: <20090509160428.0bf3c0e6.zaitcev@redhat.com> On Fri, 08 May 2009 03:58:18 +0530, Rahul Sundaram wrote: > eglibc FAQ claims that it wants to be binary and source compatible and > will rebase regularly with Glibc and that doesn't seem much of a fork. It doesn't matter what the PR is. But even if anyone believes this kool-aid and starts acting as if it's true (e.g. synching with Uli's glibc), they are going to end with Claws and Sylpheed eventually, unless they die off first. The "embedded" fig leaf similarly means nothing. It's just that Uli's behaviour hurt ARM the most, therefore they focused on it. It's going to change as soon as Debian bug reports start flowing in. As far as Fedora goes, IMHO we should watch the developments and evaluate the performance of eglibc against a simple criterium: if they add bugs or fix bugs. Next big performance anomaly in something like MySQL will prove eglibc people's worth. If they just wait for Jakub and Uli to fix it for them, I don't see us switching. -- Pete From dimi at lattica.com Sat May 9 22:08:23 2009 From: dimi at lattica.com (Dimi Paun) Date: Sat, 09 May 2009 18:08:23 -0400 Subject: Update -> b0rken eclipse In-Reply-To: References: <1241905038.3147.13.camel@dimi.lattica.com> Message-ID: <1241906903.3147.18.camel@dimi.lattica.com> On Sat, 2009-05-09 at 14:54 -0700, darrell pfeifer wrote: > Are you starting eclipse with a brand new workspace? If so the empty > dialog problem has been around for a long time. I think it is actually > due to a gtk update. An empty workspace displays the big-buttoned > welcome screen, which is what I think is having problems. The > workaround for me is to copy an existing workspace, then delete > everything to get an empty workspace. > > I haven't seen a fix for the problem yet. I'm using Eclipse 3.4 with > newest Sun java and a completely updated rawhide. > > If it is happening on an existing workspace then I haven't seen that > one yet (though I guess if you operate from the big-button > welcome/task screen) I can see it happening all the time. Thanks Darrell, I didn't know of this issue. However, I operate from an existing workspace. I'm not sure what the dialog is about, but IIRC I have Eclipse setup to prompt me for the right workspace at startup, so that might be it. One thing is for certain -- I'm not using the big-button welcome screen. -- Dimi Paun Lattica, Inc. From dimi at lattica.com Sat May 9 22:25:36 2009 From: dimi at lattica.com (Dimi Paun) Date: Sat, 09 May 2009 18:25:36 -0400 Subject: Update -> b0rken eclipse In-Reply-To: References: <1241905038.3147.13.camel@dimi.lattica.com> Message-ID: <1241907936.3147.24.camel@dimi.lattica.com> On Sat, 2009-05-09 at 15:00 -0700, darrell pfeifer wrote: > > http://wiki.eclipse.org/IRC_FAQ#Eclipse_gets_past_the_splash_screen_but_then_an_empty_window_appears_.2F_Eclipse_is_crashing_on_me_whenever_I_initiate_a_browser_component_such_as_hovering_over_Java_methods_for_javadoc_tooltips... That sounds like it. But meanwhile I tried using the Native version (which didn't work right until recently), and after some pain (the Software Updates... feature is just horrible!) I managed to get WTP (Web Tools Project installed) and make it usable. And after all this work, I get this email from you and decided to try the old eclipse again to see if it is the bug mentioned in the above link. And you know what -- the old eclipse that refused to run is starting up again! Go figure... Thanks Darrell! P.S. Why isn't WTP packaged as an RPM? It is an important part of Eclipse, and it is a real pain to install via the Software Updates feature in Eclipse. -- Dimi Paun Lattica, Inc. From fedora at matbooth.co.uk Sat May 9 22:48:25 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Sat, 9 May 2009 23:48:25 +0100 Subject: Update -> b0rken eclipse In-Reply-To: <1241907936.3147.24.camel@dimi.lattica.com> References: <1241905038.3147.13.camel@dimi.lattica.com> <1241907936.3147.24.camel@dimi.lattica.com> Message-ID: <9497e9990905091548u61252d8ds370d29f64596f5a8@mail.gmail.com> On Sat, May 9, 2009 at 11:25 PM, Dimi Paun wrote: > P.S. Why isn't WTP packaged as an RPM? It is an important part of > Eclipse, and it is a real pain to install via the Software Updates > feature in Eclipse. > There is an ongoing effort to package WTP over here: https://bugzilla.redhat.com/show_bug.cgi?id=486369 -- Mat Booth www.matbooth.co.uk From xjakub at fi.muni.cz Sat May 9 22:51:22 2009 From: xjakub at fi.muni.cz (Milos Jakubicek) Date: Sun, 10 May 2009 00:51:22 +0200 Subject: FESco meeting summary for 20090507 In-Reply-To: <4A05D17C.8030305@gmail.com> References: <4A05BF03.6070508@fi.muni.cz> <1241891561.9577.3.camel@localhost.localdomain> <4A05D17C.8030305@gmail.com> Message-ID: <4A0608EA.6010700@fi.muni.cz> Hi, Dne 9.5.2009 20:54, Toshio Kuratomi wrote: > Christoph Wickert wrote: >> Am Samstag, den 09.05.2009, 19:36 +0200 schrieb Milos Jakubicek: >> >>>> == Deactivated maintainers == >>>> >>>> FESCo approved orphaning packages owned by deactivated maintainers >>>> >>> Could you please send then a list of packages that are going to be orphaned? >> Most likely: http://toshio.fedorapeople.org/pkg-orphans.txt >> > I've updated this list. We're down to 91 packages. I'll perform the > orphaning tomorrow. I'd take over the following packages -- provided the current comaintainers are not interested in becoming primary maintainers, of course! python-wikimarkup python-dotconf html-xml-utils log4cxx lzma mysql-connector-java splint (Panu?) nbd (Warren? dyoung?) Sprog suitesparse (deji?) tktray trousers (ejratl?) snmp++ (Mamoru?) Regards, Milos From skvidal at fedoraproject.org Sat May 9 22:50:45 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Sat, 9 May 2009 18:50:45 -0400 (EDT) Subject: glibc fork ? In-Reply-To: <20090509160428.0bf3c0e6.zaitcev@redhat.com> References: <4A02F8D3.2010807@poolshark.org> <4A036082.8000107@fedoraproject.org> <20090509160428.0bf3c0e6.zaitcev@redhat.com> Message-ID: On Sat, 9 May 2009, Pete Zaitcev wrote: > On Fri, 08 May 2009 03:58:18 +0530, Rahul Sundaram wrote: > >> eglibc FAQ claims that it wants to be binary and source compatible and >> will rebase regularly with Glibc and that doesn't seem much of a fork. > > It doesn't matter what the PR is. But even if anyone believes this > kool-aid and starts acting as if it's true (e.g. synching with Uli's > glibc), they are going to end with Claws and Sylpheed eventually, > unless they die off first. > > The "embedded" fig leaf similarly means nothing. It's just that > Uli's behaviour hurt ARM the most, therefore they focused on it. > It's going to change as soon as Debian bug reports start flowing in. > > As far as Fedora goes, IMHO we should watch the developments and > evaluate the performance of eglibc against a simple criterium: > if they add bugs or fix bugs. Next big performance anomaly in > something like MySQL will prove eglibc people's worth. If they > just wait for Jakub and Uli to fix it for them, I don't see us > switching. Pete, You and I don't agree on much - but I agree with you on the above. -sv From dwmw2 at infradead.org Sat May 9 23:20:02 2009 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 10 May 2009 00:20:02 +0100 Subject: Secondary Architecture Status? In-Reply-To: References: Message-ID: <1241911202.24436.81.camel@macbook.infradead.org> On Sat, 2009-05-09 at 13:24 -0400, Jon Stanley wrote: > FESCo conducted a brief discussion of moving PowerPC to a secondary > architecture for Fedora 12. The general consensus is that since > Fedora 12 development cycle has already begun, it is not appropriate > for Fedora 12. However, for Fedora 13, FESCo is in favor of the idea. > NB: THIS IS NOT AN OFFICIAL VOTE OR POSISTION, THAT WILL COME NEXT > WEEK. It was originally decreed by the Board that we wouldn't drop PowerPC from being a primary architecture until some other architecture has actually shown that the infrastructure for secondary architectures is working. We still don't have any secondary architectures gearing up to ship Fedora 11 -- it would be really interesting to know why that is. What technical barriers are still there -- why don't we have a release yet? I think that at this point it's acceptable to leave the fate of the port to the people who most care about it -- but if there are infrastructure or other problems which would block a release _regardless_ of how hard the port maintainers work, that's less reasonable. So a report from our existing secondary architecture teams on why they haven't managed to release yet would be useful input to next week's meeting. -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation From dwmw2 at infradead.org Sat May 9 23:28:05 2009 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 10 May 2009 00:28:05 +0100 Subject: glibc fork ? In-Reply-To: <20090509160428.0bf3c0e6.zaitcev@redhat.com> References: <4A02F8D3.2010807@poolshark.org> <4A036082.8000107@fedoraproject.org> <20090509160428.0bf3c0e6.zaitcev@redhat.com> Message-ID: <1241911685.24436.93.camel@macbook.infradead.org> On Sat, 2009-05-09 at 16:04 -0600, Pete Zaitcev wrote: > As far as Fedora goes, IMHO we should watch the developments and > evaluate the performance of eglibc against a simple criterium: > if they add bugs or fix bugs. Next big performance anomaly in > something like MySQL will prove eglibc people's worth. If they > just wait for Jakub and Uli to fix it for them, I don't see us > switching. I have no particularly strong opinion either way, and I agree with your assessment -- but do let me know when I can start using strlcat(). :) -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation From oget.fedora at gmail.com Sun May 10 01:33:55 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Sat, 9 May 2009 21:33:55 -0400 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <20090507210920.GB9105@amd.home.annexia.org> References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> Message-ID: On Thu, May 7, 2009 at 5:09 PM, Richard W.M. Jones wrote: > On Thu, May 07, 2009 at 10:41:37AM -0700, Jesse Keating wrote: >> How is it we have 182 stable updates pending for F11 already? ?How have >> these seen any testing by a wider audience? ?Are we really just not >> bothering with updates-testing anymore? ?Do we not care about distro >> stability? > > I'll tell you the three reasons I'm pushing stuff directly to stable: > > (1) New package. > [cut] Is it a good practice to push a new package to stable? Orcan From mmcgrath at redhat.com Sat May 9 23:21:47 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 9 May 2009 18:21:47 -0500 (CDT) Subject: Outage Notification - 2009-05-10 20:00 UTC Message-ID: There will be an outage starting at 2009-05-10 20:00 UTC, which will last approximately 2 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2009-05-10 20:00 UTC' Affected Services: Buildsystem Database Mirror System Translation Services Websites Unaffected Services: CVS / Source Control DNS Fedora Hosted Fedora People Fedora Talk Mail Torrent Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/1376 Reason for Outage: Moving the db2 databases back to db2 now that it's hardware has been fixed. We'll also be rebooting nfs1 during this time. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From jussi.lehtola at iki.fi Sun May 10 09:59:16 2009 From: jussi.lehtola at iki.fi (Jussi Lehtola) Date: Sun, 10 May 2009 12:59:16 +0300 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> Message-ID: <1241949557.3109.2.camel@localhost.localdomain> On Sat, 2009-05-09 at 21:33 -0400, Orcan Ogetbil wrote: > On Thu, May 7, 2009 at 5:09 PM, Richard W.M. Jones wrote: > > I'll tell you the three reasons I'm pushing stuff directly to stable: > > > > (1) New package. > > [cut] > > Is it a good practice to push a new package to stable? Why not? The purpose of testing is to find out if the package breaks something. In the case of a new package there is no functionality of it to break; the only possibility of getting into trouble is if the package itself hasn't been made correctly (clashing file names or so on), which should be in any case picked up in the review. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From lists at ebourne.me.uk Sun May 10 10:53:25 2009 From: lists at ebourne.me.uk (Martin Ebourne) Date: Sun, 10 May 2009 10:53:25 +0000 (UTC) Subject: OpenOffice 3.1 References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> Message-ID: On Sat, 09 May 2009 12:51:18 +0100, Caol?n McNamara wrote: > Well, in this case updating F-10 3.1 properly would require updating a > load of other stuff as well with all the risks and work that entails. > But even if that wasn't the case I generally don't bump major versions > of OOo in a released product. I see our fedora release cycle as ones of > iterative stable complete releases, rather than one which has an > always-open pool of stable packages which always contains the latest > stable version of a package. i.e. F-10 was history as soon as it was > released, and F-11 is likewise almost dead to me already :-) Not that I > won't fix bugs in them, just that I don't see them as live development > releases. +1 With my user hat on I wish that policy was used more often in Fedora. In general regressions are far more annoying than missing features or already present bugs, and over the last 5 years I feel the rate of regression in Fedora has been somewhat higher than it should be, especially within a release. I like to see new feature updates (but not major changes) in the latest Fedora release because the distribution sells itself on being leading edge and I like that. Once a release has been superseded though (and F10 is so close to being superseded as it matters) I would much prefer a bug- fix only policy. Anyone who really wants shiny new toys will already be on the latest release (or if not will happily switch), anyone who wants to stay on the previous release probably wants a bit more stability in their lives. Cheers, Martin From mschwendt at gmail.com Sun May 10 11:06:22 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sun, 10 May 2009 13:06:22 +0200 Subject: Guaranteeing running code is signed In-Reply-To: <3da3b5b40905091228s1acfcfa2s91d53fed72a56504@mail.gmail.com> References: <3da3b5b40905091136s3dd92954kffde00706905a850@mail.gmail.com> <2d319b780905091212x531acea1v837e28429d901601@mail.gmail.com> <3da3b5b40905091228s1acfcfa2s91d53fed72a56504@mail.gmail.com> Message-ID: <20090510130622.093a91ac@faldor.intranet> On Sat, 9 May 2009 22:28:58 +0300, Ahmed wrote: > while rpm's verify options are useful in many cases, they are not in this > one. The use case is, Admin A takes ownership of server-C from admin B, > admin-B might have infested server-C with all kinds of "custom" code (and > even worse, scripts executing as root). How does admin-A ensure no custom > code (scripts are probably even harder?) is running on server-C.This looks > to me like it needs collaboration from the auditing subsystem (whenever a > process starts), and selinux (detecting/blocking) executables not meeting > signing requests, or at least logging what happened > > Does fedora have the tools to accomplish such a task today, if not what's > missing If at least the admins in your scenario are trusted, you could make them use intrusion detection tools like AIDE (package "aide") or Tripwire (package "tripwire") as these can cover all files found on the system (not just those known by the RPM database). The important thing to do is to ensure that the admins only update the AIDE/Tripwire database (and store it on external media) when the system installation is in a known good state. If any of the admins don't pay proper attention to reports of files that have changed and update the checksums database nevertheless, you lose. From lists at ebourne.me.uk Sun May 10 11:09:23 2009 From: lists at ebourne.me.uk (Martin Ebourne) Date: Sun, 10 May 2009 11:09:23 +0000 (UTC) Subject: FESco meeting summary for 20090507 References: <4A05BF03.6070508@fi.muni.cz> <1241891561.9577.3.camel@localhost.localdomain> <4A05D17C.8030305@gmail.com> Message-ID: On Sat, 09 May 2009 11:54:52 -0700, Toshio Kuratomi wrote: > Christoph Wickert wrote: >> Am Samstag, den 09.05.2009, 19:36 +0200 schrieb Milos Jakubicek: >>> Could you please send then a list of packages that are going to be >>> orphaned? >> >> Most likely: http://toshio.fedorapeople.org/pkg-orphans.txt >> > I've updated this list. We're down to 91 packages. I'll perform the > orphaning tomorrow. I'll take: gdmap (for anyone who hasn't tried it, great way of visualising disk usage and finding where it all went) Cheers, Martin From mschwendt at gmail.com Sun May 10 11:11:15 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sun, 10 May 2009 13:11:15 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241949557.3109.2.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241949557.3109.2.camel@localhost.localdomain> Message-ID: <20090510131115.226b27a5@faldor.intranet> On Sun, 10 May 2009 12:59:16 +0300, Jussi wrote: > On Sat, 2009-05-09 at 21:33 -0400, Orcan Ogetbil wrote: > > On Thu, May 7, 2009 at 5:09 PM, Richard W.M. Jones wrote: > > > I'll tell you the three reasons I'm pushing stuff directly to stable: > > > > > > (1) New package. > > > [cut] > > > > Is it a good practice to push a new package to stable? No. > Why not? The purpose of testing is to find out if the package breaks > something. In the case of a new package there is no functionality of it > to break; That's a sign of lack of experience. We've had bad/dangerous Provides, Obsoletes, SONAME conflicts, which caused buildroot damage, duplicate packages (with renamed upstream projects) and non-working/completely broken packages, too. > the only possibility of getting into trouble is if the package > itself hasn't been made correctly (clashing file names or so on), which > should be in any case picked up in the review. SHOULD. There is nothing in the guidelines that requires packagers and reviewers to search for conflicts, however. Do use updates-testing. From bjorn at xn--rombobjrn-67a.se Sun May 10 13:03:24 2009 From: bjorn at xn--rombobjrn-67a.se (=?iso-8859-1?q?Bj=F6rn_Persson?=) Date: Sun, 10 May 2009 15:03:24 +0200 Subject: Guaranteeing running code is signed In-Reply-To: <3da3b5b40905091228s1acfcfa2s91d53fed72a56504@mail.gmail.com> References: <3da3b5b40905091136s3dd92954kffde00706905a850@mail.gmail.com> <2d319b780905091212x531acea1v837e28429d901601@mail.gmail.com> <3da3b5b40905091228s1acfcfa2s91d53fed72a56504@mail.gmail.com> Message-ID: <200905101503.35200.bjorn@xn--rombobjrn-67a.se> Ahmed Kamal wrote: > while rpm's verify options are useful in many cases, they are not in this > one. The use case is, Admin A takes ownership of server-C from admin B, > admin-B might have infested server-C with all kinds of "custom" code (and > even worse, scripts executing as root). How does admin-A ensure no custom > code (scripts are probably even harder?) is running on server-C.This looks > to me like it needs collaboration from the auditing subsystem (whenever a > process starts), and selinux (detecting/blocking) executables not meeting > signing requests, or at least logging what happened If your concern is that admin B may have been incompetent and messed up the system with crappy code and bad configuration so that it doesn't work properly, then you could verify the whole system against the RPM database and review everything that has changed and anything that isn't in the RPM database. If your concern is that admin B may have been malicious and deliberately implanted malware in the system, or that intruder D may have broken into the system and implanted malware because admin B didn't keep the system secure, then you have to wipe the disk and reinstall from known good installation media, and then restore as little as possible from backups and scrutinize anything you do restore. It's impossible to verify the security of a computer system from within the system itself. If a malicious person may have had root access, then RPM, GPG, SElinux and the auditing subsystem may all have been tampered with and you can't trust that they tell you the truth. Reinstalling is the only way to be sure. Bj?rn Persson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From khc at pm.waw.pl Sun May 10 13:31:58 2009 From: khc at pm.waw.pl (Krzysztof Halasa) Date: Sun, 10 May 2009 15:31:58 +0200 Subject: Guaranteeing running code is signed In-Reply-To: <200905101503.35200.bjorn@xn--rombobjrn-67a.se> (=?iso-8859-2?Q?=22Bj=F6rn?= Persson"'s message of "Sun\, 10 May 2009 15\:03\:24 +0200") References: <3da3b5b40905091136s3dd92954kffde00706905a850@mail.gmail.com> <2d319b780905091212x531acea1v837e28429d901601@mail.gmail.com> <3da3b5b40905091228s1acfcfa2s91d53fed72a56504@mail.gmail.com> <200905101503.35200.bjorn@xn--rombobjrn-67a.se> Message-ID: Bj?rn Persson writes: > It's impossible to verify the security of a computer system from within the > system itself. If a malicious person may have had root access, then RPM, GPG, > SElinux and the auditing subsystem may all have been tampered with and you > can't trust that they tell you the truth. Reinstalling is the only way to be > sure. Sure? Someone may have planted something in a motherboard flash ROM (easy), in VGA flash, in CD/DVD flash, in HDD flash and/or "service" sectors etc. You can't be 100% sure that a brand-new hardware is clean. -- Krzysztof Halasa From rawhide at fedoraproject.org Sun May 10 13:39:22 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Sun, 10 May 2009 13:39:22 +0000 (UTC) Subject: rawhide report: 20090510 changes Message-ID: <20090510133922.288BE1F8214@releng2.fedora.phx.redhat.com> Compose started at Sun May 10 06:15:09 UTC 2009 Updated Packages: leonidas-kde-theme-0.2.4-3.fc11 ------------------------------- * Sat May 09 2009 Jaroslav Reznik 0.2.4-3 - wallpaper symlinks fixed (bz#496379) * Thu Apr 23 2009 Jaroslav Reznik 0.2.3-1 - new KDM theme design * Thu Apr 23 2009 Jaroslav Reznik 0.2.4-1 - default face (original by K. Peirce, CC-BY) * Thu Apr 23 2009 Jaroslav Reznik 0.2.4-2 - tarball respin Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 1 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From dwmw2 at infradead.org Sun May 10 15:11:41 2009 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 10 May 2009 16:11:41 +0100 Subject: FESco meeting summary for 20090507 In-Reply-To: <4A0608EA.6010700@fi.muni.cz> References: <4A05BF03.6070508@fi.muni.cz> <1241891561.9577.3.camel@localhost.localdomain> <4A05D17C.8030305@gmail.com> <4A0608EA.6010700@fi.muni.cz> Message-ID: <1241968301.24436.159.camel@macbook.infradead.org> On Sun, 2009-05-10 at 00:51 +0200, Milos Jakubicek wrote: > trousers (ejratl?) Want to take an interest in the openssl-tpm-engine too, then? Getting that included would be very useful. Maybe also tpm-emulator? -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation From jonstanley at gmail.com Sun May 10 15:44:50 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Sun, 10 May 2009 11:44:50 -0400 Subject: FESco meeting summary for 20090507 In-Reply-To: References: Message-ID: On Sat, May 9, 2009 at 1:34 PM, drago01 wrote: > What happened to this https://fedorahosted.org/fesco/ticket/142 ? Sorry about that, as I mentioned in the ticket, entirely my fault this didn't get brought up :( Anyhow, the concerns that I have about this is as Paul noted in the ticket, what happens if someone downloads this now more visible x86_64 release and finds that it doesn't boot their computer? I sense a lot of "man, this Fedora thing SUCKS!". Moreover, with the new architecture support feature in F11, we're now supposedly defaulting to an x86_64 kernel on an i686 install if the processor supports it (note that I say supposedly because I've not personally tested it). Thus you have an x86_64 kernel, and all of the goodness that brings, but you still have an i686 userspace. Also, keep in mind that while x86_64 hardware is quite common in the US and Western Europe (perhaps to a lesser extent there than the US, even), there are many parts of the world where that is not common, and folks would have to go find the i686 version to download. Just my $0.02 and food for thought, -Jon From lists at sapience.com Sun May 10 15:58:13 2009 From: lists at sapience.com (Mail Lists) Date: Sun, 10 May 2009 11:58:13 -0400 Subject: OpenOffice 3.1 In-Reply-To: References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> Message-ID: <4A06F995.4030802@sapience.com> On 05/10/2009 06:53 AM, Martin Ebourne wrote: >\ .. anyone who wants > to stay on the previous release probably wants a bit more stability in > their lives. > > Cheers, > Martin > While some of your goals are reasonable, please don't confuse stability of one pretty well tested application on F10 (or possible instability) with the as yet not known to be as stable entire F11 distribution. Stability is the convolution of all the parts - a 'bit more stability' of F10 over F11 is a bit premature a statement at this juncture in my view. From chris.stone at gmail.com Sun May 10 16:04:24 2009 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 10 May 2009 09:04:24 -0700 Subject: Abandon "Default Desktop" In-Reply-To: <1241624002.3030.38.camel@localhost.localdomain> References: <1241495447.6639.129.camel@localhost.localdomain> <1241547497.31208.5.camel@localhost.localdomain> <80d7e4090905051153t1bfdd3ffidc11704d9e5d4b7b@mail.gmail.com> <80d7e4090905052021s6669b85bl1c0d125ec52b54a4@mail.gmail.com> <4A014BEB.5070405@hi.is> <1241624002.3030.38.camel@localhost.localdomain> Message-ID: I find it disturbing reading some of these arguments about simply allowing one environment to have equal footing with another! You would think people are trying to *replace* GNOME with KDE. It is a shame that GNOME advocates are fighting tooth and nail to try and desperately keep their dying desktop alive. It should be very clear within the coming years that KDE is by far the superior desktop. KDE advocates should not stress too much over it now. In a couple more years I suspect most distributions will be forced to switch to KDE because GNOME is basically moving in the wrong direction and is falling way too far behind. You might disagree with this statement, but you are simply just burying your head in the sand if you do. I think the real hidden underlying argument is what does a RHEL user want, and I think the RedHat people feel that a typical RHEL user is not a power desktop user and would be more comfortable with GNOME, so therefore the RedHat team will fight the community tooth and nail to keep their simplistic desktop no matter how much the Fedora community wants KDE. The RedHat GNOME advocates do not even want KDE to be on equal footing with GNOME because they already fear KDE's growing popularity. Unfortunately for them, in a few more years they wont have much choice because by that time their RHEL customers will be demanding KDE. From bochecha at fedoraproject.org Sun May 10 16:14:40 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Sun, 10 May 2009 18:14:40 +0200 Subject: FESco meeting summary for 20090507 In-Reply-To: References: Message-ID: <2d319b780905100914n442e2501h78b2184437a67065@mail.gmail.com> On Sun, May 10, 2009 at 17:44, Jon Stanley wrote: > On Sat, May 9, 2009 at 1:34 PM, drago01 wrote: > >> What happened to this https://fedorahosted.org/fesco/ticket/142 ? > > Sorry about that, as I mentioned in the ticket, entirely my fault this > didn't get brought up :( > > Anyhow, the concerns that I have about this is as Paul noted in the > ticket, what happens if someone ?downloads this now more visible > x86_64 release and finds that it doesn't boot their computer? ?I sense > a lot of "man, this Fedora thing SUCKS!". > > Moreover, with the new architecture support feature in F11, we're now > supposedly defaulting to an x86_64 kernel on an i686 install if the > processor supports it (note that I say supposedly because I've not > personally tested it). ?Thus you have an x86_64 kernel, and all of the > goodness that brings, but you still have an i686 userspace. > > Also, keep in mind that while x86_64 hardware is quite common in the > US and Western Europe (perhaps to a lesser extent there than the US, > even), there are many parts of the world where that is not common, and > folks would have to go find the i686 version to download. Wouldn't smolt be a good way to know the rates of 64 bits processors versus 32 bits ones ? The ? arch ? tab says : i686 200890 75.2 % x86_64 64931 24.3 % But if I understood it right, that's actually the installed arch, not the capability of the CPU, so many of those i686 installs might come from 64 bits CPUs and user not knowing/willing to move to 64 bits OS... The ? CPU ? tab doesn't say whether the CPU is 32 or 64 bits though (or maybe I didn't look close enough). Knowing how many 64 bits CPUs are out there using Fedora could provide good input for this issue IMHO. Regards, ---------- Mathieu Bridon (bochecha) From abu_hurayrah at hidayahonline.org Sun May 10 16:23:08 2009 From: abu_hurayrah at hidayahonline.org (Basil Mohamed Gohar) Date: Mon, 11 May 2009 00:23:08 +0800 Subject: Guaranteeing running code is signed In-Reply-To: References: <3da3b5b40905091136s3dd92954kffde00706905a850@mail.gmail.com> <2d319b780905091212x531acea1v837e28429d901601@mail.gmail.com> <3da3b5b40905091228s1acfcfa2s91d53fed72a56504@mail.gmail.com> <200905101503.35200.bjorn@xn--rombobjrn-67a.se> Message-ID: <4A06FF6C.4080905@hidayahonline.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/10/2009 09:31 PM, Krzysztof Halasa wrote: > Bj?rn Persson writes: > >> It's impossible to verify the security of a computer system from within the >> system itself. If a malicious person may have had root access, then RPM, GPG, >> SElinux and the auditing subsystem may all have been tampered with and you >> can't trust that they tell you the truth. Reinstalling is the only way to be >> sure. > > Sure? Someone may have planted something in a motherboard flash ROM > (easy), in VGA flash, in CD/DVD flash, in HDD flash and/or "service" > sectors etc. > > You can't be 100% sure that a brand-new hardware is clean. Shift this register/logic enough in one direction, and it's going to overflow into "just trust everything"... - -- Basil Mohamed Gohar abu_hurayrah at hidayahonline.org http://www.basilgohar.com/blog basilgohar on irc.freenode.net GPG Key Fingerprint: 5AF4B362 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkoG/2gACgkQaVgOCFr0s2I8gwCeJQ+hVW4WSkz4XIMvKoawe10v zl8AniQBX7AQKRreCQtLABATQe24s/OD =oG9E -----END PGP SIGNATURE----- From drago01 at gmail.com Sun May 10 16:28:48 2009 From: drago01 at gmail.com (drago01) Date: Sun, 10 May 2009 18:28:48 +0200 Subject: FESco meeting summary for 20090507 In-Reply-To: References: Message-ID: On Sun, May 10, 2009 at 5:44 PM, Jon Stanley wrote: > On Sat, May 9, 2009 at 1:34 PM, drago01 wrote: > >> What happened to this https://fedorahosted.org/fesco/ticket/142 ? > > Sorry about that, as I mentioned in the ticket, entirely my fault this > didn't get brought up :( OK, np. > Anyhow, the concerns that I have about this is as Paul noted in the > ticket, what happens if someone ?downloads this now more visible > x86_64 release and finds that it doesn't boot their computer? ?I sense > a lot of "man, this Fedora thing SUCKS!". Yeah true, we have to present in a way where this is unlikely to happen, but hiding the x86_64 version to be only visible for people that know that it exist isn't any better either. Fedora's mission is to provide the new technologies to the user and x86_64 is definitely the way forward. > Moreover, with the new architecture support feature in F11, we're now > supposedly defaulting to an x86_64 kernel on an i686 install if the > processor supports it (note that I say supposedly because I've not > personally tested it). ?Thus you have an x86_64 kernel, and all of the > goodness that brings, but you still have an i686 userspace. Which is not really worth doing, if your hardware supports it you should be using x86_64 for userspace too. The only reason people prefer to run i686 even on x86_64 is because "apps do not work", which is nothing but a myth. Ever 32bit app should work just fine unless it ships with a (binary) kernel module. But all popular binary kernel modules (nvidia, fglrx, vmware, vbox) do ship 64bit builds. > Also, keep in mind that while x86_64 hardware is quite common in the > US and Western Europe (perhaps to a lesser extent there than the US, > even), there are many parts of the world where that is not common, and > folks would have to go find the i686 version to download. True, but everything not a netbook sold in the last couple of years is x86_64 capable. From drago01 at gmail.com Sun May 10 16:29:40 2009 From: drago01 at gmail.com (drago01) Date: Sun, 10 May 2009 18:29:40 +0200 Subject: FESco meeting summary for 20090507 In-Reply-To: <2d319b780905100914n442e2501h78b2184437a67065@mail.gmail.com> References: <2d319b780905100914n442e2501h78b2184437a67065@mail.gmail.com> Message-ID: On Sun, May 10, 2009 at 6:14 PM, Mathieu Bridon (bochecha) wrote: > On Sun, May 10, 2009 at 17:44, Jon Stanley wrote: >> On Sat, May 9, 2009 at 1:34 PM, drago01 wrote: >> >>> What happened to this https://fedorahosted.org/fesco/ticket/142 ? >> >> Sorry about that, as I mentioned in the ticket, entirely my fault this >> didn't get brought up :( >> >> Anyhow, the concerns that I have about this is as Paul noted in the >> ticket, what happens if someone ?downloads this now more visible >> x86_64 release and finds that it doesn't boot their computer? ?I sense >> a lot of "man, this Fedora thing SUCKS!". >> >> Moreover, with the new architecture support feature in F11, we're now >> supposedly defaulting to an x86_64 kernel on an i686 install if the >> processor supports it (note that I say supposedly because I've not >> personally tested it). ?Thus you have an x86_64 kernel, and all of the >> goodness that brings, but you still have an i686 userspace. >> >> Also, keep in mind that while x86_64 hardware is quite common in the >> US and Western Europe (perhaps to a lesser extent there than the US, >> even), there are many parts of the world where that is not common, and >> folks would have to go find the i686 version to download. > > Wouldn't smolt be a good way to know the rates of 64 bits processors > versus 32 bits ones ? > > The ? arch ? tab says : > i686 ? ?200890 ? ? ? ? ?75.2 % > x86_64 ?64931 ? 24.3 % > > But if I understood it right, that's actually the installed arch, not > the capability of the CPU, so many of those i686 installs might come > from 64 bits CPUs and user not knowing/willing to move to 64 bits > OS... Yeah and the installed arch does not really mean much considering how our download page is designed. From a.badger at gmail.com Sun May 10 16:33:38 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 10 May 2009 09:33:38 -0700 Subject: FESco meeting summary for 20090507 In-Reply-To: References: <4A05BF03.6070508@fi.muni.cz> <1241891561.9577.3.camel@localhost.localdomain> <4A05D17C.8030305@gmail.com> Message-ID: <4A0701E2.9040005@gmail.com> Martin Ebourne wrote: > I'll take: > > gdmap (for anyone who hasn't tried it, great way of visualising disk > usage and finding where it all went) > Done. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From ngompa13 at gmail.com Sun May 10 16:53:33 2009 From: ngompa13 at gmail.com (King InuYasha) Date: Sun, 10 May 2009 11:53:33 -0500 Subject: OpenOffice 3.1 In-Reply-To: <4A06F995.4030802@sapience.com> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <4A06F995.4030802@sapience.com> Message-ID: <8278b1b0905100953i3a9d2d8h9bfa050e71dd1ddb@mail.gmail.com> On Sun, May 10, 2009 at 10:58 AM, Mail Lists wrote: > On 05/10/2009 06:53 AM, Martin Ebourne wrote: > >\ .. anyone who wants > > to stay on the previous release probably wants a bit more stability in > > their lives. > > > > Cheers, > > Martin > > > > > While some of your goals are reasonable, please don't confuse > stability of one pretty well tested application on F10 (or possible > instability) with the as yet not known to be as stable entire F11 > distribution. > > Stability is the convolution of all the parts - a 'bit more > stability' of F10 over F11 is a bit premature a statement at this > juncture in my view. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Fedora 11 isn't even released yet, so does that mean that we will see OpenOffice.org 3.1 in Fedora 11? I for one would love to have OOo 3.1 in Fedora 11 just because of the anti aliasing alone. Another benefit is the RTL fixes. Also, grammer checking infrastructure in OOo 3.1 is improved and extended. Granted, afaik nobody has packaged up and hooked up a grammer checking module for it to use, but still.... -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.badger at gmail.com Sun May 10 16:58:40 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 10 May 2009 09:58:40 -0700 Subject: FESco meeting summary for 20090507 In-Reply-To: <4A0608EA.6010700@fi.muni.cz> References: <4A05BF03.6070508@fi.muni.cz> <1241891561.9577.3.camel@localhost.localdomain> <4A05D17C.8030305@gmail.com> <4A0608EA.6010700@fi.muni.cz> Message-ID: <4A0707C0.9050302@gmail.com> Milos Jakubicek wrote: > Hi, > > Dne 9.5.2009 20:54, Toshio Kuratomi wrote: >> Christoph Wickert wrote: >>> Am Samstag, den 09.05.2009, 19:36 +0200 schrieb Milos Jakubicek: >>> >>>>> == Deactivated maintainers == >>>>> >>>>> FESCo approved orphaning packages owned by deactivated maintainers >>>>> >>>> Could you please send then a list of packages that are going to be >>>> orphaned? >>> Most likely: http://toshio.fedorapeople.org/pkg-orphans.txt >>> >> I've updated this list. We're down to 91 packages. I'll perform the >> orphaning tomorrow. > > I'd take over the following packages -- provided the current > comaintainers are not interested in becoming primary maintainers, of > course! > > python-wikimarkup > python-dotconf > html-xml-utils > log4cxx > lzma > mysql-connector-java > splint (Panu?) > nbd (Warren? dyoung?) > Sprog > suitesparse (deji?) > tktray > trousers (ejratl?) > snmp++ (Mamoru?) > Done. I made you maintainer of all of these (and in EL-4/EL-5 where applicable). I trust that you and the current comaintainers can work out if that's the best course of action :-) (If you don't want the EPEL branches feel free to orphan them and announce here that they're up for grabs.) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From vpivaini at cs.helsinki.fi Sun May 10 16:59:32 2009 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Sun, 10 May 2009 19:59:32 +0300 Subject: OpenOffice 3.1 In-Reply-To: <8278b1b0905100953i3a9d2d8h9bfa050e71dd1ddb@mail.gmail.com> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <4A06F995.4030802@sapience.com> <8278b1b0905100953i3a9d2d8h9bfa050e71dd1ddb@mail.gmail.com> Message-ID: <1241974772.17036.2.camel@localhost.localdomain> su, 2009-05-10 kello 11:53 -0500, King InuYasha kirjoitti: > Fedora 11 isn't even released yet, so does that mean that we will see > OpenOffice.org 3.1 in Fedora 11? I for one would love to have OOo 3.1 > in Fedora 11 just because of the anti aliasing alone. Another benefit > is the RTL fixes. Also, grammer checking infrastructure in OOo 3.1 is > improved and extended. Granted, afaik nobody has packaged up and > hooked up a grammer checking module for it to use, but still.... Fedora 11 has OpenOffice.org 3.1. And as for grammar checking, the Finnish spell checking extension openoffice.org-voikko also supports basic grammar checking in Fedora 11, I don't know about other languages though. -- Ville-Pekka Vainio From mark.bidewell at alumni.clemson.edu Sun May 10 17:02:21 2009 From: mark.bidewell at alumni.clemson.edu (Mark Bidewell) Date: Sun, 10 May 2009 13:02:21 -0400 Subject: CUPS 1.4 breakage F11 Message-ID: I am running the F11 preview. When I attempt to print I get blank sheets of paper from the printer. The printer is connected via IPP but the server has not changed. Has anyone else seen this? -- Mark Bidewell http://www.linkedin.com/in/markbidewell -------------- next part -------------- An HTML attachment was scrubbed... URL: From greno at verizon.net Sun May 10 17:34:45 2009 From: greno at verizon.net (Gerry Reno) Date: Sun, 10 May 2009 13:34:45 -0400 Subject: Mirrors: [Errno -3] Error performing checksum Message-ID: <4A071035.2000707@verizon.net> The mirrors recently started returning this error when we try to run 'yum update' on F9 machines? Regards, Gerry From greno at verizon.net Sun May 10 17:37:17 2009 From: greno at verizon.net (Gerry Reno) Date: Sun, 10 May 2009 13:37:17 -0400 Subject: Mirrors: [Errno -3] Error performing checksum In-Reply-To: <4A071035.2000707@verizon.net> References: <4A071035.2000707@verizon.net> Message-ID: <4A0710CD.1030305@verizon.net> Gerry Reno wrote: > The mirrors recently started returning this error when we try to run > 'yum update' on F9 machines? > Here's an example: # yum update Loaded plugins: fastestmirror, installonlyn, refresh-packagekit, versionlock Loading mirror speeds from cached hostfile * updates-newkey: ftp.linux.ncsu.edu * fedora: ftp.linux.ncsu.edu * updates: ftp.linux.ncsu.edu * freshrpms: ayo.ie.freshrpms.net fcabfc18906d2fc553c7fe1228ef87166c449a30e9e1a32678d1ba2f | 4.5 MB 00:02 http://ftp.linux.ncsu.edu/pub/fedora/linux/updates/9/i386.newkey/repodata/fcabfc18906d2fc553c7fe1228ef87166c449a30e9e1a32678d1ba2fa055b926-primary.sqlite.bz2: [Errno -3] Error performing checksum Trying other mirror. fcabfc18906d2fc553c7fe1228ef87166c449a30e9e1a32678d1ba2f | 4.5 MB 00:02 http://mirrors.tummy.com/pub/fedora.redhat.com/fedora/linux/updates/9/i386.newkey/repodata/fcabfc18906d2fc553c7fe1228ef87166c449a30e9e1a32678d1ba2fa055b926-primary.sqlite.bz2: [Errno -3] Error performing checksum Trying other mirror. Regards, Gerry From sundaram at fedoraproject.org Sun May 10 17:44:13 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 10 May 2009 23:14:13 +0530 Subject: Mirrors: [Errno -3] Error performing checksum In-Reply-To: <4A071035.2000707@verizon.net> References: <4A071035.2000707@verizon.net> Message-ID: <4A07126D.2050907@fedoraproject.org> On 05/10/2009 11:04 PM, Gerry Reno wrote: > The mirrors recently started returning this error when we try to run > 'yum update' on F9 machines? You seem to be repeatedly post end user questions to the development list. Please use fedora-list instead. Rahul From mschwendt at gmail.com Sun May 10 17:49:26 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sun, 10 May 2009 19:49:26 +0200 Subject: FESco meeting summary for 20090507 In-Reply-To: <1241891211.9577.0.camel@localhost.localdomain> References: <4A05BF03.6070508@fi.muni.cz> <1241891211.9577.0.camel@localhost.localdomain> Message-ID: <20090510194926.243bf9e9@faldor.intranet> On Sat, 09 May 2009 19:46:50 +0200, Christoph wrote: > Am Samstag, den 09.05.2009, 19:36 +0200 schrieb Milos Jakubicek: > > > > == Deactivated maintainers == > > > > > > FESCo approved orphaning packages owned by deactivated maintainers > > > > > > > Could you please send then a list of packages that are going to be orphaned? > > Most likely: http://toshio.fedorapeople.org/pkg-orphans.txt Does that mean I can stop with following the non-responsive maintainer policy for ghenry and "cpan2rpm" (as it's on the list)? https://bugzilla.redhat.com/498746 From sanjay.ankur at gmail.com Sun May 10 17:55:14 2009 From: sanjay.ankur at gmail.com (Ankur Sinha) Date: Sun, 10 May 2009 23:25:14 +0530 Subject: Locking assertion failure. Backtrace: Message-ID: <1241978114.3331.20.camel@localhost.localdomain> hi, I'm packaging an app called "panini". The packaging's gone smoothly.. On running the app, I get [Ankur at Ankur twitter_tui]$ panini Locking assertion failure. Backtrace: #0 /usr/lib/libxcb-xlib.so.0 [0xf09767] #1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_lock+0x2e) [0xf0990e] #2 /usr/lib/libX11.so.6 [0x5a90e9] #3 /usr/lib/libX11.so.6(XCreateSimpleWindow+0x26) [0x57edb6] #4 /usr/lib/libQtGui.so.4 [0x72c3c85] #5 /usr/lib/libQtGui.so.4(_ZN14QWidgetPrivate10create_sysEmbb+0x1828) [0x72c25d8] #6 /usr/lib/libQtGui.so.4(_ZN7QWidget6createEmbb+0x16c) [0x7284c1c] #7 /usr/lib/libQtGui.so.4(_ZN14QWidgetPrivate11createWinIdEm+0x1e3) [0x727ff43] #8 /usr/lib/libQtGui.so.4(_ZN14QWidgetPrivate21setWindowTitle_helperERK7QString+0x9b) [0x72845bb] #9 /usr/lib/libQtGui.so.4(_ZN7QWidget14setWindowTitleERK7QString+0xa2) [0x7284a12] #10 /usr/lib/libQtGui.so.4(_ZN11QMessageBox14setWindowTitleERK7QString +0x24) [0x7766554] #11 /usr/lib/libQtGui.so.4 [0x7768237] #12 /usr/lib/libQtGui.so.4(_ZN11QMessageBoxC1ENS_4IconERK7QStringS3_6QFlagsINS_14StandardButtonEEP7QWidgetS4_IN2Qt10WindowTypeEE+0x1f0) [0x77685b0] #13 /usr/lib/libQtGui.so.4 [0x776885b] #14 /usr/lib/libQtGui.so.4(_ZN11QMessageBox7warningEP7QWidgetRK7QStringS4_6QFlagsINS_14StandardButtonEES6_+0x36) [0x7768a76] #15 panini [0x8057ca3] #16 /usr/lib/libQtCore.so.4(_Z17qt_message_output9QtMsgTypePKc+0x35) [0x6f0d095] #17 /usr/lib/libQtCore.so.4(_Z8qWarningPKcz+0x71) [0x6f0d431] #18 /usr/lib/libQtGui.so.4 [0x7290268] #19 /usr/lib/libX11.so.6(_XError+0x109) [0x5a1aa9] ^\Quit [Ankur at Ankur twitter_tui]$ I've googled and come across some posts related to the same, but they're related to Java etc. and were solved by exporting some varialbles, which did not work here. Can someone please tell me what the problem is? regards, Ankur From a.badger at gmail.com Sun May 10 18:03:19 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 10 May 2009 11:03:19 -0700 Subject: FESco meeting summary for 20090507 In-Reply-To: <20090510194926.243bf9e9@faldor.intranet> References: <4A05BF03.6070508@fi.muni.cz> <1241891211.9577.0.camel@localhost.localdomain> <20090510194926.243bf9e9@faldor.intranet> Message-ID: <4A0716E7.4070804@gmail.com> Michael Schwendt wrote: > On Sat, 09 May 2009 19:46:50 +0200, Christoph wrote: > >> Am Samstag, den 09.05.2009, 19:36 +0200 schrieb Milos Jakubicek: >> >>>> == Deactivated maintainers == >>>> >>>> FESCo approved orphaning packages owned by deactivated maintainers >>>> >>> Could you please send then a list of packages that are going to be orphaned? >> Most likely: http://toshio.fedorapeople.org/pkg-orphans.txt > > Does that mean I can stop with following the non-responsive maintainer > policy for ghenry and "cpan2rpm" (as it's on the list)? > https://bugzilla.redhat.com/498746 > Yes. I'll be mass orphaning this tonight. Do you think this package should be retired instead of simply orphaned? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From drago01 at gmail.com Sun May 10 18:06:58 2009 From: drago01 at gmail.com (drago01) Date: Sun, 10 May 2009 20:06:58 +0200 Subject: FESco meeting summary for 20090507 In-Reply-To: <4A0716E7.4070804@gmail.com> References: <4A05BF03.6070508@fi.muni.cz> <1241891211.9577.0.camel@localhost.localdomain> <20090510194926.243bf9e9@faldor.intranet> <4A0716E7.4070804@gmail.com> Message-ID: On Sun, May 10, 2009 at 8:03 PM, Toshio Kuratomi wrote: > Michael Schwendt wrote: >> On Sat, 09 May 2009 19:46:50 +0200, Christoph wrote: >> >>> Am Samstag, den 09.05.2009, 19:36 +0200 schrieb Milos Jakubicek: >>> >>>>> == Deactivated maintainers == >>>>> >>>>> FESCo approved orphaning packages owned by deactivated maintainers >>>>> >>>> Could you please send then a list of packages that are going to be orphaned? >>> Most likely: http://toshio.fedorapeople.org/pkg-orphans.txt >> >> Does that mean I can stop with following the non-responsive maintainer >> policy for ghenry and "cpan2rpm" (as it's on the list)? >> https://bugzilla.redhat.com/498746 >> > Yes. ?I'll be mass orphaning this tonight. ?Do you think this package > should be retired instead of simply orphaned? numlockx - jpmahowa I will take this. From a.badger at gmail.com Sun May 10 18:14:05 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 10 May 2009 11:14:05 -0700 Subject: FESco meeting summary for 20090507 In-Reply-To: <1241891211.9577.0.camel@localhost.localdomain> References: <4A05BF03.6070508@fi.muni.cz> <1241891211.9577.0.camel@localhost.localdomain> Message-ID: <4A07196D.30000@gmail.com> Christoph Wickert wrote: > Am Samstag, den 09.05.2009, 19:36 +0200 schrieb Milos Jakubicek: > >>> == Deactivated maintainers == >>> >>> FESCo approved orphaning packages owned by deactivated maintainers >>> >> Could you please send then a list of packages that are going to be orphaned? > > Most likely: http://toshio.fedorapeople.org/pkg-orphans.txt > A few additional packages that will be orphaned in EPEL or OLPC. Unless these are also listed in pkg-orphans.txt, these have Fedora maintainers so it's only going to affect EPEL/OLPC. I'll send out a complete list of what was orphaned in what branches after I do the orphaning tonight. EPEL: ginac - qspencer octave - qspencer octave-forge - qspencer pgadmin3 - ghenry rdiff-backup - ghenry reciteword - zhu scim-hangul - zhu shapelib - smccann sqlite - pnasrat tpm-tools - key OLPC: djvulibre - mpg farsight - gdesmott gstreamer-plugins-farsight - gdesmott hippo-canvas - mpg hulahop - mpg libjingle - gdesmott olpc-hardware-manager - mpg pyxapian - mpg speech-dispatcher - hemantg sugar - mpg sugar-artwork - mpg sugar-base - mpg sugar-datastore - mpg sugar-journal - mpg sugar-presence-service - mpg sugar-toolkit - mpg telepathy-stream-engine - gdesmott xapian-bindings - mpg xapian-core - mpg -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From jkeating at redhat.com Sun May 10 16:47:28 2009 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 10 May 2009 09:47:28 -0700 Subject: Guaranteeing running code is signed In-Reply-To: <3da3b5b40905091136s3dd92954kffde00706905a850@mail.gmail.com> References: <3da3b5b40905091136s3dd92954kffde00706905a850@mail.gmail.com> Message-ID: <1241974049.3452.3.camel@localhost.localdomain> On Sat, 2009-05-09 at 21:36 +0300, Ahmed Kamal wrote: > Is there any technology in fedora, that enables me to ensure that ALL > running code on a certain server (even code not installed from RPMs, such as > say by a legacy admin), has been signed by redhat, and to warn me about > un-signed code that is running or about to run. I am interested to verify a > server is in a "known-good" state 1) look into "FIPS mode" 2) rpm --query --all --verify 3) System fingerprinting tools such as AIDE -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From pbrobinson at gmail.com Sun May 10 18:22:32 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Sun, 10 May 2009 19:22:32 +0100 Subject: FESco meeting summary for 20090507 In-Reply-To: <4A07196D.30000@gmail.com> References: <4A05BF03.6070508@fi.muni.cz> <1241891211.9577.0.camel@localhost.localdomain> <4A07196D.30000@gmail.com> Message-ID: <5256d0b0905101122l76dd5925od7f86a4a1fd3755d@mail.gmail.com> I can take some of these if no one else in interested. > djvulibre - mpg > farsight - gdesmott > gstreamer-plugins-farsight - gdesmott > hippo-canvas - mpg > hulahop - mpg > libjingle - gdesmott > olpc-hardware-manager - mpg > speech-dispatcher - hemantg > sugar - mpg > sugar-artwork - mpg > sugar-base - mpg > sugar-datastore - mpg > sugar-journal - mpg > sugar-presence-service - mpg > sugar-toolkit - mpg > telepathy-stream-engine - gdesmott I've already taken ownership of these, so not sure why they are listed as orphaned. > xapian-bindings - mpg > xapian-core - mpg and I've already done the dead package process on this one as well. > pyxapian - mpg Peter From mschwendt at gmail.com Sun May 10 18:33:38 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sun, 10 May 2009 20:33:38 +0200 Subject: cpan2rpm (was: Re: FESco meeting summary for 20090507) In-Reply-To: <4A0716E7.4070804@gmail.com> References: <4A05BF03.6070508@fi.muni.cz> <1241891211.9577.0.camel@localhost.localdomain> <20090510194926.243bf9e9@faldor.intranet> <4A0716E7.4070804@gmail.com> Message-ID: <20090510203338.7d00dd5a@faldor.intranet> On Sun, 10 May 2009 11:03:19 -0700, Toshio wrote: > >> Most likely: http://toshio.fedorapeople.org/pkg-orphans.txt > > > > Does that mean I can stop with following the non-responsive maintainer > > policy for ghenry and "cpan2rpm" (as it's on the list)? > > https://bugzilla.redhat.com/498746 > > > Yes. I'll be mass orphaning this tonight. Do you think this package > should be retired instead of simply orphaned? Retiring it would be better. Bz 498746 sums up that everybody seems to use'n'prefer cpanspec instead. There's somebody who would sign up as the new owner (as a last resort), but he would also prefer to retire cpan2rpm. From jussi.lehtola at iki.fi Sun May 10 18:35:53 2009 From: jussi.lehtola at iki.fi (Jussi Lehtola) Date: Sun, 10 May 2009 21:35:53 +0300 Subject: FESco meeting summary for 20090507 In-Reply-To: <4A07196D.30000@gmail.com> References: <4A05BF03.6070508@fi.muni.cz> <1241891211.9577.0.camel@localhost.localdomain> <4A07196D.30000@gmail.com> Message-ID: <1241980553.3126.3.camel@localhost.localdomain> On Sun, 2009-05-10 at 11:14 -0700, Toshio Kuratomi wrote: > A few additional packages that will be orphaned in EPEL or OLPC. Unless > these are also listed in pkg-orphans.txt, these have Fedora maintainers > so it's only going to affect EPEL/OLPC. I'll send out a complete list > of what was orphaned in what branches after I do the orphaning tonight. > > EPEL: > > octave - qspencer > octave-forge - qspencer I can take ownership of the EPEL branch of these if no-one else is interested. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From overholt at redhat.com Sun May 10 04:25:02 2009 From: overholt at redhat.com (Andrew Overholt) Date: Sun, 10 May 2009 00:25:02 -0400 Subject: Update -> b0rken eclipse In-Reply-To: <1241907936.3147.24.camel@dimi.lattica.com> References: <1241905038.3147.13.camel@dimi.lattica.com> <1241907936.3147.24.camel@dimi.lattica.com> Message-ID: <20090510042501.GD20251@redhat.com> * Dimi Paun [2009-05-09 18:26]: > P.S. Why isn't WTP packaged as an RPM? It is an important part of > Eclipse, and it is a real pain to install via the Software Updates > feature in Eclipse. Those working on getting it packaged in the bug Mat mentions would love your help, I'm sure. Also, why is it so hard to install with the Update Manager? I'm curious both as a Fedora maintainer and an upstream person. Email me offline if you prefer. Andrew From overholt at redhat.com Sun May 10 04:20:29 2009 From: overholt at redhat.com (Andrew Overholt) Date: Sun, 10 May 2009 00:20:29 -0400 Subject: Update -> b0rken eclipse In-Reply-To: <1241907936.3147.24.camel@dimi.lattica.com> References: <1241905038.3147.13.camel@dimi.lattica.com> <1241907936.3147.24.camel@dimi.lattica.com> Message-ID: <20090510042029.GB20251@redhat.com> * Dimi Paun [2009-05-09 18:26]: > > But meanwhile I tried using the Native version (which didn't work right We don't ship gcj .so files anymore and haven't for a while so it's not really "the Native version" :) Unless you mean "the packaged version". > until recently), and after some pain (the Software Updates... feature > is just horrible!) I managed to get WTP (Web Tools Project installed) > and make it usable. How is the Update Manager any better in upstream's version? We do not differ at all. Andrew From overholt at redhat.com Sun May 10 04:23:47 2009 From: overholt at redhat.com (Andrew Overholt) Date: Sun, 10 May 2009 00:23:47 -0400 Subject: Update -> b0rken eclipse In-Reply-To: References: <1241905038.3147.13.camel@dimi.lattica.com> Message-ID: <20090510042346.GC20251@redhat.com> * darrell pfeifer [2009-05-09 17:54]: > > Are you starting eclipse with a brand new workspace? If so the empty dialog > problem has been around for a long time. I think it is actually due to a gtk > update. An empty workspace displays the big-buttoned welcome screen, which is > what I think is having problems. This "has problems" because some XULRunner interfaces that SWT's browser support uses have changed a few times. The welcome screen is rendered by the browser. Is the welcome screen broken in rawhide right now? I've been working with the 3.5 pre-release packages we're targetting at F-12 so haven't seen if recent XULRunner updates have broken SWT's browser component. Andrew From darrellpf at gmail.com Sun May 10 19:23:41 2009 From: darrellpf at gmail.com (darrell pfeifer) Date: Sun, 10 May 2009 12:23:41 -0700 Subject: Update -> b0rken eclipse In-Reply-To: <20090510042346.GC20251@redhat.com> References: <1241905038.3147.13.camel@dimi.lattica.com> <20090510042346.GC20251@redhat.com> Message-ID: On Sat, May 9, 2009 at 21:23, Andrew Overholt wrote: > * darrell pfeifer [2009-05-09 17:54]: > > > > Are you starting eclipse with a brand new workspace? If so the empty > dialog > > problem has been around for a long time. I think it is actually due to a > gtk > > update. An empty workspace displays the big-buttoned welcome screen, > which is > > what I think is having problems. > > This "has problems" because some XULRunner interfaces that SWT's browser > support uses have changed a few times. The welcome screen is rendered > by the browser. > > Is the welcome screen broken in rawhide right now? I've been working > with the 3.5 pre-release packages we're targetting at F-12 so haven't > seen if recent XULRunner updates have broken SWT's browser component. > It is still broken with the combination of 3.5M6 (from eclipse.org), java 1.6.0_14 b06 (from sun) and today's rawhide. darrell -------------- next part -------------- An HTML attachment was scrubbed... URL: From email.ahmedkamal at googlemail.com Sun May 10 19:30:12 2009 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sun, 10 May 2009 22:30:12 +0300 Subject: Guaranteeing running code is signed In-Reply-To: <1241974049.3452.3.camel@localhost.localdomain> References: <3da3b5b40905091136s3dd92954kffde00706905a850@mail.gmail.com> <1241974049.3452.3.camel@localhost.localdomain> Message-ID: <3da3b5b40905101230m397381c8mfe99f1e3f8e12e63@mail.gmail.com> Yes, I'm after making sure the system is in "known-clean" state, after a bad-admin/intruder has "potentially" deliberately inserted malicious code somewhere on the server > > 1) look into "FIPS mode" Please forgive my ignorance, but AFAICT FIPS mode is a standard specifying a number of known-good algorithms, with apps specifically compiled using FIPS mode compile options, only use FIPS libs and algorithms. This requires application level compile-time support. I'm not quite sure how that applies to the use case in this thread > 2) rpm --query --all --verify Malicious code implanted, is (surely?) not installed by rpms. I don't believe this can really help. Moreover, the rpmDB might have been tampered with. I am willing to trust my CPU/Bios, because, well trust has to start somewhere, and the skills to develop and inject custom firmware, are fairly uncommon (unless some kinda goverenment is after you). However, to trust a simple file like the rpmDB, would be naive eh? > 3) System fingerprinting tools such as AIDE > A bit useful, but with system updates being applied all the time, it is really hard to practically benefit from HIDS unless you have a known good snapshot exactly before the intruder got access to the system and with no system updates applied till the time you want to verify :-/ Hardly satisfactory I can imagine a solution that goes something like: 1- The system is powered off, booted from a known-good live/rescue CD (freshly downloaded, checksum+signature verified) 2- The live OS downloads rpm metadata that are signed by fedora (is this already the yum metadata?) 3- Once downloaded and verified, the live OS starts scanning on-disk files verifying the integrity of all the system, most notably the "basic" security related code (kernel, selinux libs, auditing, rpm-signatures-DB ...) 4- Once verified, the system boots from hard-disk, the now verified basic security code (kernel, selinux ...) get some flag such that no process is allowed to execute unless it passes signature checks from the now known-good rpmDB. 5- All foreign binaries fail to launch, and a log message is logged somewhere till the admin manually approves the 3rd party application (by perhaps assigning it some selinux label?) 6- 3rd party bash/python... etc scripts, should "somehow" be stopped from execution as well, till manually audited and approved Comments and thoughts are appreciated Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruno at wolff.to Sun May 10 19:34:20 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Sun, 10 May 2009 14:34:20 -0500 Subject: Guaranteeing running code is signed In-Reply-To: <3da3b5b40905101230m397381c8mfe99f1e3f8e12e63@mail.gmail.com> References: <3da3b5b40905091136s3dd92954kffde00706905a850@mail.gmail.com> <1241974049.3452.3.camel@localhost.localdomain> <3da3b5b40905101230m397381c8mfe99f1e3f8e12e63@mail.gmail.com> Message-ID: <20090510193420.GA12146@wolff.to> On Sun, May 10, 2009 at 22:30:12 +0300, Ahmed Kamal wrote: > Yes, I'm after making sure the system is in "known-clean" state, after a > bad-admin/intruder has "potentially" deliberately inserted malicious code > somewhere on the server > > Comments and thoughts are appreciated It'd probably be easier to back up the data, wipe the machine, reinstall and restore the data. From overholt at redhat.com Sun May 10 19:37:31 2009 From: overholt at redhat.com (Andrew Overholt) Date: Sun, 10 May 2009 15:37:31 -0400 Subject: Update -> b0rken eclipse In-Reply-To: References: <1241905038.3147.13.camel@dimi.lattica.com> <20090510042346.GC20251@redhat.com> Message-ID: <20090510193731.GA24249@redhat.com> * darrell pfeifer [2009-05-10 15:24]: > > On Sat, May 9, 2009 at 21:23, Andrew Overholt wrote: > > Is the welcome screen broken in rawhide right now? > > It is still broken with the combination of 3.5M6 (from eclipse.org), java > 1.6.0_14 b06 (from sun) and today's rawhide. What about our Eclipse packages in Fedora? What about 3.5M7 from eclipse.org? Thanks for testing this! Andrew From forum at ru.bir.ru Sun May 10 19:38:54 2009 From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus)) Date: Sun, 10 May 2009 23:38:54 +0400 Subject: Note on man pages In-Reply-To: <4A00BCE9.3050800@fedoraproject.org> References: <4A00BCE9.3050800@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > Hi, > > Debian has a policy that all the commands should have man pages as part > of their review process. Hm... Very good policy on first glance. Why Fedora do not do something similar? From john5342 at googlemail.com Sun May 10 19:59:27 2009 From: john5342 at googlemail.com (John5342) Date: Sun, 10 May 2009 20:59:27 +0100 Subject: Update -> b0rken eclipse In-Reply-To: <20090510042029.GB20251@redhat.com> References: <1241905038.3147.13.camel@dimi.lattica.com> <1241907936.3147.24.camel@dimi.lattica.com> <20090510042029.GB20251@redhat.com> Message-ID: <6dc6523c0905101259t2047b1e5i23d6499966517b1d@mail.gmail.com> 2009/5/10 Andrew Overholt : > * Dimi Paun [2009-05-09 18:26]: >> >> But meanwhile I tried using the Native version (which didn't work right > > We don't ship gcj .so files anymore and haven't for a while so it's not > really "the Native version" :) ?Unless you mean "the packaged version". > >> until recently), and after some pain (the Software Updates... feature >> is just horrible!) I managed to get WTP (Web Tools Project installed) >> and make it usable. > > How is the Update Manager any better in upstream's version? ?We do not > differ at all. I think the issue he is reffering to is that when you use the upstream version and install in your home folder for example all updates/addons are installed into that folder too and all works as expected but if you use the fedora version the rpm versions are installed in system and addons from update center are installed in home folder. result is that it is difficult to update addons that are rpm installed and combined with strict version dependencies from other addons it makes it difficult if not impossible to install some additional addons. Having said that I havent really had many issues like that recently. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... From forum at ru.bir.ru Sun May 10 20:05:44 2009 From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus)) Date: Mon, 11 May 2009 00:05:44 +0400 Subject: OpenOffice 3.1 In-Reply-To: References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> Message-ID: Kevin Kofler wrote: > Christian Rose wrote: >> IMHO, Fedora needs more maintainers who think of whole releases as >> stable release sets. > > "Stable release sets" doesn't mean "no updates", it means "no updates which > break things". > > Normally, 3.0->3.1 type upgrades aren't the kind of updates which cause > regressions or compatibility issues. +1 I fully agreed. Fedora is a bleeding edge distro. It is why I love it. It sometimes got trouble, but it is. If we have distro with other policy - please, RHEL, CentOS have it absolutely different - no updates until it absolutely needed. So, if 3.0 -> 3.1 update do not promise serious troubles - I want see it in Fedora 10. From kevin.kofler at chello.at Sun May 10 20:49:48 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 10 May 2009 22:49:48 +0200 Subject: Note on man pages References: <4A00BCE9.3050800@fedoraproject.org> Message-ID: Pavel Alexeev (aka Pahan-Hubbitus) wrote: > Hm... Very good policy on first glance. Why Fedora do not do something > similar? Because it's often a lot of work to write a manpage and generally not worth the effort if upstream isn't interested in maintaining it. Kevin Kofler From kevin.kofler at chello.at Sun May 10 20:59:53 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 10 May 2009 22:59:53 +0200 Subject: glibc fork ? References: <4A02F8D3.2010807@poolshark.org> <4A036082.8000107@fedoraproject.org> <20090509160428.0bf3c0e6.zaitcev@redhat.com> Message-ID: Pete Zaitcev wrote: > It doesn't matter what the PR is. But even if anyone believes this > kool-aid and starts acting as if it's true (e.g. synching with Uli's > glibc), they are going to end with Claws and Sylpheed eventually, > unless they die off first. Or they might actually win, like egcs did back in the day. It's hard to predict the future of a fork, it might die except possibly for a few crackpots keeping it alive (the only example I can think of is GoneMe, but there are undoubtedly many other failed forks I never even heard of), or it might win, with possibly a few crackpots keeping alive the original project (as for XFree86 (*)), or the forks might diverge from each other like Sylpheed vs. Claws or GNU Emacs vs. XEmacs. But it's clear that the regularly-synced "fork" isn't a very stable development relation and tends to degenerate into one of those 3 scenarios. Kevin Kofler (*) though arguably XFree86 is the failed fork and the X.Org Consortium is the legitimate successor of the original maintainer, but when you look at the actual code flow, the latest X.Org X11 releases are clearly forked from XFree86 From kevin.kofler at chello.at Sun May 10 21:04:23 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 10 May 2009 23:04:23 +0200 Subject: 182 pending F11 stable updates. WTF? References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241949557.3109.2.camel@localhost.localdomain> Message-ID: Jussi Lehtola wrote: > Why not? The purpose of testing is to find out if the package breaks > something. In the case of a new package there is no functionality of it > to break; the only possibility of getting into trouble is if the package > itself hasn't been made correctly (clashing file names or so on), which > should be in any case picked up in the review. But you still risk pushing out a completely broken new package, which doesn't reflect well on you. ;-) One of the ways this can happen is if you inadvertently built your new package against a buildroot override which is not in stable yet. Or of course the package itself could be broken. Kevin Kofler From forum at ru.bir.ru Sun May 10 21:08:07 2009 From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus)) Date: Mon, 11 May 2009 01:08:07 +0400 Subject: Note on man pages In-Reply-To: References: <4A00BCE9.3050800@fedoraproject.org> Message-ID: Kevin Kofler wrote: > Pavel Alexeev (aka Pahan-Hubbitus) wrote: >> Hm... Very good policy on first glance. Why Fedora do not do something >> similar? > > Because it's often a lot of work to write a manpage and generally not worth > the effort if upstream isn't interested in maintaining it. We can often borrow them form Debian though :) From forum at ru.bir.ru Sun May 10 21:12:37 2009 From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus)) Date: Mon, 11 May 2009 01:12:37 +0400 Subject: Note on man pages In-Reply-To: References: <4A00BCE9.3050800@fedoraproject.org> Message-ID: Kevin Kofler wrote: > Pavel Alexeev (aka Pahan-Hubbitus) wrote: >> Hm... Very good policy on first glance. Why Fedora do not do something >> similar? > > Because it's often a lot of work to write a manpage and generally not worth > the effort if upstream isn't interested in maintaining it. We can often borrow them from Debian though :) From kevin.kofler at chello.at Sun May 10 21:20:57 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 10 May 2009 23:20:57 +0200 Subject: FESco meeting summary for 20090507 References: Message-ID: Jon Stanley wrote: > Moreover, with the new architecture support feature in F11, we're now > supposedly defaulting to an x86_64 kernel on an i686 install if the > processor supports it (note that I say supposedly because I've not > personally tested it). Thus you have an x86_64 kernel, and all of the > goodness that brings, but you still have an i686 userspace. As explained on the relevant feature page, this hasn't actually been implemented. > Also, keep in mind that while x86_64 hardware is quite common in the > US and Western Europe (perhaps to a lesser extent there than the US, > even) Uh, you can't really buy a 32-bit machine other than a netbook here in Western Europe anymore either. Of course, some old 32-bit-only computers are still in use (like the one I'm typing this message on), but I don't think those are significantly more or less common here than in the US. Kevin Kofler From twaugh at redhat.com Sun May 10 21:23:32 2009 From: twaugh at redhat.com (Tim Waugh) Date: Sun, 10 May 2009 22:23:32 +0100 Subject: CUPS 1.4 breakage F11 In-Reply-To: References: Message-ID: <1241990612.3357.0.camel@worm> On Sun, 2009-05-10 at 13:02 -0400, Mark Bidewell wrote: > I am running the F11 preview. When I attempt to print I get blank > sheets of paper from the printer. The printer is connected via IPP > but the server has not changed. Has anyone else seen this? Please report it in bugzilla, and make sure to attach the troubleshoot.txt file you get from running the printing troubleshooter (System->Administration->Printing, then Help->Troubleshoot). Thanks, Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Sun May 10 21:29:52 2009 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 10 May 2009 14:29:52 -0700 Subject: OpenOffice 3.1 In-Reply-To: References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> Message-ID: <1241990992.3452.6.camel@localhost.localdomain> On Mon, 2009-05-11 at 00:05 +0400, Pavel Alexeev (aka Pahan-Hubbitus) wrote: > +1 > I fully agreed. Fedora is a bleeding edge distro. It is why I love it. > It sometimes got trouble, but it is. If we have distro with other policy > - please, RHEL, CentOS have it absolutely different - no updates until > it absolutely needed. > So, if 3.0 -> 3.1 update do not promise serious troubles - I want see it > in Fedora 10. Fedora has a bleeding edge release. it's called rawhide. Feel free to use it. Others prefer an actual release that tries to maintain something close to stability throughout its lifetime. Stability not just in bugs, but in how things operate and how valid the documentation is for it, or what to expect when confronted with a GA vs GA+ 4 months of updates. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From cmadams at hiwaay.net Sun May 10 21:31:12 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Sun, 10 May 2009 16:31:12 -0500 Subject: FESco meeting summary for 20090507 In-Reply-To: References: Message-ID: <20090510213112.GA628090@hiwaay.net> Once upon a time, Kevin Kofler said: > Of course, some old 32-bit-only computers are still in use (like the one I'm > typing this message on), but I don't think those are significantly more or > less common here than in the US. My 32-bit-only Thinkpad is a little over 3 years old but is still a good notebook (I have no plans to replace it any time soon, although I did recently put a bigger and faster hard drive in it). I would expect 64-bit-capable desktops to have a majority by now, but I don't know that the same is true for notebooks. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From kevin.kofler at chello.at Sun May 10 21:33:13 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 10 May 2009 23:33:13 +0200 Subject: FESco meeting summary for 20090507 References: <4A05BF03.6070508@fi.muni.cz> <1241891211.9577.0.camel@localhost.localdomain> Message-ID: Christoph Wickert wrote: > Most likely: http://toshio.fedorapeople.org/pkg-orphans.txt > kio_p7zip - nixaff4 Be warned that this one: 1. appears to be dead upstream and 2. is still KDE 3, so it doesn't work in KDE 4 apps (Dolphin, Konqueror, Krusader 2 etc.), so the best course of action might be to just retire this, unless someone wants to port it to KDE 4. > tastymenu - nixaff4 This is a Kicker applet, just plain doesn't work at all in KDE 4 and has already been retired from all active branches. Kevin Kofler From forum at ru.bir.ru Sun May 10 21:42:17 2009 From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus)) Date: Mon, 11 May 2009 01:42:17 +0400 Subject: RFE: Add URL of project into template of bug for Review Requests Message-ID: I always look for new packages coming into Fedora. Most time as user. It is very interesting see each day new software, new possibility. ~80% I skip on stage looking list of new request in Thunderbird by its title and sort description in subject. Other I read description. And I thought around of half others I go to the bug, open spec-file in my browser, look for the URL tag, copy-past url from it (and it is in case when it come as plain text, if there used macroses like %name-%version it require even more movement) to new tab of browser only to go to offsite!!! Only here I can see what I want - docs, full description, screenshots, how-to, examples and make decision - really this software interesting for me and I want watch for this Review Request or may be even reviewer it or not!!! I guess what many people do same steps from times to times. And if URL to offsite of program will be as clickable link in RR just after (or before) src.rpm and spec links it will be very useful. From kevin.kofler at chello.at Sun May 10 21:50:51 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 10 May 2009 23:50:51 +0200 Subject: Locking assertion failure. Backtrace: References: <1241978114.3331.20.camel@localhost.localdomain> Message-ID: Ankur Sinha wrote: > Locking assertion failure. Backtrace: [snip] > #1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_lock+0x2e) [0xf0990e] [snip] > #[0x77685b0] 13 /usr/lib/libQtGui.so.4 [0x776885b] 14 > #/usr/lib/libQtGui.so. (_ZN11QMessageBox7warningEP7QWidgetRK7QStringS4_6QFlagsINS_14StandardButtonEES6_+0x36) [that's QMessageBox::warning(QWidget*, QString const&, QString const&, QFlags, QMessageBox::StandardButton)] [snip] > #17 /usr/lib/libQtCore.so.4(_Z8qWarningPKcz+0x71) [0x6f0d431] [that's qWarning(char const*, ...)] [snip] > #19 /usr/lib/libX11.so.6(_XError+0x109) [0x5a1aa9] [snip] > I've googled and come across some posts related to the same, but they're > related to Java etc. and were solved by exporting some varialbles, which > did not work here. Can someone please tell me what the problem is? This program is trying to redirect qWarning messages to a message box. That is not allowed, because X11 errors are redirected to qWarning and you aren't allowed to use X11 functions within the XError handler. It will lead to lock recursion and thus a deadlock in X11 code. (I have highlighted the relevant functions in the backtrace.) The program needs to be fixed not to issue a message box for qWarning (it is also highly annoying to do that anyway), it should just use the default handler (which outputs to the console). The second issue here is that the Oxygen style (which is the default in KDE) is triggering X errors/warnings, triggering that issue in some apps. But that doesn't mean the apps don't need to be fixed too (and we already got the other offenders fixed, at least in the Fedora packages), X errors/warnings are something which can happen and the app shouldn't deadlock on it. Kevin Kofler From forum at ru.bir.ru Sun May 10 21:51:52 2009 From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus)) Date: Mon, 11 May 2009 01:51:52 +0400 Subject: OpenOffice 3.1 In-Reply-To: <1241990992.3452.6.camel@localhost.localdomain> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <1241990992.3452.6.camel@localhost.localdomain> Message-ID: Jesse Keating wrote: > On Mon, 2009-05-11 at 00:05 +0400, Pavel Alexeev (aka Pahan-Hubbitus) wrote: >> +1 >> I fully agreed. Fedora is a bleeding edge distro. It is why I love it. >> It sometimes got trouble, but it is. If we have distro with other policy >> - please, RHEL, CentOS have it absolutely different - no updates until >> it absolutely needed. >> So, if 3.0 -> 3.1 update do not promise serious troubles - I want see it >> in Fedora 10. > > Fedora has a bleeding edge release. it's called rawhide. Feel free to > use it. Others prefer an actual release that tries to maintain > something close to stability throughout its lifetime. Stability not > just in bugs, but in how things operate and how valid the documentation > is for it, or what to expect when confronted with a GA vs GA+ 4 months > of updates. I don't want start again wlamewar about several stability means. Wikipedia migration to Ubuntu last time do it very well. And as I remember most often justification was: Fedora can't and won't be enough stable, because it is very dynamical and fresh. Meantime, If you see upcoming serious trouble in this particular update - please say, and no problem, we can do not do it. If not, why you objecting from it? From kevin.kofler at chello.at Sun May 10 21:57:10 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 10 May 2009 23:57:10 +0200 Subject: [OT] was Re: FESco meeting summary for 20090507 References: <20090510213112.GA628090@hiwaay.net> Message-ID: Chris Adams wrote: > My 32-bit-only Thinkpad is a little over 3 years old but is still a good > notebook (I have no plans to replace it any time soon, although I did > recently put a bigger and faster hard drive in it). I would expect > 64-bit-capable desktops to have a majority by now, but I don't know that > the same is true for notebooks. It's funny because I have a 32-bit desktop and a 64-bit notebook. ;-) But the 64-bit notebook is very recent because I just had to replace the ancient Pentium II laptop (which was called a "notebook" at the time, but I've never seen paper notebooks as thick as that "notebook" computer ;-) ) I've been using before, so my case is certainly not the average case. :-) Kevin Kofler From john5342 at googlemail.com Sun May 10 21:58:26 2009 From: john5342 at googlemail.com (John5342) Date: Sun, 10 May 2009 22:58:26 +0100 Subject: OpenOffice 3.1 In-Reply-To: <1241990992.3452.6.camel@localhost.localdomain> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <1241990992.3452.6.camel@localhost.localdomain> Message-ID: <6dc6523c0905101458l64811e65lb9f18216a4f93941@mail.gmail.com> 2009/5/10 Jesse Keating : > On Mon, 2009-05-11 at 00:05 +0400, Pavel Alexeev (aka Pahan-Hubbitus) wrote: >> +1 >> I fully agreed. Fedora is a bleeding edge distro. It is why I love it. >> It sometimes got trouble, but it is. If we have distro with other policy >> - please, RHEL, CentOS have it absolutely different - no updates until >> it absolutely needed. >> So, if 3.0 -> 3.1 update do not promise serious troubles - I want see it >> in Fedora 10. > > Fedora has a bleeding edge release. ?it's called rawhide. ?Feel free to > use it. ?Others prefer an actual release that tries to maintain > something close to stability throughout its lifetime. ?Stability not > just in bugs, but in how things operate and how valid the documentation > is for it, or what to expect when confronted with a GA vs GA+ 4 months > of updates. That may be true to some extent but here is what i think the repos/releases should be. Rawhide - A place to dump known breaking changes to knock them into shape before next release. Updates testing. - A place to put updates which are not expected to significantly break things in order fix them so they become non-breaking updates. updates - Non-breaking updates. Nothing stopping this or any of the above from being bleeding edge and it should recieve updates to latest version where possible so long as it doesnt result in breakage or regressions. RedHat/CentOS/Your other slow release distro here - All packages should be absolutely stable and almost entirely bug fixes/minor updates. No breakage what so ever. Every distro should have its purpose/aim or it will fail. There are already plenty of distros that concentrate stability or performance or size etc. Fedora in my opinion is aiming to be leading edge. Sure it shouldnt be at the total expense of stability (cant be worked on if it doesnt work) but that doesnt mean we should avoid updating just because it might look ever so slightly different to documentation or there might be the odd bug. I think most people do (or should) know leading edge and absolute stability can conflict at times. Just my 2 cents/pence/other small currency -- There are 10 kinds of people in the world: Those who understand binary and those who don't... From sundaram at fedoraproject.org Sun May 10 22:15:21 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 11 May 2009 03:45:21 +0530 Subject: Note on man pages In-Reply-To: References: <4A00BCE9.3050800@fedoraproject.org> Message-ID: <4A0751F9.4070509@fedoraproject.org> On 05/11/2009 02:38 AM, Pavel Alexeev (aka Pahan-Hubbitus) wrote: > Kevin Kofler wrote: >> Pavel Alexeev (aka Pahan-Hubbitus) wrote: >>> Hm... Very good policy on first glance. Why Fedora do not do something >>> similar? >> >> Because it's often a lot of work to write a manpage and generally not >> worth >> the effort if upstream isn't interested in maintaining it. > > We can often borrow them form Debian though :) ... which was precisely the point of this note that I posted. Rahul From pbrobinson at gmail.com Sun May 10 22:12:59 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Sun, 10 May 2009 23:12:59 +0100 Subject: FESco meeting summary for 20090507 In-Reply-To: References: Message-ID: <5256d0b0905101512m5dae0071jad00fe7d735cf284@mail.gmail.com> Hi All, > == Deactivated maintainers == > > FESCo approved orphaning packages owned by deactivated maintainers Looking through the orphaned package list there looks to be quite a list of dead packages there as well. What is the process for marking them dead in the pgkdb or do they just hang around as orphaned in case someone wants to revive them. The gstreamer08 ones are some that come to mind. I know I have ownership of a package as well that is dead (replaced by other packages) and has gone through the dead package process, is there a process for the pkgdb part of that? Peter From bjorn at xn--rombobjrn-67a.se Sun May 10 22:14:50 2009 From: bjorn at xn--rombobjrn-67a.se (=?iso-8859-1?q?Bj=F6rn_Persson?=) Date: Mon, 11 May 2009 00:14:50 +0200 Subject: FESco meeting summary for 20090507 In-Reply-To: References: Message-ID: <200905110014.50581.bjorn@xn--rombobjrn-67a.se> Kevin Kofler wrote: > Uh, you can't really buy a 32-bit machine other than a netbook here in > Western Europe anymore either. Netbooks aren't the only kind of compact, low-power 32-bit computers. There are for example small headless servers from Soekris, Mini-ITX boards from several manufacturers, and many brands of miniature desktop computers such as "eBox"; and retailers exist in Western Europe: http://www.soekris.eu/shop/ http://www.dustin.se/productdetails.aspx?prodid=5010198913 https://www1.elfa.se/elfa~eu_en/b2b/catalogstart.do?tab=catalog Bj?rn Persson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From sundaram at fedoraproject.org Sun May 10 22:20:58 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 11 May 2009 03:50:58 +0530 Subject: Locking assertion failure. Backtrace: In-Reply-To: References: <1241978114.3331.20.camel@localhost.localdomain> Message-ID: <4A07534A.2040509@fedoraproject.org> On 05/11/2009 03:20 AM, Kevin Kofler wrote: > This program is trying to redirect qWarning messages to a message box. That > is not allowed, because X11 errors are redirected to qWarning and you > aren't allowed to use X11 functions within the XError handler. It will lead > to lock recursion and thus a deadlock in X11 code. (I have highlighted the > relevant functions in the backtrace.) The program needs to be fixed not to > issue a message box for qWarning (it is also highly annoying to do that > anyway), it should just use the default handler (which outputs to the > console). > > The second issue here is that the Oxygen style (which is the default in KDE) > is triggering X errors/warnings, triggering that issue in some apps. But > that doesn't mean the apps don't need to be fixed too (and we already got > the other offenders fixed, at least in the Fedora packages), X > errors/warnings are something which can happen and the app shouldn't > deadlock on it. So is the answer to point these issues to upstream and hope that they fix it? Would you be willing to write a patch? Rahul From forum at ru.bir.ru Sun May 10 22:16:50 2009 From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus)) Date: Mon, 11 May 2009 02:16:50 +0400 Subject: Note on man pages In-Reply-To: <4A0751F9.4070509@fedoraproject.org> References: <4A00BCE9.3050800@fedoraproject.org> <4A0751F9.4070509@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > On 05/11/2009 02:38 AM, Pavel Alexeev (aka Pahan-Hubbitus) wrote: >> Kevin Kofler wrote: >>> Pavel Alexeev (aka Pahan-Hubbitus) wrote: >>>> Hm... Very good policy on first glance. Why Fedora do not do something >>>> similar? >>> Because it's often a lot of work to write a manpage and generally not >>> worth >>> the effort if upstream isn't interested in maintaining it. >> We can often borrow them form Debian though :) > > ... which was precisely the point of this note that I posted. Yes, but not precisely ;) While it is just a recommendation and only in maillist it will missed by many maintainers. I speak why we do not want propagate it to guidelines change and then to Reviewer MUST things? From sundaram at fedoraproject.org Sun May 10 22:30:39 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 11 May 2009 04:00:39 +0530 Subject: Note on man pages In-Reply-To: References: <4A00BCE9.3050800@fedoraproject.org> <4A0751F9.4070509@fedoraproject.org> Message-ID: <4A07558F.5050604@fedoraproject.org> On 05/11/2009 03:46 AM, Pavel Alexeev (aka Pahan-Hubbitus) wrote: > While it is just a recommendation and only in maillist it will missed by > many maintainers. I speak why we do not want propagate it to guidelines > change and then to Reviewer MUST things? If you want to propose a draft, be my guest. https://fedoraproject.org/wiki/Packaging:Committee#Step_One:_Draft_Guidelines Thanks. Rahul From christoph.wickert at googlemail.com Sun May 10 22:31:23 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Mon, 11 May 2009 00:31:23 +0200 Subject: Orphaned packages (Re: FESco meeting summary for 20090507) In-Reply-To: References: <4A05BF03.6070508@fi.muni.cz> <1241891211.9577.0.camel@localhost.localdomain> Message-ID: <1241994683.3552.8.camel@localhost.localdomain> Am Sonntag, den 10.05.2009, 23:33 +0200 schrieb Kevin Kofler: > Christoph Wickert wrote: > > Most likely: http://toshio.fedorapeople.org/pkg-orphans.txt > > > kio_p7zip - nixaff4 > Be warned that this one: More warnings: * firestarter - last release in January 2005 * gfa - crash on adding a contact, no release or fix since 2007, seems to be dead upstream * glipper - same as gfa + # 449890 * notecase - last release in Dec 2008 but officially discontinued now * tasty menu - only for KDE3 Regards, Christoph From forum at ru.bir.ru Sun May 10 22:52:49 2009 From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus)) Date: Mon, 11 May 2009 02:52:49 +0400 Subject: Note on man pages In-Reply-To: <4A07558F.5050604@fedoraproject.org> References: <4A00BCE9.3050800@fedoraproject.org> <4A0751F9.4070509@fedoraproject.org> <4A07558F.5050604@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > On 05/11/2009 03:46 AM, Pavel Alexeev (aka Pahan-Hubbitus) wrote: > >> While it is just a recommendation and only in maillist it will missed by >> many maintainers. I speak why we do not want propagate it to guidelines >> change and then to Reviewer MUST things? > > If you want to propose a draft, be my guest. > > https://fedoraproject.org/wiki/Packaging:Committee#Step_One:_Draft_Guidelines Off course. But I want hear what think other maintainers about this. And, while I more think about it, can me in Guidelines directly refer to the foreign project like Debian or anything else? And can we in guidelines oblige copy it f.e. from Debian, but do not require maintainer write it from scratch if it absent?? From sundaram at fedoraproject.org Sun May 10 23:12:43 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 11 May 2009 04:42:43 +0530 Subject: Note on man pages In-Reply-To: References: <4A00BCE9.3050800@fedoraproject.org> <4A0751F9.4070509@fedoraproject.org> <4A07558F.5050604@fedoraproject.org> Message-ID: <4A075F6B.3060503@fedoraproject.org> On 05/11/2009 04:22 AM, Pavel Alexeev (aka Pahan-Hubbitus) wrote: > And, while I more think about it, can me in Guidelines directly refer to > the foreign project like Debian or anything else? And can we in > guidelines oblige copy it f.e. from Debian, but do not require > maintainer write it from scratch if it absent?? Sure. It can be worded something like: "If additional useful patches exist in other distribution packages (ex: man pages in Debian), the package maintainer should evaluate them carefully, add those that are suitable and send them to the [http://fedoraproject.org/wiki/Staying_close_to_upstream_projects upstream project] as well, It is highly recommended that the package maintainers consider writing a man page, especially for command line applications where good documentation is missing in the upstream project, It might be useful to talk to the upstream projects first and check whether they are willing to accept man pages or other forms of documentation as patches" Rahul From rodd at clarkson.id.au Sun May 10 23:37:30 2009 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Mon, 11 May 2009 09:37:30 +1000 Subject: OpenOffice 3.1 In-Reply-To: References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> Message-ID: <1241998651.2760.9.camel@moose> On Mon, 2009-05-11 at 00:05 +0400, Pavel Alexeev (aka Pahan-Hubbitus) wrote: > Kevin Kofler wrote: > > Christian Rose wrote: > >> IMHO, Fedora needs more maintainers who think of whole releases as > >> stable release sets. > > > > "Stable release sets" doesn't mean "no updates", it means "no updates which > > break things". > > > > Normally, 3.0->3.1 type upgrades aren't the kind of updates which cause > > regressions or compatibility issues. > +1 > I fully agreed. Fedora is a bleeding edge distro. It is why I love it. > It sometimes got trouble, but it is. If we have distro with other policy > - please, RHEL, CentOS have it absolutely different - no updates until > it absolutely needed. > So, if 3.0 -> 3.1 update do not promise serious troubles - I want see it > in Fedora 10. Um, I'm a little confused. You want bleeding edge, and you see Fedora as a bleeding edge distro. You also want OOo3.1 backported from f11 to f10. If you're into bleeding edge, won't you get OOo3.1 when you upgrage to f11? And if you're not upgrading from f10, then your comments about bleeding edge can't be that serious. I think it's fair to assume that anyone using f10 is happy with it just the way it is, and don't desperately want the current version, and that if they aren't they will choose to upgrade (or cross over to another distro). As such, doesn't Caolan's policy make a lot of sense? R. From forum at ru.bir.ru Mon May 11 00:11:45 2009 From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus)) Date: Mon, 11 May 2009 04:11:45 +0400 Subject: OpenOffice 3.1 In-Reply-To: <1241998651.2760.9.camel@moose> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <1241998651.2760.9.camel@moose> Message-ID: Rodd Clarkson wrote: > Um, I'm a little confused. You want bleeding edge, and you see Fedora > as a bleeding edge distro. You also want OOo3.1 backported from f11 to > f10. > > If you're into bleeding edge, won't you get OOo3.1 when you upgrage to > f11? And if you're not upgrading from f10, then your comments about > bleeding edge can't be that serious. > > I think it's fair to assume that anyone using f10 is happy with it just > the way it is, and don't desperately want the current version, and that > if they aren't they will choose to upgrade (or cross over to another > distro). > I speak about Fedora distro, not only rawhide. You think user which is not upgraded into Fedora 11 first alpha do not want get updates for used application?? Off course, main new features like new hash algorithm in RPM, ext4 by default etc. must be *only* in new release. But, I, as maintainer, still use Fedora 9 on one of my machine, and still can't find time to upgrade it... So, please tell me why you think if I, say on My Work notebook use Fedora 10 I do not want use OO 3.1??? I want. I maintain my packages mostly on Fedora 9 yet, but nothing prevent me maintain it for the all supported releases: F9, F10, F11 and some also for EPEL. And it is not prevent me love and hate bleeding edge Fedora! Also I can't on work notebook have risk what X server don't started after upgrade to alpha/beta/preview F11. And I play with it in Live media and in Virtual Machine. So, new features is new features. It is cool, but, if you bothered about users, you must provide for that up to date environment, especially it is not caused problems for you in all (ok, ok, I initially do not speak about coming EOL Fedora 9) supported releases. In the end, no one is forcing update! If you like OO 3.0 - please, use it, but if you want 3.1, also - please, take it. IMHO, off course. From rodd at clarkson.id.au Mon May 11 00:45:55 2009 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Mon, 11 May 2009 10:45:55 +1000 Subject: OpenOffice 3.1 In-Reply-To: References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <1241998651.2760.9.camel@moose> Message-ID: <1242002755.2760.23.camel@moose> On Mon, 2009-05-11 at 04:11 +0400, Pavel Alexeev (aka Pahan-Hubbitus) wrote: > Rodd Clarkson wrote: > > Um, I'm a little confused. You want bleeding edge, and you see Fedora > > as a bleeding edge distro. You also want OOo3.1 backported from f11 to > > f10. > > > > If you're into bleeding edge, won't you get OOo3.1 when you upgrage to > > f11? And if you're not upgrading from f10, then your comments about > > bleeding edge can't be that serious. > > > > I think it's fair to assume that anyone using f10 is happy with it just > > the way it is, and don't desperately want the current version, and that > > if they aren't they will choose to upgrade (or cross over to another > > distro). > > > I speak about Fedora distro, not only rawhide. You think user which is > not upgraded into Fedora 11 first alpha do not want get updates for used > application?? I never mentioned rawhide, but if I had I might have said 'if you want bleeding edge and often broken'. > Off course, main new features like new hash algorithm in RPM, ext4 by > default etc. must be *only* in new release. But, I, as maintainer, still > use Fedora 9 on one of my machine, and still can't find time to upgrade > it... So, please tell me why you think if I, say on My Work notebook use > Fedora 10 I do not want use OO 3.1??? I want. I maintain my packages > mostly on Fedora 9 yet, but nothing prevent me maintain it for the all > supported releases: F9, F10, F11 and some also for EPEL. And it is not > prevent me love and hate bleeding edge Fedora! Also I can't on work > notebook have risk what X server don't started after upgrade to > alpha/beta/preview F11. And I play with it in Live media and in Virtual > Machine. I can't account for your time use, and I understand that upgrading takes time, especially when you maintain a number of machines. As for your work laptop running f10 and not having time to upgrade to f11, but want OOo3.1, let me give you and opposing argument. My wife doesn't want to update her laptop every 6 months (I do) and she gets really annoyed when the applications she uses change mid release and she has to change with them. She doesn't have the time to re-learn an application and just want's to work in an consistent and expected way. She does however appreciate that her laptop is (relatively) up-to-date and doesn't mind upgrading every 12 months (or so). Should she have to have take the time to relearn applications because you haven't got the time to upgrade? More importantly, from her perspective she doesn't give a damn if there are changes to things like "new hash algorithm in RPM, ext4 by default etc" and doesn't even realize that she uses these things. She does however use OOo, Firefox, Evolution and other applications and she does notice when they chance and she doesn't like it changing all the time (and especially mid-release). > So, new features is new features. It is cool, but, if you bothered about > users, you must provide for that up to date environment, especially it > is not caused problems for you in all (ok, ok, I initially do not speak > about coming EOL Fedora 9) supported releases. In the end, no one is > forcing update! If you like OO 3.0 - please, use it, but if you want > 3.1, also - please, take it. I love new-ness and up-to-date goodness, but the thing missing in this whole discussion is what might be so compelling about OOo3.1 that we need to be upgrade it mid-release (which is is for f10). The original email (for this thread) made some inquiries which appear to be problems elsewhere and most of the other needs for OOo3.1 seem to be upgrades for the sake of getting the latests (with no critical new features mentioned). I understand where you're coming from, but I also understand that not everyone is coming from the same place as you and that while you're needs (OOo3.1) are easy enough to address (with and upgrade, time withstanding) you also need to appreciate that some don't want the update, don't need it and are happy to have fallen a little bit away (not RHEL, Centos, etc far, but a little bit) from the bleeding edge (or more correctly, leading edge). R. > > IMHO, off course. From skvidal at fedoraproject.org Mon May 11 02:55:26 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Sun, 10 May 2009 22:55:26 -0400 (EDT) Subject: 182 pending F11 stable updates. WTF? In-Reply-To: References: <1241718097.3209.11.camel@localhost.localdomain> <4A033B7F.1030801@redhat.com> <4A0348D3.8000302@gmail.com> <4A038D53.7040200@redhat.com> <1241806113.2923.512.camel@adam.local.net> <604aa7910905081417l4bd77c74l60d4631d76b4ddf1@mail.gmail.com> <1241824854.2923.526.camel@adam.local.net> Message-ID: On Sat, 9 May 2009, Panu Matilainen wrote: > On Fri, 8 May 2009, Adam Williamson wrote: > >> On Fri, 2009-05-08 at 13:17 -0800, Jeff Spaleta wrote: >>> On Fri, May 8, 2009 at 10:08 AM, Adam Williamson >>> wrote: >>>> I think PackageKit / yum integration would definitely be the way to go. >>> >>> Goes back to the underlying issue... how do you notify the user that >>> package foo came from updates-testing X number of minutes/hours/days >>> of testing..after system installation..so they can report back after >>> those X number of minutes/hourse/days of testing? >>> >>> We don't record from which repository a package was installed from. To >>> know what maybe installed from testing you have to be clever and do >>> something like yum --disablerepo=updates-testing list extras diffed >>> against yum list extras. >> >> That sounds extremely ugly. I think if we want to have more metadata >> about packages, we should start tracking it at the appropriate level - >> rpm or yum should track that information. If we're not willing to do >> that, we shouldn't try and implement ugly hacks to generate the metadata >> some other way. > > There already is an accurate way of tracking this: package signatures. For > example, this'll give you the packages that came from F10 testing: > > rpm -qa --qf "%{name}-%{version}-%{release}\t%{dsaheader:pgpsig}\n"|grep "Key > ID 92a1023d0b86274e"|cut -f1 > > It doesn't tell you if/when the package gets moved from testing to updates of > course, but it does tell you where a given package *originated* from. In yum 3.2.23 (coming soon to a theater near you) we'll have this info saved on every pkg you install. It will save the repo from which it was installed (if any) when it is being installed. -sv From rc040203 at freenet.de Mon May 11 03:27:55 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 11 May 2009 05:27:55 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <20090510131115.226b27a5@faldor.intranet> References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241949557.3109.2.camel@localhost.localdomain> <20090510131115.226b27a5@faldor.intranet> Message-ID: <4A079B3B.20606@freenet.de> Michael Schwendt wrote: > On Sun, 10 May 2009 12:59:16 +0300, Jussi wrote: > >> On Sat, 2009-05-09 at 21:33 -0400, Orcan Ogetbil wrote: >>> On Thu, May 7, 2009 at 5:09 PM, Richard W.M. Jones wrote: >>>> I'll tell you the three reasons I'm pushing stuff directly to stable: >>>> >>>> (1) New package. >>>> [cut] >>> Is it a good practice to push a new package to stable? > > No. I strongly disagree. Adding "stable" packages to stable is the primary interest contributors are after. It's the #1 reason, why Fedora Extras one had been launched. What destabilizes Fedora is Fedora being based on insufficiently stable SW, not "new packages". Ralf From dimi at lattica.com Mon May 11 04:26:01 2009 From: dimi at lattica.com (Dimi Paun) Date: Mon, 11 May 2009 00:26:01 -0400 Subject: Update -> b0rken eclipse In-Reply-To: <20090510042029.GB20251@redhat.com> References: <1241905038.3147.13.camel@dimi.lattica.com> <1241907936.3147.24.camel@dimi.lattica.com> <20090510042029.GB20251@redhat.com> Message-ID: <1242015961.3147.39.camel@dimi.lattica.com> On Sun, 2009-05-10 at 00:20 -0400, Andrew Overholt wrote: > > But meanwhile I tried using the Native version (which didn't work > right > > We don't ship gcj .so files anymore and haven't for a while so it's > not really "the Native version" :) Unless you mean "the packaged > version". OK, "the packaged version" than it is :) It's hard to tell if there are .so files or not... > > until recently), and after some pain (the Software Updates... > feature > is just horrible!) I managed to get WTP (Web Tools Project > installed) > and make it usable. > > How is the Update Manager any better in upstream's version? We do not > differ at all. You are right, it's not different -- it was just a small rant that was out of context. Eclipse is an amazing application, and it sets a very high bar, but that particular part is very poorly though out from a usability perspective. To add insult to injury, it might be worse with the packaged version due to the fact that some components are fixed. But that's conjecture, all I know it's been painful. I'll detail why in a different message. -- Dimi Paun Lattica, Inc. From dimi at lattica.com Mon May 11 05:18:51 2009 From: dimi at lattica.com (Dimi Paun) Date: Mon, 11 May 2009 01:18:51 -0400 Subject: Update -> b0rken eclipse In-Reply-To: <20090510042501.GD20251@redhat.com> References: <1241905038.3147.13.camel@dimi.lattica.com> <1241907936.3147.24.camel@dimi.lattica.com> <20090510042501.GD20251@redhat.com> Message-ID: <1242019131.3147.92.camel@dimi.lattica.com> On Sun, 2009-05-10 at 00:25 -0400, Andrew Overholt wrote: > Also, why is it so hard to install with the Update > Manager? I'm curious both as a Fedora maintainer and an upstream > person. OK, so this is a partial story (now that I have things working, I can not easily reproduce all problems). But check this out. Problem: you are a Java developer and need the Web Server Tools 1. You go to Software Updates ... 2. There's no WST anywhere, so you click on "Manage Sites", which looks something like this: http://img228.imageshack.us/img228/52/screenshotavailablesoft.png WTF?!? Which one do I pick? You try to parse the URLs, there's no "web" in there it seems. 3. So you say, OK, let's add the site: http://img219.imageshack.us/img219/2415/screenshotaddsite.png Great, but where do I find it, how? You go on the eclipse.org site, you click around, the information is hard to find. You find lots of complicated download pages, you lose a lot of time finding the silly URL, finally you discover it on the download page and wonder why you didn't find it the first 2-3 times you looked at it. 4. You add the site, and try to install the WST. You expand it and you see this: http://img24.imageshack.us/img24/881/screenshotsoftwareupdat.png Dali? Patch Features? WTF?!? All I want are the Web tools! 5. So you expand one more level to try to find what you're looking for: http://img219.imageshack.us/img219/881/screenshotsoftwareupdat.png Holly crap! What do you pick from there? This would make a grown man cry :) So you go and pick a few safe things that seem reasonable (Java EE Developer Tools, Eclipse XML Editor and Tools, etc) 6. Then you click "Install": http://img219.imageshack.us/img219/5549/screenshotprogressinfor.png This is great. So it looks up dependencies, etc. But wait! At the end of the install, I get a small dialog telling me that the install failed due to missing dependencies (despite the dependency check saying it was OK)! You parse the cryptic names, and install some EMF that might seem to help. Try again. Fail! Add GFE, that might help. Fail. Similar error at the _end_ of the install. WTF? What next? Maybe instead of installing all 4 features at once, lets try to do it one by one. What do you know, that works... As I was writing this, I realized that maybe some of the problems stem from the fact that I started with a non-pristine .eclipse dir. So I've erased it, and tried again: - add the WST project site - select the 4 components I am interested in - click install: http://img140.imageshack.us/img140/4483/screenshotinstall.png What am I supposed to do next? The whole thing is an interaction disaster. When I add a site it should automatically read some metadata and add any dependencies automatically, etc, etc. This is DLL/RPM/you-name-it hell all over again. -- Dimi Paun Lattica, Inc. From linuxguy123 at gmail.com Mon May 11 05:51:12 2009 From: linuxguy123 at gmail.com (Linuxguy123) Date: Sun, 10 May 2009 23:51:12 -0600 Subject: Update -> b0rken eclipse In-Reply-To: <1242019131.3147.92.camel@dimi.lattica.com> References: <1241905038.3147.13.camel@dimi.lattica.com> <1241907936.3147.24.camel@dimi.lattica.com> <20090510042501.GD20251@redhat.com> <1242019131.3147.92.camel@dimi.lattica.com> Message-ID: <1242021072.3688.11.camel@localhost.localdomain> On Mon, 2009-05-11 at 01:18 -0400, Dimi Paun wrote: > On Sun, 2009-05-10 at 00:25 -0400, Andrew Overholt wrote: > > Also, why is it so hard to install with the Update > > Manager? I'm curious both as a Fedora maintainer and an upstream > > person. > > OK, so this is a partial story (now that I have things working, > I can not easily reproduce all problems). But check this out. > > Problem: you are a Java developer and need the Web Server Tools > > 1. You go to Software Updates ... > 2. There's no WST anywhere, so you click on "Manage Sites", which > looks something like this: > http://img228.imageshack.us/img228/52/screenshotavailablesoft.png > > WTF?!? Which one do I pick? You try to parse the URLs, there's > no "web" in there it seems. > > 3. So you say, OK, let's add the site: > http://img219.imageshack.us/img219/2415/screenshotaddsite.png > > Great, but where do I find it, how? You go on the eclipse.org > site, you click around, the information is hard to find. > You find lots of complicated download pages, you lose a lot of > time finding the silly URL, finally you discover it on the > download page and wonder why you didn't find it the first 2-3 > times you looked at it. > > 4. You add the site, and try to install the WST. You expand it > and you see this: > http://img24.imageshack.us/img24/881/screenshotsoftwareupdat.png > > Dali? Patch Features? WTF?!? All I want are the Web tools! > > 5. So you expand one more level to try to find what you're looking for: > http://img219.imageshack.us/img219/881/screenshotsoftwareupdat.png > > Holly crap! What do you pick from there? This would make a grown > man cry :) So you go and pick a few safe things that seem reasonable > (Java EE Developer Tools, Eclipse XML Editor and Tools, etc) > > 6. Then you click "Install": > http://img219.imageshack.us/img219/5549/screenshotprogressinfor.png > > This is great. So it looks up dependencies, etc. But wait! > At the end of the install, I get a small dialog telling me that the > install failed due to missing dependencies (despite the dependency > check saying it was OK)! You parse the cryptic names, and install > some EMF that might seem to help. Try again. Fail! Add GFE, that > might help. Fail. Similar error at the _end_ of the install. > > WTF? What next? Maybe instead of installing all 4 features at once, > lets try to do it one by one. What do you know, that works... > > As I was writing this, I realized that maybe some of the problems stem > from the fact that I started with a non-pristine .eclipse dir. > > So I've erased it, and tried again: > - add the WST project site > - select the 4 components I am interested in > - click install: > http://img140.imageshack.us/img140/4483/screenshotinstall.png > > What am I supposed to do next? > > The whole thing is an interaction disaster. When I add a site it > should automatically read some metadata and add any dependencies > automatically, etc, etc. This is DLL/RPM/you-name-it hell all > over again. I think I had similar problems. You might want to check out a series of posts on Eclipse setup issues in the Fedora-list list starting on November 30th, 2008. The "solved" thread starts on December 4th, 2008. You might also want to check out https://bugzilla.redhat.com/show_bug.cgi?id=474509 It gives a more concise description, but without some of the background information. Once I installed Eclipse properly, everything worked perfectly, including adding new features and updating. LG. From rc040203 at freenet.de Mon May 11 06:07:56 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 11 May 2009 08:07:56 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <200905081059.20191.mhlavink@redhat.com> <1241795878.3209.88.camel@localhost.localdomain> <20090508153102.GA15821@bludgeon.org> <1241798647.3209.95.camel@localhost.localdomain> <4A04D59A.20006@freenet.de> <1241831621.2923.552.camel@adam.local.net> <4A04DD30.5010805@freenet.de> <1241833349.2923.555.camel@adam.local.net> <4A04F905.7020708@freenet.de> Message-ID: <4A07C0BC.40305@freenet.de> Kevin Kofler wrote: > Ralf Corsepius wrote: >> e.g. being unable to update F11 packages because >> prerequisite package deps are not available in F11. > > That's what buildroot overrides are for. "buildroot overrides" are an inefficient bureaucratic cludge, to workaround and the play down the defects of rel-eng's process. It's exactly the plague, I am trying to get rid of and want to see replaced with something more efficient. From bojan at rexursive.com Mon May 11 06:56:10 2009 From: bojan at rexursive.com (Bojan Smojver) Date: Mon, 11 May 2009 06:56:10 +0000 (UTC) Subject: 182 pending F11 stable updates. WTF? References: <1241718097.3209.11.camel@localhost.localdomain> Message-ID: Jesse Keating redhat.com> writes: > How is it we have 182 stable updates pending for F11 already? How have > these seen any testing by a wider audience? Are we really just not > bothering with updates-testing anymore? Do we not care about distro > stability? > > I know that many of these are newpackages, but many aren't though. > There is one of mine in there - just API docs for Subversion. Should not destabilise anything. -- Bojan From dwmw2 at infradead.org Mon May 11 09:37:12 2009 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 11 May 2009 10:37:12 +0100 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241881514.30126.2.camel@concord3.proximity.on.ca> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <200905081059.20191.mhlavink@redhat.com> <1241795878.3209.88.camel@localhost.localdomain> <20090508153102.GA15821@bludgeon.org> <1241798647.3209.95.camel@localhost.localdomain> <4A04D59A.20006@freenet.de> <1241831621.2923.552.camel@adam.local.net> <1241866003.2910.80.camel@macbook.infradead.org> <1241881514.30126.2.camel@concord3.proximity.on.ca> Message-ID: <1242034632.24436.298.camel@macbook.infradead.org> On Sat, 2009-05-09 at 11:05 -0400, Chris Tyler wrote: > On Sat, 2009-05-09 at 11:46 +0100, David Woodhouse wrote: > > By including the option to add the F11 updates repo at install time. > > > > Er, can't we already do that?? > > ? As long as the repo isn't on NFS, that is. > > And as long as you're using a wired (and not wireless) connection > (tested yesterday). I was aware that it's broken for wireless with WEP -- it says it's waiting for NetworkManager, but nothing ever asks me for the WEP key. Didn't know it was also broken without WEP. -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation From mschwendt at gmail.com Mon May 11 09:43:15 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Mon, 11 May 2009 11:43:15 +0200 Subject: rtorrent GCC 4.1 incompatibility? Message-ID: <20090511114315.5a1f6cb5@rawhide.intranet> [Bcc to rtorrent-owner] The rtorrent.spec file does | # work around a bug thats triggered by gcc 4.1 | | export RPM_OPT_FLAGS=`echo $RPM_OPT_FLAGS | %{__sed} s/-O2/-Os/` and the reader wonders what bug that may be? No bugzilla ticket is linked. The %changelog says: | * Sun Nov 26 2006 Chris Chabot - 0.6.4-1 | - New upstream version | - Compile with -Os to work around a gcc 4.1 incompatibility No bz number either. And it's an entry from 2006. We're in 2009, however, and are using a much newer GCC release. So, what GCC 4.1 bug is it? Is the -Os still needed? From mschwendt at gmail.com Mon May 11 10:20:57 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Mon, 11 May 2009 12:20:57 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241949557.3109.2.camel@localhost.localdomain> Message-ID: <20090511122057.02a66ba1@rawhide.intranet> On Sun, 10 May 2009 23:04:23 +0200, Kevin wrote: > Jussi Lehtola wrote: > > Why not? The purpose of testing is to find out if the package breaks > > something. In the case of a new package there is no functionality of it > > to break; the only possibility of getting into trouble is if the package > > itself hasn't been made correctly (clashing file names or so on), which > > should be in any case picked up in the review. > > But you still risk pushing out a completely broken new package, which > doesn't reflect well on you. ;-) > > One of the ways this can happen is if you inadvertently built your new > package against a buildroot override which is not in stable yet. Or of > course the package itself could be broken. Just to acknowledge that this is not only theory, it has happened before actually. Most recently with qtorrent in Fedora 11 stable updates, with the needed rb_libtorrent only sitting in the koji buildroot. The opposite has happened before, too, however. ABI-incompatible library updates marked stable for one or more dists -- after not using rpmdiff, or deliberately as a result of not knowing the releng buildroot override procedure. Explicit Requires (with and without versions) also cause unresolved dependencies regularly (on one or all archs) when pushing updates to multiple target dists. Other breakage is caused by automatically disabled features at %build/%configure time, if a package is mass-built for multiple dists without accurate/safe/fatal checks of build requirements and without the packager skimming over build logs. From mcepl at redhat.com Mon May 11 10:33:58 2009 From: mcepl at redhat.com (Matej Cepl) Date: Mon, 11 May 2009 12:33:58 +0200 Subject: Update -> b0rken eclipse References: <1241905038.3147.13.camel@dimi.lattica.com> <1241907936.3147.24.camel@dimi.lattica.com> <20090510042501.GD20251@redhat.com> Message-ID: On 2009-05-10, 04:25 GMT, Andrew Overholt wrote: > Those working on getting it packaged in the bug Mat mentions > would love your help, I'm sure. Is there any package review bug for it where I could join the party? Mat?j From akurtako at redhat.com Mon May 11 10:59:27 2009 From: akurtako at redhat.com (Alexander Kurtakov) Date: Mon, 11 May 2009 12:59:27 +0200 Subject: Update -> b0rken eclipse In-Reply-To: References: <1241905038.3147.13.camel@dimi.lattica.com> <20090510042501.GD20251@redhat.com> Message-ID: <200905111259.31350.akurtako@redhat.com> On Monday 11 May 2009 12:33:58 Matej Cepl wrote: > On 2009-05-10, 04:25 GMT, Andrew Overholt wrote: > > Those working on getting it packaged in the bug Mat mentions > > would love your help, I'm sure. > > Is there any package review bug for it where I could join the > party? There is a bug tracking it https://bugzilla.redhat.com/show_bug.cgi?id=486369 . But there is no package review for now because noone found the time to package it. I'm not sure how far the effort is from a package review but packaging wtp is really a place where help is wanted. Alex > > Mat?j From mschwendt at gmail.com Mon May 11 11:12:59 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Mon, 11 May 2009 13:12:59 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <4A07C0BC.40305@freenet.de> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <200905081059.20191.mhlavink@redhat.com> <1241795878.3209.88.camel@localhost.localdomain> <20090508153102.GA15821@bludgeon.org> <1241798647.3209.95.camel@localhost.localdomain> <4A04D59A.20006@freenet.de> <1241831621.2923.552.camel@adam.local.net> <4A04DD30.5010805@freenet.de> <1241833349.2923.555.camel@adam.local.net> <4A04F905.7020708@freenet.de> <4A07C0BC.40305@freenet.de> Message-ID: <20090511131259.22244f97@rawhide.intranet> On Mon, 11 May 2009 08:07:56 +0200, Ralf wrote: > Kevin Kofler wrote: > > Ralf Corsepius wrote: > >> e.g. being unable to update F11 packages because > >> prerequisite package deps are not available in F11. > > > > That's what buildroot overrides are for. > "buildroot overrides" are an inefficient bureaucratic cludge, to > workaround and the play down the defects of rel-eng's process. > It's exactly the plague, I am trying to get rid of and want to see > replaced with something more efficient. The basic idea of buildroot protection is good. What doesn't work well so far, however, is how the buildroot overrides are executed. A packager submits a releng ticket, the request is accepted, the tag gets created, the incompatible package enters the buildroots, no announcement is sent, danger lies ahead. As pointed out elsewhere in this thread, this has hit qtorrent (rb_libtorrent, springlobby) for Fedora 11. The process would be much better if (a) all buildroot overrides would be announced in a prominent place and (b) marking incompatible packages "stable" in order to skip the buildroot override procedure would be forbidden. From mcepl at redhat.com Mon May 11 11:01:04 2009 From: mcepl at redhat.com (Matej Cepl) Date: Mon, 11 May 2009 13:01:04 +0200 Subject: OpenOffice 3.1 References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <4A05B97D.9010705@sapience.com> Message-ID: On 2009-05-09, 17:12 GMT, Mail Llists wrote: > We are happy to have kernel updates Speak just for yourself, please. From mcepl at redhat.com Mon May 11 11:00:23 2009 From: mcepl at redhat.com (Matej Cepl) Date: Mon, 11 May 2009 13:00:23 +0200 Subject: OpenOffice 3.1 References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> Message-ID: <73dld6-n4p.ln1@ppp1053.in.ipex.cz> On 2009-05-09, 11:51 GMT, Caol?n McNamara wrote: > I see our fedora release cycle as ones of iterative stable > complete releases, rather than one which has an always-open > pool of stable packages which always contains the latest stable > version of a package. i.e. F-10 was history as soon as it was > released, and F-11 is likewise almost dead to me already :-) > Not that I won't fix bugs in them, just that I don't see them > as live development releases. +1 and I am sorry this has never been codified as official Fedora policy. I hate that my wife's Fedora 10 (no updates-testing, just updates) is broken quite often, because somebody is spreading their half-baked junk to stable releases. Mat?j (sorry, it's ugly weather outside and my mood is not good accordingly). From mcepl at redhat.com Mon May 11 11:03:21 2009 From: mcepl at redhat.com (Matej Cepl) Date: Mon, 11 May 2009 13:03:21 +0200 Subject: best practices for updates in stable releases (was: Re: OpenOffice 3.1) References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <4A05B234.2020608@leemhuis.info> <1241890311.2886.63.camel@localhost.localdomain> Message-ID: On 2009-05-09, 17:31 GMT, Jesse Keating wrote: > http://fedoraproject.org/wiki/PackageMaintainers/Package_update_guidelines > we have this. What we don't seem to have is everybody > following it. Yes, because this is yet another case where nobody is willing to enforce what has been agreed upon. Mat?j From mschwendt at gmail.com Mon May 11 11:25:26 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Mon, 11 May 2009 13:25:26 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <4A079B3B.20606@freenet.de> References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241949557.3109.2.camel@localhost.localdomain> <20090510131115.226b27a5@faldor.intranet> <4A079B3B.20606@freenet.de> Message-ID: <20090511132526.3195dc37@rawhide.intranet> On Mon, 11 May 2009 05:27:55 +0200, Ralf wrote: > Michael Schwendt wrote: > > On Sun, 10 May 2009 12:59:16 +0300, Jussi wrote: > > > >> On Sat, 2009-05-09 at 21:33 -0400, Orcan Ogetbil wrote: > >>> On Thu, May 7, 2009 at 5:09 PM, Richard W.M. Jones wrote: > >>>> I'll tell you the three reasons I'm pushing stuff directly to stable: > >>>> > >>>> (1) New package. > >>>> [cut] > >>> Is it a good practice to push a new package to stable? > > > > No. > > I strongly disagree. Adding "stable" packages to stable is the primary > interest contributors are after. It's the #1 reason, why Fedora Extras > one had been launched. Cool down and slow down, at least a bit, please. This is about not skipping updates-testing. This is about offering them at least a few days in updates-testing, so the community may contribute actual testing. Fact is that one packager plus one reviewer are not enough to ensure that new packages really work good enough to call them "stable" for one or more dist targets. > What destabilizes Fedora is Fedora being based on insufficiently stable > SW, not "new packages". Agreed, but that's a different topic. Poor updates also create chaos in buildroots. We've had issues like that already during Fedora Extras. From mcepl at redhat.com Mon May 11 11:13:25 2009 From: mcepl at redhat.com (Matej Cepl) Date: Mon, 11 May 2009 13:13:25 +0200 Subject: Another update, another reboot, no sound! References: <1241728409.7634.21.camel@dimi.lattica.com> <20090507214017.GA9824@tango.0pointer.de> <20d6441a0905071448o10cb4928r4cab031966284aac@mail.gmail.com> Message-ID: On 2009-05-07, 21:48 GMT, Jud Craft wrote: > I have no ideas for VirtualBox, don't use it. From what > I hear, virtualized sound is an entirely different can of > worms, and I'm not surprised it doesn't work. Nothing against Virtualbox, just to note that sound works pretty well for me in kvm/qemu guests (tested with RHEL5 and Windows 7 as guests), and user interface of libvirt apps is pretty nice in F11. Mat?j From mcepl at redhat.com Mon May 11 11:07:03 2009 From: mcepl at redhat.com (Matej Cepl) Date: Mon, 11 May 2009 13:07:03 +0200 Subject: OpenOffice 3.1 References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <1241998651.2760.9.camel@moose> Message-ID: On 2009-05-11, 00:11 GMT, Pavel Alexeev (aka Pahan-Hubbitus) wrote: > it... So, please tell me why you think if I, say on My Work > notebook use Fedora 10 I do not want use OO 3.1??? I want. I believe OOo 3.1 from http://download.openoffice.org/other.html works on Fedora 9. Mat?j From rc040203 at freenet.de Mon May 11 11:58:19 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 11 May 2009 13:58:19 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241836379.2886.30.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <645d17210905071452n7da5f852s8bfc5d808a04c56b@mail.gmail.com> <1241733287.3209.61.camel@localhost.localdomain> <4A03A31C.4010003@freenet.de> <1241754133.3209.71.camel@localhost.localdomain> <4A03AF94.60605@freenet.de> <1241756375.3209.76.camel@localhost.localdomain> <4A03BB64.10006@freenet.de> <1241795563.3209.83.camel@localhost.localdomain> <4A04D350.1000904@freenet.de> <1241832771.2886.15.camel@localhost.localdomain> <4A04EAAE.50907@freenet.de> <1241836379.2886.30.camel@localhost.localdomain> Message-ID: <4A0812DB.2000505@freenet.de> Jesse Keating wrote: > On Sat, 2009-05-09 at 04:30 +0200, Ralf Corsepius wrote: >> Short summary: >> * Open F11 updates/testing NOW > > We've been trying to push F11 updates for a couple days now. ... but you still haven't updated fedora-release, so neither mock doesn't pick them up. >> * Decouple cuttings DVDs from F11 development > > I honestly don't understand what you're proposing here. No DVD from the release? No, I am proposing that rel-eng chooses a set of packages to build iso etc. from, while "updates" "rolls on". Or differently: rel-eng composes the "Fedora" repo from those packages they choose, which "updates" continues, independently from rel-eng's activities. > What do we have people download to get the release? As before ... the only difference would be "Fedora" (i.e. the set of packages the DVDs etc. would have been built from) would be older than "updates" (and/or "Everything") > What do > we hand out at events? Openly said, ... I would hand out netboot.img's, accompanied with a yum repository of "Everything" ... but that's a different topic. >> * Implement rawhide/testing > > Is this a full time thing, you always want a rawhide, and a > rawhide-testing, which is driven by bodhi? I haven't thought about all details, but I am inclined to lean towards a "permanent rawhide-testing". There would be times where it hardly would be used, but there can easily be times, when it would be heavily used (e.g. there currently is a proposal pending which would severely change perl's behavior (perl module search order and file system layout), with currently unclear outcome). Ralf From overholt at redhat.com Mon May 11 12:05:27 2009 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 11 May 2009 08:05:27 -0400 Subject: Update -> b0rken eclipse In-Reply-To: <1242021072.3688.11.camel@localhost.localdomain> References: <1241905038.3147.13.camel@dimi.lattica.com> <1241907936.3147.24.camel@dimi.lattica.com> <20090510042501.GD20251@redhat.com> <1242019131.3147.92.camel@dimi.lattica.com> <1242021072.3688.11.camel@localhost.localdomain> Message-ID: <20090511120526.GA3602@redhat.com> > On Mon, 2009-05-11 at 01:18 -0400, Dimi Paun wrote: > > http://img219.imageshack.us/img219/2415/screenshotaddsite.png > > > > Great, but where do I find it, how? Unfortunately, https://bugs.eclipse.org/249133 :( > > http://img24.imageshack.us/img24/881/screenshotsoftwareupdat.png > > > > Dali? Patch Features? WTF?!? All I want are the Web tools! Okay, so you don't like the categorization upstream :) > > You parse the cryptic names, and install > > some EMF that might seem to help. Try again. Fail! Add GFE, that > > might help. Fail. Similar error at the _end_ of the install. This is indeed a problem and should never happen. And yes, p2's error reporting in 3.4 needed work. If we can figure out why this happens, we can look at fixing it. If anyone ever gets into this situation and can reproduce, please let me know. > > [...] > > > > When I add a site it should automatically read some metadata and add > > any dependencies automatically, etc, etc. Yes, it should. There should really only be one site and it should be pre-configured. Unfortunately, https://bugs.eclipse.org/249133 . Andrew From sgallagh at redhat.com Mon May 11 12:07:09 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 11 May 2009 08:07:09 -0400 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 Message-ID: <4A0814ED.60205@redhat.com> OK, first off, why in $DEITY's name are we including Firefox 3.5b4 and Thunderbird 3.0b2 in Fedora 11? These are unstable branches of the browser and email client, and as such are supported by almost none of the myriad of extensions available for the 3.0 and 2.0 versions, respectively. I was more than a little disappointed when I upgraded my laptop to the F11 Preview to discover that only two out of seven of my Thunderbird extensions and three of my thirteen Firefox extensions remained functional. I understand that Fedora is a development OS, and I think it's a great idea to have a firefox35 package and a thunderbird30 package, but these SHOULD NOT be the defaults. Taking away the full functionality of a developer's web browser and email client is an incredible step backwards for Fedora 11. The default install of Fedora 11 should include the latest STABLE versions of Firefox and Thunderbird, and then provide an OPTION to replace them with the unstable development branch. I would understand if Firefox and Thunderbird were in their release candidate phase, and we could reasonably expect that within three months that they would hit final release. Firefox has no definitive (or even approximate) release date scheduled, and Thunderbird is only in its second beta. There is little-to-no guarantee that either of these products will be deemed stable before Fedora 12, and I think it is a severe mistake to make them the default before then. If nothing else, consider this an open request to the Firefox, Thunderbird and Lightning maintainers to provide a compatibility package that can downgrade and replace the unstable and non-extensible versions currently in the distribution. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From pbrobinson at gmail.com Mon May 11 12:18:33 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 11 May 2009 13:18:33 +0100 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A0814ED.60205@redhat.com> References: <4A0814ED.60205@redhat.com> Message-ID: <5256d0b0905110518w650b8da2u73a36d674f690406@mail.gmail.com> > I would understand if Firefox and Thunderbird were in their release > candidate phase, and we could reasonably expect that within three months > that they would hit final release. Firefox has no definitive (or even > approximate) release date scheduled, and Thunderbird is only in its > second beta. There is little-to-no guarantee that either of these > products will be deemed stable before Fedora 12, and I think it is a > severe mistake to make them the default before then. Firefox should be in RC phase by the time F11 is release and is basically in that phase now. The difference between beta 4 and RC will be minor bug fixes. Peter From sgallagh at redhat.com Mon May 11 12:23:14 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 11 May 2009 08:23:14 -0400 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <5256d0b0905110518w650b8da2u73a36d674f690406@mail.gmail.com> References: <4A0814ED.60205@redhat.com> <5256d0b0905110518w650b8da2u73a36d674f690406@mail.gmail.com> Message-ID: <4A0818B2.6090709@redhat.com> On 05/11/2009 08:18 AM, Peter Robinson wrote: >> I would understand if Firefox and Thunderbird were in their release >> candidate phase, and we could reasonably expect that within three months >> that they would hit final release. Firefox has no definitive (or even >> approximate) release date scheduled, and Thunderbird is only in its >> second beta. There is little-to-no guarantee that either of these >> products will be deemed stable before Fedora 12, and I think it is a >> severe mistake to make them the default before then. > > Firefox should be in RC phase by the time F11 is release and is > basically in that phase now. The difference between beta 4 and RC will > be minor bug fixes. > > Peter > That still does not address my concern about Thunderbird, which is still well within the "Don't use this on any system you care about" phase of its development... -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From paul at city-fan.org Mon May 11 12:24:41 2009 From: paul at city-fan.org (Paul Howarth) Date: Mon, 11 May 2009 13:24:41 +0100 Subject: FESco meeting summary for 20090507 In-Reply-To: <4A05D17C.8030305@gmail.com> References: <4A05BF03.6070508@fi.muni.cz> <1241891561.9577.3.camel@localhost.localdomain> <4A05D17C.8030305@gmail.com> Message-ID: <4A081909.3010807@city-fan.org> Toshio Kuratomi wrote: > Christoph Wickert wrote: >> Am Samstag, den 09.05.2009, 19:36 +0200 schrieb Milos Jakubicek: >> >>>> == Deactivated maintainers == >>>> >>>> FESCo approved orphaning packages owned by deactivated maintainers >>>> >>> Could you please send then a list of packages that are going to be orphaned? >> Most likely: http://toshio.fedorapeople.org/pkg-orphans.txt >> > I've updated this list. We're down to 91 packages. I'll perform the > orphaning tomorrow. I'll take perl-IO-Multiplex Paul. From dgboles at comcast.net Mon May 11 12:36:43 2009 From: dgboles at comcast.net (David) Date: Mon, 11 May 2009 08:36:43 -0400 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A0818B2.6090709@redhat.com> References: <4A0814ED.60205@redhat.com> <5256d0b0905110518w650b8da2u73a36d674f690406@mail.gmail.com> <4A0818B2.6090709@redhat.com> Message-ID: <4A081BDB.1000600@comcast.net> On 5/11/2009 8:23 AM, Stephen Gallagher wrote: > On 05/11/2009 08:18 AM, Peter Robinson wrote: >>> I would understand if Firefox and Thunderbird were in their release >>> candidate phase, and we could reasonably expect that within three months >>> that they would hit final release. Firefox has no definitive (or even >>> approximate) release date scheduled, and Thunderbird is only in its >>> second beta. There is little-to-no guarantee that either of these >>> products will be deemed stable before Fedora 12, and I think it is a >>> severe mistake to make them the default before then. >> Firefox should be in RC phase by the time F11 is release and is >> basically in that phase now. The difference between beta 4 and RC will >> be minor bug fixes. >> >> Peter >> > > That still does not address my concern about Thunderbird, which is still > well within the "Don't use this on any system you care about" phase of > its development... Thunderbird is at beta 2. I have used it since beta 1 with no problems. -- David From rawhide at fedoraproject.org Mon May 11 13:02:39 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Mon, 11 May 2009 13:02:39 +0000 (UTC) Subject: rawhide report: 20090511 changes Message-ID: <20090511130239.CADFC1F8215@releng2.fedora.phx.redhat.com> Compose started at Mon May 11 06:15:04 UTC 2009 Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 0 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From dgboles at comcast.net Mon May 11 13:02:09 2009 From: dgboles at comcast.net (David) Date: Mon, 11 May 2009 09:02:09 -0400 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A0814ED.60205@redhat.com> References: <4A0814ED.60205@redhat.com> Message-ID: <4A0821D1.8050803@comcast.net> On 5/11/2009 8:07 AM, Stephen Gallagher wrote: > OK, first off, why in $DEITY's name are we including Firefox 3.5b4 and > Thunderbird 3.0b2 in Fedora 11? These are unstable branches of the > browser and email client, and as such are supported by almost none of > the myriad of extensions available for the 3.0 and 2.0 versions, > respectively. > > I was more than a little disappointed when I upgraded my laptop to the > F11 Preview to discover that only two out of seven of my Thunderbird > extensions and three of my thirteen Firefox extensions remained functional. Depending on exactly what extensions that you have if you *download* them you can change this. Open the .xpi, or .jar, with the archive tool. Open the file named 'install.rdf' with your text editor and look for the line that says "". Change that number to the version that you are using. Or even a little higher if you like. Save and update the 'install.rdf', close the archive tool, and install your new extension. This works for most themes too. > I understand that Fedora is a development OS, and I think it's a great > idea to have a firefox35 package and a thunderbird30 package, but these > SHOULD NOT be the defaults. > > Taking away the full functionality of a developer's web browser and > email client is an incredible step backwards for Fedora 11. The default > install of Fedora 11 should include the latest STABLE versions of > Firefox and Thunderbird, and then provide an OPTION to replace them with > the unstable development branch. > > I would understand if Firefox and Thunderbird were in their release > candidate phase, and we could reasonably expect that within three months > that they would hit final release. Firefox has no definitive (or even > approximate) release date scheduled, and Thunderbird is only in its > second beta. There is little-to-no guarantee that either of these > products will be deemed stable before Fedora 12, and I think it is a > severe mistake to make them the default before then. > > If nothing else, consider this an open request to the Firefox, > Thunderbird and Lightning maintainers to provide a compatibility package > that can downgrade and replace the unstable and non-extensible versions > currently in the distribution. > > -- David From kevin.kofler at chello.at Mon May 11 13:08:49 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 11 May 2009 15:08:49 +0200 Subject: 182 pending F11 stable updates. WTF? References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <200905081059.20191.mhlavink@redhat.com> <1241795878.3209.88.camel@localhost.localdomain> <20090508153102.GA15821@bludgeon.org> <1241798647.3209.95.camel@localhost.localdomain> <4A04D59A.20006@freenet.de> <1241831621.2923.552.camel@adam.local.net> <4A04DD30.5010805@freenet.de> <1241833349.2923.555.camel@adam.local.net> <4A04F905.7020708@freenet.de> <4A07C0BC.40305@freenet.de> <20090511131259.22244f97@rawhide.intranet> Message-ID: Michael Schwendt wrote: > The basic idea of buildroot protection is good. What doesn't work well so > far, however, is how the buildroot overrides are executed. A packager > submits a releng ticket, the request is accepted, the tag gets created, > the incompatible package enters the buildroots, no announcement is sent, > danger lies ahead. As pointed out elsewhere in this thread, this has hit > qtorrent (rb_libtorrent, springlobby) for Fedora 11. The process would > be much better if (a) all buildroot overrides would be announced in a > prominent place and (b) marking incompatible packages "stable" in order > to skip the buildroot override procedure would be forbidden. +1, we just need to find an appropriate "prominent place", otherwise we'll flood fedora-devel-announce or even this list. It has also hit a few packages with Qt 4.5 in F9/F10 updates (even though I did warn about this issue on fedora-devel-announce! So we also need to make sure that people read those announcements before submitting builds!) and almost hit at least one new plasmoid with KDE 4.2.3 in F9, F10 and F11 updates (thankfully, the issue of the plasmoid not working in 4.2.2 came up in #fedora-kde on IRC and the maintainer canceled the push request directly to stable, and I also warned the maintainer of a second plasmoid which was headed for testing just to make sure he's aware of what's going on; both are now headed for testing together with KDE 4.2.3). Kevin Kofler From nicu_fedora at nicubunu.ro Mon May 11 13:18:02 2009 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Mon, 11 May 2009 16:18:02 +0300 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A0818B2.6090709@redhat.com> References: <4A0814ED.60205@redhat.com> <5256d0b0905110518w650b8da2u73a36d674f690406@mail.gmail.com> <4A0818B2.6090709@redhat.com> Message-ID: <4A08258A.80407@nicubunu.ro> On 05/11/2009 03:23 PM, Stephen Gallagher wrote: > On 05/11/2009 08:18 AM, Peter Robinson wrote: >> Firefox should be in RC phase by the time F11 is release and is >> basically in that phase now. The difference between beta 4 and RC will >> be minor bug fixes. > > That still does not address my concern about Thunderbird, which is still > well within the "Don't use this on any system you care about" phase of > its development... Considering the large number of features added and the long time since last stable release of Thunderbird, I find it a worthy addition. Also, in my experience of running it daily, I find it stable enough for serious work (however, I don't run *any* extensions with it). -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/ photography: http://photoblog.nicubunu.ro/ my Fedora stuff: http://fedora.nicubunu.ro/ From kevin.kofler at chello.at Mon May 11 13:21:33 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 11 May 2009 15:21:33 +0200 Subject: OpenOffice 3.1 References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <1241998651.2760.9.camel@moose> <1242002755.2760.23.camel@moose> Message-ID: Rodd Clarkson wrote: > Should she have to have take the time to relearn applications because > you haven't got the time to upgrade? More importantly, from her > perspective she doesn't give a damn if there are changes to things like > "new hash algorithm in RPM, ext4 by default etc" and doesn't even > realize that she uses these things. She does however use OOo, Firefox, > Evolution and other applications and she does notice when they chance > and she doesn't like it changing all the time (and especially > mid-release). Well, there are distributions (like the one starting with a 'U') with such a policy. Nobody is forcing her to use Fedora (except maybe you ;-) ). Kevin Kofler From kevin.kofler at chello.at Mon May 11 13:12:13 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 11 May 2009 15:12:13 +0200 Subject: 182 pending F11 stable updates. WTF? References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241949557.3109.2.camel@localhost.localdomain> <20090511122057.02a66ba1@rawhide.intranet> Message-ID: Michael Schwendt wrote: > Just to acknowledge that this is not only theory, it has happened before > actually. I know, I'm also speaking from experience there. A few made it through to stable (*cough* rkward *cough* Qt 4.5 *cough* and I think there were a couple more Qt 4.5 builds which slipped through too early), I managed to intercept a few others before chaos happened. Kevin Kofler From silfreed at silfreed.net Mon May 11 13:14:31 2009 From: silfreed at silfreed.net (Douglas E. Warner) Date: Mon, 11 May 2009 09:14:31 -0400 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A0821D1.8050803@comcast.net> References: <4A0814ED.60205@redhat.com> <4A0821D1.8050803@comcast.net> Message-ID: <4A0824B7.90106@silfreed.net> David wrote: > On 5/11/2009 8:07 AM, Stephen Gallagher wrote: >> OK, first off, why in $DEITY's name are we including Firefox 3.5b4 and >> Thunderbird 3.0b2 in Fedora 11? These are unstable branches of the >> browser and email client, and as such are supported by almost none of >> the myriad of extensions available for the 3.0 and 2.0 versions, >> respectively. >> >> I was more than a little disappointed when I upgraded my laptop to the >> F11 Preview to discover that only two out of seven of my Thunderbird >> extensions and three of my thirteen Firefox extensions remained functional. > > > Depending on exactly what extensions that you have if you *download* > them you can change this. Open the .xpi, or .jar, with the archive tool. > Open the file named 'install.rdf' with your text editor and look for > the line that says "". Change that number to the version > that you are using. Or even a little higher if you like. Save and update > the 'install.rdf', close the archive tool, and install your new extension. > > This works for most themes too. The point is that most extension developers haven't felt the need to try to update their extensions for Thunderbird 3 as the API hasn't stabilized yet. Thunderbird extensions are much more finicky than Firefox extensions I would wager, especially given this major feature update. I would offer that Firefox 3.5b4 is a lot closer to RC than Thunderbird 3.0b2 is, and I still expect there to be problems with extensions for Firefox before release (this was very common for Firefox 3.0 as well where changes broke extensions even in the RC series). -Doug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From kevin.kofler at chello.at Mon May 11 13:22:21 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 11 May 2009 15:22:21 +0200 Subject: OpenOffice 3.1 References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <4A05B97D.9010705@sapience.com> Message-ID: Matej Cepl wrote: > On 2009-05-09, 17:12 GMT, Mail Llists wrote: >> We are happy to have kernel updates > > Speak just for yourself, please. I'm also happy to have them, that makes at least 2 people, so "we" is correct. :-) Kevin Kofler From mike at thetroubleshooters.dk Mon May 11 13:56:00 2009 From: mike at thetroubleshooters.dk (Michael Nielsen) Date: Mon, 11 May 2009 15:56:00 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: References: Message-ID: <4A082E70.7030904@TheTroubleshooters.dk> Hi, I've been told this is the right place to place this debate starter. Not to demean the fine work that has been done in maintaining fedora, however the distribution is slowly killing itself, being destroyed by contradicting philosophies. Many of the problems have been directly copied from the Windows world. The main problems are. 1. Removal of features - the user interfaces are being dumbed down, like recently I've searched for the ability to remove the "Raise on Click" feature that is default for Gnome MetaCity, there does not appear to be any such feature anymore / argument being to simplify how it works.. Fine, create a simple view and an advanced view for the configuration tools, so that people who are clueless about any other way than the official Redmond way, can avoid being confronted with an alternative. 2. The network interfaces are being bound to the user interface, such that if your X fails for some reason, or you are running on a text console, you are unable to open the wireless configuration, at least it's not obvious how you do it, without X running. The configuration for the network interfaces are so tightly bound to the user interface, such that if there is no user interface there are no network interfaces. 3. Mounts are also embedded into the user interface, rather than in the unix mount system, which means that the shares are not accessible for non-gui programs, for instance, I like to script most thing I do often, however, there is no way for scripts to get a hold of a drive that is mounted through the gui mount system (kde and gnome). 4. Everything is thrown in huge collective directories, such as /usr/bin, /usr/lib etc, and it is a huge mess, just like windows with it's system32 directory, which is also a huge mess. really the /usr/bin,/bin/sbin, /lib etc, has very specific purposes, and should represent a core operating system, that is capable of being used as repair, with no major applications present. However even Open office is stored in these directories. 5. More and more services are bound up in the userinterface, such as the pulse audio, which is started by the GUI, this means if you use 2 user environments, which I often do for testing, where I have X:0 and X:1 running, the GUIs will conflict, because you cannot run two instances of pulseaudio. In addition pulse audio is crap, I have yet to see any installation actually work without crackling, and chopping like crazy. I like the concept that is the basis of pulse audio, but it just does not work. 6. NetworkManager which appears to be installed default, does not work with shared drives, because, the NetworkManager is shut down before the network drives are detached, and you need to modify the NetworkManager to start properly, before you mount the network drives. I've gotten used to explicit uninstalling the NetworkManager, because it just doesn't work properly. It is a lengthy discussion to describe what i mean. However, if I take a sample application like firefox, it presents a reasonable proxy for what I mean. currently default installation of firefox on my machine installs firefox in these following places. /usr/lib64/firefox /usr/lib64/firefox-3.0.7 /usr/lib/mozilla /usr/lib64/mozilla /usr/share/mozilla /usr/bin/mozilla-plugin-config /usr/bin/firefox etc. All of which are related to the firefox installation. If something goes wrong, it's a real pain to clean it up, or even to detect what went wrong. The original concept for unix was to install an application such as firefox in either, /opt or /usr/local/. Such that the entire application was contained within a single installation directory, and then to use the PATH and LD_LIBRARY_PATH to allow the execution of the application. The standard approach with /opt or /usr/local installation also makes it triviel to have multiple installations, and configurations operating in paralellel, by simply creating. /opt/mozilla/firefox -> /opt/mozilla/firefox-3.0.7 /opt/mozilla/firefox-3.0.7 /opt/mozilla/firefox-2.0.9 A user can then easily conifgure their account to use either version of the application, without installation problems. Additionally using that installation method, also means that if someone wants to use a newer version of an application, they can download the source, and trivially install it in parallel to the package managed application, by using the --prefix option, and the installation can easily be removed, by simple rm -rf /opt/mozilla/firefox-3.0.7. With the current installation, it is nearly impossible, or at least very difficult to find out if the package manager has cleaned up properly, or if there is something left behind - something which is identicial to the problem on windows. A UNIX based system is intended to have everything accessible through standard accesses, such as the file system, and the network, however, the current trend in moving away from having the system control things (which I can see is easier), breaks with the ability of scripting. If this tendency keeps going, Linux is going to become a useless mismatch of junk, that no one can really use for anything but a toy. In my opinion, the trend has been visible for about a decade, but it has really gone downhill from about rethat 7/8.. though in Fedora 8, everything worked fine on most machines that I installed on, apart from some obscure drivers, however, since Fedora 8, i've yet to have a system where the audio works properly, and with Fedora 10, the kernel Ooopses so often it's not funny, on quite a few of my machines, to such a degree that I'm recommending that people do not upgrade past Fedora 8, and I'm considering dropping the Fedora line of Linux, because it is becoming just too messy, and clumsy. The divergence between the "GUI" focused approach, and the "Server" approach is not good for Linux, as it means there will be a fork, which will be incompatible. There really isn't a good reason for this split. I am wondering is anyone else concerned about, what in my opinion, is the copying of the mistakes that Microsoft made with windows, to the Linux environment. IMO it is really badly time to do a "back-to-basics" approach, and to clean up the system. I'm really curious as to the reasoning for moving everything from the standard configuration mechanisms to the gui layer, breaking compatibility with scripting, and other standard UNIX featuers.. I'm also curious as to the reasoning for throwing everything in one huge mess in the /usr/bin, /bin, /sbin, etc.. As all that is achieved is to make it hard to strip the system back to a minimal setup. regards mike. From skvidal at fedoraproject.org Mon May 11 13:56:48 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 11 May 2009 09:56:48 -0400 (EDT) Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A082E70.7030904@TheTroubleshooters.dk> References: <4A082E70.7030904@TheTroubleshooters.dk> Message-ID: On Mon, 11 May 2009, Michael Nielsen wrote: > Hi, > > I've been told this is the right place to place this debate starter. You were told incorrectly. I'm sure there is a place for this kind of debate but it is SURELY not the devel list. -sv From lili at redhat.com Mon May 11 13:59:25 2009 From: lili at redhat.com (Liam) Date: Mon, 11 May 2009 21:59:25 +0800 Subject: 2009-05-14 - Fedora Test Day - IBus input method Message-ID: <4A082F3D.6070500@redhat.com> Greetings testers, IBus input method - Ibus has been rewritten in C, and provides a simple, clean default system for changing the way international users input information into a Fedora system. Most of the work on iBus is being done upstream by Huang Peng. This feature proposal covers moving from scim to ibus as the default input method framework for Fedora 11 iBus is designed to improve a number of deficiencies of scim: * Ibus has been rewritten in C. Scim written in C++ using STL has problems with weak symbol conflicts without the added complexity and lower stability of the scim-bridge layer to workaround that. * It is possible to write client and engines for ibus in any language that supports dbus bindings. * ibus loads engines on demand rather than all installed engines as scim does, which improves the startup time and memory footprint. * scim loads engines as dl-modules so a problem in any engine can take down scim, whereas in ibus because the processes are separated only a faulty process will die leaving rest of the system working normally. * The architecture of ibus is bus-centric and so much closer to the CJK OSS Forum Workgroup 3 draft "Specification of IM engine Service Provider Interface" architecture, which might be supportable in the future. I'd like to invite you to join #fedora-qa this Thursday, May 14, 2009 to test Ibus input method.Get more details from: https://fedoraproject.org/wiki/Test_Day:2009-05-14_iBus Thanks, Liam From katzj at redhat.com Mon May 11 14:04:13 2009 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 11 May 2009 10:04:13 -0400 Subject: FESco meeting summary for 20090507 In-Reply-To: References: Message-ID: <20090511140413.GB8730@redhat.com> On Sunday, May 10 2009, Jon Stanley said: > Moreover, with the new architecture support feature in F11, we're now > supposedly defaulting to an x86_64 kernel on an i686 install if the > processor supports it (note that I say supposedly because I've not > personally tested it). Thus you have an x86_64 kernel, and all of the > goodness that brings, but you still have an i686 userspace. Due to some complications, we fell back to the contingency and aren't installing the x86_64 kernel on the 32bit distro at all for F11 quite a while ago[1] Jeremy [1] Or more accurately, never got to where we were installing the x86_64 kernel on 32bit distros and just enacted the contingency of not changing thigns :) From kevin.kofler at chello.at Mon May 11 13:27:42 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 11 May 2009 15:27:42 +0200 Subject: FESco meeting summary for 20090507 References: <200905110014.50581.bjorn@xn--rombobjrn-67a.se> Message-ID: Bj?rn Persson wrote: > http://www.dustin.se/productdetails.aspx?prodid=5010198913 That one uses the Atom 330, which does support 64-bit (though there's at least one report of 2.6.27 kernels not working in 64-bit mode on it, you apparently need 2.6.29). The netbook Atoms don't, the desktop ones do. Kevin Kofler From cdahlin at redhat.com Mon May 11 14:03:22 2009 From: cdahlin at redhat.com (Casey Dahlin) Date: Mon, 11 May 2009 10:03:22 -0400 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A082E70.7030904@TheTroubleshooters.dk> References: <4A082E70.7030904@TheTroubleshooters.dk> Message-ID: <4A08302A.2020705@redhat.com> Michael Nielsen wrote: > *snip* Write feature proposals. If you don't want to then implement them, pawn them off to someone else. Maybe we have this problem because out of all the people screaming about the end times, not one of them can't think of something better to do with their time than fix it. --CJD From ajax at redhat.com Mon May 11 14:12:40 2009 From: ajax at redhat.com (Adam Jackson) Date: Mon, 11 May 2009 10:12:40 -0400 Subject: glibc fork ? In-Reply-To: References: <4A02F8D3.2010807@poolshark.org> <4A036082.8000107@fedoraproject.org> <20090509160428.0bf3c0e6.zaitcev@redhat.com> Message-ID: <1242051160.5583.196.camel@atropine.boston.devel.redhat.com> On Sun, 2009-05-10 at 22:59 +0200, Kevin Kofler wrote: > (*) though arguably XFree86 is the failed fork and the X.Org Consortium is > the legitimate successor of the original maintainer, but when you look at > the actual code flow, the latest X.Org X11 releases are clearly forked from > XFree86 I don't think we ever pretended otherwise. We had to change the name of the server and config binaries (and default config file) for trademark reasons, but the code still has a directory called hw/xfree86/ and a ton of functions named xf86SomethingOrOther. But really, XFree86 is not a failed fork. The Consortium, like the rest of the unix industry, completely underestimated the PC and free software. XFree86 did tremendous work enhancing the nascent 386 port in X11R5, and basically from R6.4 onwards XFree86 were the only people doing any interesting development on X. That may sound recent, but remember that 6.4 was eleven years ago. For the next six years, XFree86 4.x was the de facto standard. If the goal was "X on PC hardware", XFree86 completely nailed it. Also, just to clarify, the current organization is the X.Org Foundation, a non-profit [1] scientific charity with no employees. The original Consortium was a membership corporation much like the Khronos Group (current stewards of OpenGL among much else), with a technical staff responsible for the majority of the work on X from R6 to R6.3 inclusive. After them, de jure stewardship was technically in the hands of The Open Group until the initial Foundation release of R6.7 in 2004, though de facto leadership was XFree86. While the Foundation did acquire the trademarks from TOG, it is not a spinoff or direct descendant of either TOG or the Consortium in a legal sense. [1] - I'm almost certain this is true. We were an LLC initially, which was a terrible idea, but istr hearing at a recent board meeting that we'd finally switched to 501(c)3. So yay for that. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From ajax at redhat.com Mon May 11 14:16:28 2009 From: ajax at redhat.com (Adam Jackson) Date: Mon, 11 May 2009 10:16:28 -0400 Subject: FESco meeting summary for 20090507 In-Reply-To: References: Message-ID: <1242051388.5583.198.camel@atropine.boston.devel.redhat.com> On Sun, 2009-05-10 at 11:44 -0400, Jon Stanley wrote: > Moreover, with the new architecture support feature in F11, we're now > supposedly defaulting to an x86_64 kernel on an i686 install if the > processor supports it (note that I say supposedly because I've not > personally tested it). Thus you have an x86_64 kernel, and all of the > goodness that brings, but you still have an i686 userspace. Factually inaccurate, we're not doing opportunistic 64-bit kernels in F11. On the "try again for F12" list though. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kevin.kofler at chello.at Mon May 11 14:18:24 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 11 May 2009 16:18:24 +0200 Subject: Locking assertion failure. Backtrace: References: <1241978114.3331.20.camel@localhost.localdomain> <4A07534A.2040509@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > So is the answer to point these issues to upstream and hope that they > fix it? Would you be willing to write a patch? I'm willing to write a patch for panini, it's trivial to fix that (I can put the warning -> message box redirects into a #ifndef Q_WS_X11 if upstream wants to keep that "feature" for Winblow$). I need to look at where the X errors/warnings triggered by Oxygen come from to see if I can fix those. Kevin Kofler From dgboles at comcast.net Mon May 11 14:15:48 2009 From: dgboles at comcast.net (David) Date: Mon, 11 May 2009 10:15:48 -0400 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A0824B7.90106@silfreed.net> References: <4A0814ED.60205@redhat.com> <4A0821D1.8050803@comcast.net> <4A0824B7.90106@silfreed.net> Message-ID: <4A083314.9020802@comcast.net> On 5/11/2009 9:14 AM, Douglas E. Warner wrote: > David wrote: >> On 5/11/2009 8:07 AM, Stephen Gallagher wrote: >>> OK, first off, why in $DEITY's name are we including Firefox 3.5b4 and >>> Thunderbird 3.0b2 in Fedora 11? These are unstable branches of the >>> browser and email client, and as such are supported by almost none of >>> the myriad of extensions available for the 3.0 and 2.0 versions, >>> respectively. >>> >>> I was more than a little disappointed when I upgraded my laptop to the >>> F11 Preview to discover that only two out of seven of my Thunderbird >>> extensions and three of my thirteen Firefox extensions remained functional. >> >> Depending on exactly what extensions that you have if you *download* >> them you can change this. Open the .xpi, or .jar, with the archive tool. >> Open the file named 'install.rdf' with your text editor and look for >> the line that says "". Change that number to the version >> that you are using. Or even a little higher if you like. Save and update >> the 'install.rdf', close the archive tool, and install your new extension. >> >> This works for most themes too. > > The point is that most extension developers haven't felt the need to try to > update their extensions for Thunderbird 3 as the API hasn't stabilized yet. > Thunderbird extensions are much more finicky than Firefox extensions I would > wager, especially given this major feature update. I would offer that Firefox > 3.5b4 is a lot closer to RC than Thunderbird 3.0b2 is, and I still expect > there to be problems with extensions for Firefox before release (this was very > common for Firefox 3.0 as well where changes broke extensions even in the RC > series). I use nine extensions with Thunderbird 3.0b2. Most of them I 'modified' as I described above. I use eleven extensions with Firefox 3.5b4. Most of which I 'modified'. I have not had any problems with any of them. -- David From sgallagh at redhat.com Mon May 11 14:27:02 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 11 May 2009 10:27:02 -0400 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A083314.9020802@comcast.net> References: <4A0814ED.60205@redhat.com> <4A0821D1.8050803@comcast.net> <4A0824B7.90106@silfreed.net> <4A083314.9020802@comcast.net> Message-ID: <4A0835B6.3000102@redhat.com> On 05/11/2009 10:15 AM, David wrote: > On 5/11/2009 9:14 AM, Douglas E. Warner wrote: >> David wrote: >>> On 5/11/2009 8:07 AM, Stephen Gallagher wrote: >>>> OK, first off, why in $DEITY's name are we including Firefox 3.5b4 and >>>> Thunderbird 3.0b2 in Fedora 11? These are unstable branches of the >>>> browser and email client, and as such are supported by almost none of >>>> the myriad of extensions available for the 3.0 and 2.0 versions, >>>> respectively. >>>> >>>> I was more than a little disappointed when I upgraded my laptop to the >>>> F11 Preview to discover that only two out of seven of my Thunderbird >>>> extensions and three of my thirteen Firefox extensions remained functional. >>> Depending on exactly what extensions that you have if you *download* >>> them you can change this. Open the .xpi, or .jar, with the archive tool. >>> Open the file named 'install.rdf' with your text editor and look for >>> the line that says "". Change that number to the version >>> that you are using. Or even a little higher if you like. Save and update >>> the 'install.rdf', close the archive tool, and install your new extension. >>> >>> This works for most themes too. >> The point is that most extension developers haven't felt the need to try to >> update their extensions for Thunderbird 3 as the API hasn't stabilized yet. >> Thunderbird extensions are much more finicky than Firefox extensions I would >> wager, especially given this major feature update. I would offer that Firefox >> 3.5b4 is a lot closer to RC than Thunderbird 3.0b2 is, and I still expect >> there to be problems with extensions for Firefox before release (this was very >> common for Firefox 3.0 as well where changes broke extensions even in the RC >> series). > > > I use nine extensions with Thunderbird 3.0b2. Most of them I 'modified' > as I described above. I use eleven extensions with Firefox 3.5b4. Most > of which I 'modified'. I have not had any problems with any of them. Ok, just so I make sure I understand your argument completely. "It's fine to include a pre-release copy of Thunderbird and Firefox because you can bludgeon unsupported extensions into being supported by following an undocumented and potentially dangerous hack." Seriously, people. This is exactly the sort of elitist bullshit that puts people off of using Fedora. Furthermore, it's damned hypocritical. With everything else on the desktop, we're all about simplifying and making usage easier. But for the two most-used features, we're going to require that our users learn to hack .xpi files? I call bullshit. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From stransky at redhat.com Mon May 11 14:34:13 2009 From: stransky at redhat.com (Martin Stransky) Date: Mon, 11 May 2009 16:34:13 +0200 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A0835B6.3000102@redhat.com> References: <4A0814ED.60205@redhat.com> <4A0821D1.8050803@comcast.net> <4A0824B7.90106@silfreed.net> <4A083314.9020802@comcast.net> <4A0835B6.3000102@redhat.com> Message-ID: <4A083765.6030907@redhat.com> On 05/11/2009 04:27 PM, Stephen Gallagher wrote: > On 05/11/2009 10:15 AM, David wrote: >> On 5/11/2009 9:14 AM, Douglas E. Warner wrote: >>> David wrote: >>>> On 5/11/2009 8:07 AM, Stephen Gallagher wrote: >>>>> OK, first off, why in $DEITY's name are we including Firefox 3.5b4 and >>>>> Thunderbird 3.0b2 in Fedora 11? These are unstable branches of the >>>>> browser and email client, and as such are supported by almost none of >>>>> the myriad of extensions available for the 3.0 and 2.0 versions, >>>>> respectively. >>>>> >>>>> I was more than a little disappointed when I upgraded my laptop to the >>>>> F11 Preview to discover that only two out of seven of my Thunderbird >>>>> extensions and three of my thirteen Firefox extensions remained functional. >>>> Depending on exactly what extensions that you have if you *download* >>>> them you can change this. Open the .xpi, or .jar, with the archive tool. >>>> Open the file named 'install.rdf' with your text editor and look for >>>> the line that says "". Change that number to the version >>>> that you are using. Or even a little higher if you like. Save and update >>>> the 'install.rdf', close the archive tool, and install your new extension. >>>> >>>> This works for most themes too. >>> The point is that most extension developers haven't felt the need to try to >>> update their extensions for Thunderbird 3 as the API hasn't stabilized yet. >>> Thunderbird extensions are much more finicky than Firefox extensions I would >>> wager, especially given this major feature update. I would offer that Firefox >>> 3.5b4 is a lot closer to RC than Thunderbird 3.0b2 is, and I still expect >>> there to be problems with extensions for Firefox before release (this was very >>> common for Firefox 3.0 as well where changes broke extensions even in the RC >>> series). >> >> I use nine extensions with Thunderbird 3.0b2. Most of them I 'modified' >> as I described above. I use eleven extensions with Firefox 3.5b4. Most >> of which I 'modified'. I have not had any problems with any of them. > > Ok, just so I make sure I understand your argument completely. "It's > fine to include a pre-release copy of Thunderbird and Firefox because > you can bludgeon unsupported extensions into being supported by > following an undocumented and potentially dangerous hack." > > Seriously, people. This is exactly the sort of elitist bullshit that > puts people off of using Fedora. Furthermore, it's damned hypocritical. There's Fedora 10 with Firefox 3.0 and Thunderbird 2.0 in already. Nobody forces you to update to F11 now, when it contains those "unstable" packages. ma. From silfreed at silfreed.net Mon May 11 14:37:35 2009 From: silfreed at silfreed.net (Douglas E. Warner) Date: Mon, 11 May 2009 10:37:35 -0400 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A0835B6.3000102@redhat.com> References: <4A0814ED.60205@redhat.com> <4A0821D1.8050803@comcast.net> <4A0824B7.90106@silfreed.net> <4A083314.9020802@comcast.net> <4A0835B6.3000102@redhat.com> Message-ID: <4A08382F.8020408@silfreed.net> Stephen Gallagher wrote: > On 05/11/2009 10:15 AM, David wrote: >> On 5/11/2009 9:14 AM, Douglas E. Warner wrote: >>> David wrote: >>>> On 5/11/2009 8:07 AM, Stephen Gallagher wrote: >>>>> OK, first off, why in $DEITY's name are we including Firefox 3.5b4 and >>>>> Thunderbird 3.0b2 in Fedora 11? These are unstable branches of the >>>>> browser and email client, and as such are supported by almost none of >>>>> the myriad of extensions available for the 3.0 and 2.0 versions, >>>>> respectively. >>>>> >>>>> I was more than a little disappointed when I upgraded my laptop to the >>>>> F11 Preview to discover that only two out of seven of my Thunderbird >>>>> extensions and three of my thirteen Firefox extensions remained functional. >>>> Depending on exactly what extensions that you have if you *download* >>>> them you can change this. Open the .xpi, or .jar, with the archive tool. >>>> Open the file named 'install.rdf' with your text editor and look for >>>> the line that says "". Change that number to the version >>>> that you are using. Or even a little higher if you like. Save and update >>>> the 'install.rdf', close the archive tool, and install your new extension. >>>> >>>> This works for most themes too. >>> The point is that most extension developers haven't felt the need to try to >>> update their extensions for Thunderbird 3 as the API hasn't stabilized yet. >>> Thunderbird extensions are much more finicky than Firefox extensions I would >>> wager, especially given this major feature update. I would offer that Firefox >>> 3.5b4 is a lot closer to RC than Thunderbird 3.0b2 is, and I still expect >>> there to be problems with extensions for Firefox before release (this was very >>> common for Firefox 3.0 as well where changes broke extensions even in the RC >>> series). >> >> I use nine extensions with Thunderbird 3.0b2. Most of them I 'modified' >> as I described above. I use eleven extensions with Firefox 3.5b4. Most >> of which I 'modified'. I have not had any problems with any of them. > > Ok, just so I make sure I understand your argument completely. "It's > fine to include a pre-release copy of Thunderbird and Firefox because > you can bludgeon unsupported extensions into being supported by > following an undocumented and potentially dangerous hack." > > Seriously, people. This is exactly the sort of elitist bullshit that > puts people off of using Fedora. Furthermore, it's damned hypocritical. > > With everything else on the desktop, we're all about simplifying and > making usage easier. But for the two most-used features, we're going to > require that our users learn to hack .xpi files? > > I call bullshit. > > I agree; extension developers are in a similar situation to package maintainers here; they need to test their product against a moving upstream and re-release when working. The fact that they haven't done this yet is just a clue that it's not time to update Firefox/Thunderbird. -Doug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From sanjay.ankur at gmail.com Mon May 11 14:43:53 2009 From: sanjay.ankur at gmail.com (Ankur Sinha) Date: Mon, 11 May 2009 20:13:53 +0530 Subject: Locking assertion failure. Backtrace: In-Reply-To: References: <1241978114.3331.20.camel@localhost.localdomain> <4A07534A.2040509@fedoraproject.org> Message-ID: <1242053033.3331.39.camel@localhost.localdomain> On Mon, 2009-05-11 at 16:18 +0200, Kevin Kofler wrote: > Rahul Sundaram wrote: > > So is the answer to point these issues to upstream and hope that they > > fix it? Would you be willing to write a patch? > > I'm willing to write a patch for panini, it's trivial to fix that (I can put > the warning -> message box redirects into a #ifndef Q_WS_X11 if upstream > wants to keep that "feature" for Winblow$). I need to look at where the X > errors/warnings triggered by Oxygen come from to see if I can fix those. > > Kevin Kofler > hi Kevin, all the rpms etc. are at http://ankursinha.fedorapeople.org/panini/ and the project site itself is http://sourceforge.net/projects/pvqt/ I installed the package and ran it from the terminal when the errors popped up.. If there are any steps you'd want me to try that could help you diagnose the source of the errors please just post. regards, Ankur From forum at ru.bir.ru Mon May 11 14:45:20 2009 From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus)) Date: Mon, 11 May 2009 18:45:20 +0400 Subject: Note on man pages In-Reply-To: <4A075F6B.3060503@fedoraproject.org> References: <4A00BCE9.3050800@fedoraproject.org> <4A0751F9.4070509@fedoraproject.org> <4A07558F.5050604@fedoraproject.org> <4A075F6B.3060503@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > Sure. It can be worded something like: > > "If additional useful patches exist in other distribution packages (ex: > man pages in Debian), the package maintainer should evaluate them > carefully, add those that are suitable and send them to the > [http://fedoraproject.org/wiki/Staying_close_to_upstream_projects > upstream project] as well, It is highly recommended that the package > maintainers consider writing a man page, especially for command line > applications where good documentation is missing in the upstream > project, It might be useful to talk to the upstream projects first and > check whether they are willing to accept man pages or other forms of > documentation as patches" Indeed! You are done most of work!! Thank you very much. I have done proposal: https://fedoraproject.org/wiki/MAN_pages_which_exists_in_other_places(draft) From rc040203 at freenet.de Mon May 11 14:37:17 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 11 May 2009 16:37:17 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: References: <4A082E70.7030904@TheTroubleshooters.dk> Message-ID: <4A08381D.5030604@freenet.de> Seth Vidal wrote: > > > On Mon, 11 May 2009, Michael Nielsen wrote: > >> Hi, >> >> I've been told this is the right place to place this debate starter. > > > You were told incorrectly. > > I'm sure there is a place for this kind of debate but it is SURELY not > the devel list. @RH ignorance? If not here, where else to discuss a distro's long term development? From loupgaroublond at gmail.com Mon May 11 14:35:56 2009 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Mon, 11 May 2009 10:35:56 -0400 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A082E70.7030904@TheTroubleshooters.dk> References: <4A082E70.7030904@TheTroubleshooters.dk> Message-ID: <7f692fec0905110735tf8a1bd4u7a71d85f6de7f14b@mail.gmail.com> This is trolling, not starting debates. 2009/5/11 Michael Nielsen : > Hi, > > I've been told this is the right place to place this debate starter. > > > Not to demean the fine work that has been done in maintaining fedora, > however the distribution is slowly killing itself, being destroyed by > contradicting philosophies. Many of the problems have been directly copied > from the Windows world. > > The main problems are. > > 1. Removal of features - the user interfaces are being dumbed down, like > recently I've searched for the ability to remove the "Raise on Click" > feature that is default for Gnome MetaCity, there does not appear to be any > such feature anymore / argument being to simplify how it works.. Fine, > create a simple view and an advanced view for the configuration tools, so > that people who are clueless about any other way than the official Redmond > way, can avoid being confronted with an alternative. This is upstream and has to do with Gnome. Fedora stays as close to upstream as possible, which means if the Gnome developers think this is a good idea, then this is (possibly) a good idea. If you don't like it, get a clue and install a different window manager. Try Openbox. > 2. The network interfaces are being bound to the user interface, such that > if your X fails for some reason, or you are running on a text console, you > are unable to open the wireless configuration, at least it's not obvious how > you do it, without X running. The configuration for the network interfaces > are so tightly bound to the user interface, such that if there is no user > interface there are no network interfaces. This is the artifact of working in a desktop environment. If you need more functionality then you are a power user. There is a very advanced interface for configuring the network, we like to call it the command line. Not to be picky, but in your previous post, you commented you want a simple and advanced view. Think of the desktop as a simple view, and the command line as your advanced view. > > 3. Mounts are also embedded into the user interface, rather than in the unix > mount system, which means that the shares are not accessible for non-gui > programs, for instance, I like to script most thing I do often, however, > there is no way for scripts to get a hold of a drive that is mounted through > the gui mount system (kde and gnome). You're right, they could potentially do a bit better. Except that they do, most of your mounts should be available in /media. If you have a specific complaint, please file a bug report on Gnome or KDE. > > 4. Everything is thrown in huge collective directories, such as /usr/bin, > /usr/lib etc, and it is a huge mess, just like windows with it's system32 > directory, which is also a huge mess. really the /usr/bin,/bin/sbin, /lib > etc, has very specific purposes, and should represent a core operating > system, that is capable of being used as repair, with no major applications > present. However even Open office is stored in these directories. This is by design. Complaining about the design isn't going to start a debate unfortunately. If the design really does bother you, try Gobo. http://www.gobolinux.org/ > > 5. More and more services are bound up in the userinterface, such as the > pulse audio, which is started by the GUI, this means if you use 2 user > environments, which I often do for testing, where I have X:0 and X:1 > running, the GUIs will conflict, because you cannot run two instances of > pulseaudio. In addition pulse audio is crap, I have yet to see any > installation actually work without crackling, and chopping like crazy. I > like the concept that is the basis of pulse audio, but it just does not > work. Read the answer to #2. Also, if you have a specific complaint, file a bug on Pulseaudio and Alsa. > > 6. NetworkManager which appears to be installed default, does not work with > shared drives, because, the NetworkManager is shut down before the network > drives are detached, and you need to modify the NetworkManager to start > properly, before you mount the network drives. I've gotten used to explicit > uninstalling the NetworkManager, because it just doesn't work properly. Again, you're a power user. Reorder your shutdown sequence. > > It is a lengthy discussion to describe what i mean. > > However, if I take a sample application like firefox, it presents a > reasonable proxy for what I mean. > > currently default installation of firefox on my machine installs firefox in > these following places. > > /usr/lib64/firefox > /usr/lib64/firefox-3.0.7 > /usr/lib/mozilla > /usr/lib64/mozilla > /usr/share/mozilla > /usr/bin/mozilla-plugin-config > /usr/bin/firefox > > etc. > > All of which are related to the firefox installation. If something goes > wrong, it's a real pain to clean it up, or even to detect what went wrong. > The original concept for unix was to install an application such as firefox > in either, /opt or /usr/local/. Such that the entire application was > contained within a single installation directory, and then to use the PATH > and LD_LIBRARY_PATH to allow the execution of the application. > > The standard approach with /opt or /usr/local installation also makes it > triviel to have multiple installations, and configurations operating in > paralellel, by simply creating. > > /opt/mozilla/firefox -> /opt/mozilla/firefox-3.0.7 > /opt/mozilla/firefox-3.0.7 > /opt/mozilla/firefox-2.0.9 > > A user can then easily conifgure their account to use either version of the > application, without installation problems. > > Additionally using that installation method, also means that if someone > wants to use a newer version of an application, they can download the > source, and trivially install it in parallel to the package managed > application, by using the --prefix option, and the installation can easily > be removed, by simple rm -rf /opt/mozilla/firefox-3.0.7. > > With the current installation, it is nearly impossible, or at least very > difficult to find out if the package manager has cleaned up properly, or if > there is something left behind - something which is identicial to the > problem on windows. Wrong, see Gobo if this is a feature you want. Using this split up file system layout is by design, it's a standard of the Unix Way of Doing Things. Everything that ships in Fedora and/or a 3rd party repo that is designed to integrate with the core functionality will use this layout. /opt is for third party software that doesn't want to behave. /usr/local is for bits that are specific to your machine. If your installation fails it's because of two things. A) there is a bug in RPM/Yum that needs to be fixed. The design goal is for these bits to be rock solid reliable. They should never fail. 2) Your power went out. RPM and Yum really should recover and continue from where they left off. Handling such a use case is really a very difficult to solve problem. If you have any concrete ideas, let's hear them, but complaining about the file system layout is not going to solve the problem one bit. > I'm really curious as to the reasoning for moving everything from the > standard configuration mechanisms to the gui layer, breaking compatibility > with scripting, and other standard UNIX featuers.. ? I'm also curious as to > the reasoning for throwing everything in one huge mess in the /usr/bin, > /bin, /sbin, etc.. ? As all that is achieved is to make it hard to strip the > system back to a minimal setup. Is there anything concrete that breaks? Can you give us an example of shell code that doesn't work in Fedora 11 anymore? -Yaakov From rc040203 at freenet.de Mon May 11 15:07:23 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 11 May 2009 17:07:23 +0200 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A083765.6030907@redhat.com> References: <4A0814ED.60205@redhat.com> <4A0821D1.8050803@comcast.net> <4A0824B7.90106@silfreed.net> <4A083314.9020802@comcast.net> <4A0835B6.3000102@redhat.com> <4A083765.6030907@redhat.com> Message-ID: <4A083F2B.1020107@freenet.de> Martin Stransky wrote: > > There's Fedora 10 with Firefox 3.0 and Thunderbird 2.0 in already. > Nobody forces you to update to F11 now, when it contains those > "unstable" packages. Unstable packages belong into rawhide and not into "stable" Fedoras. Ralf From dr.diesel at gmail.com Mon May 11 15:10:12 2009 From: dr.diesel at gmail.com (Dr. Diesel) Date: Mon, 11 May 2009 10:10:12 -0500 Subject: Fedora (Linux) is Destroying it self In-Reply-To: References: <4A082E70.7030904@TheTroubleshooters.dk> Message-ID: <2a28d2ab0905110810j3a7e149elede56efe87d3dcbc@mail.gmail.com> On Mon, May 11, 2009 at 8:56 AM, Seth Vidal wrote: > > > On Mon, 11 May 2009, Michael Nielsen wrote: > > Hi, >> >> I've been told this is the right place to place this debate starter. >> > > > You were told incorrectly. > > I'm sure there is a place for this kind of debate but it is SURELY not the > devel list. > One of the moderators from Fedoraforum sent him this way. -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Mon May 11 15:12:19 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 May 2009 08:12:19 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <4A0812DB.2000505@freenet.de> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <645d17210905071452n7da5f852s8bfc5d808a04c56b@mail.gmail.com> <1241733287.3209.61.camel@localhost.localdomain> <4A03A31C.4010003@freenet.de> <1241754133.3209.71.camel@localhost.localdomain> <4A03AF94.60605@freenet.de> <1241756375.3209.76.camel@localhost.localdomain> <4A03BB64.10006@freenet.de> <1241795563.3209.83.camel@localhost.localdomain> <4A04D350.1000904@freenet.de> <1241832771.2886.15.camel@localhost.localdomain> <4A04EAAE.50907@freenet.de> <1241836379.2886.30.camel@localhost.localdomain> <4A0812DB.2000505@freenet.de> Message-ID: <1242054739.3452.15.camel@localhost.localdomain> On Mon, 2009-05-11 at 13:58 +0200, Ralf Corsepius wrote: > > We've been trying to push F11 updates for a couple days now. > ... but you still haven't updated fedora-release, so neither mock > doesn't pick them up. That's right, I wanted to make sure they hit mirrors OK before I released a fedora-release with repo configuration pointing to them. Of course you're free to manually turn those repos on and test it out for yourself. > > >> * Decouple cuttings DVDs from F11 development > > > > I honestly don't understand what you're proposing here. No DVD from the release? > No, I am proposing that rel-eng chooses a set of packages to build iso > etc. from, while "updates" "rolls on". > > Or differently: rel-eng composes the "Fedora" repo from those packages > they choose, which "updates" continues, independently from rel-eng's > activities. > > > What do we have people download to get the release? > As before ... the only difference would be "Fedora" (i.e. the set of > packages the DVDs etc. would have been built from) would be older than > "updates" (and/or "Everything") Which does nothing to help the upgrade and n-v-r case. > > > What do > > we hand out at events? > Openly said, ... I would hand out netboot.img's, accompanied with a yum > repository of "Everything" ... but that's a different topic. > > >> * Implement rawhide/testing > > > > Is this a full time thing, you always want a rawhide, and a > > rawhide-testing, which is driven by bodhi? > I haven't thought about all details, but I am inclined to lean towards a > "permanent rawhide-testing". > > There would be times where it hardly would be used, but there can easily > be times, when it would be heavily used (e.g. there currently is a > proposal pending which would severely change perl's behavior (perl > module search order and file system layout), with currently unclear > outcome). How would one choose to use it? Why would anyone choose to use bodhi if they were allowed to build directly into rawhide? Should we force the use of bodhi during freezes, and make it optional otherwise? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Mon May 11 15:15:13 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 May 2009 08:15:13 -0700 Subject: best practices for updates in stable releases (was: Re: OpenOffice 3.1) In-Reply-To: References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <4A05B234.2020608@leemhuis.info> <1241890311.2886.63.camel@localhost.localdomain> Message-ID: <1242054913.3452.16.camel@localhost.localdomain> On Mon, 2009-05-11 at 13:03 +0200, Matej Cepl wrote: > > Yes, because this is yet another case where nobody is willing to > enforce what has been agreed upon. Suggestions on how to "enforce" ? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From forum at ru.bir.ru Mon May 11 15:22:00 2009 From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus)) Date: Mon, 11 May 2009 19:22:00 +0400 Subject: OpenOffice 3.1 In-Reply-To: <1242002755.2760.23.camel@moose> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <1241998651.2760.9.camel@moose> <1242002755.2760.23.camel@moose> Message-ID: Rodd Clarkson wrote: > I can't account for your time use, and I understand that upgrading takes > time, especially when you maintain a number of machines. > > As for your work laptop running f10 and not having time to upgrade to > f11, but want OOo3.1, let me give you and opposing argument. > > My wife doesn't want to update her laptop every 6 months (I do) and she > gets really annoyed when the applications she uses change mid release > and she has to change with them. She doesn't have the time to re-learn > an application and just want's to work in an consistent and expected > way. She does however appreciate that her laptop is (relatively) > up-to-date and doesn't mind upgrading every 12 months (or so). > > Should she have to have take the time to relearn applications because > you haven't got the time to upgrade? More importantly, from her > perspective she doesn't give a damn if there are changes to things like > "new hash algorithm in RPM, ext4 by default etc" and doesn't even > realize that she uses these things. She does however use OOo, Firefox, > Evolution and other applications and she does notice when they chance > and she doesn't like it changing all the time (and especially > mid-release). Ho-ho!!! I have exactly same situation: My wife always disagree with my updates and experiments. All what she need - "It warks, please do not touch it". And, I can say confidently - all questions was gone when I leave her notebook! For few times when I use it I install second, fully independent copy of new release Fedora 11 from alpha, and leave Fodora 8 unchanged. All happy. And please, keep in mind - she have not any matter - will pushed OO 3.1 to Fedora 9 or not if she is not planed update it at all!!! I think with you wire situation is exactly the same. From drago01 at gmail.com Mon May 11 15:07:36 2009 From: drago01 at gmail.com (drago01) Date: Mon, 11 May 2009 17:07:36 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A082E70.7030904@TheTroubleshooters.dk> References: <4A082E70.7030904@TheTroubleshooters.dk> Message-ID: On Mon, May 11, 2009 at 3:56 PM, Michael Nielsen wrote: > Hi, > 3. Mounts are also embedded into the user interface, rather than in the unix > mount system, which means that the shares are not accessible for non-gui > programs, for instance, I like to script most thing I do often, however, > there is no way for scripts to get a hold of a drive that is mounted through > the gui mount system (kde and gnome). This is not true, in case of gnome you can access everything mounted by nautilus / gvfs by accessing ~/.gvfs works with ANY app. From forum at ru.bir.ru Mon May 11 15:23:24 2009 From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus)) Date: Mon, 11 May 2009 19:23:24 +0400 Subject: OpenOffice 3.1 In-Reply-To: References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <1241998651.2760.9.camel@moose> Message-ID: Matej Cepl wrote: > On 2009-05-11, 00:11 GMT, Pavel Alexeev (aka Pahan-Hubbitus) wrote: >> it... So, please tell me why you think if I, say on My Work >> notebook use Fedora 10 I do not want use OO 3.1??? I want. > > I believe OOo 3.1 from http://download.openoffice.org/other.html > works on Fedora 9. > Cool. Can me treat it as proof what it is not break anything in system? From mike at cchtml.com Mon May 11 15:25:58 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Mon, 11 May 2009 10:25:58 -0500 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A08382F.8020408@silfreed.net> References: <4A0814ED.60205@redhat.com> <4A0821D1.8050803@comcast.net> <4A0824B7.90106@silfreed.net> <4A083314.9020802@comcast.net> <4A0835B6.3000102@redhat.com> <4A08382F.8020408@silfreed.net> Message-ID: <4A084386.4010304@cchtml.com> -------- Original Message -------- Subject: Re: Downgrading Firefox 3.5 and Thunderbird 3.0 From: Douglas E. Warner To: Development discussions related to Fedora Date: 05/11/2009 09:37 AM > > I agree; extension developers are in a similar situation to package > maintainers here; they need to test their product against a moving upstream > and re-release when working. The fact that they haven't done this yet is just > a clue that it's not time to update Firefox/Thunderbird. The only time you get extension developers to update[1] is when the final Firefox update is released. Should Firefox releases wait on extension developers? Think about that for a second. Really think about that. If an extension you use is that important to you you should create a bug on mozilla.org for a feature request and make it a blocker of the next release. Good luck on that. This whole thread so far is sensationalist crap. Every day people bitch that Fedora is not bleeding enough. Now we have people bitching about a Fedora release, not even at GA, being too bleeding. Stop, read, and listen to yourselves before replying to this thread again. This discussion happens constantly and it is tiresome. The time wasted in these type of discussions is better spent elsewhere. Work on getting your extension developer involved in Firefox updates. (*GASP*) [1] Sure, some extensions such as Adblock stay on top of Firefox changes, but not all extensions do. From sgallagh at redhat.com Mon May 11 15:31:51 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 11 May 2009 11:31:51 -0400 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A084386.4010304@cchtml.com> References: <4A0814ED.60205@redhat.com> <4A0821D1.8050803@comcast.net> <4A0824B7.90106@silfreed.net> <4A083314.9020802@comcast.net> <4A0835B6.3000102@redhat.com> <4A08382F.8020408@silfreed.net> <4A084386.4010304@cchtml.com> Message-ID: <4A0844E7.3030208@redhat.com> On 05/11/2009 11:25 AM, Michael Cronenworth wrote: > -------- Original Message -------- > Subject: Re: Downgrading Firefox 3.5 and Thunderbird 3.0 > From: Douglas E. Warner > To: Development discussions related to Fedora > > Date: 05/11/2009 09:37 AM > >> >> I agree; extension developers are in a similar situation to package >> maintainers here; they need to test their product against a moving >> upstream >> and re-release when working. The fact that they haven't done this yet >> is just >> a clue that it's not time to update Firefox/Thunderbird. > > > The only time you get extension developers to update[1] is when the > final Firefox update is released. Should Firefox releases wait on > extension developers? Think about that for a second. Really think about > that. If an extension you use is that important to you you should create > a bug on mozilla.org for a feature request and make it a blocker of the > next release. Good luck on that. > > This whole thread so far is sensationalist crap. > > Every day people bitch that Fedora is not bleeding enough. Now we have > people bitching about a Fedora release, not even at GA, being too > bleeding. Stop, read, and listen to yourselves before replying to this > thread again. This discussion happens constantly and it is tiresome. The > time wasted in these type of discussions is better spent elsewhere. Work > on getting your extension developer involved in Firefox updates. (*GASP*) > > [1] Sure, some extensions such as Adblock stay on top of Firefox > changes, but not all extensions do. > I never said that Mozilla releases should wait on extension releases. I said that Firefox and Thunderbird packages in a "stable" Fedora should be based on stable Mozilla releases, not pre-releases. I don't think there's anything wrong with having Firefox 3.5b4 and Thunderbird 3.0b2 in the updates-testing repository and rawhide, once the release is out, but it's really problematic for users if they're upgraded into an unsupported, unstable version of their most important tools. And as I said in a previous email: I can forgive Firefox 3.5b4 since it's due to go stable before Fedora 12, but there's not a snowball's chance in Hell that the same is true of Thunderbird. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From bernie at codewiz.org Mon May 11 15:36:08 2009 From: bernie at codewiz.org (Bernie Innocenti) Date: Mon, 11 May 2009 17:36:08 +0200 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A0814ED.60205@redhat.com> References: <4A0814ED.60205@redhat.com> Message-ID: <4A0845E8.2080805@codewiz.org> On 05/11/09 14:07, Stephen Gallagher wrote: > OK, first off, why in $DEITY's name are we including Firefox 3.5b4 and > Thunderbird 3.0b2 in Fedora 11? As a Thunderbird user, I'm glad we're switching to 3.0 as it is a lot faster and more usable for me. However, the package in Fedora is still at 3.0b2, which still contains an IMAP bug affecting me which was fixed upstream one month ago: https://bugzilla.mozilla.org/show_bug.cgi?id=480870 I'd be grateful if we could import the latest beta release so I can finally stop dealing with assorted crap like Mercurial, CVS and autoconf-2.13 when I just need a binary that will let me read my mail :-) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ From sgallagh at redhat.com Mon May 11 15:40:47 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 11 May 2009 11:40:47 -0400 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A0845E8.2080805@codewiz.org> References: <4A0814ED.60205@redhat.com> <4A0845E8.2080805@codewiz.org> Message-ID: <4A0846FF.505@redhat.com> On 05/11/2009 11:36 AM, Bernie Innocenti wrote: > On 05/11/09 14:07, Stephen Gallagher wrote: >> OK, first off, why in $DEITY's name are we including Firefox 3.5b4 and >> Thunderbird 3.0b2 in Fedora 11? > > As a Thunderbird user, I'm glad we're switching to 3.0 as it is a lot > faster and more usable for me. > > However, the package in Fedora is still at 3.0b2, which still contains > an IMAP bug affecting me which was fixed upstream one month ago: > > https://bugzilla.mozilla.org/show_bug.cgi?id=480870 > > I'd be grateful if we could import the latest beta release so I can > finally stop dealing with assorted crap like Mercurial, CVS and > autoconf-2.13 when I just need a binary that will let me read my mail :-) > This brings up another excellent point. The beta releases of Firefox and Thunderbird are released at a much slower rate than point releases of the stable revisions. This means that a security issue in the beta may go unpatched for a much longer period of time. I agree with Bernie that if we're going to move ahead with the pre-release versions, we need to at least be grabbing builds from the source. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From forum at ru.bir.ru Mon May 11 15:24:44 2009 From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus)) Date: Mon, 11 May 2009 19:24:44 +0400 Subject: OpenOffice 3.1 In-Reply-To: References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <4A05B97D.9010705@sapience.com> Message-ID: Kevin Kofler wrote: > Matej Cepl wrote: > >> On 2009-05-09, 17:12 GMT, Mail Llists wrote: >>> We are happy to have kernel updates >> Speak just for yourself, please. > > I'm also happy to have them, that makes at least 2 people, so "we" is > correct. :-) +1 I also here. From rc040203 at freenet.de Mon May 11 15:46:48 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 11 May 2009 17:46:48 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <20090511132526.3195dc37@rawhide.intranet> References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241949557.3109.2.camel@localhost.localdomain> <20090510131115.226b27a5@faldor.intranet> <4A079B3B.20606@freenet.de> <20090511132526.3195dc37@rawhide.intranet> Message-ID: <4A084868.4040807@freenet.de> Michael Schwendt wrote: > On Mon, 11 May 2009 05:27:55 +0200, Ralf wrote: > >> Michael Schwendt wrote: >>> On Sun, 10 May 2009 12:59:16 +0300, Jussi wrote: >>> >>>> On Sat, 2009-05-09 at 21:33 -0400, Orcan Ogetbil wrote: >>>>> On Thu, May 7, 2009 at 5:09 PM, Richard W.M. Jones wrote: >>>>>> I'll tell you the three reasons I'm pushing stuff directly to stable: >>>>>> >>>>>> (1) New package. >>>>>> [cut] >>>>> Is it a good practice to push a new package to stable? >>> No. >> I strongly disagree. Adding "stable" packages to stable is the primary >> interest contributors are after. It's the #1 reason, why Fedora Extras >> one had been launched. > > Cool down and slow down, at least a bit, please. Why should I? Openly said, Fedora 11's development develops in ways, I think it would be appropriate to demand personal consequences in Fedora's management. > This is about not skipping updates-testing. This is about offering them at > least a few days in updates-testing, so the community may contribute > actual testing. * Fact is: In the overwhelming majority of all cases, testing is effectively a delay queue, and a PITA to developers. * Fact also is: "Testing" doesn't help wrt. packagers doing a poor job. * Fact also is: "Testing" occasionally is the cause of broken package deps. > Fact is that one packager plus one reviewer are not enough > to ensure that new packages really work good enough to call them "stable" > for one or more dist targets. So you are demanding for even more bureaucracy and for more @RH deitism? This would be truely silly. >> What destabilizes Fedora is Fedora being based on insufficiently stable >> SW, not "new packages". > > Agreed, but that's a different topic. IMO, this would be the topic to discuss! Many of the packages, esp. those for which the upstreams are sitting in or near Fedora, IMO should never have been unleashed in Fedora, ... > Poor updates also create chaos > in buildroots. We've had issues like that already during Fedora Extras. As far as I am concerned, it's this freaking freeze and run-down shape the fedora repso currently is in, which is causing the mess. Ralf From craftjml at gmail.com Mon May 11 15:49:22 2009 From: craftjml at gmail.com (Jud Craft) Date: Mon, 11 May 2009 10:49:22 -0500 Subject: best practices for updates in stable releases (was: Re: OpenOffice 3.1) In-Reply-To: <1242054913.3452.16.camel@localhost.localdomain> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <4A05B234.2020608@leemhuis.info> <1241890311.2886.63.camel@localhost.localdomain> <1242054913.3452.16.camel@localhost.localdomain> Message-ID: <20d6441a0905110849r6b6e9537ofa343ddb27156ba1@mail.gmail.com> On Mon, May 11, 2009 at 10:15 AM, Jesse Keating wrote: > On Mon, 2009-05-11 at 13:03 +0200, Matej Cepl wrote: > Suggestions on how to "enforce" ? Lock out developers who don't follow guidelines? Sanction them? Remove their ability to push updates? No sass meant, I just figured that was a strange rhetorical question. Does Fedora really not have any ability to enforce its own guidelines? From rc040203 at freenet.de Mon May 11 15:49:46 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 11 May 2009 17:49:46 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241949557.3109.2.camel@localhost.localdomain> <20090511122057.02a66ba1@rawhide.intranet> Message-ID: <4A08491A.2000506@freenet.de> Kevin Kofler wrote: > Michael Schwendt wrote: >> Just to acknowledge that this is not only theory, it has happened before >> actually. > > I know, I'm also speaking from experience there. A few made it through to > stable (*cough* rkward *cough* Qt 4.5 *cough* and I think there were a > couple more Qt 4.5 builds which slipped through too early), I managed to > intercept a few others before chaos happened. Then you're more lucky then I am. I am trying to push a chain of packages updates/upgrades, but I am stuck in a cobweb of broken, inconsistent repos and mock setups, which allows me to push untested packages, but doesn't allow me to build them locally. Ralf From fedora at camperquake.de Mon May 11 15:32:36 2009 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 11 May 2009 17:32:36 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <20090511131259.22244f97@rawhide.intranet> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <200905081059.20191.mhlavink@redhat.com> <1241795878.3209.88.camel@localhost.localdomain> <20090508153102.GA15821@bludgeon.org> <1241798647.3209.95.camel@localhost.localdomain> <4A04D59A.20006@freenet.de> <1241831621.2923.552.camel@adam.local.net> <4A04DD30.5010805@freenet.de> <1241833349.2923.555.camel@adam.local.net> <4A04F905.7020708@freenet.de> <4A07C0BC.40305@freenet.de> <20090511131259.22244f97@rawhide.intranet> Message-ID: <20090511173236.612f8fd4@lain.camperquake.de> Hi. On Mon, 11 May 2009 13:12:59 +0200, Michael Schwendt wrote > The basic idea of buildroot protection is good. What doesn't work > well so far, however, is how the buildroot overrides are executed. A > packager submits a releng ticket, the request is accepted, the tag > gets created, the incompatible package enters the buildroots, no > announcement is sent, danger lies ahead. As pointed out elsewhere in > this thread, this has hit qtorrent (rb_libtorrent, springlobby) for > Fedora 11. The process would be much better if (a) all buildroot > overrides would be announced in a prominent place and (b) marking > incompatible packages "stable" in order to skip the buildroot > override procedure would be forbidden. Could koji provide 'private' buildroots, which are created for a limited time and in which the override packages are imported? Like this: a) Packager builds new package of libfoo b) Packager request buildroot override for libfoo c) a private koji tag is created which includes the new libfoo and which stays valid for a specific time (say, a couple of days, or until the packager dismisses it) d) Packager builds appfoo in the private tag Noone except the packager would be affected by the override, until libfoo hits the proper repos. From seg at haxxed.com Mon May 11 15:33:06 2009 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 11 May 2009 10:33:06 -0500 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A082E70.7030904@TheTroubleshooters.dk> References: <4A082E70.7030904@TheTroubleshooters.dk> Message-ID: <1242055986.2510.3.camel@localhost.localdomain> On Mon, 2009-05-11 at 15:56 +0200, Michael Nielsen wrote: > IMO it is really badly time to do a "back-to-basics" approach, and to > clean up the system. http://www.linuxfromscratch.org/ Start from the bottom up and show us how it's done. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Mon May 11 16:04:52 2009 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 11 May 2009 11:04:52 -0500 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A0814ED.60205@redhat.com> References: <4A0814ED.60205@redhat.com> Message-ID: <1242057892.2510.7.camel@localhost.localdomain> On Mon, 2009-05-11 at 08:07 -0400, Stephen Gallagher wrote: > OK, first off, why in $DEITY's name are we including Firefox 3.5b4 and > Thunderbird 3.0b2 in Fedora 11? These are unstable branches of the > browser and email client, and as such are supported by almost none of > the myriad of extensions available for the 3.0 and 2.0 versions, > respectively. > > I was more than a little disappointed when I upgraded my laptop to the > F11 Preview to discover that only two out of seven of my Thunderbird > extensions and three of my thirteen Firefox extensions remained functional. You could just... not upgrade your system to a pre-release Fedora. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From pertusus at free.fr Mon May 11 16:08:55 2009 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 11 May 2009 18:08:55 +0200 Subject: best practices for updates in stable releases (was: Re: OpenOffice 3.1) In-Reply-To: <20d6441a0905110849r6b6e9537ofa343ddb27156ba1@mail.gmail.com> References: <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <4A05B234.2020608@leemhuis.info> <1241890311.2886.63.camel@localhost.localdomain> <1242054913.3452.16.camel@localhost.localdomain> <20d6441a0905110849r6b6e9537ofa343ddb27156ba1@mail.gmail.com> Message-ID: <20090511160855.GG2851@free.fr> On Mon, May 11, 2009 at 10:49:22AM -0500, Jud Craft wrote: > On Mon, May 11, 2009 at 10:15 AM, Jesse Keating wrote: > > On Mon, 2009-05-11 at 13:03 +0200, Matej Cepl wrote: > > Suggestions on how to "enforce" ? > > Lock out developers who don't follow guidelines? Sanction them? > Remove their ability to push updates? > > No sass meant, I just figured that was a strange rhetorical question. > Does Fedora really not have any ability to enforce its own guidelines? In general, no. Maintainers from the community are benevolent and aren't bound by a contract. Also some people @RH don't seem to feel obliged that much by fedora policies. I guess that @RH managers could do something then, but only if they think that those fedora policies are to be followed, and my guess is that, in some RH teams, the updating policy is not viewed as relevant. FESCo is something like an authority that can ask for sanctions, but will rarely do so. There are some places where some interaction happens, and some checks of guidelines, are possible, like in reviews. Also some specific cases have policies (missing maintainer, who is allowed to change other people packages). But in general maintainers are free to do whatever they want in their packages. In fact I think that it is a good thing, except when bugs are not fixed, even though the bug reporter provided with a fix. -- Pat From sgallagh at redhat.com Mon May 11 16:13:03 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 11 May 2009 12:13:03 -0400 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <1242057892.2510.7.camel@localhost.localdomain> References: <4A0814ED.60205@redhat.com> <1242057892.2510.7.camel@localhost.localdomain> Message-ID: <4A084E8F.3020404@redhat.com> On 05/11/2009 12:04 PM, Callum Lerwick wrote: > On Mon, 2009-05-11 at 08:07 -0400, Stephen Gallagher wrote: >> OK, first off, why in $DEITY's name are we including Firefox 3.5b4 and >> Thunderbird 3.0b2 in Fedora 11? These are unstable branches of the >> browser and email client, and as such are supported by almost none of >> the myriad of extensions available for the 3.0 and 2.0 versions, >> respectively. >> >> I was more than a little disappointed when I upgraded my laptop to the >> F11 Preview to discover that only two out of seven of my Thunderbird >> extensions and three of my thirteen Firefox extensions remained functional. > > You could just... not upgrade your system to a pre-release Fedora. > Callum, my problem is that the final release of Fedora 11 is scheduled to ship with these pre-release versions of Firefox and Thunderbird. I'm fully aware that unstable software is expected in a pre-release Fedora. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From jkeating at redhat.com Mon May 11 16:12:49 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 May 2009 09:12:49 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <20090511173236.612f8fd4@lain.camperquake.de> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <200905081059.20191.mhlavink@redhat.com> <1241795878.3209.88.camel@localhost.localdomain> <20090508153102.GA15821@bludgeon.org> <1241798647.3209.95.camel@localhost.localdomain> <4A04D59A.20006@freenet.de> <1241831621.2923.552.camel@adam.local.net> <4A04DD30.5010805@freenet.de> <1241833349.2923.555.camel@adam.local.net> <4A04F905.7020708@freenet.de> <4A07C0BC.40305@freenet.de> <20090511131259.22244f97@rawhide.intranet> <20090511173236.612f8fd4@lain.camperquake.de> Message-ID: <1242058369.3452.21.camel@localhost.localdomain> On Mon, 2009-05-11 at 17:32 +0200, Ralf Ertzinger wrote: > Could koji provide 'private' buildroots, which are created for a limited > time and in which the override packages are imported? Like this: > > a) Packager builds new package of libfoo > b) Packager request buildroot override for libfoo > c) a private koji tag is created which includes the new libfoo and which > stays valid for a specific time (say, a couple of days, or until the > packager dismisses it) > d) Packager builds appfoo in the private tag > > Noone except the packager would be affected by the override, until > libfoo hits the proper repos. It can be done, but it has a much higher cost. More releng time to create the one-off buildroot, more buildsystem time to generate repodata from scratch for the new buildroot, more developer time to remember to build into a specific target, and lots more moving parts that can go wrong. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mschwendt at gmail.com Mon May 11 16:19:05 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Mon, 11 May 2009 18:19:05 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <200905081059.20191.mhlavink@redhat.com> <1241795878.3209.88.camel@localhost.localdomain> <20090508153102.GA15821@bludgeon.org> <1241798647.3209.95.camel@localhost.localdomain> <4A04D59A.20006@freenet.de> <1241831621.2923.552.camel@adam.local.net> <4A04DD30.5010805@freenet.de> <1241833349.2923.555.camel@adam.local.net> <4A04F905.7020708@freenet.de> <4A07C0BC.40305@freenet.de> <20090511131259.22244f97@rawhide.intranet> Message-ID: <20090511181905.3ecc3cd6@rawhide.intranet> On Mon, 11 May 2009 15:08:49 +0200, Kevin wrote: [buildroot overrides / directly pushing to stable] > It has also hit a few packages with Qt 4.5 in F9/F10 updates (even though I > did warn about this issue on fedora-devel-announce! So we also need to make > sure that people read those announcements before submitting builds!) Of course. People doing updates must be careful in general. If all ordinary updates were pushed to updates-testing first, this would reduce the breakage. Secret/silent buildroot overrides bear a risk. It's a potential race condition for everyone who is not aware of such overrides. For example, one can't expect a new package contributor, who may be working on his first Fedora package, to know about buildroot overrides in koji that may be active while building and preparing an update for bodhi. Security/emergency-fixes are also affected by buildroot overrides. From mike at cchtml.com Mon May 11 16:20:59 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Mon, 11 May 2009 11:20:59 -0500 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A084E8F.3020404@redhat.com> References: <4A0814ED.60205@redhat.com> <1242057892.2510.7.camel@localhost.localdomain> <4A084E8F.3020404@redhat.com> Message-ID: <4A08506B.8080606@cchtml.com> > On 05/11/2009 10:25 PM, Michael Cronenworth wrote: > Stop, read, and listen to yourselves before replying to this > thread again. ... > On 05/11/2009 11:13 PM, Stephen Gallagher wrote: > Callum, my problem is that the final release of Fedora 11 is scheduled > to ship with these pre-release versions of Firefox and Thunderbird. > > I'm fully aware that unstable software is expected in a pre-release Fedora. > At this point you are just trolling. I'm done with this thread. From mschwendt at gmail.com Mon May 11 16:24:25 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Mon, 11 May 2009 18:24:25 +0200 Subject: Build problems? (was: Re: 182 pending F11 stable updates. WTF?) In-Reply-To: <4A08491A.2000506@freenet.de> References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241949557.3109.2.camel@localhost.localdomain> <20090511122057.02a66ba1@rawhide.intranet> <4A08491A.2000506@freenet.de> Message-ID: <20090511182425.1a5c18c4@rawhide.intranet> On Mon, 11 May 2009 17:49:46 +0200, Ralf wrote: > Kevin Kofler wrote: > > Michael Schwendt wrote: > >> Just to acknowledge that this is not only theory, it has happened before > >> actually. > > > > I know, I'm also speaking from experience there. A few made it through to > > stable (*cough* rkward *cough* Qt 4.5 *cough* and I think there were a > > couple more Qt 4.5 builds which slipped through too early), I managed to > > intercept a few others before chaos happened. > > Then you're more lucky then I am. I am trying to push a chain of > packages updates/upgrades, but I am stuck in a cobweb of broken, > inconsistent repos and mock setups, which allows me to push untested > packages, but doesn't allow me to build them locally. What exactly is the problem? Do you need buildroot overrides as done by releng? Have you activated any already? Can you build your updates in koji? (you can even submit src.rpm to koji as scratch-builds) How about opening a new thread about such problems? From jarod at redhat.com Mon May 11 16:24:35 2009 From: jarod at redhat.com (Jarod Wilson) Date: Mon, 11 May 2009 12:24:35 -0400 Subject: FESco meeting summary for 20090507 In-Reply-To: References: <200905110014.50581.bjorn@xn--rombobjrn-67a.se> Message-ID: <200905111224.35392.jarod@redhat.com> On Monday 11 May 2009 09:27:42 Kevin Kofler wrote: > Bj?rn Persson wrote: > > http://www.dustin.se/productdetails.aspx?prodid=5010198913 > > That one uses the Atom 330, which does support 64-bit (though there's at > least one report of 2.6.27 kernels not working in 64-bit mode on it, you > apparently need 2.6.29). I have that board. 64-bit 2.6.27 works fine, after you update the bios on the board. With the original bios on mine, a 32-bit 2.6.27 and a 64-bit 2.6.29 both booted fine, while 64-bit 2.6.27 crashed and burned. -- Jarod Wilson jarod at redhat.com From sgallagh at redhat.com Mon May 11 16:27:21 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 11 May 2009 12:27:21 -0400 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A08506B.8080606@cchtml.com> References: <4A0814ED.60205@redhat.com> <1242057892.2510.7.camel@localhost.localdomain> <4A084E8F.3020404@redhat.com> <4A08506B.8080606@cchtml.com> Message-ID: <4A0851E9.5050808@redhat.com> On 05/11/2009 12:20 PM, Michael Cronenworth wrote: >> On 05/11/2009 10:25 PM, Michael Cronenworth wrote: >> Stop, read, and listen to yourselves before replying to this >> thread again. > > ... > >> On 05/11/2009 11:13 PM, Stephen Gallagher wrote: >> Callum, my problem is that the final release of Fedora 11 is scheduled >> to ship with these pre-release versions of Firefox and Thunderbird. >> >> I'm fully aware that unstable software is expected in a pre-release >> Fedora. >> > > At this point you are just trolling. I'm done with this thread. > I'm not sure I understand. I see that there is a problem: Fedora 11 (the final release) is scheduled to include two half-baked and highly important components. Your solution is "Don't install a pre-release Fedora". So I should not raise an issue to the attention of the fedora-devel-list until it's too late to change it? I'm not trolling, I just feel that the decision to ship these two packages is wrong (or at least that the stable versions should also be in the repository) This is going to cause chaos and headaches to anyone who installs the final release. -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From kanarip at kanarip.com Mon May 11 16:33:49 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 11 May 2009 18:33:49 +0200 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A0818B2.6090709@redhat.com> References: <4A0814ED.60205@redhat.com> <5256d0b0905110518w650b8da2u73a36d674f690406@mail.gmail.com> <4A0818B2.6090709@redhat.com> Message-ID: <4A08536D.5000704@kanarip.com> On 05/11/2009 02:23 PM, Stephen Gallagher wrote: > That still does not address my concern about Thunderbird, which is still > well within the "Don't use this on any system you care about" phase of > its development... > I cannot but agree with the previous two responses in this thread, also running Thunderbird on rawhide on the one system I really care about. -Jeroen From jkeating at redhat.com Mon May 11 16:37:30 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 May 2009 09:37:30 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <20090511181905.3ecc3cd6@rawhide.intranet> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <200905081059.20191.mhlavink@redhat.com> <1241795878.3209.88.camel@localhost.localdomain> <20090508153102.GA15821@bludgeon.org> <1241798647.3209.95.camel@localhost.localdomain> <4A04D59A.20006@freenet.de> <1241831621.2923.552.camel@adam.local.net> <4A04DD30.5010805@freenet.de> <1241833349.2923.555.camel@adam.local.net> <4A04F905.7020708@freenet.de> <4A07C0BC.40305@freenet.de> <20090511131259.22244f97@rawhide.intranet> <20090511181905.3ecc3cd6@rawhide.intranet> Message-ID: <1242059850.3452.23.camel@localhost.localdomain> On Mon, 2009-05-11 at 18:19 +0200, Michael Schwendt wrote: > Secret/silent buildroot overrides bear a risk. It's a potential race > condition for everyone who is not aware of such overrides. > > For example, one can't expect a new package contributor, who may be > working on his first Fedora package, to know about buildroot overrides in > koji that may be active while building and preparing an update for bodhi. > > Security/emergency-fixes are also affected by buildroot overrides. I'd really like to know what people's thoughts are on making the overrides more known. One problem we have with them as well is that maintainers don't let us know when the build is done, so that we can remove the override to prevent poisoning further builds. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From walters at verbum.org Mon May 11 16:43:13 2009 From: walters at verbum.org (Colin Walters) Date: Mon, 11 May 2009 12:43:13 -0400 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241836379.2886.30.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <1241754133.3209.71.camel@localhost.localdomain> <4A03AF94.60605@freenet.de> <1241756375.3209.76.camel@localhost.localdomain> <4A03BB64.10006@freenet.de> <1241795563.3209.83.camel@localhost.localdomain> <4A04D350.1000904@freenet.de> <1241832771.2886.15.camel@localhost.localdomain> <4A04EAAE.50907@freenet.de> <1241836379.2886.30.camel@localhost.localdomain> Message-ID: On Fri, May 8, 2009 at 10:32 PM, Jesse Keating wrote: > On Sat, 2009-05-09 at 04:30 +0200, Ralf Corsepius wrote: >> Short summary: >> * Open F11 updates/testing NOW > > We've been trying to push F11 updates for a couple days now. > >> * Decouple cuttings DVDs from F11 development > > I honestly don't understand what you're proposing here. ?No DVD from the > release? ?What do we have people download to get the release? ?What do > we hand out at events? I'd say we should be handing out live cds. If DVD format is desired for various reasons, the ideal way it's structured would be that it'd be a live dvd, with the stuff that didn't fit from the corresponding comps set installed (I'm thinking OpenOffice here). How any remaining space should be filled is a matter for debate (do we do development tools? servers? popular games? a mix of all?). From dcbw at redhat.com Mon May 11 16:51:08 2009 From: dcbw at redhat.com (Dan Williams) Date: Mon, 11 May 2009 12:51:08 -0400 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A082E70.7030904@TheTroubleshooters.dk> References: <4A082E70.7030904@TheTroubleshooters.dk> Message-ID: <1242060668.28322.85.camel@localhost.localdomain> On Mon, 2009-05-11 at 15:56 +0200, Michael Nielsen wrote: > Hi, > > I've been told this is the right place to place this debate starter. > > > Not to demean the fine work that has been done in maintaining fedora, > however the distribution is slowly killing itself, being destroyed by > contradicting philosophies. Many of the problems have been directly > copied from the Windows world. > > The main problems are. > > 1. Removal of features - the user interfaces are being dumbed down, like > recently I've searched for the ability to remove the "Raise on Click" > feature that is default for Gnome MetaCity, there does not appear to be > any such feature anymore / argument being to simplify how it works.. > Fine, create a simple view and an advanced view for the configuration > tools, so that people who are clueless about any other way than the > official Redmond way, can avoid being confronted with an alternative. > > 2. The network interfaces are being bound to the user interface, such > that if your X fails for some reason, or you are running on a text > console, you are unable to open the wireless configuration, at least > it's not obvious how you do it, without X running. The configuration for > the network interfaces are so tightly bound to the user interface, such > that if there is no user interface there are no network interfaces. This is false. NetworkManager will read (and write!) system network configuration for wired & wireless devices, and can bring those devices up before login. I think what you may be missing is an easy one-command tool to activate/deactivate those, and that's fairly simple with dbus-send, and yes, its something that should be written. But in now way is network tied to a UI or unusable without a UI. Dan > 3. Mounts are also embedded into the user interface, rather than in the > unix mount system, which means that the shares are not accessible for > non-gui programs, for instance, I like to script most thing I do often, > however, there is no way for scripts to get a hold of a drive that is > mounted through the gui mount system (kde and gnome). > > 4. Everything is thrown in huge collective directories, such as > /usr/bin, /usr/lib etc, and it is a huge mess, just like windows with > it's system32 directory, which is also a huge mess. really the > /usr/bin,/bin/sbin, /lib etc, has very specific purposes, and should > represent a core operating system, that is capable of being used as > repair, with no major applications present. However even Open office is > stored in these directories. > > 5. More and more services are bound up in the userinterface, such as the > pulse audio, which is started by the GUI, this means if you use 2 user > environments, which I often do for testing, where I have X:0 and X:1 > running, the GUIs will conflict, because you cannot run two instances of > pulseaudio. In addition pulse audio is crap, I have yet to see any > installation actually work without crackling, and chopping like crazy. I > like the concept that is the basis of pulse audio, but it just does not > work. > > 6. NetworkManager which appears to be installed default, does not work > with shared drives, because, the NetworkManager is shut down before the > network drives are detached, and you need to modify the NetworkManager > to start properly, before you mount the network drives. I've gotten used > to explicit uninstalling the NetworkManager, because it just doesn't > work properly. > > It is a lengthy discussion to describe what i mean. > > However, if I take a sample application like firefox, it presents a > reasonable proxy for what I mean. > > currently default installation of firefox on my machine installs firefox > in these following places. > > /usr/lib64/firefox > /usr/lib64/firefox-3.0.7 > /usr/lib/mozilla > /usr/lib64/mozilla > /usr/share/mozilla > /usr/bin/mozilla-plugin-config > /usr/bin/firefox > > etc. > > All of which are related to the firefox installation. If something goes > wrong, it's a real pain to clean it up, or even to detect what went > wrong. The original concept for unix was to install an application such > as firefox in either, /opt or /usr/local/. Such that the entire > application was contained within a single installation directory, and > then to use the PATH and LD_LIBRARY_PATH to allow the execution of the > application. > > The standard approach with /opt or /usr/local installation also makes it > triviel to have multiple installations, and configurations operating in > paralellel, by simply creating. > > /opt/mozilla/firefox -> /opt/mozilla/firefox-3.0.7 > /opt/mozilla/firefox-3.0.7 > /opt/mozilla/firefox-2.0.9 > > A user can then easily conifgure their account to use either version of > the application, without installation problems. > > Additionally using that installation method, also means that if someone > wants to use a newer version of an application, they can download the > source, and trivially install it in parallel to the package managed > application, by using the --prefix option, and the installation can > easily be removed, by simple rm -rf /opt/mozilla/firefox-3.0.7. > > With the current installation, it is nearly impossible, or at least very > difficult to find out if the package manager has cleaned up properly, or > if there is something left behind - something which is identicial to the > problem on windows. > > > > A UNIX based system is intended to have everything accessible through > standard accesses, such as the file system, and the network, however, > the current trend in moving away from having the system control things > (which I can see is easier), breaks with the ability of scripting. > > If this tendency keeps going, Linux is going to become a useless > mismatch of junk, that no one can really use for anything but a toy. > > In my opinion, the trend has been visible for about a decade, but it has > really gone downhill from about rethat 7/8.. though in Fedora 8, > everything worked fine on most machines that I installed on, apart from > some obscure drivers, however, since Fedora 8, i've yet to have a system > where the audio works properly, and with Fedora 10, the kernel Ooopses > so often it's not funny, on quite a few of my machines, to such a degree > that I'm recommending that people do not upgrade past Fedora 8, and I'm > considering dropping the Fedora line of Linux, because it is becoming > just too messy, and clumsy. > > The divergence between the "GUI" focused approach, and the "Server" > approach is not good for Linux, as it means there will be a fork, which > will be incompatible. There really isn't a good reason for this split. > > > I am wondering is anyone else concerned about, what in my opinion, is > the copying of the mistakes that Microsoft made with windows, to the > Linux environment. > > IMO it is really badly time to do a "back-to-basics" approach, and to > clean up the system. > > I'm really curious as to the reasoning for moving everything from the > standard configuration mechanisms to the gui layer, breaking > compatibility with scripting, and other standard UNIX featuers.. I'm > also curious as to the reasoning for throwing everything in one huge > mess in the /usr/bin, /bin, /sbin, etc.. As all that is achieved is to > make it hard to strip the system back to a minimal setup. > > regards > mike. > From emmanuel.seyman at club-internet.fr Mon May 11 16:50:19 2009 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Mon, 11 May 2009 18:50:19 +0200 Subject: best practices for updates in stable releases (was: Re: OpenOffice 3.1) In-Reply-To: <1242054913.3452.16.camel@localhost.localdomain> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <4A05B234.2020608@leemhuis.info> <1241890311.2886.63.camel@localhost.localdomain> <1242054913.3452.16.camel@localhost.localdomain> Message-ID: <20090511165019.GA32443@orient.maison.lan> * Jesse Keating [11/05/2009 17:47] : > > Suggestions on how to "enforce" ? A karma system which limits your ability to push updates based on how gratuitous your previous ones were ? Emmanuel From oget.fedora at gmail.com Mon May 11 16:51:15 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Mon, 11 May 2009 12:51:15 -0400 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <20090511181905.3ecc3cd6@rawhide.intranet> References: <1241718097.3209.11.camel@localhost.localdomain> <1241831621.2923.552.camel@adam.local.net> <4A04DD30.5010805@freenet.de> <1241833349.2923.555.camel@adam.local.net> <4A04F905.7020708@freenet.de> <4A07C0BC.40305@freenet.de> <20090511131259.22244f97@rawhide.intranet> <20090511181905.3ecc3cd6@rawhide.intranet> Message-ID: On Mon, May 11, 2009 at 12:19 PM, Michael Schwendt wrote: > On Mon, 11 May 2009 15:08:49 +0200, Kevin wrote: > > [buildroot overrides / directly pushing to stable] > >> It has also hit a few packages with Qt 4.5 in F9/F10 updates (even though I >> did warn about this issue on fedora-devel-announce! So we also need to make >> sure that people read those announcements before submitting builds!) > > Of course. People doing updates must be careful in general. If all > ordinary updates were pushed to updates-testing first, this would reduce > the breakage. > Some packages pull ~200 other packages (on top of the minimal build environment) through BR's during building. Do you really expect packagers to check the versions of all packages being pulled and compare them with the actual packages in the repos? One thing that could be done to reduce the pain is to explicitly indicate the buildroot overrides (as if they are coming from a different source repo) in root.log. Is this possible? Right now there is no way to tell where BR's come from without manual checking. Orcan From forum at ru.bir.ru Mon May 11 17:07:34 2009 From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus)) Date: Mon, 11 May 2009 21:07:34 +0400 Subject: best practices for updates in stable releases In-Reply-To: <20090511160855.GG2851@free.fr> References: <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <4A05B234.2020608@leemhuis.info> <1241890311.2886.63.camel@localhost.localdomain> <1242054913.3452.16.camel@localhost.localdomain> <20d6441a0905110849r6b6e9537ofa343ddb27156ba1@mail.gmail.com> <20090511160855.GG2851@free.fr> Message-ID: Patrice Dumas wrote: > There are some places where some interaction happens, and some checks of > guidelines, are possible, like in reviews. Also some specific cases > have policies (missing maintainer, who is allowed to change other people > packages). But in general maintainers are free to do whatever they want > in their packages. > > In fact I think that it is a good thing, except when bugs are not fixed, > even though the bug reporter provided with a fix. Great words! Free is freedom is freedom with all pluses and minuses! Freedom it is not only be free doing want you want, it is also allow do it for others! Sure, please do not threat it as proclamation to anarchy! We have guidelines, and I believe what most of maintainers tried be closer to it. We pedantic check following to it in step where it may be formalized: In review request, in reviewing, in sponsoring, in guidelines change, in many other situation. But we can't even try apply any sanctions to maintainer to its treat some very common recommendations like [1] Sorry, but it is only recommendations. F.e. how you are suggest apply any sanction by formulation like (cite [1]): "New upstream releases should not necessarily be pushed to release branches. The benefit of the bugfixes and new features should be weighed up against the risk of regressions.". How it should be weighed? Who should weight it? For what scale in last??? Must we call FESCO on each update to vote it? Do karma absolutely necessarily (so, some rigidity and qualification here even I wish see, but it is subject another thread)? Any things? [1] http://fedoraproject.org/wiki/PackageMaintainers/Package_update_guidelines From awilliam at redhat.com Mon May 11 17:18:40 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 11 May 2009 10:18:40 -0700 Subject: FESco meeting summary for 20090507 In-Reply-To: References: Message-ID: <1242062320.2923.586.camel@adam.local.net> On Sun, 2009-05-10 at 18:28 +0200, drago01 wrote: > The only reason people prefer to run i686 even on x86_64 is because > "apps do not work", which is nothing but a myth. It's not a myth, but it's now (only quite recently) mostly outdated. wine has never had a decent x86-64 port, and still doesn't. openoffice.org's x86-64 version was unusable for a long time. Running Flash on x86-64 was a big pain for a long time (even with nspluginwrapper) until Adobe finally released a native x86-64 plugin (which is still technically an alpha, and really doesn't work as well as the x86-32 plugin in some ways). Java was equally painful until OpenJDK came along, as Sun consistently refused to release a native x86-64 Java plugin. Those were the major issues. OO.o and Java are fixed and Flash is mostly fixed, but wine is still valid. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From jkeating at redhat.com Mon May 11 17:18:57 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 May 2009 10:18:57 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: References: <1241718097.3209.11.camel@localhost.localdomain> <1241754133.3209.71.camel@localhost.localdomain> <4A03AF94.60605@freenet.de> <1241756375.3209.76.camel@localhost.localdomain> <4A03BB64.10006@freenet.de> <1241795563.3209.83.camel@localhost.localdomain> <4A04D350.1000904@freenet.de> <1241832771.2886.15.camel@localhost.localdomain> <4A04EAAE.50907@freenet.de> <1241836379.2886.30.camel@localhost.localdomain> Message-ID: <1242062337.3452.27.camel@localhost.localdomain> On Mon, 2009-05-11 at 12:43 -0400, Colin Walters wrote: > > I'd say we should be handing out live cds. If DVD format is desired > for various reasons, the ideal way it's structured would be that it'd > be a live dvd, with the stuff that didn't fit from the corresponding > comps set installed (I'm thinking OpenOffice here). How any remaining > space should be filled is a matter for debate (do we do development > tools? servers? popular games? a mix of all?). Whether it's a DVD or a Live image, it is still a static pile of packages from a specific date in time. Of course, the Live image doesn't necessarily have the upgrade problem we're talking about, because you can't use the live image to do an upgrade. Makes it less than useful for people. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From cdahlin at redhat.com Mon May 11 17:18:19 2009 From: cdahlin at redhat.com (Casey Dahlin) Date: Mon, 11 May 2009 13:18:19 -0400 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A08381D.5030604@freenet.de> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08381D.5030604@freenet.de> Message-ID: <4A085DDB.101@redhat.com> Ralf Corsepius wrote: > Seth Vidal wrote: >> >> >> On Mon, 11 May 2009, Michael Nielsen wrote: >> >>> Hi, >>> >>> I've been told this is the right place to place this debate starter. >> >> >> You were told incorrectly. >> >> I'm sure there is a place for this kind of debate but it is SURELY not >> the devel list. > @RH ignorance? Do you contribute anything to this list /besides/ blaming everything on Red Hat? --CJD From konrad at tylerc.org Mon May 11 17:23:01 2009 From: konrad at tylerc.org (Conrad Meyer) Date: Mon, 11 May 2009 10:23:01 -0700 Subject: rtorrent GCC 4.1 incompatibility? In-Reply-To: <20090511114315.5a1f6cb5@rawhide.intranet> References: <20090511114315.5a1f6cb5@rawhide.intranet> Message-ID: <200905111023.01232.konrad@tylerc.org> On Monday 11 May 2009 02:43:15 am Michael Schwendt wrote: > [Bcc to rtorrent-owner] > > The rtorrent.spec file does > > | # work around a bug thats triggered by gcc 4.1 > | > | export RPM_OPT_FLAGS=`echo $RPM_OPT_FLAGS | %{__sed} s/-O2/-Os/` > > and the reader wonders what bug that may be? > > No bugzilla ticket is linked. The %changelog says: > | * Sun Nov 26 2006 Chris Chabot - 0.6.4-1 > | - New upstream version > | - Compile with -Os to work around a gcc 4.1 incompatibility > > No bz number either. And it's an entry from 2006. We're in 2009, > however, and are using a much newer GCC release. > > So, what GCC 4.1 bug is it? Is the -Os still needed? I doubt it's needed, I'll change it back to using normal Fedora optflags. Regards, -- Conrad Meyer From rc040203 at freenet.de Mon May 11 17:23:25 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 11 May 2009 19:23:25 +0200 Subject: Build problems? In-Reply-To: <20090511182425.1a5c18c4@rawhide.intranet> References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241949557.3109.2.camel@localhost.localdomain> <20090511122057.02a66ba1@rawhide.intranet> <4A08491A.2000506@freenet.de> <20090511182425.1a5c18c4@rawhide.intranet> Message-ID: <4A085F0D.5030109@freenet.de> Michael Schwendt wrote: > On Mon, 11 May 2009 17:49:46 +0200, Ralf wrote: > >> Kevin Kofler wrote: >>> Michael Schwendt wrote: >>>> Just to acknowledge that this is not only theory, it has happened before >>>> actually. >>> I know, I'm also speaking from experience there. A few made it through to >>> stable (*cough* rkward *cough* Qt 4.5 *cough* and I think there were a >>> couple more Qt 4.5 builds which slipped through too early), I managed to >>> intercept a few others before chaos happened. >> Then you're more lucky then I am. I am trying to push a chain of >> packages updates/upgrades, but I am stuck in a cobweb of broken, >> inconsistent repos and mock setups, which allows me to push untested >> packages, but doesn't allow me to build them locally. > > What exactly is the problem? It's all f*cked up: * Fedora's default mock configurations don't reflect reality: - They don't know anything about fc12 (n/a) - FC10's mock builds i386 rpms instead of i586 for Fc11- - mock doesn't handle rpm's md5/sha256 check-sums correctly (All versions). * koji/bodji allow building fc11 and fc12 packages => I am able to build and push packages into fc11 and fc12, I an mot able to build locally, using packages of unknown origin. > Do you need buildroot overrides as done by releng? That's a rel-eng's centric view. My view: rel-reg shouled finally finally start using the infrastructure they dictated to contributors. I have fc11 packages pending, I marked as stable => they should release them and let "build overrides" die. Whether as "updates" or as "build-overides" is irrelevant. > Have you activated any already? Buildroot overrides? No, because a) I am actively boycotting them. b) these updates are non critical. > Can you build your updates in koji? Yes, some of them even have been pushed and are in FC9/Fc10 and FC12, but not in FC11! > (you can even submit src.rpm > to koji as scratch-builds) > > How about opening a new thread about such problems? No, I feel sufficiently peed, I am not interested and do not have any time left to waste on this matter, but prefer users and rel-eng to experience the consequences of the brokenness of Fedora's work-flow, themselves - These issues are one cause of the flood of (low quality) updates users will be facing very short after the release. From walters at verbum.org Mon May 11 17:37:02 2009 From: walters at verbum.org (Colin Walters) Date: Mon, 11 May 2009 13:37:02 -0400 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1242062337.3452.27.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <1241756375.3209.76.camel@localhost.localdomain> <4A03BB64.10006@freenet.de> <1241795563.3209.83.camel@localhost.localdomain> <4A04D350.1000904@freenet.de> <1241832771.2886.15.camel@localhost.localdomain> <4A04EAAE.50907@freenet.de> <1241836379.2886.30.camel@localhost.localdomain> <1242062337.3452.27.camel@localhost.localdomain> Message-ID: On Mon, May 11, 2009 at 1:18 PM, Jesse Keating wrote: > On Mon, 2009-05-11 at 12:43 -0400, Colin Walters wrote: >> >> I'd say we should be handing out live cds. ?If DVD format is desired >> for various reasons, the ideal way it's structured would be that it'd >> be a live dvd, with the stuff that didn't fit from the corresponding >> comps set installed (I'm thinking OpenOffice here). How any remaining >> space should be filled is a matter for debate (do we do development >> tools? ?servers? ?popular games? ?a mix of all?). > > Whether it's a DVD or a Live image, it is still a static pile of > packages from a specific date in time. Well, I see it as a well defined *targeted product* which happens to be composed of packages. It's the base from which other things can be installed from the Internet. What is the problem with "static pile of packages"? (I have to admit to only skimming this thread) > Of course, the Live image > doesn't necessarily have the upgrade problem we're talking about, > because you can't use the live image to do an upgrade. ?Makes it less > than useful for people. For upgrades we should be pushing people towards preupgrade. If preupgrade works well, I'm having trouble thinking of scenarios in which you'd end up with a physical image and want to do an upgrade. Maybe if you're out of disk space you'd need physical media to download the updates on to, but there's also no reason preupgrade couldn't prompt you to insert a USB stick or blank CD. From konrad at tylerc.org Mon May 11 17:40:27 2009 From: konrad at tylerc.org (Conrad Meyer) Date: Mon, 11 May 2009 10:40:27 -0700 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A082E70.7030904@TheTroubleshooters.dk> References: <4A082E70.7030904@TheTroubleshooters.dk> Message-ID: <200905111040.27935.konrad@tylerc.org> >From this rant it seems like your operating system of choice ought to be Slackware, not Fedora. I'm sure you'll find it much more to your liking (crummy-to-no package management, out of date software, etc). Regards, -- Conrad Meyer From tcallawa at redhat.com Mon May 11 17:40:01 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 11 May 2009 13:40:01 -0400 Subject: SPARC Status (Was Re: Secondary Architecture Status?) In-Reply-To: <1241911202.24436.81.camel@macbook.infradead.org> References: <1241911202.24436.81.camel@macbook.infradead.org> Message-ID: <4A0862F1.2030608@redhat.com> On 05/09/2009 07:20 PM, David Woodhouse wrote: > We still don't have any secondary architectures gearing up to ship > Fedora 11 -- it would be really interesting to know why that is. > > What technical barriers are still there -- why don't we have a release > yet? For SPARC, there are a few barriers: * Amount of code writing contributors is very small. Realistically, it is me and Dennis Gilmore. This significantly slows down efforts in areas where we need to do more than perform basic package triage, e.g. anaconda. We have 99% of a Fedora 8 Tree done, but there are still enough painful bugs and missing features in anaconda that prevent us from doing a release. * Automated builds are not yet happening, although, when Dennis gets back from vacation, I'm going to work with him to setup koji-shadow to run on an aggressive cron job. I'd still like to see someone solve this problem correctly with a message bus, but as I have neither the skillset nor the time to do this, it will likely never happen. Which leads us to the next barrier: * The few SPARC contributors have very little time to allocate to the SPARC effort. Neither of us are paid to do full-time SPARC, and I've got my fingers in so many pies, I might as well be a pie. This isn't a technical barrier, per se, merely pointing out that being responsible for an architecture is a LOT of work. Not to mention that Sun is about to get swallowed up by Oracle, who I doubt will be overly concerned about Linux/SPARC, so it is even less likely that we will see additional code help or community involvement from them (as a contrast to IBM on PPC/S390). ~spot From konrad at tylerc.org Mon May 11 17:42:12 2009 From: konrad at tylerc.org (Conrad Meyer) Date: Mon, 11 May 2009 10:42:12 -0700 Subject: Fedora (Linux) is Destroying it self In-Reply-To: References: <4A082E70.7030904@TheTroubleshooters.dk> Message-ID: <200905111042.12301.konrad@tylerc.org> On Monday 11 May 2009 08:07:36 am drago01 wrote: > On Mon, May 11, 2009 at 3:56 PM, Michael Nielsen > > wrote: > > Hi, > > > > 3. Mounts are also embedded into the user interface, rather than in the > > unix mount system, which means that the shares are not accessible for > > non-gui programs, for instance, I like to script most thing I do often, > > however, there is no way for scripts to get a hold of a drive that is > > mounted through the gui mount system (kde and gnome). > > This is not true, in case of gnome you can access everything mounted > by nautilus / gvfs by accessing ~/.gvfs works with ANY app. How does a script know which user's $HOME to look in? -- Conrad Meyer From konrad at tylerc.org Mon May 11 17:43:54 2009 From: konrad at tylerc.org (Conrad Meyer) Date: Mon, 11 May 2009 10:43:54 -0700 Subject: rtorrent GCC 4.1 incompatibility? In-Reply-To: <200905111023.01232.konrad@tylerc.org> References: <20090511114315.5a1f6cb5@rawhide.intranet> <200905111023.01232.konrad@tylerc.org> Message-ID: <200905111043.54259.konrad@tylerc.org> On Monday 11 May 2009 10:23:01 am Conrad Meyer wrote: > On Monday 11 May 2009 02:43:15 am Michael Schwendt wrote: > > [Bcc to rtorrent-owner] > > > > The rtorrent.spec file does > > > > | # work around a bug thats triggered by gcc 4.1 > > | > > | export RPM_OPT_FLAGS=`echo $RPM_OPT_FLAGS | %{__sed} s/-O2/-Os/` > > > > and the reader wonders what bug that may be? > > > > No bugzilla ticket is linked. The %changelog says: > > | * Sun Nov 26 2006 Chris Chabot - 0.6.4-1 > > | - New upstream version > > | - Compile with -Os to work around a gcc 4.1 incompatibility > > > > No bz number either. And it's an entry from 2006. We're in 2009, > > however, and are using a much newer GCC release. > > > > So, what GCC 4.1 bug is it? Is the -Os still needed? > > I doubt it's needed, I'll change it back to using normal Fedora optflags. > > Regards, > -- > Conrad Meyer http://koji.fedoraproject.org/koji/taskinfo?taskID=1348191 Done in F-12. -- Conrad Meyer From tgl at redhat.com Mon May 11 17:51:36 2009 From: tgl at redhat.com (Tom Lane) Date: Mon, 11 May 2009 13:51:36 -0400 Subject: FESco meeting summary for 20090507 In-Reply-To: <1242062320.2923.586.camel@adam.local.net> References: <1242062320.2923.586.camel@adam.local.net> Message-ID: <6764.1242064296@sss.pgh.pa.us> Adam Williamson writes: > On Sun, 2009-05-10 at 18:28 +0200, drago01 wrote: >> The only reason people prefer to run i686 even on x86_64 is because >> "apps do not work", which is nothing but a myth. > It's not a myth, but it's now (only quite recently) mostly outdated. True. > Those were the major issues. OO.o and Java are fixed and Flash is mostly > fixed, but wine is still valid. Java is still a huge mess; there are any number of webapps that just plain don't work in 64-bit. (I'm not sure this is Java's fault per se, but the fact remains that things don't work and the authors seem content to tell you to install a 32-bit browser instead of fixing their broken code...) regards, tom lane From naheemzaffar at gmail.com Mon May 11 17:52:23 2009 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Mon, 11 May 2009 18:52:23 +0100 Subject: FESco meeting summary for 20090507 In-Reply-To: <1242062320.2923.586.camel@adam.local.net> References: <1242062320.2923.586.camel@adam.local.net> Message-ID: <3adc77210905111052n60790350ia40d1296816b2179@mail.gmail.com> 2009/5/11 Adam Williamson > > wine has never had a decent x86-64 port, and still doesn't. WOuld that not be kind of pointless since the people using it will be most likely trying to use 32 bit apps from the Windows world? -------------- next part -------------- An HTML attachment was scrubbed... URL: From drago01 at gmail.com Mon May 11 17:55:13 2009 From: drago01 at gmail.com (drago01) Date: Mon, 11 May 2009 19:55:13 +0200 Subject: FESco meeting summary for 20090507 In-Reply-To: <3adc77210905111052n60790350ia40d1296816b2179@mail.gmail.com> References: <1242062320.2923.586.camel@adam.local.net> <3adc77210905111052n60790350ia40d1296816b2179@mail.gmail.com> Message-ID: On Mon, May 11, 2009 at 7:52 PM, Naheem Zaffar wrote: > > > 2009/5/11 Adam Williamson >> >> wine has never had a decent x86-64 port, and still doesn't. > > WOuld that not be kind of pointless since the people using it will be most > likely trying to use 32 bit apps from the Windows world? Exactly wine does not work any worse on x86_64 you can only run 32 bit apps with it but that is not a regression compared to running it on a 32 bit os. From packages at amiga-hardware.com Mon May 11 17:57:23 2009 From: packages at amiga-hardware.com (Ian Chapman) Date: Tue, 12 May 2009 01:57:23 +0800 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A082E70.7030904@TheTroubleshooters.dk> References: <4A082E70.7030904@TheTroubleshooters.dk> Message-ID: <4A086703.1080906@amiga-hardware.com> Michael Nielsen wrote: > 1. Removal of features - the user interfaces are being dumbed down, like > recently I've searched for the ability to remove the "Raise on Click" > feature that is default for Gnome MetaCity. These are really development decisions made by Gnome upstream. It's really not as if you don't have plenty of alternatives to choose from. > 2. The network interfaces are being bound to the user interface, such > that if your X fails for some reason, or you are running on a text If you require a persistent network connection without logging into X, you can always switch off the NetworkManager service and use the network service instead. > 3. Mounts are also embedded into the user interface, rather than in the > unix mount system, which means that the shares are not accessible for Simply not true. Right this moment I'm copying podcasts to my mp3 player which was mounted directly by Gnome. It's accessible under /media/disk. My external USB drive, the partitions for the other OSs I have installed, my SD cards, camera etc are all available in a similar way. > 4. Everything is thrown in huge collective directories, such as > /usr/bin, /usr/lib etc, and it is a huge mess, just like windows with I'm surprised at this one. This is a big plus for me. As someone who regularly has to deal with Solaris systems amongst others, I get tired of playing guess the location of the binary, hunt the man page and setting an ever increasing $PATH. > 5. More and more services are bound up in the userinterface, such as the > pulse audio, which is started by the GUI, this means if you use 2 user Unfortunately Linux has suffered countless audio 'standards' and many applications have been slow to catch up with the standard du jour, if at all. Probably the single thing I most hate having to deal with when it doesn't just work. > wrong. The original concept for unix was to install an application such > as firefox in either, /opt or /usr/local/. IIRC /opt was intended for self contained applications, which provide their own tree. They are often statically compiled or depend only upon libraries and files found in their own tree. They can be a complete PITA to deal with. /usr/local I believe was intended to for installing software locally to a specific machine or a group of machines without interfering with system files or vice versa. Often the filesystems weren't even local but NFS mounted from a server or similar. Good package management and the fact that in general, most of the filesystems these days are local has negated those reasons and /usr/local is frequently (mis)used in other ways. > Such that the entire > application was contained within a single installation directory, and > then to use the PATH and LD_LIBRARY_PATH to allow the execution of the > application. Exactly, I refer to the PATH hell earlier. Additionally LD_LIBRARY_PATH is considered a security risk by many, especially when many OSs have had alternatives for years. > I'm really curious as to the reasoning for moving everything from the > standard configuration mechanisms to the gui layer, breaking > compatibility with scripting, and other standard UNIX featuers. Curious. I maintain many Linux servers without a GUI installed. I don't think I've had a requirement to configure anything that's required a GUI. If by moving, you mean providing GUI tools for configuration tasks that have traditionally required a command line, I'm all for it. -- Ian Chapman. From rc040203 at freenet.de Mon May 11 17:30:27 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 11 May 2009 19:30:27 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A085DDB.101@redhat.com> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08381D.5030604@freenet.de> <4A085DDB.101@redhat.com> Message-ID: <4A0860B3.5030802@freenet.de> Casey Dahlin wrote: > Ralf Corsepius wrote: >> Seth Vidal wrote: >>> >>> On Mon, 11 May 2009, Michael Nielsen wrote: >>> >>>> Hi, >>>> >>>> I've been told this is the right place to place this debate starter. >>> >>> You were told incorrectly. >>> >>> I'm sure there is a place for this kind of debate but it is SURELY not >>> the devel list. >> @RH ignorance? > > Do you contribute anything to this list /besides/ blaming everything on Red Hat? Everything? Maybe it escapes you, but it's always the same issue: When "upstream" == "@RH", common sense and rationality seems to be switched off in Fedora. Updating firefox "last minute", between "F11-Preview" and "Final" from a "stable version" to an "unstable version" is such a case - It's beyond reason! The only explanation I have for such incidents: @RHs are abusing Fedora for selfish purposes and @RH's in Fedora are exempt from "the rules being applied otherwise". Worse, when people bring up such issues, other @RHs (Here Seth) prefer to brush off and shoot down any glimpse of criticism. From dpierce at redhat.com Mon May 11 18:00:45 2009 From: dpierce at redhat.com (Darryl L. Pierce) Date: Mon, 11 May 2009 14:00:45 -0400 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A0860B3.5030802@freenet.de> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08381D.5030604@freenet.de> <4A085DDB.101@redhat.com> <4A0860B3.5030802@freenet.de> Message-ID: <20090511180045.GR3435@mcpierce-laptop.rdu.redhat.com> On Mon, May 11, 2009 at 07:30:27PM +0200, Ralf Corsepius wrote: > Everything? Maybe it escapes you, but it's always the same issue: > > When "upstream" == "@RH", common sense and rationality seems to be > switched off in Fedora. Red Hat's not upstream to Fedora. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Virtual Machine Management - http://www.ovirt.org/ Is fearr Gaeilge bhriste n? B?arla cliste. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From seg at haxxed.com Mon May 11 18:02:01 2009 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 11 May 2009 13:02:01 -0500 Subject: FESco meeting summary for 20090507 In-Reply-To: <2d319b780905100914n442e2501h78b2184437a67065@mail.gmail.com> References: <2d319b780905100914n442e2501h78b2184437a67065@mail.gmail.com> Message-ID: <1242064921.2510.119.camel@localhost.localdomain> On Sun, 2009-05-10 at 18:14 +0200, Mathieu Bridon (bochecha) wrote: > On Sun, May 10, 2009 at 17:44, Jon Stanley wrote: > Wouldn't smolt be a good way to know the rates of 64 bits processors > versus 32 bits ones ? > > The ? arch ? tab says : > i686 200890 75.2 % > x86_64 64931 24.3 % > > But if I understood it right, that's actually the installed arch, not > the capability of the CPU, so many of those i686 installs might come > from 64 bits CPUs and user not knowing/willing to move to 64 bits > OS... > > The ? CPU ? tab doesn't say whether the CPU is 32 or 64 bits though > (or maybe I didn't look close enough). > > Knowing how many 64 bits CPUs are out there using Fedora could provide > good input for this issue IMHO. Yes, Smolt's CPU stats are mostly useless. What it *needs* to do is collect up everyone's cpuinfo flags: $ grep "model name" /proc/cpuinfo model name : AMD Athlon(tm) 64 Processor 3000+ $ grep flags /proc/cpuinfo flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow up rep_good pni lahf_lm Then we could come up with all kinds of meaningful stats, like how many people have cmov/MMX/SSE, and how many support 64 bit regardless of installed architecture. The "lm" flag means "long mode" is supported, aka "64 bit": http://en.wikipedia.org/wiki/Long_mode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From awilliam at redhat.com Mon May 11 18:02:48 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 11 May 2009 11:02:48 -0700 Subject: OpenOffice 3.1 In-Reply-To: <6dc6523c0905101458l64811e65lb9f18216a4f93941@mail.gmail.com> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <1241990992.3452.6.camel@localhost.localdomain> <6dc6523c0905101458l64811e65lb9f18216a4f93941@mail.gmail.com> Message-ID: <1242064968.2923.615.camel@adam.local.net> On Sun, 2009-05-10 at 22:58 +0100, John5342 wrote: > updates - Non-breaking updates. Nothing stopping this or any of the > above from being bleeding edge and it should recieve updates to latest > version where possible so long as it doesnt result in breakage or > regressions. This is an essentially nonsensical criterion for something as big as OpenOffice.org and KDE. The likelihood of any versioned change in a codebase that big introducing *some* regression *somewhere* for *somebody* comes very close to 1. The only sensible policies for updates are the traditional "minimum possible change required to fix the specific bug being addressed" (which most distributions follow), or "whatever the hell you like". Trying to codify anything in the middle distribution-wide is essentially impossible, because we package several thousand chunks of code of hugely varying size and importance with utterly different policies as to what a major version means, what a minor version means and so on. To me, this comes back - again - to what I've been thinking about for a while now: what do we want Fedora to be? Who do we want it to be for? If we care about end users - the stereotypical "my aunt", "my grandad", whoever people think of when they think of someone who just doesn't care and wants a computer that works - we need a proper conservative stable update set somewhere. I think Mandriva has the best policy: it has stable releases and a two-tier upgrade repository system. Each stable release has a /updates repository, and a /backports repository. /updates is the traditional "minimum possible change" repository, and is the only update repo enabled by default, so by default you get the traditional conservative, stable update strategy. It is gated through the QA team and then the security team (which is a bit of a historical anomaly, but in practice, works well) who only sign off on updates that comply with the policy. /backports is the "anything you want" repository: maintainers can throw in new packages, new versions, experimental new patches, pretty much anything they like, without oversight (maintainers literally just run a single submit command and it goes straight out to the public repos). If you want new versions of stuff for a stable release, you use /backports. I know this is a good system because I was around for the previous system (a messy compromise rather like the current Fedora system), which everyone hated - developers didn't know what to ship where, users didn't know what to expect. The current system is great: developers understand it and have the flexibility to ship the type of updates they want (they can choose to ignore /backports entirely and only ship stable updates, or they can use it extensively and provide, say, a whole new version of KDE), users understand it and have the flexibility to choose exactly what type of updates they want (/updates only for a quiet life, specific packages from /backports if you just need some particular new feature, or everything from /backports if you like surprises). Significantly, there have been exactly no major arguments like this present one ever since the system was changed, whereas bitching and arguing over the previous system was frequent on both the 'user' and 'developer' sides. If we don't care about end users who want a stable computing platform and we want Fedora to be principally a platform for development / experimentation, I think a single "whatever the hell you like" update repository works best. The two-tier system that's good for end users would also work, but would be overly complicated for achieving the desired result (and maintainers likely wouldn't see the value in following it). We could certainly care about 'quality' in the update repository in terms of whether the packages are valid, have broken dependencies etc, but we wouldn't necessarily care about regressions / breakages in the code they contain. But, yet again, it's a question that can't be answered until we know what exactly Fedora is supposed to be, and for whose benefit. Even if we come up with a consistent and coherent policy it likely won't work until that question is properly answered and agreed upon. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From sven at lank.es Mon May 11 18:04:37 2009 From: sven at lank.es (Sven Lankes) Date: Mon, 11 May 2009 20:04:37 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A0860B3.5030802@freenet.de> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08381D.5030604@freenet.de> <4A085DDB.101@redhat.com> <4A0860B3.5030802@freenet.de> Message-ID: <20090511180436.GA10054@killefiz> On Mon, May 11, 2009 at 07:30:27PM +0200, Ralf Corsepius wrote: > Updating firefox "last minute", between "F11-Preview" and "Final" from a > "stable version" to an "unstable version" is such a case - It's beyond > reason! That is why it didn't happen. F11-preview had firefox-3.1-0.11.beta3.fc11, current f11 has firefox-3.5-0.20.beta4.fc11 which is the next beta from beta3 (mozilla decided to rename ff 3.1 to 3.5 in the meantime). I for one am very happy with both ff and thunderbird as they are currently in f11. Both are massive improvements over their predecessors. -- sven === jabber/xmpp: sven at lankes.net From pertusus at free.fr Mon May 11 18:08:36 2009 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 11 May 2009 20:08:36 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <20090511180045.GR3435@mcpierce-laptop.rdu.redhat.com> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08381D.5030604@freenet.de> <4A085DDB.101@redhat.com> <4A0860B3.5030802@freenet.de> <20090511180045.GR3435@mcpierce-laptop.rdu.redhat.com> Message-ID: <20090511180817.GA10057@free.fr> On Mon, May 11, 2009 at 02:00:45PM -0400, Darryl L. Pierce wrote: > On Mon, May 11, 2009 at 07:30:27PM +0200, Ralf Corsepius wrote: > > Everything? Maybe it escapes you, but it's always the same issue: > > > > When "upstream" == "@RH", common sense and rationality seems to be > > switched off in Fedora. > > Red Hat's not upstream to Fedora. That's not what Ralf is saying. RH is upstream for some packages or involved especially in upstream (for example, NetworkManager, hal, consolekit, gdm, many gnome components...), and in that case it is not rare that the corresponding packages end up in fedora releases although there are features that were present in previous components that are not already ready, or the applications are not that well tested as shown in rawhide testing. -- Pat From sundaram at fedoraproject.org Mon May 11 18:15:17 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 11 May 2009 23:45:17 +0530 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A0814ED.60205@redhat.com> References: <4A0814ED.60205@redhat.com> Message-ID: <4A086B35.4060102@fedoraproject.org> On 05/11/2009 05:37 PM, Stephen Gallagher wrote: > OK, first off, why in $DEITY's name are we including Firefox 3.5b4 and > Thunderbird 3.0b2 in Fedora 11? These are unstable branches of the > browser and email client, and as such are supported by almost none of > the myriad of extensions available for the 3.0 and 2.0 versions, > respectively. > > I was more than a little disappointed when I upgraded my laptop to the > F11 Preview to discover that only two out of seven of my Thunderbird > extensions and three of my thirteen Firefox extensions remained functional. > > I understand that Fedora is a development OS, and I think it's a great > idea to have a firefox35 package and a thunderbird30 package, but these > SHOULD NOT be the defaults. As a very heavy user of both Firefox and Thunderbird, the pre-releases have been substantial improvements for me over the "stable" versions. Even RHEL 5.3 included a "beta" release of Firefox, remember? I trust that the maintainers have assessed the stability and considered the advantages as worth the cost of losing some extensions for the short run and I agree with that decision. Rahul From maxamillion at gmail.com Mon May 11 18:11:25 2009 From: maxamillion at gmail.com (Adam Miller) Date: Mon, 11 May 2009 13:11:25 -0500 Subject: SPARC Status (Was Re: Secondary Architecture Status?) In-Reply-To: <4A0862F1.2030608@redhat.com> References: <1241911202.24436.81.camel@macbook.infradead.org> <4A0862F1.2030608@redhat.com> Message-ID: I completely agree with everything posted by Spot and I (nor I assume anyone) am aware of what Oracle's game plan is but they have announced that they are planning to put more money into SPARC. http://www.osnews.com/story/21458/Oracle_To_Invest_in_SPARC_Wants_to_Be_Like_Apple_Cisco This would be nice because we could (hopefully) see some SPARC workstations come back into play allowing people to become interested in and contribute to the project once more. Don't know that it would give the architecture enough of a user base to make it an applicable architecture again, but its at least something I think should be watched as time goes on. -Adam -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From pbrobinson at gmail.com Mon May 11 18:14:42 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 11 May 2009 19:14:42 +0100 Subject: FESco meeting summary for 20090507 In-Reply-To: <1242062320.2923.586.camel@adam.local.net> References: <1242062320.2923.586.camel@adam.local.net> Message-ID: <5256d0b0905111114i5573c52dq66caeffdeee82efa@mail.gmail.com> >> The only reason people prefer to run i686 even on x86_64 is because >> "apps do not work", which is nothing but a myth. > > It's not a myth, but it's now (only quite recently) mostly outdated. > > wine has never had a decent x86-64 port, and still doesn't. > openoffice.org's x86-64 version was unusable for a long time. Running > Flash on x86-64 was a big pain for a long time (even with > nspluginwrapper) until Adobe finally released a native x86-64 plugin > (which is still technically an alpha, and really doesn't work as well as > the x86-32 plugin in some ways). Java was equally painful until OpenJDK > came along, as Sun consistently refused to release a native x86-64 Java > plugin. > > Those were the major issues. OO.o and Java are fixed and Flash is mostly > fixed, but wine is still valid. I've run x86_64 with wine but the 32bit in multilib for quite some time. x64 client versions windows until very recently have been mostly pointless anyway as there have been very few native 64 bit windows apps. Peter From jkeating at redhat.com Mon May 11 18:19:20 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 May 2009 11:19:20 -0700 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A0860B3.5030802@freenet.de> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08381D.5030604@freenet.de> <4A085DDB.101@redhat.com> <4A0860B3.5030802@freenet.de> Message-ID: <1242065960.3452.32.camel@localhost.localdomain> On Mon, 2009-05-11 at 19:30 +0200, Ralf Corsepius wrote: > When "upstream" == "@RH", common sense and rationality seems to be > switched off in Fedora. > > Updating firefox "last minute", between "F11-Preview" and "Final" from a > "stable version" to an "unstable version" is such a case - It's beyond > reason! Red Hat isn't the upstream for Firefox. The firefox in F11 preview was firefox-3.1-0.11.beta3.fc11. The one currently in rawhide is firefox-3.5-0.20.beta4.fc11. Mozilla itself changed the version from 3.1 to 3.5, but the planned contents didn't. See https://developer.mozilla.org/devnews/index.php/2009/03/05/firefox-31-may-become-firefox-35/ The update was to a /more/ stable version, a later beta release with more fixes. Attack if you want, but please be sure to have the facts straight. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mschwendt at gmail.com Mon May 11 18:21:03 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Mon, 11 May 2009 20:21:03 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <4A084868.4040807@freenet.de> References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241949557.3109.2.camel@localhost.localdomain> <20090510131115.226b27a5@faldor.intranet> <4A079B3B.20606@freenet.de> <20090511132526.3195dc37@rawhide.intranet> <4A084868.4040807@freenet.de> Message-ID: <20090511202103.5b90f3b0@rawhide.intranet> On Mon, 11 May 2009 17:46:48 +0200, Ralf wrote: > >>>>>> (1) New package. > >>>>>> [cut] > >>>>> Is it a good practice to push a new package to stable? > >>> No. > >> I strongly disagree. Adding "stable" packages to stable is the primary > >> interest contributors are after. It's the #1 reason, why Fedora Extras > >> one had been launched. > > > > Cool down and slow down, at least a bit, please. > > Why should I? Because your reply above looks a lot as if you misunderstood the question. And in case you didn't, it doesn't become clear why "stable packages" should not spend 1-2 weeks in updates-testing? Why rush? What do we win by doing it? Impatient users can get the released (!) packages from the updates-testing repo. There's nothing wrong with disagreeing. I just see that skipping updates-testing leads to more problems. > * Fact is: In the overwhelming majority of all cases, testing is > effectively a delay queue, and a PITA to developers. > > * Fact also is: "Testing" doesn't help wrt. packagers doing a poor job. Depends on the level of poorness. Ignoring feedback in bodhi and ignoring negative karma in bodhi is bad, yes. Fortunately, there are only very few half-assed packagers who don't take -1 karma votes serious and who would show other PITA attitudes. > * Fact also is: "Testing" occasionally is the cause of broken package deps. How? Or, what do you mean? > > Fact is that one packager plus one reviewer are not enough > > to ensure that new packages really work good enough to call them "stable" > > for one or more dist targets. > So you are demanding for even more bureaucracy and for more @RH deitism? > This would be truely silly. If packagers, who try to maintain a hundred packages, are concerned about artificial hurdles and "bureaucracy", it's not my role to disagree with them. Voice your concerns as much as you like. I expect a committee of Fedora leaders to influence [or decide on] the road to take. It is beyond my energy to fight endlessly and with continuing intensity. It's easier to reduce activity and wish them luck. With F9, for example, I asked myself "why spend any time at all on running repository checking tools if some issues, such as broken deps or conflicts, won't be fixed?" In many cases I'm willing to compromise. A new Fedora dist release is made every six months. That's a rather short period. I don't see what we win by skipping updates-testing. Give the community what it deserves. If there's not a single user who gives positive feedback about a new package [or a version upgrade], then why rush and skip updates-testing? You may be confident enough to perform the necessary testing yourself and take responsibility for breakage. You may be competent enough to publish sane updates only. You may be experienced enough to avoid poor mistakes. Still, there are other packagers who release broken updates or who don't understand how to fix them. What can be done to increase the quality of updates? Maybe it needs a privilege bit like "provenpackager" to skip updates-testing? I don't know. I just wish some people would be more conservative (or "shy") in what they choose to push to multiple dists without any testing. > As far as I am concerned, it's this freaking freeze and run-down shape > the fedora repso currently is in, which is causing the mess. In case it's not known, I've never backed up the post-Core freeze process. The long time of inactivity in Rawhide, the growing pile of pending updates, the massive amount of zero-day updates, and the increasing number of unknown broken deps in the uninstallable FN+1 Rawhide have confused me and caused me to raise an eyebrow. Something's wrong with how package developers follow Rawhide/Alpha/Beta (or the Test releases previously) and when/how they start to prepare their packages for the next Fedora while Rawhide is frozen. The thing simply is, in a community of volunteers (with some Fedora staff being paid by Red Hat and a muddy situation with Red Hat developers who happen to maintain Fedora packages) I don't see any organisational structures and hierarchies that would be possible in a company. I can't tell any other Fedora person to do this or that, and I don't want to deal with From oget.fedora at gmail.com Mon May 11 18:20:52 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Mon, 11 May 2009 14:20:52 -0400 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <20090511180045.GR3435@mcpierce-laptop.rdu.redhat.com> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08381D.5030604@freenet.de> <4A085DDB.101@redhat.com> <4A0860B3.5030802@freenet.de> <20090511180045.GR3435@mcpierce-laptop.rdu.redhat.com> Message-ID: On Mon, May 11, 2009 at 2:00 PM, Darryl L. Pierce wrote: > On Mon, May 11, 2009 at 07:30:27PM +0200, Ralf Corsepius wrote: >> Everything? Maybe it escapes you, but it's always the same issue: >> >> When "upstream" == "@RH", common sense and rationality seems to be >> switched off in Fedora. > > Red Hat's not upstream to Fedora. > > -- > Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. > Virtual Machine Management - http://www.ovirt.org/ > Is fearr Gaeilge bhriste n? B?arla cliste. > There are packages in Fedora where Redhat is the sole upstream. Some of these packages contain patches (yes, upstream uses patches on its own code) that aren't "fully suitable for upstream yet". The quotes are the words of the upstream, a.k.a. Redhat. Doesn't that make you feel like a guinea pig? Orcan From jkeating at redhat.com Mon May 11 18:22:03 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 May 2009 11:22:03 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: References: <1241718097.3209.11.camel@localhost.localdomain> <1241756375.3209.76.camel@localhost.localdomain> <4A03BB64.10006@freenet.de> <1241795563.3209.83.camel@localhost.localdomain> <4A04D350.1000904@freenet.de> <1241832771.2886.15.camel@localhost.localdomain> <4A04EAAE.50907@freenet.de> <1241836379.2886.30.camel@localhost.localdomain> <1242062337.3452.27.camel@localhost.localdomain> Message-ID: <1242066123.3452.34.camel@localhost.localdomain> On Mon, 2009-05-11 at 13:37 -0400, Colin Walters wrote: > Well, I see it as a well defined *targeted product* which happens to > be composed of packages. It's the base from which other things can be > installed from the Internet. What is the problem with "static pile of > packages"? (I have to admit to only skimming this thread) Updates to the previous release will quickly become N-V-R "newer" than the static pile of packages, which renders your upgrade a bit... odd. > > > Of course, the Live image > > doesn't necessarily have the upgrade problem we're talking about, > > because you can't use the live image to do an upgrade. Makes it less > > than useful for people. > > For upgrades we should be pushing people towards preupgrade. If > preupgrade works well, I'm having trouble thinking of scenarios in > which you'd end up with a physical image and want to do an upgrade. > Maybe if you're out of disk space you'd need physical media to > download the updates on to, but there's also no reason preupgrade > couldn't prompt you to insert a USB stick or blank CD. preupgrade requires a significant network cost. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mschwendt at gmail.com Mon May 11 18:27:27 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Mon, 11 May 2009 20:27:27 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <20090511202103.5b90f3b0@rawhide.intranet> References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241949557.3109.2.camel@localhost.localdomain> <20090510131115.226b27a5@faldor.intranet> <4A079B3B.20606@freenet.de> <20090511132526.3195dc37@rawhide.intranet> <4A084868.4040807@freenet.de> <20090511202103.5b90f3b0@rawhide.intranet> Message-ID: <20090511202727.63e46778@rawhide.intranet> Claws Mail truncated my reply. It's not the final draft either. The end and a couple of edits are missing. This was done on Fedora release 10.93 (Leonidas) - Linux 2.6.29.2-126.fc11.i586 while running yum update. From caillon at redhat.com Mon May 11 18:31:16 2009 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 11 May 2009 11:31:16 -0700 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A0814ED.60205@redhat.com> References: <4A0814ED.60205@redhat.com> Message-ID: <4A086EF4.8090109@redhat.com> On 05/11/2009 05:07 AM, Stephen Gallagher wrote: > I would understand if Firefox and Thunderbird were in their release > candidate phase, and we could reasonably expect that within three months > that they would hit final release. This was a strong part of my decision process. I cannot guarantee it, but I have very high confidence this will be the case for both (actually I was using a 2 month basis). So, it appears we're on the same page, you now understand, and we can drop this argument. I am sorry you're using extensions that don't have responsive maintainers to the bugs you've filed (you have filed bugs right?). I'd encourage you to contact them again, requesting that they update their extensions. It will benefit both parties. From caillon at redhat.com Mon May 11 18:34:54 2009 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 11 May 2009 11:34:54 -0700 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A0846FF.505@redhat.com> References: <4A0814ED.60205@redhat.com> <4A0845E8.2080805@codewiz.org> <4A0846FF.505@redhat.com> Message-ID: <4A086FCE.5070602@redhat.com> On 05/11/2009 08:40 AM, Stephen Gallagher wrote: > This brings up another excellent point. The beta releases of Firefox and > Thunderbird are released at a much slower rate than point releases of > the stable revisions. This means that a security issue in the beta may > go unpatched for a much longer period of time. I have been adding patches for security when needed in the past in rawhide. Why do you expect that to stop after F11 final is released? From skvidal at fedoraproject.org Mon May 11 18:35:40 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 11 May 2009 14:35:40 -0400 (EDT) Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A08381D.5030604@freenet.de> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08381D.5030604@freenet.de> Message-ID: On Mon, 11 May 2009, Ralf Corsepius wrote: > Seth Vidal wrote: >> >> >> On Mon, 11 May 2009, Michael Nielsen wrote: >> >>> Hi, >>> >>> I've been told this is the right place to place this debate starter. >> >> >> You were told incorrectly. >> >> I'm sure there is a place for this kind of debate but it is SURELY not the >> devel list. > @RH ignorance? > > If not here, where else to discuss a distro's long term development? but this isn't about the distro's long term development. It's a rant, a screed. It's a tirade. It's going to render zero positive results. how do I know this? B/c I can, in fact, see into the near future. Here's what I see - a 30-40 msg thread that has no signal and all noise. I'm not going to bother with the rest of this thread. I'm speaking here not as an employee at red hat but as an elected member of the fedora board. "This thread will bear no good results and I'm tired of everything being full of bile and vitriol" I won't be running for the fedora board in the next round of elections. You can run, Ralf. I hope you have great success tilting at windmills. -sv From cra at WPI.EDU Mon May 11 18:35:39 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 11 May 2009 14:35:39 -0400 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1242066123.3452.34.camel@localhost.localdomain> References: <4A03BB64.10006@freenet.de> <1241795563.3209.83.camel@localhost.localdomain> <4A04D350.1000904@freenet.de> <1241832771.2886.15.camel@localhost.localdomain> <4A04EAAE.50907@freenet.de> <1241836379.2886.30.camel@localhost.localdomain> <1242062337.3452.27.camel@localhost.localdomain> <1242066123.3452.34.camel@localhost.localdomain> Message-ID: <20090511183539.GV31498@angus.ind.WPI.EDU> On Mon, May 11, 2009 at 11:22:03AM -0700, Jesse Keating wrote: > On Mon, 2009-05-11 at 13:37 -0400, Colin Walters wrote: > > Well, I see it as a well defined *targeted product* which happens to > > be composed of packages. It's the base from which other things can be > > installed from the Internet. What is the problem with "static pile of > > packages"? (I have to admit to only skimming this thread) > > Updates to the previous release will quickly become N-V-R "newer" than > the static pile of packages, which renders your upgrade a bit... odd. Why do we not force updates to Fedora X to always be N-V-R older than Fedora X+1? We can use the Release tag to enforce this within a Version, and newer Versions shouldn't appear in older Fedora's until they've been in the newer Fedora first. From caillon at redhat.com Mon May 11 18:40:22 2009 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 11 May 2009 11:40:22 -0700 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A086B35.4060102@fedoraproject.org> References: <4A0814ED.60205@redhat.com> <4A086B35.4060102@fedoraproject.org> Message-ID: <4A087116.5050906@redhat.com> On 05/11/2009 11:15 AM, Rahul Sundaram wrote: > Even RHEL 5.3 included a "beta" release of Firefox, remember? 5.2 From mschwendt at gmail.com Mon May 11 18:42:39 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Mon, 11 May 2009 20:42:39 +0200 Subject: Build problems? In-Reply-To: <4A085F0D.5030109@freenet.de> References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241949557.3109.2.camel@localhost.localdomain> <20090511122057.02a66ba1@rawhide.intranet> <4A08491A.2000506@freenet.de> <20090511182425.1a5c18c4@rawhide.intranet> <4A085F0D.5030109@freenet.de> Message-ID: <20090511204239.6066ea17@rawhide.intranet> On Mon, 11 May 2009 19:23:25 +0200, Ralf wrote: > > What exactly is the problem? > > It's all f*cked up: > > * Fedora's default mock configurations don't reflect reality: > - They don't know anything about fc12 (n/a) > - FC10's mock builds i386 rpms instead of i586 for Fc11- > - mock doesn't handle rpm's md5/sha256 check-sums correctly (All versions). That's a pitty. Some of them can be found here: http://bugz.fedoraproject.org/mock From smooge at gmail.com Mon May 11 18:51:07 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 11 May 2009 12:51:07 -0600 Subject: SPARC Status (Was Re: Secondary Architecture Status?) In-Reply-To: References: <1241911202.24436.81.camel@macbook.infradead.org> <4A0862F1.2030608@redhat.com> Message-ID: <80d7e4090905111151r52549289odde91ef8794768c9@mail.gmail.com> On Mon, May 11, 2009 at 12:11 PM, Adam Miller wrote: > I completely agree with everything posted by Spot and I (nor I assume > anyone) am aware of what Oracle's game plan is but they have announced > that they are planning to put more money into SPARC. When dealing with anything with Oracle.. one has to look at where the money is. Oracle will say a lot of things but what they do will be what gets Larry Ellison another yacht. [I say this because this quote seems very close to their Oracle focusing on building its own browser, and other items]. My guess is that Oracle will focus on getting Fujitsu dealing with Sparc and working on Solaris for it. The operative quote on it is "[Apple and Cisco] enjoy very high-margins because they do a good job of designing their hardware and software to work together." I do not see this as a we will help Linux compete on it. > http://www.osnews.com/story/21458/Oracle_To_Invest_in_SPARC_Wants_to_Be_Like_Apple_Cisco > > This would be nice because we could (hopefully) see some SPARC > workstations come back into play allowing people to become interested > in and contribute to the project once more. Don't know that it would > give the architecture enough of a user base to make it an applicable > architecture again, but its at least something I think should be > watched as time goes on. > > -Adam > > > -- > http://maxamillion.googlepages.com > --------------------------------------------------------- > () ?ascii ribbon campaign - against html e-mail > /\ ?www.asciiribbon.org ? - against proprietary attachments > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From jwboyer at gmail.com Mon May 11 18:51:47 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 11 May 2009 14:51:47 -0400 Subject: SPARC Status (Was Re: Secondary Architecture Status?) In-Reply-To: References: <1241911202.24436.81.camel@macbook.infradead.org> <4A0862F1.2030608@redhat.com> Message-ID: <20090511185147.GA3256@yoda.jdub.homelinux.org> On Mon, May 11, 2009 at 01:11:25PM -0500, Adam Miller wrote: >I completely agree with everything posted by Spot and I (nor I assume >anyone) am aware of what Oracle's game plan is but they have announced >that they are planning to put more money into SPARC. > >http://www.osnews.com/story/21458/Oracle_To_Invest_in_SPARC_Wants_to_Be_Like_Apple_Cisco > >This would be nice because we could (hopefully) see some SPARC >workstations come back into play allowing people to become interested >in and contribute to the project once more. Don't know that it would >give the architecture enough of a user base to make it an applicable >architecture again, but its at least something I think should be >watched as time goes on. I very much doubt new SPARC workstations will happen. For a multitude of reasons, but primarily: 1) They will not be price competitive with their x86 counterparts 2) They will not have feature parity with their x86 counterparts because of 1. 3) The market for a non-x86 workstation is significantly tiny (and SPARC isn't exactly netbook friendly, so not really targetable there like ARM might be). I would really like to see a proliferation of secondary arches in Fedora, but I don't think 'workstation' is a viable usage model for them to get started. Most will have to focus on the type of hardware that actually sells for that arch, and yes I realize that can be at odds with some of the directions Fedora is going. josh From jkeating at redhat.com Mon May 11 18:57:34 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 May 2009 11:57:34 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <20090511183539.GV31498@angus.ind.WPI.EDU> References: <4A03BB64.10006@freenet.de> <1241795563.3209.83.camel@localhost.localdomain> <4A04D350.1000904@freenet.de> <1241832771.2886.15.camel@localhost.localdomain> <4A04EAAE.50907@freenet.de> <1241836379.2886.30.camel@localhost.localdomain> <1242062337.3452.27.camel@localhost.localdomain> <1242066123.3452.34.camel@localhost.localdomain> <20090511183539.GV31498@angus.ind.WPI.EDU> Message-ID: <1242068254.3452.36.camel@localhost.localdomain> On Mon, 2009-05-11 at 14:35 -0400, Chuck Anderson wrote: > Why do we not force updates to Fedora X to always be N-V-R older than > Fedora X+1? We can use the Release tag to enforce this within a > Version, and newer Versions shouldn't appear in older Fedora's until > they've been in the newer Fedora first. "until they've been in the newer Fedora first" doesn't work with the newer fedora release media is a static pile of packages. Your suggest would lead to not allowing F10's package versions to /ever/ be newer than what Fedora 11 ships with at GA. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mschwendt at gmail.com Mon May 11 19:00:49 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Mon, 11 May 2009 21:00:49 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: References: <1241718097.3209.11.camel@localhost.localdomain> <1241831621.2923.552.camel@adam.local.net> <4A04DD30.5010805@freenet.de> <1241833349.2923.555.camel@adam.local.net> <4A04F905.7020708@freenet.de> <4A07C0BC.40305@freenet.de> <20090511131259.22244f97@rawhide.intranet> <20090511181905.3ecc3cd6@rawhide.intranet> Message-ID: <20090511210049.67a31d6e@rawhide.intranet> On Mon, 11 May 2009 12:51:15 -0400, Orcan wrote: > On Mon, May 11, 2009 at 12:19 PM, Michael Schwendt wrote: > > On Mon, 11 May 2009 15:08:49 +0200, Kevin wrote: > > > > [buildroot overrides / directly pushing to stable] > > > >> It has also hit a few packages with Qt 4.5 in F9/F10 updates (even though I > >> did warn about this issue on fedora-devel-announce! So we also need to make > >> sure that people read those announcements before submitting builds!) > > > > Of course. People doing updates must be careful in general. If all > > ordinary updates were pushed to updates-testing first, this would reduce > > the breakage. > > > > Some packages pull ~200 other packages (on top of the minimal build > environment) through BR's during building. Do you really expect > packagers to check the versions of all packages being pulled and > compare them with the actual packages in the repos? What kind of question is that? I expect them to examine the update builds with tools like rpmdiff, to skim over the build log, and to install their own package releases and updates as soon as they appear in the updates-testing repo. And if that is asked for too much, I expect them to reduce the number of mass-updates that enter "stable" without community feedback. Don't you realise that the lower the number of version upgrades, the lower the risk of undetected breakage? Crucial changes enter a package with version upgrades (unless a package applies huge/many patches). Blindly pushing upstream's version upgrades bears a risk. Library SONAME changes, for example, cannot poison the buildroots unless a package is marked stable or gets tagged by releng. Buildroot stability reduces the potential for breakage. From pbrobinson at gmail.com Mon May 11 19:02:59 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 11 May 2009 20:02:59 +0100 Subject: SPARC Status (Was Re: Secondary Architecture Status?) In-Reply-To: <20090511185147.GA3256@yoda.jdub.homelinux.org> References: <1241911202.24436.81.camel@macbook.infradead.org> <4A0862F1.2030608@redhat.com> <20090511185147.GA3256@yoda.jdub.homelinux.org> Message-ID: <5256d0b0905111202x2df6b773y689fe618b502315c@mail.gmail.com> > I would really like to see a proliferation of secondary arches in > Fedora, but I don't think 'workstation' is a viable usage model for > them to get started. ?Most will have to focus on the type of hardware > that actually sells for that arch, and yes I realize that can be at > odds with some of the directions Fedora is going. I think there are most likely two candidates for a secondary arch other than PPC. The first is sparc where from the server point of view where its probably about as prolific as PPC in that regard. The second would be arm but that is more from the NetBook/MID/Phone/STB perspective where there are quite a few devices in the 500Mhz-1Ghz range with 256-512Mb RAM. With the OLPC X0-1 we've proven that Fedora can run relatively well on that sort of spec, they also tend to be relatively cheap. Peter From cra at WPI.EDU Mon May 11 19:04:16 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 11 May 2009 15:04:16 -0400 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1242068254.3452.36.camel@localhost.localdomain> References: <4A04D350.1000904@freenet.de> <1241832771.2886.15.camel@localhost.localdomain> <4A04EAAE.50907@freenet.de> <1241836379.2886.30.camel@localhost.localdomain> <1242062337.3452.27.camel@localhost.localdomain> <1242066123.3452.34.camel@localhost.localdomain> <20090511183539.GV31498@angus.ind.WPI.EDU> <1242068254.3452.36.camel@localhost.localdomain> Message-ID: <20090511190415.GW31498@angus.ind.WPI.EDU> On Mon, May 11, 2009 at 11:57:34AM -0700, Jesse Keating wrote: > On Mon, 2009-05-11 at 14:35 -0400, Chuck Anderson wrote: > > Why do we not force updates to Fedora X to always be N-V-R older than > > Fedora X+1? We can use the Release tag to enforce this within a > > Version, and newer Versions shouldn't appear in older Fedora's until > > they've been in the newer Fedora first. > > "until they've been in the newer Fedora first" doesn't work with the > newer fedora release media is a static pile of packages. > > Your suggest would lead to not allowing F10's package versions to /ever/ > be newer than what Fedora 11 ships with at GA. I guess epochs are the only way to solve that then. From loganjerry at gmail.com Mon May 11 19:05:31 2009 From: loganjerry at gmail.com (Jerry James) Date: Mon, 11 May 2009 13:05:31 -0600 Subject: Fedora (Linux) is Destroying it self In-Reply-To: References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08381D.5030604@freenet.de> Message-ID: <870180fe0905111205x37683fa5gb246bab58a5c02a1@mail.gmail.com> On Mon, May 11, 2009 at 12:35 PM, Seth Vidal wrote: > "This thread will bear no good results and I'm tired of everything being full of bile and vitriol" Part of the problem may be that people who are happy have no trigger that fires to tell them, "I should post a message about how happy I am!" So you wind up with lots of threads started by unhappy people. Let me tell you how happy I am. I switched from Slackware to RedHat Linux during the RedHat 4.3 era. I followed every upgrade up through RedHat 9, and then switched over to Fedora. I've had every Fedora release since installed on one machine or another. Yes, there have been some problems, but I bugzilla them and they get fixed eventually. In the meantime, I get what attracted me in the first place: the most up-to-date applications and drivers available for Linux. With Slackware, I was constantly cursing the fact that I needed feature X available in version Y of application Z, but Slackware only gave me version W < Y. I've been much happier with RedHat, and now Fedora. Things have been even better since Ville talked me into donating my private stash of RPMs to Fedora. Now other people get to take advantage of the packaging work I did, and the upstreams benefit from having more users using their code [1]. Life is good. > I won't be running for the fedora board in the next round of elections. You can run, Ralf. I hope you have great success tilting at windmills. Because of the negativity, or for other reasons? I've mostly stayed on the sidelines in the great debates that have taken place on this list. Speaking from that position, I'll say that I have recognized a small set of people whom I can count on to whine on a regular basis. Those people are only hurting their own reputations. I know who they are, and I have no respect for them at all. If one of them were to run for something, I would immediately find ANYONE else to vote for. I want people who jump in and fix things running the show, not whiners. Long live the meritocracy! Footnotes: [1] Except that I *still* have a large number of packages waiting for me to submit. If anyone sees something on [2] that you just have to have in Fedora, let me know and I'll bump its priority up [3]. [2] http://jjames.fedorapeople.org/ [3] Actually, what is mostly holding me up is finding time to review other people's packages, so I don't wind up with negative karma. I think I'm a more efficient packager than I am a package reviewer, but that probably just means that I need more practice at the latter. -- Jerry James, who did too much Usenet in the 90s http://www.jamezone.org/ From kevin.kofler at chello.at Mon May 11 19:12:38 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 11 May 2009 21:12:38 +0200 Subject: 182 pending F11 stable updates. WTF? References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <200905081059.20191.mhlavink@redhat.com> <1241795878.3209.88.camel@localhost.localdomain> <20090508153102.GA15821@bludgeon.org> <1241798647.3209.95.camel@localhost.localdomain> <4A04D59A.20006@freenet.de> <1241831621.2923.552.camel@adam.local.net> <4A04DD30.5010805@freenet.de> <1241833349.2923.555.camel@adam.local.net> <4A04F905.7020708@freenet.de> <4A07C0BC.40305@freenet.de> <20090511131259.22244f97@rawhide.intranet> <20090511181905.3ecc3cd6@rawhide.intranet> <1242059850.3452.23.camel@localhost.localdomain> Message-ID: Jesse Keating wrote: > I'd really like to know what people's thoughts are on making the > overrides more known. One problem we have with them as well is that > maintainers don't let us know when the build is done, so that we can > remove the override to prevent poisoning further builds. Well, in cases like kdelibs, building all of KDE can take a couple days, and the builds all need the new kdelibs in the buildroot override. We also need the buildroot override if we add fixes to the testing updates. So cleaning up the buildroot after the builds completed is easier said than done. Kevin Kofler From craftjml at gmail.com Mon May 11 19:18:59 2009 From: craftjml at gmail.com (Jud Craft) Date: Mon, 11 May 2009 14:18:59 -0500 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1242068254.3452.36.camel@localhost.localdomain> References: <4A03BB64.10006@freenet.de> <1241832771.2886.15.camel@localhost.localdomain> <4A04EAAE.50907@freenet.de> <1241836379.2886.30.camel@localhost.localdomain> <1242062337.3452.27.camel@localhost.localdomain> <1242066123.3452.34.camel@localhost.localdomain> <20090511183539.GV31498@angus.ind.WPI.EDU> <1242068254.3452.36.camel@localhost.localdomain> Message-ID: <20d6441a0905111218q36cbfebbs6997631e8c8251e3@mail.gmail.com> On Mon, May 11, 2009 at 1:57 PM, Jesse Keating wrote: > On Mon, 2009-05-11 at 14:35 -0400, Chuck Anderson wrote: >> Why do we not force updates to Fedora X to always be N-V-R older than >> Fedora X+1? ?We can use the Release tag to enforce this within a >> Version, and newer Versions shouldn't appear in older Fedora's until >> they've been in the newer Fedora first. > > Your suggest would lead to not allowing F10's package versions to /ever/ > be newer than what Fedora 11 ships with at GA. > Question! Why not force them to be "N-V" older, then? Wouldn't that still allow for security updates? (I assumed security updates were the minor-point-number -R packages). So in essence, the F9 packages are set in stone when F10 is released, except for minor patches. No new versions. From sundaram at fedoraproject.org Mon May 11 19:24:24 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 12 May 2009 00:54:24 +0530 Subject: yum-presto installed by default for Fedora 11? Message-ID: <4A087B68.4060208@fedoraproject.org> Hi, Is the yum plugin going to be installed by default in Fedora 11? The feature page says, no but I wanted to confirm this since there been a number of changes back and forth related to delta rpms Rahul From pbrobinson at gmail.com Mon May 11 19:21:08 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 11 May 2009 20:21:08 +0100 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1242059850.3452.23.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <4A04DD30.5010805@freenet.de> <1241833349.2923.555.camel@adam.local.net> <4A04F905.7020708@freenet.de> <4A07C0BC.40305@freenet.de> <20090511131259.22244f97@rawhide.intranet> <20090511181905.3ecc3cd6@rawhide.intranet> <1242059850.3452.23.camel@localhost.localdomain> Message-ID: <5256d0b0905111221u2821f2ecld8ce711a43ab64c0@mail.gmail.com> >> Secret/silent buildroot overrides bear a risk. It's a potential race >> condition for everyone who is not aware of such overrides. >> >> For example, one can't expect a new package contributor, who may be >> working on his first Fedora package, to know about buildroot overrides in >> koji that may be active while building and preparing an update for bodhi. >> >> Security/emergency-fixes are also affected by buildroot overrides. > > I'd really like to know what people's thoughts are on making the > overrides more known. ?One problem we have with them as well is that > maintainers don't let us know when the build is done, so that we can > remove the override to prevent poisoning further builds. I wasn't even aware that we were suppose to notify when we no longer needed the build overrides. Maybe the eng ticket should remain open once the override has been done and only closed once the override is removed with a generic note from rel-eng. Peter From dr.diesel at gmail.com Mon May 11 19:23:14 2009 From: dr.diesel at gmail.com (Dr. Diesel) Date: Mon, 11 May 2009 14:23:14 -0500 Subject: yum-presto installed by default for Fedora 11? In-Reply-To: <4A087B68.4060208@fedoraproject.org> References: <4A087B68.4060208@fedoraproject.org> Message-ID: <2a28d2ab0905111223g4f7b3541kf57b98fa363e2e18@mail.gmail.com> On Mon, May 11, 2009 at 2:24 PM, Rahul Sundaram wrote: > Hi, > > Is the yum plugin going to be installed by default in Fedora 11? The > feature page says, no but I wanted to confirm this since there been a > number of changes back and forth related to delta rpms > > Rahul This change has to many positives and most won't even know it is there. Let's enable it and work through the issues! << Probably the wrong attitude but.... -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschwendt at gmail.com Mon May 11 19:25:25 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Mon, 11 May 2009 21:25:25 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1242059850.3452.23.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <200905081059.20191.mhlavink@redhat.com> <1241795878.3209.88.camel@localhost.localdomain> <20090508153102.GA15821@bludgeon.org> <1241798647.3209.95.camel@localhost.localdomain> <4A04D59A.20006@freenet.de> <1241831621.2923.552.camel@adam.local.net> <4A04DD30.5010805@freenet.de> <1241833349.2923.555.camel@adam.local.net> <4A04F905.7020708@freenet.de> <4A07C0BC.40305@freenet.de> <20090511131259.22244f97@rawhide.intranet> <20090511181905.3ecc3cd6@rawhide.intranet> <1242059850.3452.23.camel@localhost.localdomain> Message-ID: <20090511212525.333f7480@rawhide.intranet> On Mon, 11 May 2009 09:37:30 -0700, Jesse wrote: > I'd really like to know what people's thoughts are on making the > overrides more known. One problem we have with them as well is that > maintainers don't let us know when the build is done, so that we can > remove the override to prevent poisoning further builds. How does it help? For example, you tag a library pkg that bumps a SONAME, then you can rebuild deps against the new SONAME, and when done you want to untag the lib, so any other packager would build against the old SONAME again? What am I missing? You need the buildroot override tags to rebuild deps. Releasing builds into updates-testing would give time to detect broken deps. Currently. Skipping updates-testing would remove that chance. As soon as somebody requests to override the buildroots, there must be a complete plan on whether it will be possible to prepare updates for *all* deps (isn't it true that most problems originate in upgrades which require a chain of upgrades of deps?). Or else you need something like "atomic buildroot override build-jobs". Which either build in an isolated modified buildroot. Or which lock down the normal buildroot, so only a specific set of packages as requested by a packager may be rebuilt against temporary buildroot modifications. From skvidal at fedoraproject.org Mon May 11 19:25:40 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 11 May 2009 15:25:40 -0400 (EDT) Subject: yum-presto installed by default for Fedora 11? In-Reply-To: <4A087B68.4060208@fedoraproject.org> References: <4A087B68.4060208@fedoraproject.org> Message-ID: On Tue, 12 May 2009, Rahul Sundaram wrote: > Hi, > > Is the yum plugin going to be installed by default in Fedora 11? The > feature page says, no but I wanted to confirm this since there been a > number of changes back and forth related to delta rpms > No change in that status. The presto plugin will not be installed by default. installing it is the only step necessary to enabling presto support, though. -sv From skvidal at fedoraproject.org Mon May 11 19:26:48 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 11 May 2009 15:26:48 -0400 (EDT) Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <20d6441a0905111218q36cbfebbs6997631e8c8251e3@mail.gmail.com> References: <4A03BB64.10006@freenet.de> <1241832771.2886.15.camel@localhost.localdomain> <4A04EAAE.50907@freenet.de> <1241836379.2886.30.camel@localhost.localdomain> <1242062337.3452.27.camel@localhost.localdomain> <1242066123.3452.34.camel@localhost.localdomain> <20090511183539.GV31498@angus.ind.WPI.EDU> <1242068254.3452.36.camel@localhost.localdomain> <20d6441a0905111218q36cbfebbs6997631e8c8251e3@mail.gmail.com> Message-ID: On Mon, 11 May 2009, Jud Craft wrote: > On Mon, May 11, 2009 at 1:57 PM, Jesse Keating wrote: >> On Mon, 2009-05-11 at 14:35 -0400, Chuck Anderson wrote: >>> Why do we not force updates to Fedora X to always be N-V-R older than >>> Fedora X+1? ?We can use the Release tag to enforce this within a >>> Version, and newer Versions shouldn't appear in older Fedora's until >>> they've been in the newer Fedora first. >> >> Your suggest would lead to not allowing F10's package versions to /ever/ >> be newer than what Fedora 11 ships with at GA. >> > > Question! > > Why not force them to be "N-V" older, then? Wouldn't that still allow > for security updates? (I assumed security updates were the > minor-point-number -R packages). > > So in essence, the F9 packages are set in stone when F10 is released, > except for minor patches. No new versions. Security patches are not uncommonly just patches and therefore just a release update. -sv From jonstanley at gmail.com Mon May 11 19:29:04 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Mon, 11 May 2009 15:29:04 -0400 Subject: FESco meeting summary for 20090507 In-Reply-To: <1242064921.2510.119.camel@localhost.localdomain> References: <2d319b780905100914n442e2501h78b2184437a67065@mail.gmail.com> <1242064921.2510.119.camel@localhost.localdomain> Message-ID: On Mon, May 11, 2009 at 2:02 PM, Callum Lerwick wrote: > Yes, Smolt's CPU stats are mostly useless. What it *needs* to do is > collect up everyone's cpuinfo flags: Ever since this ticket came up, I've been working on a smolt patch in my spare time to do exactly this. Unfortunately, I'm moving in 3 weeks, so time is something that's been in somewhat short supply recently :) From kevin.kofler at chello.at Mon May 11 19:31:31 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 11 May 2009 21:31:31 +0200 Subject: 182 pending F11 stable updates. WTF? References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241949557.3109.2.camel@localhost.localdomain> <20090510131115.226b27a5@faldor.intranet> <4A079B3B.20606@freenet.de> <20090511132526.3195dc37@rawhide.intranet> <4A084868.4040807@freenet.de> <20090511202103.5b90f3b0@rawhide.intranet> Message-ID: Michael Schwendt wrote: > On Mon, 11 May 2009 17:46:48 +0200, Ralf wrote: > >> * Fact also is: "Testing" occasionally is the cause of broken package >> deps. > > How? Or, what do you mean? One example is Qt 4.5: it was in the buildroot, but only in testing, so stuff which got moved to stable before Qt 4.5 was was broken. But that doesn't mean testing should not exist, we kept Qt 4.5 in testing that long for a reason (actually several ones, there were a few regressions we had to fix). Kevin Kofler From kevin.kofler at chello.at Mon May 11 19:34:17 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 11 May 2009 21:34:17 +0200 Subject: 182 pending F11 stable updates. WTF? References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241949557.3109.2.camel@localhost.localdomain> <20090511122057.02a66ba1@rawhide.intranet> <4A08491A.2000506@freenet.de> Message-ID: Ralf Corsepius wrote: > Then you're more lucky then I am. I am trying to push a chain of > packages updates/upgrades, but I am stuck in a cobweb of broken, > inconsistent repos and mock setups, which allows me to push untested > packages, but doesn't allow me to build them locally. Mock configs indeed do not reflect buildroot overrides. The fix there is to have a local repo with the overrides, or to just build things in Koji and download them from there to test them. Boycotting buildroot overrides doesn't fix anything. Kevin Kofler From benny+usenet at amorsen.dk Mon May 11 19:35:49 2009 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Mon, 11 May 2009 21:35:49 +0200 Subject: Another update, another reboot, no sound! In-Reply-To: (Peter Lemenkov's message of "Fri\, 8 May 2009 23\:17\:16 +0400") References: <1241728409.7634.21.camel@dimi.lattica.com> <1241806776.2923.513.camel@adam.local.net> <1241809450.7634.70.camel@dimi.lattica.com> Message-ID: Peter Lemenkov writes: > It seems, that it affects only those poor guys, who are pointlessly > trying to use pulseaudio. Everyone knows that PA is doomed, and that's > why nobody cares. Killing pulseaudio won't fix the problems that pulseaudio try to solve. For one thing, applications sharing the same output device need SOME kind of daemon running, since ALSA (for good reasons) won't do mixing in the driver. /Benny From seg at haxxed.com Mon May 11 19:38:28 2009 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 11 May 2009 14:38:28 -0500 Subject: FESco meeting summary for 20090507 In-Reply-To: <1242062320.2923.586.camel@adam.local.net> References: <1242062320.2923.586.camel@adam.local.net> Message-ID: <1242070708.2510.122.camel@localhost.localdomain> On Mon, 2009-05-11 at 10:18 -0700, Adam Williamson wrote: > wine has never had a decent x86-64 port, and still doesn't. Being 32-bit is kind of fundamental to the way Wine works. That's not going to change. The windows world is still mostly stuck in 32-bit land. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dr.diesel at gmail.com Mon May 11 19:29:28 2009 From: dr.diesel at gmail.com (Dr. Diesel) Date: Mon, 11 May 2009 14:29:28 -0500 Subject: yum-presto installed by default for Fedora 11? In-Reply-To: References: <4A087B68.4060208@fedoraproject.org> Message-ID: <2a28d2ab0905111229r5d732055o247dfd4a31fd8222@mail.gmail.com> On Mon, May 11, 2009 at 2:25 PM, Seth Vidal wrote: > > > On Tue, 12 May 2009, Rahul Sundaram wrote: > > Hi, >> >> Is the yum plugin going to be installed by default in Fedora 11? The >> feature page says, no but I wanted to confirm this since there been a >> number of changes back and forth related to delta rpms >> >> > No change in that status. The presto plugin will not be installed by > default. > > installing it is the only step necessary to enabling presto support, > though. > > -sv Because of limited testing or some other limitation/factor? -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From awilliam at redhat.com Mon May 11 19:48:16 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 11 May 2009 12:48:16 -0700 Subject: FESco meeting summary for 20090507 In-Reply-To: <6764.1242064296@sss.pgh.pa.us> References: <1242062320.2923.586.camel@adam.local.net> <6764.1242064296@sss.pgh.pa.us> Message-ID: <1242071296.2923.654.camel@adam.local.net> On Mon, 2009-05-11 at 13:51 -0400, Tom Lane wrote: > Adam Williamson writes: > > On Sun, 2009-05-10 at 18:28 +0200, drago01 wrote: > >> The only reason people prefer to run i686 even on x86_64 is because > >> "apps do not work", which is nothing but a myth. > > > It's not a myth, but it's now (only quite recently) mostly outdated. > > True. > > > Those were the major issues. OO.o and Java are fixed and Flash is mostly > > fixed, but wine is still valid. > > Java is still a huge mess; there are any number of webapps that just > plain don't work in 64-bit. (I'm not sure this is Java's fault per se, > but the fact remains that things don't work and the authors seem content > to tell you to install a 32-bit browser instead of fixing their broken > code...) Hmm, that's nasty. I hadn't personally run across any of those yet, which is I guess why I didn't know about it. Thanks for the info. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From kevin.kofler at chello.at Mon May 11 19:47:50 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 11 May 2009 21:47:50 +0200 Subject: OpenOffice 3.1 References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <1241990992.3452.6.camel@localhost.localdomain> <6dc6523c0905101458l64811e65lb9f18216a4f93941@mail.gmail.com> <1242064968.2923.615.camel@adam.local.net> Message-ID: Adam Williamson wrote: > I know this is a good system because I was around for the previous > system (a messy compromise rather like the current Fedora system), which > everyone hated - developers didn't know what to ship where, users didn't > know what to expect. The current system is great: developers understand > it and have the flexibility to ship the type of updates they want (they > can choose to ignore /backports entirely and only ship stable updates, > or they can use it extensively and provide, say, a whole new version of > KDE), So there's still the same inconsistency we're having in Fedora too (and having "backports" not enabled by default also encourages laziness, i.e. ignoring it entirely; IMHO disabling "backports" by default is also a disservice to users, who don't get the latest bug fixes). > users understand it and have the flexibility to choose exactly > what type of updates they want (/updates only for a quiet life, specific > packages from /backports if you just need some particular new feature, > or everything from /backports if you like surprises). Significantly, > there have been exactly no major arguments like this present one ever > since the system was changed, whereas bitching and arguing over the > previous system was frequent on both the 'user' and 'developer' sides. A big problem with having separate "updates" and "backports" is that we'd have twice as many branches to maintain, "updates" for every Fedora release with only the stuff which is arbitrarily defined to be acceptable there and "backports" with the current upstream releases. KDE SIG and several other maintainers or teams are already overworked, doubling our workload (for everything except Rawhide, but if Ralf's "rawhide-testing" idea gets implemented, we might end up with doubled workload there too!) isn't going to help at all! IMHO "backports" are a half-baked workaround for inflexible upgrading policies and generate unneccessary maintainer workload and a poor user experience (especially if they're labeled "unsupported" as e.g. Ubuntu is doing, I'm not sure how Mandriva handles it). The only kind of "backports" repository I could envision is for packages which DON'T make sense to ship as stable updates, e.g. major bumps like Amarok 1->2 in F9, i.e. the kind of stuff we're shipping in kde-redhat unstable and other similar repositories. But it should not be the norm for all new versions (and mixing minor bumps like KDE 4.0->4.1->4.2 with major changes like Amarok 1->2 in a single repository would also significantly degrade the user experience ? this is another problem I've seen with "backports" repositories, they encourage throwing in risky or even unstable (e.g. KOffice 2) updates together with riskless ones like even bugfix releases of KDE (e.g. 4.1.2->4.1.3) in the same repository). Kevin Kofler From denis at poolshark.org Mon May 11 19:50:56 2009 From: denis at poolshark.org (Denis Leroy) Date: Mon, 11 May 2009 21:50:56 +0200 Subject: SPARC Status (Was Re: Secondary Architecture Status?) In-Reply-To: <4A0862F1.2030608@redhat.com> References: <1241911202.24436.81.camel@macbook.infradead.org> <4A0862F1.2030608@redhat.com> Message-ID: <4A0881A0.8080506@poolshark.org> On 05/11/2009 07:40 PM, Tom "spot" Callaway wrote: > Not to mention that Sun is about > to get swallowed up by Oracle, who I doubt will be overly concerned > about Linux/SPARC, so it is even less likely that we will see additional > code help or community involvement from them (as a contrast to IBM on > PPC/S390). It's still too early to say how the acquisition is going to affect that effort, to be honest. Do you have any Sun contributors today to Fedora Linux/SPARC ? Most of the SPARC people you run into at Sun tend to be Solaris old-school fanatics (and vice-versa)... From kevin.kofler at chello.at Mon May 11 19:49:19 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 11 May 2009 21:49:19 +0200 Subject: OpenOffice 3.1 References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <1241998651.2760.9.camel@moose> <1242002755.2760.23.camel@moose> Message-ID: Pavel Alexeev (aka Pahan-Hubbitus) wrote: > Ho-ho!!! I have exactly same situation: My wife always disagree with my > updates and experiments. All what she need - "It warks, please do not > touch it". And, I can say confidently - all questions was gone when I > leave her notebook! For few times when I use it I install second, fully > independent copy of new release Fedora 11 from alpha, and leave Fodora 8 > unchanged. All happy. That F8 installation will indeed not get updated at all because there are no more updates for F8... But this also means it doesn't get any security updates! IMHO it's completely unresponsible to keep her on F8, the system must be upgraded to a supported version! Kevin Kofler From skvidal at fedoraproject.org Mon May 11 19:51:58 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 11 May 2009 15:51:58 -0400 (EDT) Subject: yum-presto installed by default for Fedora 11? In-Reply-To: <2a28d2ab0905111229r5d732055o247dfd4a31fd8222@mail.gmail.com> References: <4A087B68.4060208@fedoraproject.org> <2a28d2ab0905111229r5d732055o247dfd4a31fd8222@mail.gmail.com> Message-ID: On Mon, 11 May 2009, Dr. Diesel wrote: > ? > > Because of limited testing or some other limitation/factor? > > Somewhat, yes. We wanted to be sure that we wouldn't be shipping something out that would break everyone's updates/installs. And we were not completely sure. Considering how critical a component yum is we decided to punt on making it default. -sv From awilliam at redhat.com Mon May 11 19:55:24 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 11 May 2009 12:55:24 -0700 Subject: SPARC Status (Was Re: Secondary Architecture Status?) In-Reply-To: <20090511185147.GA3256@yoda.jdub.homelinux.org> References: <1241911202.24436.81.camel@macbook.infradead.org> <4A0862F1.2030608@redhat.com> <20090511185147.GA3256@yoda.jdub.homelinux.org> Message-ID: <1242071724.2923.656.camel@adam.local.net> On Mon, 2009-05-11 at 14:51 -0400, Josh Boyer wrote: > I would really like to see a proliferation of secondary arches in > Fedora, but I don't think 'workstation' is a viable usage model for > them to get started. Most will have to focus on the type of hardware > that actually sells for that arch, and yes I realize that can be at > odds with some of the directions Fedora is going. Semi-sidetrack here: Ubuntu has a secondary 'architecture' called LPIA which is, in fact, just an alternative set of compiler optimizations which they claim results in better code for 'netbook systems' (presumably meaning 'Atom CPUs'). Would that be something we could look into, or not interesting? Reference: http://lwn.net/Articles/247003/ -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From jkeating at redhat.com Mon May 11 19:57:32 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 May 2009 12:57:32 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241949557.3109.2.camel@localhost.localdomain> <20090511122057.02a66ba1@rawhide.intranet> <4A08491A.2000506@freenet.de> Message-ID: <1242071852.3452.39.camel@localhost.localdomain> On Mon, 2009-05-11 at 21:34 +0200, Kevin Kofler wrote: > Mock configs indeed do not reflect buildroot overrides. The fix there is to > have a local repo with the overrides, or to just build things in Koji and > download them from there to test them. Boycotting buildroot overrides > doesn't fix anything. Or use the unmirrored koji repos that we kind of expose. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bjorn at xn--rombobjrn-67a.se Mon May 11 19:59:08 2009 From: bjorn at xn--rombobjrn-67a.se (=?utf-8?q?Bj=C3=B6rn_Persson?=) Date: Mon, 11 May 2009 21:59:08 +0200 Subject: FESco meeting summary for 20090507 In-Reply-To: References: <200905110014.50581.bjorn@xn--rombobjrn-67a.se> Message-ID: <200905112159.08449.bjorn@xn--rombobjrn-67a.se> Kevin Kofler wrote: > Bj?rn Persson wrote: > > http://www.dustin.se/productdetails.aspx?prodid=5010198913 > > That one uses the Atom 330, which does support 64-bit (though there's at > least one report of 2.6.27 kernels not working in 64-bit mode on it, you > apparently need 2.6.29). The netbook Atoms don't, the desktop ones do. Oh! I assumed that all Atoms were 32-bit. I *should* know by now that there is no correlation between marketing names and hardware capabilities. Then I give you instead this Mini-ITX board with a Geode LX 800 processor, which is compatible with x86 but not x86_64: http://www.alix-board.de/produkte/alix1d.html Bj?rn Persson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From jkeating at redhat.com Mon May 11 20:03:19 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 May 2009 13:03:19 -0700 Subject: OpenOffice 3.1 In-Reply-To: References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <1241990992.3452.6.camel@localhost.localdomain> <6dc6523c0905101458l64811e65lb9f18216a4f93941@mail.gmail.com> <1242064968.2923.615.camel@adam.local.net> Message-ID: <1242072199.3452.40.camel@localhost.localdomain> On Mon, 2009-05-11 at 21:47 +0200, Kevin Kofler wrote: > The only kind of "backports" repository I could envision is for packages > which DON'T make sense to ship as stable updates, e.g. major bumps like > Amarok 1->2 in F9, i.e. the kind of stuff we're shipping in kde-redhat > unstable and other similar repositories. But it should not be the norm for > all new versions (and mixing minor bumps like KDE 4.0->4.1->4.2 with major > changes like Amarok 1->2 in a single repository would also significantly > degrade the user experience ? this is another problem I've seen > with "backports" repositories, they encourage throwing in risky or even > unstable (e.g. KOffice 2) updates together with riskless ones like even > bugfix releases of KDE (e.g. 4.1.2->4.1.3) in the same repository). Yeah, the kde-redhat type thing could be solved with Koji Personal Repos if I ever get the time to work on that. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From seandarcy2 at gmail.com Mon May 11 20:11:32 2009 From: seandarcy2 at gmail.com (sean darcy) Date: Mon, 11 May 2009 16:11:32 -0400 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A0814ED.60205@redhat.com> References: <4A0814ED.60205@redhat.com> Message-ID: Stephen Gallagher wrote: > OK, first off, why in $DEITY's name are we including Firefox 3.5b4 and > Thunderbird 3.0b2 in Fedora 11? These are unstable branches of the > browser and email client, and as such are supported by almost none of > the myriad of extensions available for the 3.0 and 2.0 versions, > respectively. > > I was more than a little disappointed when I upgraded my laptop to the > F11 Preview to discover that only two out of seven of my Thunderbird > extensions and three of my thirteen Firefox extensions remained functional. > > I understand that Fedora is a development OS, and I think it's a great > idea to have a firefox35 package and a thunderbird30 package, but these > SHOULD NOT be the defaults. > > Taking away the full functionality of a developer's web browser and > email client is an incredible step backwards for Fedora 11. The default > install of Fedora 11 should include the latest STABLE versions of > Firefox and Thunderbird, and then provide an OPTION to replace them with > the unstable development branch. > > I would understand if Firefox and Thunderbird were in their release > candidate phase, and we could reasonably expect that within three months > that they would hit final release. Firefox has no definitive (or even > approximate) release date scheduled, and Thunderbird is only in its > second beta. There is little-to-no guarantee that either of these > products will be deemed stable before Fedora 12, and I think it is a > severe mistake to make them the default before then. > > If nothing else, consider this an open request to the Firefox, > Thunderbird and Lightning maintainers to provide a compatibility package > that can downgrade and replace the unstable and non-extensible versions > currently in the distribution. > > FWIW, I agree, at least with respect to TB. I downgraded to 2.0.0.21, which required a rebuild with some hackery for gcc-4.4 issues. With 3.x, I couldn't send mail ( reply or write ) to newsgroups, including this one. With just downgrading - exactly the same setup - it works. See https://bugzilla.redhat.com/show_bug.cgi?id=493738 sean From sanjay.ankur at gmail.com Mon May 11 20:14:43 2009 From: sanjay.ankur at gmail.com (Ankur Sinha) Date: Tue, 12 May 2009 01:44:43 +0530 Subject: yum-presto installed by default for Fedora 11? In-Reply-To: References: <4A087B68.4060208@fedoraproject.org> <2a28d2ab0905111229r5d732055o247dfd4a31fd8222@mail.gmail.com> Message-ID: <1242072883.3331.41.camel@localhost.localdomain> On Mon, 2009-05-11 at 15:51 -0400, Seth Vidal wrote: > > On Mon, 11 May 2009, Dr. Diesel wrote: > > > > > > > Because of limited testing or some other limitation/factor? > > > > > > Somewhat, yes. We wanted to be sure that we wouldn't be shipping something > out that would break everyone's updates/installs. > > And we were not completely sure. > > Considering how critical a component yum is we decided to punt on making > it default. > > -sv > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list hi, Can we help test it? Has there been such a test day or something of the sort yet?? regards, Ankur From awilliam at redhat.com Mon May 11 20:14:25 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 11 May 2009 13:14:25 -0700 Subject: OpenOffice 3.1 In-Reply-To: References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <1241990992.3452.6.camel@localhost.localdomain> <6dc6523c0905101458l64811e65lb9f18216a4f93941@mail.gmail.com> <1242064968.2923.615.camel@adam.local.net> Message-ID: <1242072865.2923.670.camel@adam.local.net> On Mon, 2009-05-11 at 21:47 +0200, Kevin Kofler wrote: > Adam Williamson wrote: > > I know this is a good system because I was around for the previous > > system (a messy compromise rather like the current Fedora system), which > > everyone hated - developers didn't know what to ship where, users didn't > > know what to expect. The current system is great: developers understand > > it and have the flexibility to ship the type of updates they want (they > > can choose to ignore /backports entirely and only ship stable updates, > > or they can use it extensively and provide, say, a whole new version of > > KDE), > > So there's still the same inconsistency we're having in Fedora too (and > having "backports" not enabled by default also encourages laziness, i.e. > ignoring it entirely; IMHO disabling "backports" by default is also a > disservice to users, who don't get the latest bug fixes). The fundamental point here is that most end users want stable systems. So you have to provide a set of stable updates and *only* stable updates. Some distros do only this - Ubuntu, for e.g. - and leave the more adventurous stuff to messy alternatives (PPAs, the sparsely used semi-official 'backports' repository for Ubuntu, random repositories set up by random people on random pages somewhere). How MDV got to where it is is basically that it started by only producing stable updates, then realized there was enough of a demand for adventurous updates that an outlet for those should be provided somehow. I think the two-tier, adventurous updates disabled by default setup is the best compromise anyone's come up with yet, *for the case where a stable update set is considered important* (i.e. we actually care about Aunt Flo). I can see your theoretical point about backports being ignored, but in practice - for whatever reason - it isn't the case. the repository is heavily used by both maintainers and users. > > users understand it and have the flexibility to choose exactly > > what type of updates they want (/updates only for a quiet life, specific > > packages from /backports if you just need some particular new feature, > > or everything from /backports if you like surprises). Significantly, > > there have been exactly no major arguments like this present one ever > > since the system was changed, whereas bitching and arguing over the > > previous system was frequent on both the 'user' and 'developer' sides. > > A big problem with having separate "updates" and "backports" is that we'd > have twice as many branches to maintain, "updates" for every Fedora release > with only the stuff which is arbitrarily defined to be acceptable there > and "backports" with the current upstream releases. KDE SIG and several > other maintainers or teams are already overworked, doubling our workload > (for everything except Rawhide, but if Ralf's "rawhide-testing" idea gets > implemented, we might end up with doubled workload there too!) isn't going > to help at all! Yep, this is the biggest concrete objection. My answer is that if we care about Aunt Flo, suck it up, princess, because it's the only viable system. :) Any "flexible" update system is going to screw Aunt Flo (or Joe Stable-Set-Of-Systems Sysadmin, or anyone who needs the proper stable update set) over at some point. If we don't care about Aunt Flo - or any of the other users who need a stable update set - see my original post, where I said we can then just have the single 'whatever the hell you like' update repo. It's not a rhetorical trick, it's a genuine fundamental point for discussion: I'd be perfectly happy if we, once and for all, declared that we really don't give a shit about 'stable' use cases; if you want those, use some other distro. I'm fine with that. But it's a decision that needs to be taken, because right now we have confusion, lack of focus and messy compromises in a whole bunch of areas caused by the lack of a clear answer to that question. > IMHO "backports" are a half-baked workaround for inflexible upgrading > policies and generate unneccessary maintainer workload and a poor user > experience (especially if they're labeled "unsupported" as e.g. Ubuntu is > doing, I'm not sure how Mandriva handles it). They're officially unsupported, because MDV is a commercial distro with a strict definition of what 'supported' means (MDV commits to fix serious bugs and security issues in packages labelled as 'supported') and it is insane to make that commitment for backport packages. But in practice, most maintainers accept and fix bug reports in backport packages much the same way they do for others. The Ubuntu backport repositories are an excellent example of how not to do it - they have crappy user and maintainer buy-in and most 'backports' are in practice done through PPAs, official or unofficial. Which stinks, but we're not in a 'why Ubuntu stinks' thread here :) > The only kind of "backports" repository I could envision is for packages > which DON'T make sense to ship as stable updates, e.g. major bumps like > Amarok 1->2 in F9, i.e. the kind of stuff we're shipping in kde-redhat > unstable and other similar repositories. But it should not be the norm for > all new versions (and mixing minor bumps like KDE 4.0->4.1->4.2 with major > changes like Amarok 1->2 in a single repository would also significantly > degrade the user experience ? this is another problem I've seen > with "backports" repositories, they encourage throwing in risky or even > unstable (e.g. KOffice 2) updates together with riskless ones like even > bugfix releases of KDE (e.g. 4.1.2->4.1.3) in the same repository). See my original post. I don't accept that you can safely have an updates policy which professes to provide a 'stable' update repository while allowing tomfoolery like upgrading KDE wholesale. It's just not practically possible, and our current update repositories prove that quite nicely. The only consistently practicable update policies are "minimal necessary changes" and "do whatever you like". If you run a stable Fedora release and install all official updates, you will get significant changes in basic functionality and, in all likelihood, visible regressions. Our current updates policy does not provide a stable experience along the lines of what you get from distributions which follow the industry standard "minimal possible change" policy. As I said a few times, this isn't inherently a bad thing. If we're clear that this is what we *want*, and we communicate that properly, it's fine. But I don't think you can pretend to provide a 'stable' distribution while allowing the shipping of updates in the way we currently do. We need clarity and focus here. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From skvidal at fedoraproject.org Mon May 11 20:15:47 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 11 May 2009 16:15:47 -0400 (EDT) Subject: yum-presto installed by default for Fedora 11? In-Reply-To: <1242072883.3331.41.camel@localhost.localdomain> References: <4A087B68.4060208@fedoraproject.org> <2a28d2ab0905111229r5d732055o247dfd4a31fd8222@mail.gmail.com> <1242072883.3331.41.camel@localhost.localdomain> Message-ID: On Tue, 12 May 2009, Ankur Sinha wrote: > On Mon, 2009-05-11 at 15:51 -0400, Seth Vidal wrote: >> >> On Mon, 11 May 2009, Dr. Diesel wrote: >> >>> >>> >>> Because of limited testing or some other limitation/factor? >>> >>> >> >> Somewhat, yes. We wanted to be sure that we wouldn't be shipping something >> out that would break everyone's updates/installs. >> >> And we were not completely sure. >> >> Considering how critical a component yum is we decided to punt on making >> it default. >> >> -sv >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list > > hi, > > Can we help test it? Has there been such a test day or something of the > sort yet?? > Yes. it was 2 weeks ago. We had some good results. Currently I do not expect anything bad to happen but no one was confident enough in that result to do it by default for F11. Remember all you have to do to enable presto is run: yum install yum-presto and then it is enabled on the next run of yum. -sv From walters at verbum.org Mon May 11 20:18:03 2009 From: walters at verbum.org (Colin Walters) Date: Mon, 11 May 2009 16:18:03 -0400 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1242066123.3452.34.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <1241795563.3209.83.camel@localhost.localdomain> <4A04D350.1000904@freenet.de> <1241832771.2886.15.camel@localhost.localdomain> <4A04EAAE.50907@freenet.de> <1241836379.2886.30.camel@localhost.localdomain> <1242062337.3452.27.camel@localhost.localdomain> <1242066123.3452.34.camel@localhost.localdomain> Message-ID: On Mon, May 11, 2009 at 2:22 PM, Jesse Keating wrote: > On Mon, 2009-05-11 at 13:37 -0400, Colin Walters wrote: >> Well, I see it as a well defined *targeted product* which happens to >> be composed of packages. ?It's the base from which other things can be >> installed from the Internet. ?What is the problem with "static pile of >> packages"? (I have to admit to only skimming this thread) > > Updates to the previous release will quickly become N-V-R "newer" than > the static pile of packages, which renders your upgrade a bit... odd. In the desktop context packages get upgraded when PackageKit notices new stuff and the user starts downloading it. What was originally on the CD is mostly irrelevant. >> > Of course, the Live image >> > doesn't necessarily have the upgrade problem we're talking about, >> > because you can't use the live image to do an upgrade. ?Makes it less >> > than useful for people. >> >> For upgrades we should be pushing people towards preupgrade. ?If >> preupgrade works well, I'm having trouble thinking of scenarios in >> which you'd end up with a physical image and want to do an upgrade. >> Maybe if you're out of disk space you'd need physical media to >> download the updates on to, but there's also no reason preupgrade >> couldn't prompt you to insert a USB stick or blank CD. > > preupgrade requires a significant network cost. Sure, but how did you get that CD in the first place? I'm having trouble thinking of scenarios where somehow you acquire a CD that you didn't download yourself, but you already have Fedora installed, and you don't have access to enough network bandwidth to upgrade. Anyways the angle I'm coming at here is that Fedora should be producing only a few live images and things like Richard Jones' minimal image, not the choose-your-own-adventure DVD. From sanjay.ankur at gmail.com Mon May 11 20:22:26 2009 From: sanjay.ankur at gmail.com (Ankur Sinha) Date: Tue, 12 May 2009 01:52:26 +0530 Subject: yum-presto installed by default for Fedora 11? In-Reply-To: References: <4A087B68.4060208@fedoraproject.org> <2a28d2ab0905111229r5d732055o247dfd4a31fd8222@mail.gmail.com> <1242072883.3331.41.camel@localhost.localdomain> Message-ID: <1242073346.3331.43.camel@localhost.localdomain> On Mon, 2009-05-11 at 16:15 -0400, Seth Vidal wrote: > Yes. it was 2 weeks ago. We had some good results. Currently I do not > expect anything bad to happen but no one was confident enough in that > result to do it by default for F11. > > Remember all you have to do to enable presto is run: > > yum install yum-presto > > and then it is enabled on the next run of yum. > > -sv > hi, Oh.. means I missed out.. anyway, I'll enable it and report anything out of line.. Thanks for all the effort you folks put into presto.. :) regards, Ankur From a.badger at gmail.com Mon May 11 20:21:06 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 11 May 2009 13:21:06 -0700 Subject: FESco meeting summary for 20090507 In-Reply-To: <5256d0b0905101122l76dd5925od7f86a4a1fd3755d@mail.gmail.com> References: <4A05BF03.6070508@fi.muni.cz> <1241891211.9577.0.camel@localhost.localdomain> <4A07196D.30000@gmail.com> <5256d0b0905101122l76dd5925od7f86a4a1fd3755d@mail.gmail.com> Message-ID: <4A0888B2.9060201@gmail.com> Peter Robinson wrote: > I can take some of these if no one else in interested. >> djvulibre - mpg >> farsight - gdesmott >> gstreamer-plugins-farsight - gdesmott >> hippo-canvas - mpg >> hulahop - mpg >> libjingle - gdesmott >> olpc-hardware-manager - mpg >> speech-dispatcher - hemantg >> sugar - mpg >> sugar-artwork - mpg >> sugar-base - mpg >> sugar-datastore - mpg >> sugar-journal - mpg >> sugar-presence-service - mpg >> sugar-toolkit - mpg >> telepathy-stream-engine - gdesmott > Done. > I've already taken ownership of these, so not sure why they are listed > as orphaned. >> xapian-bindings - mpg >> xapian-core - mpg > These are because the F-9 and OLPC-2 branches are still owned by mpg. I've orphaned them. This does bring up, however, that we need to figure out when to EOL OLPC branches. > and I've already done the dead package process on this one as well. >> pyxapian - mpg > Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From jameshubbard at gmail.com Mon May 11 20:23:21 2009 From: jameshubbard at gmail.com (James Hubbard) Date: Mon, 11 May 2009 16:23:21 -0400 Subject: OpenOffice 3.1 In-Reply-To: <1242064968.2923.615.camel@adam.local.net> References: <4A034FD0.40103@gnat.ca> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <1241990992.3452.6.camel@localhost.localdomain> <6dc6523c0905101458l64811e65lb9f18216a4f93941@mail.gmail.com> <1242064968.2923.615.camel@adam.local.net> Message-ID: On Mon, May 11, 2009 at 2:02 PM, Adam Williamson wrote: [snip] > To me, this comes back - again - to what I've been thinking about for a > while now: what do we want Fedora to be? Who do we want it to be for? [snip] > But, yet again, it's a question that can't be answered until we know > what exactly Fedora is supposed to be, and for whose benefit. Even if we > come up with a consistent and coherent policy it likely won't work until > that question is properly answered and agreed upon. I've seen this question asked in a round about way by others, but I've never seen anyone address it. I've just taken it for granted that Fedora is a developer distribution that gets periodically rolled into a commercial distribution. I expect some churn/breakage. I don't expect my non-technical friends to install/use Fedora. When I install a distribution on someone's machine, it's usually Ubuntu. If it won't work because of drivers, I may consider Fedora. I wouldn't expect a non-techie user to update their system as soon as it was EOL ~1 year. Some of my co-works have jumped to Ubuntu because they don't like the short support cycle. It appears to be easier to upgrade from one version of Ubuntu to the next and it's support cycle is longer (16 months for 9.04). This means it's less work for me to help them. I'm okay with wiping the appropriate partitions on my machines and re-installing things from scratch when I'm ready to update. I don't want to help people do that once a year for Fedora. I do that enough now with windows. From mschwendt at gmail.com Mon May 11 20:27:29 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Mon, 11 May 2009 22:27:29 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241949557.3109.2.camel@localhost.localdomain> <20090510131115.226b27a5@faldor.intranet> <4A079B3B.20606@freenet.de> <20090511132526.3195dc37@rawhide.intranet> <4A084868.4040807@freenet.de> <20090511202103.5b90f3b0@rawhide.intranet> Message-ID: <20090511222729.08425a92@rawhide.intranet> On Mon, 11 May 2009 21:31:31 +0200, Kevin wrote: > Michael Schwendt wrote: > > > On Mon, 11 May 2009 17:46:48 +0200, Ralf wrote: > > > >> * Fact also is: "Testing" occasionally is the cause of broken package > >> deps. > > > > How? Or, what do you mean? > > One example is Qt 4.5: it was in the buildroot, but only in testing, so > stuff which got moved to stable before Qt 4.5 was was broken. Can't parse that yet. :( Builds pushed to updates-testing don't appear in the buildroots. They need to be pushed to stable. Unless a buildroot override tag is used. So, with the help of buildroot override you've had a complete set of Qt 4.5 builds in testing (as repoclosure has not detected related breakage), but somebody pushed only parts of the builds to stable? (instead of grouping all builds in a single bodhi ticket) Then one cannot say "Testing [...] is the cause of broken package deps", but once again, the improperly treated version upgrade has been the cause of broken deps. For library ABI changes, it's "all or nothing". Either push all related builds or none of them. From christoph.wickert at googlemail.com Mon May 11 20:27:00 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Mon, 11 May 2009 22:27:00 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1241720728.3209.12.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <200905071959.22508.opensource@till.name> <1241720728.3209.12.camel@localhost.localdomain> Message-ID: <1242073620.3658.64.camel@localhost.localdomain> Am Donnerstag, den 07.05.2009, 11:25 -0700 schrieb Jesse Keating: > On Thu, 2009-05-07 at 19:59 +0200, Till Maas wrote: > > Afaik, requests to updates-testing were not processed for F11, e.g. for one or > > two of my new packages I requested updates-testing for F9, F10 and F11 at the > > same time, got positive feedback / no negative feedback for F9 or F10 and then > > moved them all to stable at the same time, resp. canceled the testing request > > for F11 and made it to a stable one. I guess this affects also other packages, > > that were updated in F9 or F10 and F11, to have a working update path from FX > > with updates to FX+1 with updates. > > Upgrade paths are a concern yes, however our upgrade path stuff is so > busted anyway when doing upgrades to the next release that... well... > *sigh*. Something is busted anyway is not a convincing argument. Effectively through the upgrade paths the development freeze also affects all releases < F11, so effectively it's impossible to add new packages to the stable releases for 6 weeks. This is annoying. Regards, Christoph From cdahlin at redhat.com Mon May 11 20:28:59 2009 From: cdahlin at redhat.com (Casey Dahlin) Date: Mon, 11 May 2009 16:28:59 -0400 Subject: glibc fork ? In-Reply-To: <1241911685.24436.93.camel@macbook.infradead.org> References: <4A02F8D3.2010807@poolshark.org> <4A036082.8000107@fedoraproject.org> <20090509160428.0bf3c0e6.zaitcev@redhat.com> <1241911685.24436.93.camel@macbook.infradead.org> Message-ID: <4A088A8B.6070007@redhat.com> David Woodhouse wrote: > On Sat, 2009-05-09 at 16:04 -0600, Pete Zaitcev wrote: >> As far as Fedora goes, IMHO we should watch the developments and >> evaluate the performance of eglibc against a simple criterium: >> if they add bugs or fix bugs. Next big performance anomaly in >> something like MySQL will prove eglibc people's worth. If they >> just wait for Jakub and Uli to fix it for them, I don't see us >> switching. > > I have no particularly strong opinion either way, and I agree with your > assessment -- but do let me know when I can start using strlcat(). :) > Never! Drepper is right about str* being an awful family of functions, even their new strl* incarnations. Now, granted, I want them around, for the simple fact that I want to build BSD code on linux (that jot command would be nice to have...) but still. --CJD From kevin.kofler at chello.at Mon May 11 20:31:17 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 11 May 2009 22:31:17 +0200 Subject: Locking assertion failure. Backtrace: References: <1241978114.3331.20.camel@localhost.localdomain> <4A07534A.2040509@fedoraproject.org> <1242053033.3331.39.camel@localhost.localdomain> Message-ID: Ankur Sinha wrote: > I installed the package and ran it from the terminal when the errors > popped up.. If there are any steps you'd want me to try that could help > you diagnose the source of the errors please just post. OK, the real problem there is that they're abusing Qt's warning/error system to handle application errors, which isn't what it's designed for. That's why they're redirecting it to a message box. I fixed the code to disable that error handler and call QMessageBox directly where needed. Please try the following patch: http://repo.calcforge.org/f10/panini-0.62-x11-lock-recursion.patch Kevin Kofler From kevin.kofler at chello.at Mon May 11 20:34:43 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 11 May 2009 22:34:43 +0200 Subject: Fedora (Linux) is Destroying it self References: <4A082E70.7030904@TheTroubleshooters.dk> <7f692fec0905110735tf8a1bd4u7a71d85f6de7f14b@mail.gmail.com> Message-ID: Yaakov Nemoy wrote: > This is upstream and has to do with Gnome. Fedora stays as close to > upstream as possible, which means if the Gnome developers think this > is a good idea, then this is (possibly) a good idea. If you don't like > it, get a clue and install a different window manager. Try Openbox. Or KWin. :-) Kevin Kofler From jkeating at redhat.com Mon May 11 20:36:28 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 May 2009 13:36:28 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: References: <1241718097.3209.11.camel@localhost.localdomain> <1241795563.3209.83.camel@localhost.localdomain> <4A04D350.1000904@freenet.de> <1241832771.2886.15.camel@localhost.localdomain> <4A04EAAE.50907@freenet.de> <1241836379.2886.30.camel@localhost.localdomain> <1242062337.3452.27.camel@localhost.localdomain> <1242066123.3452.34.camel@localhost.localdomain> Message-ID: <1242074189.3452.43.camel@localhost.localdomain> On Mon, 2009-05-11 at 16:18 -0400, Colin Walters wrote: > In the desktop context packages get upgraded when PackageKit notices > new stuff and the user starts downloading it. What was originally on > the CD is mostly irrelevant. Except when you can't actually get to the desktop or use the update tool because it's the F10 version that doesn't work with the rest of the F11 content. If you've waited a while and have newer F10 packages than what's on the F11 media you'll have a system in a fragile undefined state. > > >> > Of course, the Live image > >> > doesn't necessarily have the upgrade problem we're talking about, > >> > because you can't use the live image to do an upgrade. Makes it less > >> > than useful for people. > >> > >> For upgrades we should be pushing people towards preupgrade. If > >> preupgrade works well, I'm having trouble thinking of scenarios in > >> which you'd end up with a physical image and want to do an upgrade. > >> Maybe if you're out of disk space you'd need physical media to > >> download the updates on to, but there's also no reason preupgrade > >> couldn't prompt you to insert a USB stick or blank CD. > > > > preupgrade requires a significant network cost. > > Sure, but how did you get that CD in the first place? I'm having > trouble thinking of scenarios where somehow you acquire a CD that you > didn't download yourself, but you already have Fedora installed, and > you don't have access to enough network bandwidth to upgrade. Free media, Linux shows, LUGs, a friend's computer, a library, etc... There is a not insignificant amount of our user base that is bandwidth challenged. While it would be easy to just tell them to go find another distribution that is more friendly to their setup, I don't think that's what we should do. > > Anyways the angle I'm coming at here is that Fedora should be > producing only a few live images and things like Richard Jones' > minimal image, not the choose-your-own-adventure DVD. How is the "minimal image" not a choose your own adventure? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kevin.kofler at chello.at Mon May 11 20:40:30 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 11 May 2009 22:40:30 +0200 Subject: Fedora (Linux) is Destroying it self References: <4A082E70.7030904@TheTroubleshooters.dk> Message-ID: Michael Nielsen wrote: > 4. Everything is thrown in huge collective directories, such as > /usr/bin, /usr/lib etc, and it is a huge mess This is called the Filesystem Hierarchy Standard, and it encodes decades of experience organizing file systems into a standard which minimizes differences across implementations. > just like windows with it's system32 directory, which is also a huge mess. Actually Window$ is the system which started this "one directory per app" stupidity. *nix has never worked that way. Kevin Kofler From awilliam at redhat.com Mon May 11 20:41:01 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 11 May 2009 13:41:01 -0700 Subject: yum-presto installed by default for Fedora 11? In-Reply-To: <1242072883.3331.41.camel@localhost.localdomain> References: <4A087B68.4060208@fedoraproject.org> <2a28d2ab0905111229r5d732055o247dfd4a31fd8222@mail.gmail.com> <1242072883.3331.41.camel@localhost.localdomain> Message-ID: <1242074461.2923.671.camel@adam.local.net> On Tue, 2009-05-12 at 01:44 +0530, Ankur Sinha wrote: > > Somewhat, yes. We wanted to be sure that we wouldn't be shipping something > > out that would break everyone's updates/installs. > > > > And we were not completely sure. > > > > Considering how critical a component yum is we decided to punt on making > > it default. > > > > -sv > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > hi, > > Can we help test it? Has there been such a test day or something of the > sort yet?? Yes, there was a test day, and you can certainly still go through the tests from it and log your results: https://fedoraproject.org/wiki/Test_Day:Presto_2009-04-16 -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From tcallawa at redhat.com Mon May 11 20:40:37 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 11 May 2009 16:40:37 -0400 Subject: SPARC Status (Was Re: Secondary Architecture Status?) In-Reply-To: <1242071724.2923.656.camel@adam.local.net> References: <1241911202.24436.81.camel@macbook.infradead.org> <4A0862F1.2030608@redhat.com> <20090511185147.GA3256@yoda.jdub.homelinux.org> <1242071724.2923.656.camel@adam.local.net> Message-ID: <4A088D45.7010607@redhat.com> On 05/11/2009 03:55 PM, Adam Williamson wrote: > On Mon, 2009-05-11 at 14:51 -0400, Josh Boyer wrote: > >> I would really like to see a proliferation of secondary arches in >> Fedora, but I don't think 'workstation' is a viable usage model for >> them to get started. Most will have to focus on the type of hardware >> that actually sells for that arch, and yes I realize that can be at >> odds with some of the directions Fedora is going. > > Semi-sidetrack here: Ubuntu has a secondary 'architecture' called LPIA > which is, in fact, just an alternative set of compiler optimizations > which they claim results in better code for 'netbook > systems' (presumably meaning 'Atom CPUs'). Would that be something we > could look into, or not interesting? Sure, I see no reason why someone couldn't take that on as a "secondary arch". It would need a new arch identifier target for rpm to prevent namespace collisions. ~spot From awilliam at redhat.com Mon May 11 20:43:08 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 11 May 2009 13:43:08 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: References: <1241718097.3209.11.camel@localhost.localdomain> <1241795563.3209.83.camel@localhost.localdomain> <4A04D350.1000904@freenet.de> <1241832771.2886.15.camel@localhost.localdomain> <4A04EAAE.50907@freenet.de> <1241836379.2886.30.camel@localhost.localdomain> <1242062337.3452.27.camel@localhost.localdomain> <1242066123.3452.34.camel@localhost.localdomain> Message-ID: <1242074588.2923.673.camel@adam.local.net> On Mon, 2009-05-11 at 16:18 -0400, Colin Walters wrote: > Sure, but how did you get that CD in the first place? I'm having > trouble thinking of scenarios where somehow you acquire a CD that you > didn't download yourself, but you already have Fedora installed, and > you don't have access to enough network bandwidth to upgrade. I don't know how much it happens for Fedora, but for MDV, there are significant communities in countries with mainly slow internet connections, where one person who had a fast connection through work or an education institution or something like that would download the images, and burn and distribute copies to many other people. Sometimes I even shipped out copies of the MDV live CD to such 'seeders' in places like this myself, who would then duplicate them for dozens of other people in the country / city / whatever. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From a.badger at gmail.com Mon May 11 20:29:11 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 11 May 2009 13:29:11 -0700 Subject: FESco meeting summary for 20090507 In-Reply-To: <5256d0b0905101512m5dae0071jad00fe7d735cf284@mail.gmail.com> References: <5256d0b0905101512m5dae0071jad00fe7d735cf284@mail.gmail.com> Message-ID: <4A088A97.2030604@gmail.com> Peter Robinson wrote: > Hi All, > >> == Deactivated maintainers == >> >> FESCo approved orphaning packages owned by deactivated maintainers > > Looking through the orphaned package list there looks to be quite a > list of dead packages there as well. What is the process for marking > them dead in the pgkdb or do they just hang around as orphaned in case > someone wants to revive them. The gstreamer08 ones are some that come > to mind. I know I have ownership of a package as well that is dead > (replaced by other packages) and has gone through the dead package > process, is there a process for the pkgdb part of that? > There will be but there isn't yet. I'm testing and working out bugs in a large packagedb update now. It has support for retiring packages. We'll probably have to write some new supporting scripts to go along with that (to push retired package information from packagedb into koji, maybe to do the dead.package stuff from the packagedb rather than manually by the maintainer, etc). -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From tgl at redhat.com Mon May 11 20:46:31 2009 From: tgl at redhat.com (Tom Lane) Date: Mon, 11 May 2009 16:46:31 -0400 Subject: FESco meeting summary for 20090507 In-Reply-To: <1242071296.2923.654.camel@adam.local.net> References: <1242062320.2923.586.camel@adam.local.net> <6764.1242064296@sss.pgh.pa.us> <1242071296.2923.654.camel@adam.local.net> Message-ID: <29158.1242074791@sss.pgh.pa.us> Adam Williamson writes: > On Mon, 2009-05-11 at 13:51 -0400, Tom Lane wrote: >> Java is still a huge mess; there are any number of webapps that just >> plain don't work in 64-bit. (I'm not sure this is Java's fault per se, >> but the fact remains that things don't work and the authors seem content >> to tell you to install a 32-bit browser instead of fixing their broken >> code...) > Hmm, that's nasty. I hadn't personally run across any of those yet, > which is I guess why I didn't know about it. Thanks for the info. I've run into it twice in the past two months for apps used inside Red Hat. (Not developed inside Red Hat, I'm glad to say.) This is out of a sample of exactly two apps, since I avoid webapps where I can. So I admit I don't have a lot of data, but from here it looks like a problem. regards, tom lane From kevin.kofler at chello.at Mon May 11 20:47:11 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 11 May 2009 22:47:11 +0200 Subject: glibc fork ? References: <4A02F8D3.2010807@poolshark.org> <4A036082.8000107@fedoraproject.org> <20090509160428.0bf3c0e6.zaitcev@redhat.com> <1241911685.24436.93.camel@macbook.infradead.org> <4A088A8B.6070007@redhat.com> Message-ID: Casey Dahlin wrote: > Now, granted, I want them around, for the simple fact that I want to build > BSD code on linux (that jot command would be nice to have...) but still. Well, you can just copy the implementation from *BSD or from kdelibs/kdecore/fakes.c: http://websvn.kde.org/trunk/KDE/kdelibs/kdecore/fakes.c?revision=720340&view=markup Or you could even link to libkdecore.so.5 which exports those functions. ;-) Kevin Kofler From kevin.kofler at chello.at Mon May 11 20:49:13 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 11 May 2009 22:49:13 +0200 Subject: 182 pending F11 stable updates. WTF? References: <1241718097.3209.11.camel@localhost.localdomain> <200905071959.22508.opensource@till.name> <1241720728.3209.12.camel@localhost.localdomain> <1242073620.3658.64.camel@localhost.localdomain> Message-ID: Christoph Wickert wrote: > Effectively through the upgrade paths the development freeze also > affects all releases < F11, so effectively it's impossible to add new > packages to the stable releases for 6 weeks. This is annoying. You only have to provide upgrade paths from updates to updates, not from updates to GA. Just queue the updates for F9, F10 and F11 at once. Kevin Kofler From walters at verbum.org Mon May 11 20:51:12 2009 From: walters at verbum.org (Colin Walters) Date: Mon, 11 May 2009 16:51:12 -0400 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1242074588.2923.673.camel@adam.local.net> References: <1241718097.3209.11.camel@localhost.localdomain> <1241832771.2886.15.camel@localhost.localdomain> <4A04EAAE.50907@freenet.de> <1241836379.2886.30.camel@localhost.localdomain> <1242062337.3452.27.camel@localhost.localdomain> <1242066123.3452.34.camel@localhost.localdomain> <1242074588.2923.673.camel@adam.local.net> Message-ID: On Mon, May 11, 2009 at 4:43 PM, Adam Williamson wrote: > On Mon, 2009-05-11 at 16:18 -0400, Colin Walters wrote: > >> Sure, but how did you get that CD in the first place? ?I'm having >> trouble thinking of scenarios where somehow you acquire a CD that you >> didn't download yourself, but you already have Fedora installed, and >> you don't have access to enough network bandwidth to upgrade. > > I don't know how much it happens for Fedora, but for MDV, there are > significant communities in countries with mainly slow internet > connections, where one person who had a fast connection through work or > an education institution or something like that would download the > images, and burn and distribute copies to many other people. Ok, well, maybe the right thing is for the DVD images to have the installed live RPMs also in RPM form so they can be used as a package cache as well. Or maybe instead we figure out how to reconstruct the RPMs from the installed image reliably (not sure what the blockers are there). Anyways I'm not saying the DVDs shouldn't be possible to use for upgrading, what I'm arguing against is the user experience of the DVD where it just boots into anaconda and asks questions like "Do you want to install a server or a desktop? Do you want OpenOffice?" etc. A much better experience is for it to boot into a full working desktop, and from there you can image it to your drive if you like what you see, but also in the menus or somewhere else have other options. From a.badger at gmail.com Mon May 11 20:54:04 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 11 May 2009 13:54:04 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <20d6441a0905111218q36cbfebbs6997631e8c8251e3@mail.gmail.com> References: <4A03BB64.10006@freenet.de> <1241832771.2886.15.camel@localhost.localdomain> <4A04EAAE.50907@freenet.de> <1241836379.2886.30.camel@localhost.localdomain> <1242062337.3452.27.camel@localhost.localdomain> <1242066123.3452.34.camel@localhost.localdomain> <20090511183539.GV31498@angus.ind.WPI.EDU> <1242068254.3452.36.camel@localhost.localdomain> <20d6441a0905111218q36cbfebbs6997631e8c8251e3@mail.gmail.com> Message-ID: <4A08906C.7010805@gmail.com> Jud Craft wrote: > On Mon, May 11, 2009 at 1:57 PM, Jesse Keating wrote: >> On Mon, 2009-05-11 at 14:35 -0400, Chuck Anderson wrote: >>> Why do we not force updates to Fedora X to always be N-V-R older than >>> Fedora X+1? We can use the Release tag to enforce this within a >>> Version, and newer Versions shouldn't appear in older Fedora's until >>> they've been in the newer Fedora first. >> Your suggest would lead to not allowing F10's package versions to /ever/ >> be newer than what Fedora 11 ships with at GA. >> > > Question! > > Why not force them to be "N-V" older, then? Wouldn't that still allow > for security updates? (I assumed security updates were the > minor-point-number -R packages). > > So in essence, the F9 packages are set in stone when F10 is released, > except for minor patches. No new versions. > We don't currently demand backporting skills from our maintainers. Upgrading to a newer upstream release that fixes a problem is a valid strategy. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From kevin.kofler at chello.at Mon May 11 20:50:06 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 11 May 2009 22:50:06 +0200 Subject: 182 pending F11 stable updates. WTF? References: <4A03BB64.10006@freenet.de> <1241832771.2886.15.camel@localhost.localdomain> <4A04EAAE.50907@freenet.de> <1241836379.2886.30.camel@localhost.localdomain> <1242062337.3452.27.camel@localhost.localdomain> <1242066123.3452.34.camel@localhost.localdomain> <20090511183539.GV31498@angus.ind.WPI.EDU> <1242068254.3452.36.camel@localhost.localdomain> <20d6441a0905111218q36cbfebbs6997631e8c8251e3@mail.gmail.com> Message-ID: Jud Craft wrote: > So in essence, the F9 packages are set in stone when F10 is released, > except for minor patches. No new versions. Fedora is not Debian stable. Kevin Kofler From pbrobinson at gmail.com Mon May 11 20:57:10 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 11 May 2009 21:57:10 +0100 Subject: FESco meeting summary for 20090507 In-Reply-To: <4A0888B2.9060201@gmail.com> References: <4A05BF03.6070508@fi.muni.cz> <1241891211.9577.0.camel@localhost.localdomain> <4A07196D.30000@gmail.com> <5256d0b0905101122l76dd5925od7f86a4a1fd3755d@mail.gmail.com> <4A0888B2.9060201@gmail.com> Message-ID: <5256d0b0905111357nc23c028j230409783a91a47e@mail.gmail.com> >> I can take some of these if no one else in interested. >>> djvulibre - mpg >>> farsight - gdesmott >>> gstreamer-plugins-farsight - gdesmott >>> hippo-canvas - mpg >>> hulahop - mpg >>> libjingle - gdesmott >>> olpc-hardware-manager - mpg >>> speech-dispatcher - hemantg >>> sugar - mpg >>> sugar-artwork - mpg >>> sugar-base - mpg >>> sugar-datastore - mpg >>> sugar-journal - mpg >>> sugar-presence-service - mpg >>> sugar-toolkit - mpg >>> telepathy-stream-engine - gdesmott >> > Done. > >> I've already taken ownership of these, so not sure why they are listed >> as orphaned. >>> xapian-bindings - mpg >>> xapian-core - mpg >> > > These are because the F-9 and OLPC-2 branches are still owned by mpg. > I've orphaned them. ?This does bring up, however, that we need to figure > out when to EOL OLPC branches. Ah. OK. I was thinking about the EOL of the OLPC branches as well. Might be one for Greg DeK as well. Peter From christoph.wickert at googlemail.com Mon May 11 20:58:40 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Mon, 11 May 2009 22:58:40 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: References: <1241718097.3209.11.camel@localhost.localdomain> <200905071959.22508.opensource@till.name> <1241720728.3209.12.camel@localhost.localdomain> <1242073620.3658.64.camel@localhost.localdomain> Message-ID: <1242075520.3658.66.camel@localhost.localdomain> Am Montag, den 11.05.2009, 22:49 +0200 schrieb Kevin Kofler: > Christoph Wickert wrote: > > Effectively through the upgrade paths the development freeze also > > affects all releases < F11, so effectively it's impossible to add new > > packages to the stable releases for 6 weeks. This is annoying. > > You only have to provide upgrade paths from updates to updates, not from > updates to GA. Just queue the updates for F9, F10 and F11 at once. But F-11 updates are not processed, so on the day of release they will not be available. Or how about the people who upgrade from the DVD without having internet during install? > Kevin Kofler Regards, Christoph From tcallawa at redhat.com Mon May 11 20:58:14 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 11 May 2009 16:58:14 -0400 Subject: SPARC Status (Was Re: Secondary Architecture Status?) In-Reply-To: <4A0881A0.8080506@poolshark.org> References: <1241911202.24436.81.camel@macbook.infradead.org> <4A0862F1.2030608@redhat.com> <4A0881A0.8080506@poolshark.org> Message-ID: <4A089166.3000203@redhat.com> On 05/11/2009 03:50 PM, Denis Leroy wrote: > It's still too early to say how the acquisition is going to affect that > effort, to be honest. Do you have any Sun contributors today to Fedora > Linux/SPARC ? Most of the SPARC people you run into at Sun tend to be > Solaris old-school fanatics (and vice-versa)... Historically, yes. Currently? No. All of those individuals have left Sun for greener pastures. ~spot From walters at verbum.org Mon May 11 21:01:10 2009 From: walters at verbum.org (Colin Walters) Date: Mon, 11 May 2009 17:01:10 -0400 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1242074189.3452.43.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <1241832771.2886.15.camel@localhost.localdomain> <4A04EAAE.50907@freenet.de> <1241836379.2886.30.camel@localhost.localdomain> <1242062337.3452.27.camel@localhost.localdomain> <1242066123.3452.34.camel@localhost.localdomain> <1242074189.3452.43.camel@localhost.localdomain> Message-ID: On Mon, May 11, 2009 at 4:36 PM, Jesse Keating wrote: > On Mon, 2009-05-11 at 16:18 -0400, Colin Walters wrote: >> In the desktop context packages get upgraded when PackageKit notices >> new stuff and the user starts downloading it. ?What was originally on >> the CD is mostly irrelevant. > > Except when you can't actually get to the desktop or use the update tool > because it's the F10 version that doesn't work with the rest of the F11 > content. ?If you've waited a while and have newer F10 packages than > what's on the F11 media you'll have a system in a fragile undefined > state. Ahh...I'm confused. How do you get to this state? It sounds like something preupgrade could handle in any case. Let me take a step back - here's all I'm trying to say: The user experience of the live images is way better than anaconda-the-OS, and we should be sure users who don't explicitly want a choose-your-own-adventure are getting the live images. Especially from things like trade shows. > How is the "minimal image" not a choose your own adventure? The minimal image is a targeted product in the sense that it's intended for people to build higher-level products on, like virtual machine appliances and the like. We wouldn't expect people to take the minimal image and then try to convert it into a desktop workstation. From kevin.kofler at chello.at Mon May 11 21:03:01 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 11 May 2009 23:03:01 +0200 Subject: 182 pending F11 stable updates. WTF? References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241949557.3109.2.camel@localhost.localdomain> <20090510131115.226b27a5@faldor.intranet> <4A079B3B.20606@freenet.de> <20090511132526.3195dc37@rawhide.intranet> <4A084868.4040807@freenet.de> <20090511202103.5b90f3b0@rawhide.intranet> <20090511222729.08425a92@rawhide.intranet> Message-ID: Michael Schwendt wrote: > So, with the help of buildroot override you've had a complete set of Qt > 4.5 builds in testing (as repoclosure has not detected related breakage), > but somebody pushed only parts of the builds to stable? (instead of > grouping all builds in a single bodhi ticket) Qt 4.5 was not a soname bump, it was a basically backwards-compatible release, only some stuff had to be rebuilt against it (thankfully; otherwise it wouldn't have been possible to do the upgrade, there's too much stuff using Qt!), and we needed the buildroot override for that stuff. What happened is that people inadvertently built Qt-based packages which did not require a rebuild and thus weren't on our radar against the Qt 4.5 buildroot override, then pushed them to stable while Qt 4.5 was still in testing (which doesn't work because the compatibility is only unidirectional: you can build against 4.4 and run on 4.5, except for a few special packages which required the buildroot override, but you can't build on 4.5 and run on 4.4). What needed the buildroot override: * some packages (mostly KDE packages, and we had to rebuild those anyway for the 4.2.2 upgrade) which had build-time conditionals on the Qt version controlling some Qt-version-specific workarounds (some of those required some new API in Qt 4.5 to fix issues with Qt 4.5, others just dropped Qt-4.4-specific workarounds when built against 4.5), * 1 package which segfaulted when built on 4.4 and run on 4.5, rebuilding fixed it (apparent silent Qt ABI breakage, but it only affected 1 single package), * a few packages which require Qt >= 4.5 to build (current Arora which uses the latest QtWebKit features, Qt Creator etc.), but by no means all Qt-using packages needed a rebuild! Kevin Kofler From rjones at redhat.com Mon May 11 21:13:38 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 11 May 2009 22:13:38 +0100 Subject: FESco meeting summary for 20090507 In-Reply-To: <1242064921.2510.119.camel@localhost.localdomain> References: <2d319b780905100914n442e2501h78b2184437a67065@mail.gmail.com> <1242064921.2510.119.camel@localhost.localdomain> Message-ID: <20090511211338.GA9156@amd.home.annexia.org> On Mon, May 11, 2009 at 01:02:01PM -0500, Callum Lerwick wrote: > Then we could come up with all kinds of meaningful stats, like how many > people have cmov/MMX/SSE, and how many support 64 bit regardless of > installed architecture. And don't forget, how many have hardware virtualization (and whether it's "new" or "old" hardware virt). Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw From drago01 at gmail.com Mon May 11 21:19:07 2009 From: drago01 at gmail.com (drago01) Date: Mon, 11 May 2009 23:19:07 +0200 Subject: FESco meeting summary for 20090507 In-Reply-To: <29158.1242074791@sss.pgh.pa.us> References: <1242062320.2923.586.camel@adam.local.net> <6764.1242064296@sss.pgh.pa.us> <1242071296.2923.654.camel@adam.local.net> <29158.1242074791@sss.pgh.pa.us> Message-ID: On Mon, May 11, 2009 at 10:46 PM, Tom Lane wrote: > Adam Williamson writes: >> On Mon, 2009-05-11 at 13:51 -0400, Tom Lane wrote: >>> Java is still a huge mess; there are any number of webapps that just >>> plain don't work in 64-bit. ?(I'm not sure this is Java's fault per se, >>> but the fact remains that things don't work and the authors seem content >>> to tell you to install a 32-bit browser instead of fixing their broken >>> code...) > >> Hmm, that's nasty. I hadn't personally run across any of those yet, >> which is I guess why I didn't know about it. Thanks for the info. > > I've run into it twice in the past two months for apps used inside Red > Hat. ?(Not developed inside Red Hat, I'm glad to say.) ?This is out of a > sample of exactly two apps, since I avoid webapps where I can. ?So I > admit I don't have a lot of data, but from here it looks like a problem. Well if our java implementation is broken it should be broken for 32 bit too. As for sun's java they have released a 64 bit plugin. So this should be no longer relevant. From sanjay.ankur at gmail.com Mon May 11 21:35:24 2009 From: sanjay.ankur at gmail.com (Ankur Sinha) Date: Tue, 12 May 2009 03:05:24 +0530 Subject: Locking assertion failure. Backtrace: In-Reply-To: References: <1241978114.3331.20.camel@localhost.localdomain> <4A07534A.2040509@fedoraproject.org> <1242053033.3331.39.camel@localhost.localdomain> Message-ID: <1242077724.3331.47.camel@localhost.localdomain> On Mon, 2009-05-11 at 22:31 +0200, Kevin Kofler wrote: > OK, the real problem there is that they're abusing Qt's warning/error > system > to handle application errors, which isn't what it's designed for. > That's > why they're redirecting it to a message box. > > I fixed the code to disable that error handler and call QMessageBox > directly > where needed. Please try the following patch: > http://repo.calcforge.org/f10/panini-0.62-x11-lock-recursion.patch hi, Tried the patch out..It works!! Gives this on the terminal though..Again and again..Do we need to fix this too? X Error: BadLength (poly request too large or internal Xlib length error) 16 Extension: 144 (Uknown extension) Minor opcode: 1 (Unknown request) Resource id: 0x4e0002a Here's a screenshot.. I think that's the way the app is supposed to be.. http://ankursinha.fedorapeople.org/panini/panini-screenshot.png @Rahul : Is the packaging done now? regards, Ankur From sundaram at fedoraproject.org Mon May 11 21:50:06 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 12 May 2009 03:20:06 +0530 Subject: Locking assertion failure. Backtrace: In-Reply-To: <1242077724.3331.47.camel@localhost.localdomain> References: <1241978114.3331.20.camel@localhost.localdomain> <4A07534A.2040509@fedoraproject.org> <1242053033.3331.39.camel@localhost.localdomain> <1242077724.3331.47.camel@localhost.localdomain> Message-ID: <4A089D8E.8090104@fedoraproject.org> On 05/12/2009 03:05 AM, Ankur Sinha wrote: > Here's a screenshot.. I think that's the way the app is supposed to be.. > > http://ankursinha.fedorapeople.org/panini/panini-screenshot.png > > @Rahul : Is the packaging done now? Well, you can apply the patch, submit the package for review, send the patch upstream and point them to this thread. That will get the discussions rolling. Rahul From notting at redhat.com Mon May 11 21:48:37 2009 From: notting at redhat.com (Bill Nottingham) Date: Mon, 11 May 2009 17:48:37 -0400 Subject: yum-presto installed by default for Fedora 11? In-Reply-To: References: <4A087B68.4060208@fedoraproject.org> <2a28d2ab0905111229r5d732055o247dfd4a31fd8222@mail.gmail.com> Message-ID: <20090511214837.GA22336@nostromo.devel.redhat.com> > Somewhat, yes. We wanted to be sure that we wouldn't be shipping > something out that would break everyone's updates/installs. > > And we were not completely sure. Moreover, we did not enable deltas until well after the feature freeze. (which is the major contributing factor to why F11 updates were not pushed sooner.) Bill From jkeating at redhat.com Mon May 11 21:49:23 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 May 2009 14:49:23 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1242075520.3658.66.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <200905071959.22508.opensource@till.name> <1241720728.3209.12.camel@localhost.localdomain> <1242073620.3658.64.camel@localhost.localdomain> <1242075520.3658.66.camel@localhost.localdomain> Message-ID: <1242078563.3452.44.camel@localhost.localdomain> On Mon, 2009-05-11 at 22:58 +0200, Christoph Wickert wrote: > > But F-11 updates are not processed, so on the day of release they will > not be available. We push updates early. They're on the mirrors now. > Or how about the people who upgrade from the DVD > without having internet during install? Upgrading from the DVD with internet available won't help you either. Anaconda doesn't have a mode to enable external repos when upgrading. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Mon May 11 21:54:39 2009 From: notting at redhat.com (Bill Nottingham) Date: Mon, 11 May 2009 17:54:39 -0400 Subject: FESco meeting summary for 20090507 In-Reply-To: <20090511140413.GB8730@redhat.com> References: <20090511140413.GB8730@redhat.com> Message-ID: <20090511215439.GB22336@nostromo.devel.redhat.com> Jeremy Katz (katzj at redhat.com) said: > On Sunday, May 10 2009, Jon Stanley said: > > Moreover, with the new architecture support feature in F11, we're now > > supposedly defaulting to an x86_64 kernel on an i686 install if the > > processor supports it (note that I say supposedly because I've not > > personally tested it). Thus you have an x86_64 kernel, and all of the > > goodness that brings, but you still have an i686 userspace. > > Due to some complications, we fell back to the contingency and aren't > installing the x86_64 kernel on the 32bit distro at all for F11 quite a > while ago[1] To elaborate: - yum uses the running architecture to determine $basearch to use in your repo files - Hence, installing an x86_64 kernel means yum immediately switches you to the x86_64 repo. Oops. Also, you'd need one of: - rpm code to allow installing x86_64 kernels when the host arch was x86 *OR* - syslinux/grub code for automatically picking the right kernel, and anaconda changes to ship both on the image While we did create some patches, fixing this in a way that simultaneously: - didn't require changes to existing repo files - wasn't extremely gross is non-trivial. Bill From notting at redhat.com Mon May 11 21:57:52 2009 From: notting at redhat.com (Bill Nottingham) Date: Mon, 11 May 2009 17:57:52 -0400 Subject: FESco meeting summary for 20090507 In-Reply-To: <4A05D52B.7050100@gmail.com> References: <4A05D52B.7050100@gmail.com> Message-ID: <20090511215752.GC22336@nostromo.devel.redhat.com> Toshio Kuratomi (a.badger at gmail.com) said: > One thing that was mentioned was the lack of fs acls at the moment. > After looking at what we have now, I'm not sure that fs acls fix > anything that's not also broken currently. > > Currently: > > * the cvs repository has no fs acls > * unix group for all directories is set to packager with a sticky group bit. > * the cvs acl script limits who can actually commit to packages to > @provenpackager and the specific people involved. > > Implementation-wise, the proposal would allow the cvs acl script to have > @packager as another allowed group so people who are just in the > packager group can commit to a specific package. > > I can see fs acls being used to lock down our repo against bugs in the > cvs acl script or being used to replace the cvs acl script. But that > seems to be somewhat separate from the proposal. I don't think it would > solve anything specific to the proposal but could make things more > secure for both the current and proposed method. > > notting, do you see something that I don't? You *could* swap the permissions so that all packages are only provenpackager-writable, and implement packager (and owner) access via FS acls. Whether that scales or not is another matter. Bill From kevin.kofler at chello.at Mon May 11 21:57:57 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 11 May 2009 23:57:57 +0200 Subject: OpenOffice 3.1 References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <1241990992.3452.6.camel@localhost.localdomain> <6dc6523c0905101458l64811e65lb9f18216a4f93941@mail.gmail.com> <1242064968.2923.615.camel@adam.local.net> <1242072865.2923.670.camel@adam.local.net> Message-ID: Adam Williamson wrote: > See my original post. I don't accept that you can safely have an updates > policy which professes to provide a 'stable' update repository while > allowing tomfoolery like upgrading KDE wholesale. It's just not > practically possible, and our current update repositories prove that > quite nicely. The only consistently practicable update policies are > "minimal necessary changes" and "do whatever you like". If you run a > stable Fedora release and install all official updates, you will get > significant changes in basic functionality and, in all likelihood, > visible regressions. Our current updates policy does not provide a > stable experience along the lines of what you get from distributions > which follow the industry standard "minimal possible change" policy. I don't think I can agree with this. I think equating "version upgrades == unstable" is something which just doesn't make sense. Version upgrades can be categorized into 4 classes (note that the numbers are just examples, they are not authoritative, as some projects use weird versioning schemes or make strange decisions what to include in bugfix releases): 1. the "single fix only" release, often signaled by prepending "a" or an extra ".1" to the version number ? those are almost always completely safe, they aren't any more dangerous than just applying the patch to the RPM in any case (which we usually want to do anyway because those "a"/".1" fixes are often security fixes or "brown paper bag" fixes). 2. the bugfix release, e.g. KDE a.b.n -> a.b.n+1 or the kernel 2.6.a.n stable branches ? those are almost always appropriate for stable updates, after 1 or 2 weeks of testing. Fixing bugs is what updates are for! And those releases are designed to do nothing else. Now there are cases where such releases introduce regressions (e.g. Qt 4.5.1 has some regressions from 4.5.0), so they need to be handled with care, but in general it's a good idea to push these! I don't see how an update from e.g. KDE 4.1.2 to 4.1.3 is going to make "average users" unhappy, all it does it fix bugs and update translations! 3. the minor feature release, e.g. KDE a.n -> a.n+1 or kernel 2.6.n -> 2.6.n+1 ? those need to be handled with care as they can introduce breakage. But those normally (of course it depends on upstream!) don't come with major functionality change which breaks everything: for example, Qt and kdelibs maintain backwards API/ABI compatibility, the kernel often has config options which use the old code rather than the new one for major changes like libata and those options are used in the stable updates, etc. Of course those updates should stay in testing for at least 2 weeks to track down and fix regressions and in some cases pushing the update may be a bad idea altogether. This kind of updates really needs to be evaluated by the maintainer of the individual component. (But I do personally think that in most cases those are OK for a stable update.) 4. the major feature release or rewrite, e.g. KDE 3 -> 4, Amarok 1 -> 2 etc. ? those come with known feature and stability/reliability regressions make absolutely no sense to push as a stable update to a released distro! (Of course there are some project releasing "new major versions" which are not of that type, but in that case they should be handled like "minor feature releases" above. But e.g. Amarok 2 is most definitely a major feature release with significant code rewriting.) I think a "backports" release mixing 1, 2, 3 and 4 is completely useless (how's that different from Rawhide?), whereas 1 and 2, and 3 when carefully done can lead to usable "stable but current" updates. (I could probably live with just 1 and 2, but I think it would be worse than the current system and there would need to be some exceptions, e.g. I think leaving F9 with KDE 4.0 would have been a major disservice to our users.) Thankfully, "1 and 2, and 3 when carefully done" is mostly how Fedora's current updates work. The complaints are about maintainers who refuse to push type 3 or even type 2 updates altogether, or in some cases about maintainers who push type 4 updates or badly-tested/untested type 3 updates. Kevin Kofler From jkeating at redhat.com Mon May 11 22:00:49 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 May 2009 15:00:49 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: References: <1241718097.3209.11.camel@localhost.localdomain> <1241832771.2886.15.camel@localhost.localdomain> <4A04EAAE.50907@freenet.de> <1241836379.2886.30.camel@localhost.localdomain> <1242062337.3452.27.camel@localhost.localdomain> <1242066123.3452.34.camel@localhost.localdomain> <1242074588.2923.673.camel@adam.local.net> Message-ID: <1242079249.3452.45.camel@localhost.localdomain> On Mon, 2009-05-11 at 16:51 -0400, Colin Walters wrote: > > Anyways I'm not saying the DVDs shouldn't be possible to use for > upgrading, what I'm arguing against is the user experience of the DVD > where it just boots into anaconda and asks questions like "Do you want > to install a server or a desktop? Do you want OpenOffice?" etc. A > much better experience is for it to boot into a full working desktop, > and from there you can image it to your drive if you like what you > see, but also in the menus or somewhere else have other options. The problem with this is that if we wanted to offer different options to people, we have to host these huge binary images that hold large amounts of duplicate data and then users have to download these huge things to get a slight difference between them. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Mon May 11 22:05:41 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 May 2009 15:05:41 -0700 Subject: OpenOffice 3.1 In-Reply-To: References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <1241990992.3452.6.camel@localhost.localdomain> <6dc6523c0905101458l64811e65lb9f18216a4f93941@mail.gmail.com> <1242064968.2923.615.camel@adam.local.net> <1242072865.2923.670.camel@adam.local.net> Message-ID: <1242079541.3452.48.camel@localhost.localdomain> On Mon, 2009-05-11 at 23:57 +0200, Kevin Kofler wrote: > 4. the major feature release or rewrite, e.g. KDE 3 -> 4, Amarok 1 -> 2 > etc. ? those come with known feature and stability/reliability regressions > make absolutely no sense to push as a stable update to a released distro! > (Of course there are some project releasing "new major versions" which are > not of that type, but in that case they should be handled like "minor > feature releases" above. But e.g. Amarok 2 is most definitely a major > feature release with significant code rewriting.) The problem I think we're having is that while KDE may use sane numbers to represent these 4 classes, not all upstreams do. But users see KDE do a a.b.n to a.b.n+1 or even a.b to a.b+1 and think that it's OK to do that with their software too, even though their upstream may do massive feature changes between a.b and a.b+1. Basically trying to insert numbers anywhere in this discussion is going to fail, and we have to stick to concepts like you outlined. For what its worth, I agree with the 4 classes and which are appropriate or not. Unfortunately I don't think everybody agrees. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From smooge at gmail.com Mon May 11 22:08:09 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 11 May 2009 16:08:09 -0600 Subject: SPARC Status (Was Re: Secondary Architecture Status?) In-Reply-To: <4A088D45.7010607@redhat.com> References: <1241911202.24436.81.camel@macbook.infradead.org> <4A0862F1.2030608@redhat.com> <20090511185147.GA3256@yoda.jdub.homelinux.org> <1242071724.2923.656.camel@adam.local.net> <4A088D45.7010607@redhat.com> Message-ID: <80d7e4090905111508x55d813caxf6db6df6bf49f831@mail.gmail.com> On Mon, May 11, 2009 at 2:40 PM, Tom "spot" Callaway wrote: > On 05/11/2009 03:55 PM, Adam Williamson wrote: >> On Mon, 2009-05-11 at 14:51 -0400, Josh Boyer wrote: >> >>> I would really like to see a proliferation of secondary arches in >>> Fedora, but I don't think 'workstation' is a viable usage model for >>> them to get started. ?Most will have to focus on the type of hardware >>> that actually sells for that arch, and yes I realize that can be at >>> odds with some of the directions Fedora is going. >> >> Semi-sidetrack here: Ubuntu has a secondary 'architecture' called LPIA >> which is, in fact, just an alternative set of compiler optimizations >> which they claim results in better code for 'netbook >> systems' (presumably meaning 'Atom CPUs'). Would that be something we >> could look into, or not interesting? > > Sure, I see no reason why someone couldn't take that on as a "secondary > arch". It would need a new arch identifier target for rpm to prevent > namespace collisions. > x86_32? x86_green? It would be interesting to see what that would break in RPM ;). -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From snecklifter at gmail.com Mon May 11 22:08:20 2009 From: snecklifter at gmail.com (Christopher Brown) Date: Mon, 11 May 2009 23:08:20 +0100 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A0814ED.60205@redhat.com> References: <4A0814ED.60205@redhat.com> Message-ID: <364d303b0905111508l6ff8a4c4ufa7d2c23f921cb83@mail.gmail.com> 2009/5/11 Stephen Gallagher : > OK, first off, why in $DEITY's name are we including Firefox 3.5b4 and > Thunderbird 3.0b2 in Fedora 11? These were planned features waaaaay back. http://fedoraproject.org/wiki/Features/Thunderbird_3 http://fedoraproject.org/wiki/Features/Firefox_3.1 I don't recall you raising your objection at the time. Both have had considerable review by FESCO and others so please don't complain about this so late in the day. -- Christopher Brown From cra at WPI.EDU Mon May 11 22:15:15 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 11 May 2009 18:15:15 -0400 Subject: yum-presto installed by default for Fedora 11? In-Reply-To: <20090511214837.GA22336@nostromo.devel.redhat.com> References: <4A087B68.4060208@fedoraproject.org> <2a28d2ab0905111229r5d732055o247dfd4a31fd8222@mail.gmail.com> <20090511214837.GA22336@nostromo.devel.redhat.com> Message-ID: <20090511221515.GA31498@angus.ind.WPI.EDU> On Mon, May 11, 2009 at 05:48:37PM -0400, Bill Nottingham wrote: > > Somewhat, yes. We wanted to be sure that we wouldn't be shipping > > something out that would break everyone's updates/installs. > > > > And we were not completely sure. > > Moreover, we did not enable deltas until well after the feature freeze. > (which is the major contributing factor to why F11 updates were not pushed > sooner.) Did you already get the bodhi/updates process deltified? I know that was one reason things were lagging--rawhide got deltas, but the regular updates process hadn't yet. From kyle at mcmartin.ca Mon May 11 22:18:12 2009 From: kyle at mcmartin.ca (Kyle McMartin) Date: Mon, 11 May 2009 18:18:12 -0400 Subject: SPARC Status (Was Re: Secondary Architecture Status?) In-Reply-To: <4A088D45.7010607@redhat.com> References: <1241911202.24436.81.camel@macbook.infradead.org> <4A0862F1.2030608@redhat.com> <20090511185147.GA3256@yoda.jdub.homelinux.org> <1242071724.2923.656.camel@adam.local.net> <4A088D45.7010607@redhat.com> Message-ID: <20090511221812.GB7213@bombadil.infradead.org> On Mon, May 11, 2009 at 04:40:37PM -0400, Tom spot Callaway wrote: > On 05/11/2009 03:55 PM, Adam Williamson wrote: > > On Mon, 2009-05-11 at 14:51 -0400, Josh Boyer wrote: > > > >> I would really like to see a proliferation of secondary arches in > >> Fedora, but I don't think 'workstation' is a viable usage model for > >> them to get started. Most will have to focus on the type of hardware > >> that actually sells for that arch, and yes I realize that can be at > >> odds with some of the directions Fedora is going. > > > > Semi-sidetrack here: Ubuntu has a secondary 'architecture' called LPIA > > which is, in fact, just an alternative set of compiler optimizations > > which they claim results in better code for 'netbook > > systems' (presumably meaning 'Atom CPUs'). Would that be something we > > could look into, or not interesting? > > Sure, I see no reason why someone couldn't take that on as a "secondary > arch". It would need a new arch identifier target for rpm to prevent > namespace collisions. > To be fair, the Ubuntu 'lpia' distribution actually performs /worse/ than normal compiled x86 code. (Since the GCC version they used didn't support scheduling for Atom. notting, others, and I have all done benchmarks when the i586 switch took place to see this.) Profiling to see if the atom target actually helps at all in gcc-4.4 thanks to Jakub backporting from GCC trunk would be a worthwhile endeavour though. regards, Kyle From awilliam at redhat.com Mon May 11 22:21:37 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 11 May 2009 15:21:37 -0700 Subject: OpenOffice 3.1 In-Reply-To: <1242079541.3452.48.camel@localhost.localdomain> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <1241990992.3452.6.camel@localhost.localdomain> <6dc6523c0905101458l64811e65lb9f18216a4f93941@mail.gmail.com> <1242064968.2923.615.camel@adam.local.net> <1242072865.2923.670.camel@adam.local.net> <1242079541.3452.48.camel@localhost.localdomain> Message-ID: <1242080497.2923.676.camel@adam.local.net> On Mon, 2009-05-11 at 15:05 -0700, Jesse Keating wrote: > On Mon, 2009-05-11 at 23:57 +0200, Kevin Kofler wrote: > > 4. the major feature release or rewrite, e.g. KDE 3 -> 4, Amarok 1 -> 2 > > etc. ? those come with known feature and stability/reliability regressions > > make absolutely no sense to push as a stable update to a released distro! > > (Of course there are some project releasing "new major versions" which are > > not of that type, but in that case they should be handled like "minor > > feature releases" above. But e.g. Amarok 2 is most definitely a major > > feature release with significant code rewriting.) > > The problem I think we're having is that while KDE may use sane numbers > to represent these 4 classes, not all upstreams do. But users see KDE > do a a.b.n to a.b.n+1 or even a.b to a.b+1 and think that it's OK to do > that with their software too, even though their upstream may do massive > feature changes between a.b and a.b+1. > > Basically trying to insert numbers anywhere in this discussion is going > to fail, and we have to stick to concepts like you outlined. For what > its worth, I agree with the 4 classes and which are appropriate or not. > Unfortunately I don't think everybody agrees. Exactly. I'm replying to Jesse to keep things compact, but to address one point from your post: "equating "version upgrades == unstable" is not the point. It's not ==, it's *may possibly equal*. As I said, one of the two practical update policies is "minimum possible change necessary to fix the specific issue being addressed". If, say, you want to fix a single bug in awesomeapplication 1.0, and awesomeapplication 1.0.1 does nothing but fix that bug, then shipping awesomeapplication 1.0.1 as an update passes the policy. It's not as simple as saying "you can't ship any version updates". The policy is, quite simply, as it says: you ship the minimum necessary code changes to address the specific bug the update is intended to address. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From sundaram at fedoraproject.org Mon May 11 22:26:23 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 12 May 2009 03:56:23 +0530 Subject: glibc fork ? In-Reply-To: <4A088A8B.6070007@redhat.com> References: <4A02F8D3.2010807@poolshark.org> <4A036082.8000107@fedoraproject.org> <20090509160428.0bf3c0e6.zaitcev@redhat.com> <1241911685.24436.93.camel@macbook.infradead.org> <4A088A8B.6070007@redhat.com> Message-ID: <4A08A60F.4030009@fedoraproject.org> On 05/12/2009 01:58 AM, Casey Dahlin wrote: > David Woodhouse wrote: >> On Sat, 2009-05-09 at 16:04 -0600, Pete Zaitcev wrote: >>> As far as Fedora goes, IMHO we should watch the developments and >>> evaluate the performance of eglibc against a simple criterium: >>> if they add bugs or fix bugs. Next big performance anomaly in >>> something like MySQL will prove eglibc people's worth. If they >>> just wait for Jakub and Uli to fix it for them, I don't see us >>> switching. >> I have no particularly strong opinion either way, and I agree with your >> assessment -- but do let me know when I can start using strlcat(). :) >> > > Never! Drepper is right about str* being an awful family of functions, even their new strl* incarnations. > > Now, granted, I want them around, for the simple fact that I want to build BSD code on linux (that jot command would be nice to have...) but still. Package http://libbsd.freedesktop.org/wiki/ Rahul From sundaram at fedoraproject.org Mon May 11 22:27:43 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 12 May 2009 03:57:43 +0530 Subject: yum-presto installed by default for Fedora 11? In-Reply-To: <20090511221515.GA31498@angus.ind.WPI.EDU> References: <4A087B68.4060208@fedoraproject.org> <2a28d2ab0905111229r5d732055o247dfd4a31fd8222@mail.gmail.com> <20090511214837.GA22336@nostromo.devel.redhat.com> <20090511221515.GA31498@angus.ind.WPI.EDU> Message-ID: <4A08A65F.7040000@fedoraproject.org> On 05/12/2009 03:45 AM, Chuck Anderson wrote: > On Mon, May 11, 2009 at 05:48:37PM -0400, Bill Nottingham wrote: >>> Somewhat, yes. We wanted to be sure that we wouldn't be shipping >>> something out that would break everyone's updates/installs. >>> >>> And we were not completely sure. >> Moreover, we did not enable deltas until well after the feature freeze. >> (which is the major contributing factor to why F11 updates were not pushed >> sooner.) > > Did you already get the bodhi/updates process deltified? Yes. Refer http://jwboyer.livejournal.com/31831.html Rahul From ivazqueznet at gmail.com Mon May 11 22:23:50 2009 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Mon, 11 May 2009 18:23:50 -0400 Subject: yum-presto installed by default for Fedora 11? In-Reply-To: <20090511221515.GA31498@angus.ind.WPI.EDU> References: <4A087B68.4060208@fedoraproject.org> <2a28d2ab0905111229r5d732055o247dfd4a31fd8222@mail.gmail.com> <20090511214837.GA22336@nostromo.devel.redhat.com> <20090511221515.GA31498@angus.ind.WPI.EDU> Message-ID: <1242080630.4183.52.camel@ignacio.ignacio.lan> On Mon, 2009-05-11 at 18:15 -0400, Chuck Anderson wrote: > On Mon, May 11, 2009 at 05:48:37PM -0400, Bill Nottingham wrote: > > > Somewhat, yes. We wanted to be sure that we wouldn't be shipping > > > something out that would break everyone's updates/installs. > > > > > > And we were not completely sure. > > > > Moreover, we did not enable deltas until well after the feature freeze. > > (which is the major contributing factor to why F11 updates were not pushed > > sooner.) > > Did you already get the bodhi/updates process deltified? I know that > was one reason things were lagging--rawhide got deltas, but the > regular updates process hadn't yet. http://download.fedora.redhat.com/pub/fedora/linux/updates/11/i386/drpms/ -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kevin.kofler at chello.at Mon May 11 22:44:40 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 12 May 2009 00:44:40 +0200 Subject: FESco meeting summary for 20090507 References: <200905110014.50581.bjorn@xn--rombobjrn-67a.se> <200905112159.08449.bjorn@xn--rombobjrn-67a.se> Message-ID: Bj?rn Persson wrote: > Then I give you instead this Mini-ITX board with a Geode LX 800 processor, > which is compatible with x86 but not x86_64: > > http://www.alix-board.de/produkte/alix1d.html OK, so there are technically current 32-bit machines which are not netbooks. Certainly not the common case though. ;-) And people should choose an Atom-330-based solution instead. :-) Kevin Kofler From dmalcolm at redhat.com Mon May 11 22:52:58 2009 From: dmalcolm at redhat.com (David Malcolm) Date: Mon, 11 May 2009 18:52:58 -0400 Subject: Database SIG? Message-ID: <1242082378.30883.73.camel@radiator.bos.redhat.com> Would anyone else be interested in a database special-interest-group within Fedora? I don't see one at http://fedoraproject.org/wiki/SIGs I seem to spend much of my time working with SQL these days, and I'm interested in both client-side tools for mucking about with SQL, and with server-side implementations, test suites, plus the more esoteric things like XML and object databases, SPARQL, Tutorial D, etc. So there'd be some overlap with the Server SIG, but there are plenty of GUI tools as well (e.g. openoffice-base, schema visualizers, etc). High-level goal might be to make Fedora the best place to go for someone trying to learn about SQL and relational databases [1], and other types of db. A first step might be to gather a list of interesting open-source database software, and then to package more of it for Fedora. I've tried looking for such a list, but unfortunately the package database tends to dominate my queries. Anyone else out there? Dave [1] and, indeed, the differences between the two, for any followers of the "Third Manifesto" out there From kevin.kofler at chello.at Mon May 11 23:04:44 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 12 May 2009 01:04:44 +0200 Subject: 182 pending F11 stable updates. WTF? References: <1241718097.3209.11.camel@localhost.localdomain> <200905071959.22508.opensource@till.name> <1241720728.3209.12.camel@localhost.localdomain> <1242073620.3658.64.camel@localhost.localdomain> <1242075520.3658.66.camel@localhost.localdomain> Message-ID: Christoph Wickert wrote: > But F-11 updates are not processed, so on the day of release they will > not be available. Or how about the people who upgrade from the DVD They'll be screwed anyway no matter when the update comes out, unless they're one of those impatient folks upgrading on release day. They'll get the F11 build with their first post-upgrade yum update. Kevin Kofler From cmadams at hiwaay.net Mon May 11 23:06:47 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 11 May 2009 18:06:47 -0500 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <364d303b0905111508l6ff8a4c4ufa7d2c23f921cb83@mail.gmail.com> References: <4A0814ED.60205@redhat.com> <364d303b0905111508l6ff8a4c4ufa7d2c23f921cb83@mail.gmail.com> Message-ID: <20090511230646.GA622256@hiwaay.net> Once upon a time, Christopher Brown said: > 2009/5/11 Stephen Gallagher : > > OK, first off, why in $DEITY's name are we including Firefox 3.5b4 and > > Thunderbird 3.0b2 in Fedora 11? > > These were planned features waaaaay back. > > http://fedoraproject.org/wiki/Features/Thunderbird_3 > http://fedoraproject.org/wiki/Features/Firefox_3.1 I have no real opinion about this either way (since FF will be RC and I don't use Thunderbird), but having this in both feature pages: Contingency Plan There is no turning back. seems to me something that shouldn't be acceptable. Both feature pages also say "Upgrade ... to the latest release". If neither new version has been released, how can this feature claim to be 100% complete? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From kevin.kofler at chello.at Mon May 11 23:14:23 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 12 May 2009 01:14:23 +0200 Subject: glibc fork ? References: <4A02F8D3.2010807@poolshark.org> <4A036082.8000107@fedoraproject.org> <20090509160428.0bf3c0e6.zaitcev@redhat.com> <1241911685.24436.93.camel@macbook.infradead.org> <4A088A8B.6070007@redhat.com> <4A08A60F.4030009@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > Package http://libbsd.freedesktop.org/wiki/ I was crazy enough to check the license of every single source file in there: the good news: to the best of my knowledge, the package is: 1. Free Software and acceptable for Fedora, 2. 100% GPL-compatible (no advertising clause or similar nonsense) and 3. 100% non-copyleft, so there are no license issues whatsoever. The license tag should be: License: BSD and ISC and Copyright only and Public Domain (one of the "Copyright only" files is the "Beerware license" which is listed in Licensing, the other says: > * Modification and redistribution in source and binary forms is > * permitted provided that due credit is given to the author and the > * OpenBSD project (for instance by leaving this copyright notice > * intact). ). Kevin Kofler From kevin.kofler at chello.at Mon May 11 23:27:07 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 12 May 2009 01:27:07 +0200 Subject: Locking assertion failure. Backtrace: References: <1241978114.3331.20.camel@localhost.localdomain> <4A07534A.2040509@fedoraproject.org> <1242053033.3331.39.camel@localhost.localdomain> <1242077724.3331.47.camel@localhost.localdomain> Message-ID: Ankur Sinha wrote: > Gives this on the terminal though..Again and again..Do we need to fix > this too? > > X Error: BadLength (poly request too large or internal Xlib length > error) 16 > Extension: 144 (Uknown extension) > Minor opcode: 1 (Unknown request) > Resource id: 0x4e0002a This is exactly the Oxygen bug (or bug triggered by Oxygen, I haven't debugged it yet, so I'm not sure where the actual blame lies) which triggers the XError->qWarning->QMessageBox->X lock recursion. I'll see what I can do to track this down and hopefully fix this. Kevin Kofler From tibbs at math.uh.edu Tue May 12 00:05:45 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 11 May 2009 19:05:45 -0500 Subject: Agenda for the 2009-05-12 Packaging Committee meeting Message-ID: The Packaging Committee will meet Tuesday, 2009-05-12 at 17:00UTC in the #fedora-meeting channel on chat.freenode.net. FPC works from the agenda at https://fedoraproject.org/wiki/Packaging/GuidelinesTodo; here are some things which should be brought up for discussion at the next meeting: GConf scriptlets (revisit from previous meeting) - https://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/GConf Globus (revisit from previous meeting) - https://fedoraproject.org/wiki/PackagingDrafts/Globus Guidelines for package pre-reviews - https://fedoraproject.org/wiki/Pre-review_Guidelines_(draft) Manpage guidelines - https://fedoraproject.org/wiki/MAN_pages_which_exists_in_other_places(draft) - J< From lists at sapience.com Tue May 12 00:26:27 2009 From: lists at sapience.com (Mail Lists) Date: Mon, 11 May 2009 20:26:27 -0400 Subject: Fedora (Linux) is Destroying it self In-Reply-To: References: <4A082E70.7030904@TheTroubleshooters.dk> Message-ID: <4A08C233.4020902@sapience.com> On 05/11/2009 11:07 AM, drago01 wrote: > > This is not true, in case of gnome you can access everything mounted > by nautilus / gvfs by accessing ~/.gvfs works with ANY app. > Except possibly a process running as root. From bruno at wolff.to Tue May 12 00:40:47 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 11 May 2009 19:40:47 -0500 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: References: <1241718097.3209.11.camel@localhost.localdomain> <200905071959.22508.opensource@till.name> <1241720728.3209.12.camel@localhost.localdomain> <1242073620.3658.64.camel@localhost.localdomain> <1242075520.3658.66.camel@localhost.localdomain> Message-ID: <20090512004047.GA10236@wolff.to> On Tue, May 12, 2009 at 01:04:44 +0200, Kevin Kofler wrote: > Christoph Wickert wrote: > > But F-11 updates are not processed, so on the day of release they will > > not be available. Or how about the people who upgrade from the DVD > > They'll be screwed anyway no matter when the update comes out, unless > they're one of those impatient folks upgrading on release day. They'll get > the F11 build with their first post-upgrade yum update. Those are the patient people. f11 updates and testing are already available and you can already be pulling from them if you have been using rawhide. I've already given some negative feedback to an f11 package in bodhi. From tgl at redhat.com Tue May 12 01:00:16 2009 From: tgl at redhat.com (Tom Lane) Date: Mon, 11 May 2009 21:00:16 -0400 Subject: FESco meeting summary for 20090507 In-Reply-To: References: <1242062320.2923.586.camel@adam.local.net> <6764.1242064296@sss.pgh.pa.us> <1242071296.2923.654.camel@adam.local.net> <29158.1242074791@sss.pgh.pa.us> Message-ID: <13710.1242090016@sss.pgh.pa.us> drago01 writes: > On Mon, May 11, 2009 at 10:46 PM, Tom Lane wrote: >> I've run into it twice in the past two months for apps used inside Red >> Hat. ?(Not developed inside Red Hat, I'm glad to say.) ?This is out of a >> sample of exactly two apps, since I avoid webapps where I can. ?So I >> admit I don't have a lot of data, but from here it looks like a problem. > Well if our java implementation is broken it should be broken for 32 bit too. > As for sun's java they have released a 64 bit plugin. I'm not speaking of the JVM --- I'm talking about unportable applications. I suspect most of the problem is JNI code, but I cannot claim to have attempted to debug it. > So this should be no longer relevant. Which part of "you're wrong" is not clear? This is a very real issue. regards, tom lane From tgl at redhat.com Tue May 12 01:14:20 2009 From: tgl at redhat.com (Tom Lane) Date: Mon, 11 May 2009 21:14:20 -0400 Subject: SPARC Status (Was Re: Secondary Architecture Status?) In-Reply-To: <5256d0b0905111202x2df6b773y689fe618b502315c@mail.gmail.com> References: <1241911202.24436.81.camel@macbook.infradead.org> <4A0862F1.2030608@redhat.com> <20090511185147.GA3256@yoda.jdub.homelinux.org> <5256d0b0905111202x2df6b773y689fe618b502315c@mail.gmail.com> Message-ID: <19804.1242090860@sss.pgh.pa.us> Peter Robinson writes: >> I would really like to see a proliferation of secondary arches in >> Fedora, but I don't think 'workstation' is a viable usage model for >> them to get started. ?Most will have to focus on the type of hardware >> that actually sells for that arch, and yes I realize that can be at >> odds with some of the directions Fedora is going. > I think there are most likely two candidates for a secondary arch > other than PPC. The first is sparc where from the server point of view > where its probably about as prolific as PPC in that regard. The second > would be arm but that is more from the NetBook/MID/Phone/STB > perspective where there are quite a few devices in the 500Mhz-1Ghz > range with 256-512Mb RAM. With the OLPC X0-1 we've proven that Fedora > can run relatively well on that sort of spec, they also tend to be > relatively cheap. The problem that I've got with relegating PPC to a secondary arch is exactly that there are few other candidates for arches that will command enough interest to force maintainers to pay attention. And that will mean that Fedora becomes an x86 monoculture over time --- apps won't work on anything else, and their maintainers won't take any interest in fixing them, and that provides reason for other maintainers to stop worrying about portability of their apps, and it's a vicious circle. Right now, people are at least compelled to pay some attention to basic issues like endianness. If the only primary arches are little-endian then hardware independence is going to disappear. regards, tom lane From a.badger at gmail.com Tue May 12 01:13:29 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 11 May 2009 18:13:29 -0700 Subject: cpan2rpm In-Reply-To: <20090510203338.7d00dd5a@faldor.intranet> References: <4A05BF03.6070508@fi.muni.cz> <1241891211.9577.0.camel@localhost.localdomain> <20090510194926.243bf9e9@faldor.intranet> <4A0716E7.4070804@gmail.com> <20090510203338.7d00dd5a@faldor.intranet> Message-ID: <4A08CD39.2040800@gmail.com> Michael Schwendt wrote: > On Sun, 10 May 2009 11:03:19 -0700, Toshio wrote: > >>>> Most likely: http://toshio.fedorapeople.org/pkg-orphans.txt >>> Does that mean I can stop with following the non-responsive maintainer >>> policy for ghenry and "cpan2rpm" (as it's on the list)? >>> https://bugzilla.redhat.com/498746 >>> >> Yes. I'll be mass orphaning this tonight. Do you think this package >> should be retired instead of simply orphaned? > > Retiring it would be better. Bz 498746 sums up that everybody seems to > use'n'prefer cpanspec instead. There's somebody who would sign up as the > new owner (as a last resort), but he would also prefer to retire cpan2rpm. > Retired. Thanks for the heads up! -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From jkeating at redhat.com Tue May 12 01:23:09 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 May 2009 18:23:09 -0700 Subject: SPARC Status (Was Re: Secondary Architecture Status?) In-Reply-To: <19804.1242090860@sss.pgh.pa.us> References: <1241911202.24436.81.camel@macbook.infradead.org> <4A0862F1.2030608@redhat.com> <20090511185147.GA3256@yoda.jdub.homelinux.org> <5256d0b0905111202x2df6b773y689fe618b502315c@mail.gmail.com> <19804.1242090860@sss.pgh.pa.us> Message-ID: <1242091389.3452.58.camel@localhost.localdomain> On Mon, 2009-05-11 at 21:14 -0400, Tom Lane wrote: > The problem that I've got with relegating PPC to a secondary arch is > exactly that there are few other candidates for arches that will command > enough interest to force maintainers to pay attention. And that will > mean that Fedora becomes an x86 monoculture over time --- apps won't > work on anything else, and their maintainers won't take any interest in > fixing them, and that provides reason for other maintainers to stop > worrying about portability of their apps, and it's a vicious circle. > > Right now, people are at least compelled to pay some attention to basic > issues like endianness. If the only primary arches are little-endian > then hardware independence is going to disappear. This would be true if PPC as a high visible secondary arch fails. Lets not let that happen. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Tue May 12 01:59:27 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 May 2009 18:59:27 -0700 Subject: fedora-release-11-1 Message-ID: <1242093567.3452.87.camel@localhost.localdomain> Tomorrow's rawhide with have the fedora-release package I hope will be final version for Fedora 11. It enables the fedora and updates repos, and disables the rawhide repo. Mirrormanager will redirect requests for the fedora 11 repo to the public rawhide directory until we're ready to release. This allows people to easily transition into the Fedora 11 release without having to modify config files. If you wish to remain on Fedora 11, make sure that the .repo files as shipped with this package are the ones in use. Check for .rpmnew files in /etc/yum.repos.d/ and compare them to your existing .repo files to take into account any new configuration. We do have a number of Fedora 11 updates and testing updates already pushed, these are things that maintainers felt were not suitable to break the devel freeze and instead wished to push them as "zero day" updates. Feedback in bodhi would be greatly appreciated for these packages if you wish to try them. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From smooge at gmail.com Tue May 12 03:09:50 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 11 May 2009 21:09:50 -0600 Subject: SPARC Status (Was Re: Secondary Architecture Status?) In-Reply-To: <19804.1242090860@sss.pgh.pa.us> References: <1241911202.24436.81.camel@macbook.infradead.org> <4A0862F1.2030608@redhat.com> <20090511185147.GA3256@yoda.jdub.homelinux.org> <5256d0b0905111202x2df6b773y689fe618b502315c@mail.gmail.com> <19804.1242090860@sss.pgh.pa.us> Message-ID: <80d7e4090905112009i5269bad8j61e91f30b45b3641@mail.gmail.com> On Mon, May 11, 2009 at 7:14 PM, Tom Lane wrote: > Peter Robinson writes: >>> I would really like to see a proliferation of secondary arches in >>> Fedora, but I don't think 'workstation' is a viable usage model for >>> them to get started. ?Most will have to focus on the type of hardware >>> that actually sells for that arch, and yes I realize that can be at >>> odds with some of the directions Fedora is going. > >> I think there are most likely two candidates for a secondary arch >> other than PPC. The first is sparc where from the server point of view >> where its probably about as prolific as PPC in that regard. The second >> would be arm but that is more from the NetBook/MID/Phone/STB >> perspective where there are quite a few devices in the 500Mhz-1Ghz >> range with 256-512Mb RAM. With the OLPC X0-1 we've proven that Fedora >> can run relatively well on that sort of spec, they also tend to be >> relatively cheap. > > The problem that I've got with relegating PPC to a secondary arch is > exactly that there are few other candidates for arches that will command > enough interest to force maintainers to pay attention. ?And that will > mean that Fedora becomes an x86 monoculture over time --- apps won't Well even the PPC is going that way.. other than the PlayStation3 where does someone run into it these days? In fact sadly, where does someone run into anything but x86 anymore in a platform that is 'hackable'. Yes I love that my soon to be gotten new phone runs linux.. but typing on a keyboard smaller than a Timex Sinclair doesn't seem like something I hack on all day.. I run an emulator to hack on it and then play the hacked version of Tux Racer on it. However this is more of a moan to the fact that the world is moving towards 99.9999% x86 :(. [PS I actually miss supporting Alpha and Sparc even though I know they were less than 1% of the market.. they fixed lots of things.. but trying to get a hold of one and keeping them running is frickin expensive.] -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From cmadams at hiwaay.net Tue May 12 04:05:06 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 11 May 2009 23:05:06 -0500 Subject: SPARC Status (Was Re: Secondary Architecture Status?) In-Reply-To: <80d7e4090905112009i5269bad8j61e91f30b45b3641@mail.gmail.com> References: <1241911202.24436.81.camel@macbook.infradead.org> <4A0862F1.2030608@redhat.com> <20090511185147.GA3256@yoda.jdub.homelinux.org> <5256d0b0905111202x2df6b773y689fe618b502315c@mail.gmail.com> <19804.1242090860@sss.pgh.pa.us> <80d7e4090905112009i5269bad8j61e91f30b45b3641@mail.gmail.com> Message-ID: <20090512040506.GB1168313@hiwaay.net> Once upon a time, Stephen John Smoogen said: > [PS I actually miss supporting Alpha and Sparc even though I know they > were less than 1% of the market.. they fixed lots of things.. but > trying to get a hold of one and keeping them running is frickin > expensive.] I've got a couple of SPARCs at home, but one is dog-slow and the other makes more noise than the vacuum cleaner, the washing machine, and all my other computers combined. I'll probably have an Alpha at home before long as well, but all three systems will probably end up in the closet. I'd like to get the good SPARC (SunFire V480 with 4 900MHz CPUs and 8G RAM) running Linux and try to help, but Aurora crashed during install and I haven't had a chance to try Fedora (or find a place for it where the noise doesn't annoy the !@#% out of me). However, you are right; for the average person hacking at home, the only practical alternatives are 32 bit and 64 bit x86. You can play with the odd MIPS appliance, but you usually can't do much there (so not really a target for Fedora even if somebody was trying). ARM is the only other possible target, but that's still not really a target the average person can hack. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From kushaldas at gmail.com Tue May 12 05:29:57 2009 From: kushaldas at gmail.com (Kushal Das) Date: Tue, 12 May 2009 10:59:57 +0530 Subject: What is the best way to store information cross desktop Message-ID: Hi all, If one application (with GUI) wants to store informations (like username, password, some other texts) cross desktop, what is the best way to achieve that? A Gnome application can use gconf/gnome keyring or a KDE application can use KWallet, but those two are totally desktop specific. I know people who use Gnome don't want to run KWallet or a KDE user will not like to use any gnome way to store information. I am working on Python (PyKDE4) based Wordpress blog client and I want it to run properly on any desktop. Kushal -- http://fedoraproject.org http://kushaldas.in From rc040203 at freenet.de Tue May 12 05:31:39 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 12 May 2009 07:31:39 +0200 Subject: SPARC Status (Was Re: Secondary Architecture Status?) In-Reply-To: <1242071724.2923.656.camel@adam.local.net> References: <1241911202.24436.81.camel@macbook.infradead.org> <4A0862F1.2030608@redhat.com> <20090511185147.GA3256@yoda.jdub.homelinux.org> <1242071724.2923.656.camel@adam.local.net> Message-ID: <4A0909BB.4030807@freenet.de> Adam Williamson wrote: > On Mon, 2009-05-11 at 14:51 -0400, Josh Boyer wrote: > >> I would really like to see a proliferation of secondary arches in >> Fedora, but I don't think 'workstation' is a viable usage model for >> them to get started. Most will have to focus on the type of hardware >> that actually sells for that arch, and yes I realize that can be at >> odds with some of the directions Fedora is going. > > Semi-sidetrack here: Ubuntu has a secondary 'architecture' called LPIA > which is, in fact, just an alternative set of compiler optimizations > which they claim results in better code for 'netbook > systems' (presumably meaning 'Atom CPUs'). Would that be something we > could look into, or not interesting? It likely is something worth looking into, but based on my experiences with Fedora on my netbook, I am having doubts compiler optimizations alone are worth a "secondary arch". At least on my netbook, neither "speed" or "space" (mine has a disk) are actual problems. The actual problems I am facing are: a) Low level related issues (HW/drivers/kernels, Xserver, WLAN, ..., suspend/resume, function-keys). I.e. essentially the same issues as on many other machines, esp. notebooks. b) GUI layout issues: Much of the current DEs and GUI-apps appear not to be prepared/designed for usage on small, wide displays. Ralf From rc040203 at freenet.de Tue May 12 06:24:15 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 12 May 2009 08:24:15 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <870180fe0905111205x37683fa5gb246bab58a5c02a1@mail.gmail.com> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08381D.5030604@freenet.de> <870180fe0905111205x37683fa5gb246bab58a5c02a1@mail.gmail.com> Message-ID: <4A09160F.1000403@freenet.de> Jerry James wrote: > On Mon, May 11, 2009 at 12:35 PM, Seth Vidal wrote: >> "This thread will bear no good results and I'm tired of everything being full of bile and vitriol" > > Part of the problem may be that people who are happy have no trigger > that fires to tell them, "I should post a message about how happy I > am!" So you wind up with lots of threads started by unhappy people. Correct. It's the bugs and issues which cause people to complain. > Things have been even better since Ville talked me into donating my > private stash of RPMs to Fedora. Now other people get to take > advantage of the packaging work I did, and the upstreams benefit from > having more users using their code [1]. Life is good. What you outline above, is the only remaining motiviation for continuing to contribute to Fedora - This used to be different. It's a direct consequence of certain developments and of certain people being involved in Fedora. >> I won't be running for the fedora board in the next round of elections. Your freedom, your liberty. > Long live the meritocracy! To me, "meritocracy" is just a euphemism for other terms you probably don't want to hear. Ralf From a.badger at gmail.com Tue May 12 06:54:06 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 11 May 2009 23:54:06 -0700 Subject: FESco meeting summary for 20090507 In-Reply-To: <4A05BF03.6070508@fi.muni.cz> References: <4A05BF03.6070508@fi.muni.cz> Message-ID: <4A091D0E.3050102@gmail.com> Milos Jakubicek wrote: > > Could you please send then a list of packages that are going to be > orphaned? > This is the final list of packages that were orphaned and the releases they were orphaned in. Note that some of them might be retired and shouldn't be picked back up in addition to having ownership removed: orphaning VLGothic-fonts on ['devel', 'F-9', 'F-10'] orphaning ant-contrib on ['devel', 'F-9', 'F-10', 'F-11'] orphaning autotrace on ['devel', 'F-9', 'F-10', 'F-11'] orphaning bmake on ['devel', 'F-9', 'F-10', 'F-11'] orphaning buoh on ['devel', 'F-9', 'F-10', 'F-11'] orphaning cpan2rpm on ['devel', 'F-9', 'F-10', 'F-11'] orphaning drapes on ['devel', 'F-9', 'F-10', 'F-11'] orphaning elsa on ['devel', 'F-9', 'F-10', 'F-11'] orphaning fig2ps on ['devel', 'F-9', 'F-10', 'F-11'] orphaning firestarter on ['devel', 'F-9', 'F-10', 'F-11'] orphaning fish on ['devel', 'F-9', 'F-10', 'F-11'] orphaning flpsed on ['devel', 'F-9', 'F-10', 'F-11'] orphaning fmit on ['devel', 'F-9', 'F-10', 'F-11'] orphaning fontypython on ['devel', 'F-9', 'F-10', 'F-11'] orphaning gconf-cleaner on ['devel', 'F-9', 'F-10', 'F-11'] orphaning gfa on ['devel', 'F-9', 'F-10', 'F-11'] orphaning gimp-lqr-plugin on ['devel', 'F-9', 'F-10', 'F-11'] orphaning ginac on ['EL-5'] orphaning glipper on ['devel', 'F-9', 'F-10', 'F-11'] orphaning gnome-applet-netmon on ['devel', 'F-9', 'F-10'] orphaning gnome-compiz-manager on ['devel', 'F-9', 'F-10', 'F-11'] orphaning gnome-specimen on ['devel', 'F-9', 'F-10', 'F-11'] orphaning gnubiff on ['devel', 'F-9', 'F-10', 'F-11'] orphaning gstm on ['devel', 'F-9', 'F-10', 'F-11'] orphaning gtk-murrine-engine on ['devel', 'F-9', 'F-10', 'F-11'] orphaning gtkperf on ['devel', 'F-9', 'F-10', 'F-11'] orphaning ht2html on ['devel', 'F-9', 'F-10', 'F-11'] orphaning kio_p7zip on ['devel', 'F-9', 'F-10', 'F-11'] orphaning ldapvi on ['devel', 'F-9', 'F-10', 'F-11'] orphaning libatomic_ops on ['devel', 'F-9', 'F-10', 'F-11'] orphaning libgtksourceviewmm on ['devel', 'F-9', 'F-10', 'F-11'] orphaning liblqr-1 on ['devel', 'F-9', 'F-10', 'F-11'] orphaning libreadline-java on ['devel', 'F-9', 'F-10', 'F-11'] orphaning libtomoe-gtk on ['devel', 'F-9'] orphaning ltsp-utils on ['F-9', 'F-10'] orphaning macchanger on ['devel', 'F-9', 'F-10', 'F-11'] orphaning metamonitor on ['devel', 'F-9', 'F-10', 'F-11'] orphaning mftrace on ['devel', 'F-9', 'F-10', 'F-11'] orphaning mk-files on ['devel', 'F-9', 'F-10', 'F-11'] orphaning musicbox on ['devel', 'F-9', 'F-10', 'F-11'] orphaning notecase on ['devel', 'F-9', 'F-10', 'F-11'] orphaning otl on ['devel', 'F-10', 'F-9', 'F-11'] orphaning pcmanx-gtk2 on ['devel', 'F-9', 'F-10', 'F-11'] orphaning pessulus on ['devel', 'F-9', 'F-10', 'F-11'] orphaning pguiman on ['devel', 'F-9'] orphaning pidgin-knotify on ['devel', 'F-9', 'F-10', 'F-11'] orphaning pystatgrab on ['devel', 'F-10', 'F-9', 'F-11'] orphaning python-ctypes on ['devel', 'F-9', 'F-10'] orphaning qemu-launcher on ['devel', 'F-9', 'F-10', 'F-11'] orphaning quickfix on ['devel', 'F-10', 'F-9', 'F-11'] orphaning reciteword on ['EL-5'] orphaning ruby-flexmock on ['devel', 'F-9', 'F-10', 'F-11'] orphaning scim-hangul on ['EL-4'] orphaning scim-input-pad on ['devel', 'F-9', 'F-10', 'F-11'] orphaning scim-skk on ['devel', 'F-9', 'F-10', 'F-11'] orphaning scim-tomoe on ['devel', 'F-9', 'F-10', 'F-11'] orphaning shapelib on ['devel', 'EL-5', 'EL-4', 'F-9', 'F-10', 'F-11'] orphaning skkdic on ['devel', 'F-9', 'F-10', 'F-11'] orphaning smeg on ['devel', 'F-9', 'F-10'] orphaning sqlite on ['EL-4'] orphaning sugar-evince on ['devel', 'OLPC-2', 'F-9', 'OLPC-3', 'F-10', 'F-11'] orphaning surfraw on ['devel', 'F-9', 'F-10', 'F-11'] orphaning tastymenu on ['devel', 'F-9', 'F-10'] orphaning themes-backgrounds-gnome on ['devel', 'F-9', 'F-10', 'F-11'] orphaning tomoe on ['devel', 'F-9', 'F-10', 'F-11'] orphaning tpm-tools on ['devel', 'EL-5', 'F-9', 'F-10', 'F-11'] orphaning wifi-radar on ['devel', 'F-9', 'F-10', 'F-11'] orphaning xapian-bindings on ['OLPC-2', 'F-9'] orphaning xapian-core on ['OLPC-2', 'F-9'] orphaning xmms-cdread on ['devel', 'F-9', 'F-10', 'F-11'] orphaning xyz-gallery on ['devel', 'F-9', 'F-10', 'F-11'] -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From drago01 at gmail.com Tue May 12 07:12:57 2009 From: drago01 at gmail.com (drago01) Date: Tue, 12 May 2009 09:12:57 +0200 Subject: FESco meeting summary for 20090507 In-Reply-To: <13710.1242090016@sss.pgh.pa.us> References: <1242062320.2923.586.camel@adam.local.net> <6764.1242064296@sss.pgh.pa.us> <1242071296.2923.654.camel@adam.local.net> <29158.1242074791@sss.pgh.pa.us> <13710.1242090016@sss.pgh.pa.us> Message-ID: On Tue, May 12, 2009 at 3:00 AM, Tom Lane wrote: > drago01 writes: >> On Mon, May 11, 2009 at 10:46 PM, Tom Lane wrote: >>> I've run into it twice in the past two months for apps used inside Red >>> Hat. ?(Not developed inside Red Hat, I'm glad to say.) ?This is out of a >>> sample of exactly two apps, since I avoid webapps where I can. ?So I >>> admit I don't have a lot of data, but from here it looks like a problem. > >> Well if our java implementation is broken it should be broken for 32 bit too. >> As for sun's java they have released a 64 bit plugin. > > I'm not speaking of the JVM --- I'm talking about unportable > applications. ?I suspect most of the problem is JNI code, but I cannot > claim to have attempted to debug it. > >> So this should be no longer relevant. > > Which part of "you're wrong" is not clear? ?This is a very real issue. OK, so there are some random apps that are broken, but this seems not to be the common case. From ml at kiewel-online.ch Tue May 12 07:13:03 2009 From: ml at kiewel-online.ch (Uwe Kiewel) Date: Tue, 12 May 2009 09:13:03 +0200 Subject: fedora-release-11-1 In-Reply-To: <1242093567.3452.87.camel@localhost.localdomain> References: <1242093567.3452.87.camel@localhost.localdomain> Message-ID: <4A09217F.3010200@kiewel-online.ch> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, so what do I have to do to be on F11? I did my last update from rawhide on Monday, 2009-10-05, at about 9 pm UTC. Thanks, Uwe Jesse Keating schrieb: > Tomorrow's rawhide with have the fedora-release package I hope will be > final version for Fedora 11. It enables the fedora and updates repos, > and disables the rawhide repo. Mirrormanager will redirect requests for > the fedora 11 repo to the public rawhide directory until we're ready to > release. This allows people to easily transition into the Fedora 11 > release without having to modify config files. > > If you wish to remain on Fedora 11, make sure that the .repo files as > shipped with this package are the ones in use. Check for .rpmnew files > in /etc/yum.repos.d/ and compare them to your existing .repo files to > take into account any new configuration. > > We do have a number of Fedora 11 updates and testing updates already > pushed, these are things that maintainers felt were not suitable to > break the devel freeze and instead wished to push them as "zero day" > updates. Feedback in bodhi would be greatly appreciated for these > packages if you wish to try them. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Fedora-devel-announce mailing list > Fedora-devel-announce at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-announce -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSgkhCkJXG7BUuynnAQJR0g/+MBIKu1NM4M97P020f7mg80yBHcaHZiNK l7vja1QJLLN1zKfxJf56gYN/3fKfATnZu2YWWH/yNpsK757Eee5ANDIF23rf4Bw6 qHALOiiGgM1SbnUHxyLzpS2lAQMeYQHqQebHPs06WgKoYWZBBkB+8gGWbyegC90g gSUhwWHUDfzYF4/dWCUxAX43szWUky19OijGfWShv4Kqra4lg2kl6HCFa/6IIQSB Y2vdFaD3UssIfFyVBtTTPVzsP2q1zDgN0kTg7ii3G+phrJjBUEPw5IFdArw25oN7 q+07Y61UKmUovGUbShcC9I0M+IQKMz9Mr9c9jDMOfGwXeehQmF2Bo757dJL877b9 i5f/CmUN6n2stciwQdIrLMjZog/P1wjJ+OzoyCHOFlOUNsgDY5oyxKwH34+J4uCm bmLHwUO1zeZj2cA5b1lVCZNwoF+Gu4dhrZEHhRSYWer7WBYwsh1L1jViqF2hGwAZ 66denfvGU4WMH6X9hMR7DG9s0yyN15j4qu3qM+wvozYUZLpjpw361yiwwKIcugGK X9n3evcoKoKW8uSNR+h6damdTKbn1svYTdIbEf5fjb/Ur+tN8EQj8aSL7mXDiMaf Cspe5bs1/Uy4jV+vi02m7lh2Jjg38P0ewFLBIbosb/8YDhAG0is9jl2GJMEXvd1+ SFdIAi6pSj4= =dR8F -----END PGP SIGNATURE----- From dwmw2 at infradead.org Tue May 12 07:14:51 2009 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 12 May 2009 08:14:51 +0100 Subject: SPARC Status (Was Re: Secondary Architecture Status?) In-Reply-To: <4A0862F1.2030608@redhat.com> References: <1241911202.24436.81.camel@macbook.infradead.org> <4A0862F1.2030608@redhat.com> Message-ID: <1242112491.24436.416.camel@macbook.infradead.org> On Mon, 2009-05-11 at 13:40 -0400, Tom "spot" Callaway wrote: > * Automated builds are not yet happening, although, when Dennis gets > back from vacation, I'm going to work with him to setup koji-shadow to > run on an aggressive cron job. I'd still like to see someone solve this > problem correctly with a message bus, but as I have neither the skillset > nor the time to do this, it will likely never happen. Which leads us to > the next barrier: It would be really useful to have this solved. If a secondary arch build fails, we want to notify the packager as _soon_ as possible. The sooner we tell them, the more likely they are to look at the problem and resubmit the build for themselves -- which is the behaviour we want to encourage. If the notification arrives some time later when they've already context-switched to something else, it's less likely to get dealt with. Thanks for the update. -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation From pertusus at free.fr Tue May 12 07:18:06 2009 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 12 May 2009 09:18:06 +0200 Subject: What is the best way to store information cross desktop In-Reply-To: References: Message-ID: <20090512071806.GB27189@free.fr> On Tue, May 12, 2009 at 10:59:57AM +0530, Kushal Das wrote: > Hi all, > > A Gnome application can use gconf/gnome keyring or a KDE application > can use KWallet, but those two are totally desktop specific. I know > people who use Gnome don't want to run KWallet or a KDE user will not > like to use any gnome way to store information. I am aware of 2 projects trying to solve that issue: http://alumnit.ca/wiki/index.php?page=UniConf http://www.libelektra.org/Main_Page I now that elektra, although improving is in need of work. I don't know anything about uniconf readiness. -- Pat From vpivaini at cs.helsinki.fi Tue May 12 07:20:42 2009 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Tue, 12 May 2009 10:20:42 +0300 Subject: Updated translations for gnome-packagekit in F-11 GA? Message-ID: <1242112842.2386.8.camel@localhost.localdomain> Hi, As gnome-packagekit is the default graphical update tool on the GNOME desktop, would it be possible to get a package with updated translations to Fedora 11 GA version? There were quite a lot of changes during the F-11 cycle, including the new update viewer, and because gpk isn't a Fedora sub-project, it didn't go through the string and translation freezes we have in the Fedora L10n project. It would be nice to have as complete translations as possible in the released version of F-11. This might also be the case for kpackagekit but I haven't taken part in its translation so I don't know about the L10n situation there. -- Ville-Pekka Vainio From che666 at gmail.com Tue May 12 07:22:06 2009 From: che666 at gmail.com (Rudolf Kastl) Date: Tue, 12 May 2009 09:22:06 +0200 Subject: What is the best way to store information cross desktop In-Reply-To: <20090512071806.GB27189@free.fr> References: <20090512071806.GB27189@free.fr> Message-ID: 2009/5/12 Patrice Dumas : > On Tue, May 12, 2009 at 10:59:57AM +0530, Kushal Das wrote: >> Hi all, >> >> A Gnome application can use gconf/gnome keyring or a KDE application >> can use KWallet, but those two are totally desktop specific. I know >> people who use Gnome don't want to run KWallet or a KDE user will not >> like to use any gnome way to store information. > > I am aware of 2 projects trying to solve that issue: > http://alumnit.ca/wiki/index.php?page=UniConf > http://www.libelektra.org/Main_Page > > I now that elektra, although improving is in need of work. I don't know > anything about uniconf readiness. >From my point of view keyring for passwords is definitely something that should be desktop independent. i toyed with elektra years ago. going to look at uniconf. kind regards, Rudolf Kastl > > -- > Pat > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From fedora at matbooth.co.uk Tue May 12 07:25:32 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Tue, 12 May 2009 08:25:32 +0100 Subject: SPARC Status (Was Re: Secondary Architecture Status?) In-Reply-To: <4A0862F1.2030608@redhat.com> References: <1241911202.24436.81.camel@macbook.infradead.org> <4A0862F1.2030608@redhat.com> Message-ID: <9497e9990905120025j714ffa97tb4e90040ede8792c@mail.gmail.com> On Mon, May 11, 2009 at 6:40 PM, Tom "spot" Callaway wrote: > On 05/09/2009 07:20 PM, David Woodhouse wrote: >> We still don't have any secondary architectures gearing up to ship >> Fedora 11 -- it would be really interesting to know why that is. >> >> What technical barriers are still there -- why don't we have a release >> yet? > > For SPARC, there are a few barriers: > > * Amount of code writing contributors is very small. Realistically, it > is me and Dennis Gilmore. This significantly slows down efforts in areas > where we need to do more than perform basic package triage, e.g. > anaconda. We have 99% of a Fedora 8 Tree done, but there are still > enough painful bugs and missing features in anaconda that prevent us > from doing a release. > * Automated builds are not yet happening, although, when Dennis gets > back from vacation, I'm going to work with him to setup koji-shadow to > run on an aggressive cron job. I'd still like to see someone solve this > problem correctly with a message bus, but as I have neither the skillset > nor the time to do this, it will likely never happen. Which leads us to > the next barrier: > * The few SPARC contributors have very little time to allocate to the > SPARC effort. Neither of us are paid to do full-time SPARC, and I've got > my fingers in so many pies, I might as well be a pie. This isn't a > technical barrier, per se, merely pointing out that being responsible > for an architecture is a LOT of work. Not to mention that Sun is about > to get swallowed up by Oracle, who I doubt will be overly concerned > about Linux/SPARC, so it is even less likely that we will see additional > code help or community involvement from them (as a contrast to IBM on > PPC/S390). > > ~spot > There isn't a lot of information on the SPARC wiki page. Is there a currently a way to install Fedora on a SPARC so I can try it out? -- Mat Booth www.matbooth.co.uk From hughsient at gmail.com Tue May 12 07:31:17 2009 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 12 May 2009 08:31:17 +0100 Subject: Updated translations for gnome-packagekit in F-11 GA? In-Reply-To: <1242112842.2386.8.camel@localhost.localdomain> References: <1242112842.2386.8.camel@localhost.localdomain> Message-ID: <15e53e180905120031j608e4be4h5078594f92946707@mail.gmail.com> On Tue, May 12, 2009 at 8:20 AM, Ville-Pekka Vainio wrote: > As gnome-packagekit is the default graphical update tool on the GNOME > desktop, would it be possible to get a package with updated translations > to Fedora 11 GA version? There were quite a lot of changes during the > F-11 cycle, including the new update viewer, and because gpk isn't a > Fedora sub-project, it didn't go through the string and translation > freezes we have in the Fedora L10n project. It would be nice to have as > complete translations as possible in the released version of F-11. Well, as you might know we're using a development stream for F11, 2.27.1. This is not translation or ABI stable, but once F12 is released we can be in a state where we follow the normal GNOME release schedule and release freezes. This obviously works well for Fedora. I know using 2-27 in F11 GA isn't ideal, but we needed to do the transition from PK release schedule and numbering to GNOME release schedule and numbering, and this happened too late for F10. As a compromise, I was intending to backport 2.27.2 into F11 updates-testing as a pretty much zero day update. This means we get the new translations and also the fixed bugs, but also the new code gets some testing. Richard. From mike at thetroubleshooters.dk Tue May 12 08:14:20 2009 From: mike at thetroubleshooters.dk (Michael Nielsen) Date: Tue, 12 May 2009 10:14:20 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: References: <4A082E70.7030904@TheTroubleshooters.dk> Message-ID: <4A092FDC.3010200@TheTroubleshooters.dk> Seth Vidal wrote: > > > On Mon, 11 May 2009, Michael Nielsen wrote: > >> Hi, >> >> I've been told this is the right place to place this debate starter. > > > You were told incorrectly. > > I'm sure there is a place for this kind of debate but it is SURELY not > the devel list. > > Where then? The problem is logically related to the development path that Linux is taking, somewhere someone must have a plan, for where Fedora is going. If there isn't a plan for Fedora development, then that is probably the reason for the problems that I am concerned about. As the problems that I'm pointing out here, could very well be the effect of chaotic development. /mike. From mike at thetroubleshooters.dk Tue May 12 08:23:43 2009 From: mike at thetroubleshooters.dk (Michael Nielsen) Date: Tue, 12 May 2009 10:23:43 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A08302A.2020705@redhat.com> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08302A.2020705@redhat.com> Message-ID: <4A09320F.9060107@TheTroubleshooters.dk> Casey Dahlin wrote: > Michael Nielsen wrote: > >> *snip* >> > > Write feature proposals. If you don't want to then implement them, pawn them off to someone else. > > Maybe we have this problem because out of all the people screaming about the end times, not one of them can't think of something better to do with their time than fix it. > > --CJD > > I have spent months and years, trying to determine where I need to go to get some attention to the issues, and perhaps som influence on the issues that I'm pointing to here, however, I have not been able to locate anywhere, or anyone that is even remotely interested in gaining some sort of structure on the system. The only path forward, as I can see is to create one's own distribution, which seems like a major over kill. Currently, I'm left frustrating, as from my point of view, the best Fedora/Redhat distributions, seems to have been around Redhat 8, where the system was relatively clean - though not as clean as I'd like. So tell me where does one go to solve the issues that I've pointed out ? Feature proposals ? I'm not proposing features, I'm proposing that Linux, re-integrates itself, so that it stops forking every where, currently there is no less than 3-4 implementations of network management, none of which are compatible with one-another, and only one (the original), work in all cases. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn at xn--rombobjrn-67a.se Tue May 12 08:44:19 2009 From: bjorn at xn--rombobjrn-67a.se (=?utf-8?q?Bj=C3=B6rn_Persson?=) Date: Tue, 12 May 2009 10:44:19 +0200 Subject: FESco meeting summary for 20090507 In-Reply-To: References: <200905112159.08449.bjorn@xn--rombobjrn-67a.se> Message-ID: <200905121044.30495.bjorn@xn--rombobjrn-67a.se> Kevin Kofler wrote: > OK, so there are technically current 32-bit machines which are not > netbooks. Certainly not the common case though. ;-) And people should > choose an Atom-330-based solution instead. :-) That depends entirely on what they want to do with the machine. My backup server is a Soekris net4801 with a 266 MHz SC1100. It's quite sufficient for Rsync over SSH and draws about four to five watts. (That particular model has end-of-life status now though.) I agree that a time will probably come when 32-bit x86 processors are no longer manufactured, but we're not there yet. Bj?rn Persson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From mike at thetroubleshooters.dk Tue May 12 08:47:15 2009 From: mike at thetroubleshooters.dk (Michael Nielsen) Date: Tue, 12 May 2009 10:47:15 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: References: <4A082E70.7030904@TheTroubleshooters.dk> Message-ID: <4A093793.2090100@TheTroubleshooters.dk> Kevin Kofler wrote: > Michael Nielsen wrote: > >> 4. Everything is thrown in huge collective directories, such as >> /usr/bin, /usr/lib etc, and it is a huge mess >> > > This is called the Filesystem Hierarchy Standard, and it encodes decades of > experience organizing file systems into a standard which minimizes > differences across implementations. > I know of the standard, however, I really doubt the current Fedora configuration really follows it, I still don't see why everything needs to be thrown in /usr/bin? Currently on some installations, if you try to open them, are exceedingly heavy, I've had smaller machines stall out, as I try to change the application that starts when for instance a movie is to be played in firefox, apparently due to the amount of files in /usr/bin. >> just like windows with it's system32 directory, which is also a huge mess. >> > > Actually Window$ is the system which started this "one directory per app" > stupidity. *nix has never worked that way. > > Kevin Kofler > > I beg to differ, having worked with several different UNIX flavours, I've yet to see a commercial UNIX that throws everything into one directory. Though I stopped working with the commercial ones in 1999, and went to Linux then. I noted the installation procedure of not throwing everything in one directory, before windows 3.1 was implemented, so I doubt it started with windows. There are inherent advantages in not throwing everything in one big blob. Windows have seperated parts of the applications into specific directories, is a good idea, however, in Windows everything that is shared, is thrown into system32, and therefore removing an installation of a problem is nearly impossible, because there is Junk spread throughout the system, relating to a particular application, one of the causes for problems with windows. Thus if you need to run a non-packaged software, due to patches that you need (security), you can only hope that the package manager successfully removes everything, and does not leave junk behind which may, or may not affect the running of the newer compilation. Throwing everything in one directory hierarchy causes one particular problem that I personally find rather annoying, the inability to use the package manager system to have multiple versions of for-instance firefox installed on a system, as I often test on multiple versions, however, if I do not use the package manager, it is trivial to have multiple versions of an application installed, however, now the updates for the application is disabled, and they need to be manually updated, which is annoying. The same situation can be seen when you run 64 bit systems, sometimes you need to run something in 32bit compatibility, however you cannot install the libraries you need because of conflicts in the packaging system, as - again - everything is thrown into one directory - in this case the /usr/share/doc directory, which means you need to find out how to force the installation of the libraries. /mike. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at thetroubleshooters.dk Tue May 12 08:49:11 2009 From: mike at thetroubleshooters.dk (Michael Nielsen) Date: Tue, 12 May 2009 10:49:11 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A08C233.4020902@sapience.com> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08C233.4020902@sapience.com> Message-ID: <4A093807.4010403@TheTroubleshooters.dk> Mail Lists wrote: > On 05/11/2009 11:07 AM, drago01 wrote: > > >> This is not true, in case of gnome you can access everything mounted >> by nautilus / gvfs by accessing ~/.gvfs works with ANY app. >> >> > > Except possibly a process running as root. > > Doesn't work, when the user is not logged in, as the share is no longer available, and there doesn't appear to be a way to make it persistent. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilyes.gouta at gmail.com Tue May 12 08:56:23 2009 From: ilyes.gouta at gmail.com (Ilyes Gouta) Date: Tue, 12 May 2009 09:56:23 +0100 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A093807.4010403@TheTroubleshooters.dk> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08C233.4020902@sapience.com> <4A093807.4010403@TheTroubleshooters.dk> Message-ID: <234fa2210905120156h397d0125l500d9fa330bb5445@mail.gmail.com> Hi, I think it's a good idea to not throw everything in one location. May be we should really introduce this as a feature for the next Fedora releases. This would also help get rid of the /usr/bin directory, introduce more flexibility in packages management and security. -Ilyes On Tue, May 12, 2009 at 9:49 AM, Michael Nielsen wrote: > > Mail Lists wrote: > > On 05/11/2009 11:07 AM, drago01 wrote: > > > > This is not true, in case of gnome you can access everything mounted > by nautilus / gvfs by accessing ~/.gvfs works with ANY app. > > > > Except possibly a process running as root. > > > > Doesn't work, when the user is not logged in, as the share is no longer > available, and there doesn't appear to be a way > to make it persistent. > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From mschwendt at gmail.com Tue May 12 09:15:45 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 12 May 2009 11:15:45 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: References: <1241718097.3209.11.camel@localhost.localdomain> <20090507210920.GB9105@amd.home.annexia.org> <1241949557.3109.2.camel@localhost.localdomain> <20090510131115.226b27a5@faldor.intranet> <4A079B3B.20606@freenet.de> <20090511132526.3195dc37@rawhide.intranet> <4A084868.4040807@freenet.de> <20090511202103.5b90f3b0@rawhide.intranet> <20090511222729.08425a92@rawhide.intranet> Message-ID: <20090512111545.3a10d972@faldor.intranet> On Mon, 11 May 2009 23:03:01 +0200, Kevin wrote: > What happened is that people inadvertently built Qt-based packages which did > not require a rebuild and thus weren't on our radar against the Qt 4.5 > buildroot override, then pushed them to stable while Qt 4.5 was still in > testing That's no example for what Ralf has written: | Fact also is: "Testing" occasionally is the cause of broken package deps. As soon as the new Qt got tagged into the buildroot, *any* build done against Qt required coordination with you (or whoever decided when to release the new Qt and the known rebuilds). Even if the new Qt and the known set of rebuilds had been pushed directly to stable as quickly as possible, you could have missed builds done by other people. These builds would be mostly harmless if they go to updates-testing first. Not so for packages that go directly to stable. Treating the new Qt and the known rebuilds like hot potatoes is no solution for race conditions like that. Computer aided release management is needed. Especially if you say some packages segfaulted if not rebuilt. Push "all deps or nothing" from testing to stable: the new Qt and any builds done against it, but not a partial set of packages. Buildroot overrides that do more than just "poison the buildroots". Buildroot overrides that could tell the updates system to disallow Qt deps from being published before Qt. The Updates System taking into account the RPM inter-package dependencies, so a person who edits the Qt update request is shown the list of dependencies in the updates queue similar to bugzilla's "blocks/depends on" chains. From che666 at gmail.com Tue May 12 09:20:12 2009 From: che666 at gmail.com (Rudolf Kastl) Date: Tue, 12 May 2009 11:20:12 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <20090511180045.GR3435@mcpierce-laptop.rdu.redhat.com> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08381D.5030604@freenet.de> <4A085DDB.101@redhat.com> <4A0860B3.5030802@freenet.de> <20090511180045.GR3435@mcpierce-laptop.rdu.redhat.com> Message-ID: 2009/5/11 Darryl L. Pierce : > On Mon, May 11, 2009 at 07:30:27PM +0200, Ralf Corsepius wrote: >> Everything? Maybe it escapes you, but it's always the same issue: >> >> When "upstream" == "@RH", common sense and rationality seems to be >> switched off in Fedora. > > Red Hat's not upstream to Fedora. thats not what he said ;) > > -- > Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. > Virtual Machine Management - http://www.ovirt.org/ > Is fearr Gaeilge bhriste n? B?arla cliste. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From christoph.wickert at googlemail.com Tue May 12 09:36:09 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Tue, 12 May 2009 11:36:09 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A093793.2090100@TheTroubleshooters.dk> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A093793.2090100@TheTroubleshooters.dk> Message-ID: <1242120969.3755.37.camel@localhost.localdomain> Am Dienstag, den 12.05.2009, 10:47 +0200 schrieb Michael Nielsen: > I know of the standard, however, I really doubt the current Fedora > configuration really > follows it, Can you elaborate this allegation a little? Where _exactly_ does Fedora not follow it? The previous examples you gave were not proving your point of view: /usr/local is not meant to be touched by package management and /opt is not for things that belong to the distro itself. > I still don't see why everything needs to be thrown in /usr/bin? Because it _is_ the standard and has been for years. http://www.pathname.com/fhs/pub/fhs-2.3.html#USRBINMOSTUSERCOMMANDS > Thus if you need to run a non-packaged software, due to patches that > you need (security), Such patches should be in the package, file a bug if they are not. You have an example of that handy? > you can > only hope that the package manager successfully removes everything, > and does not leave junk behind > which may, or may not affect the running of the newer compilation. Again: Example? rpmdb tracks all files, so there shouldn't be left anything behind. > Throwing everything in one directory hierarchy causes one particular > problem that I personally find > rather annoying, the inability to use the package manager system to > have multiple versions of > for-instance firefox installed on a system, as I often test on > multiple versions, however, if I do not > use the package manager, it is trivial to have multiple versions of an > application installed, > however, now the updates for the application is disabled, and they > need to be manually updated, > which is annoying. This has nothing to do with the file system layout but with package management itself: A package manager will not install two versions of the same package but upgrade the older one. > The same situation can be seen when you run 64 bit systems, sometimes > you need to run something > in 32bit compatibility, however you cannot install the libraries you > need because of conflicts in the > packaging system, as - again - everything is thrown into one directory > - in this case the /usr/share/doc > directory, which means you need to find out how to force the > installation of the libraries. The problems with docdir were solved *long* time ago [1], so you can easily install both 32 and 64 bit packages. Obviously you did not try for the last two - three years, which makes your criticism pretty pointless. > /mike. Regards, Christoph [1] https://bugzilla.redhat.com/show_bug.cgi?id=209306 The fact that this bug was opened in October 2006 shows that it was very well possible to install both i386 and x86_64 together at that time. From mike at thetroubleshooters.dk Tue May 12 09:37:06 2009 From: mike at thetroubleshooters.dk (Michael Nielsen) Date: Tue, 12 May 2009 11:37:06 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <7f692fec0905110735tf8a1bd4u7a71d85f6de7f14b@mail.gmail.com> References: <4A082E70.7030904@TheTroubleshooters.dk> <7f692fec0905110735tf8a1bd4u7a71d85f6de7f14b@mail.gmail.com> Message-ID: <4A094342.7000805@TheTroubleshooters.dk> Yaakov Nemoy wrote: > This is trolling, not starting debates. > > 2009/5/11 Michael Nielsen : > >> 1. Removal of features - the user interfaces are being dumbed down, like >> recently I've searched for the ability to remove the "Raise on Click" >> feature that is default for Gnome MetaCity, there does not appear to be any >> such feature anymore / argument being to simplify how it works.. Fine, >> create a simple view and an advanced view for the configuration tools, so >> that people who are clueless about any other way than the official Redmond >> way, can avoid being confronted with an alternative. >> > > This is upstream and has to do with Gnome. Fedora stays as close to > upstream as possible, which means if the Gnome developers think this > is a good idea, then this is (possibly) a good idea. If you don't like > it, get a clue and install a different window manager. Try Openbox. > > No need to get personal. I've been setting up my own window managers for years, and I tend to do so, however, it would be really nice if one was able to use the work that others had done, such as the menu system, etc that gnome, and KDE uses, however, I do not like the default click-to-front, that I used to be able to simply disable, however this feature is no longer trivial to find, initially I could still load a useful windowmanager, and thereby replace the underlying window manager in Gnome, nor KDE for that matter. I prefer other window managers, such as enlightenment, fwm, etc, I've used quite a lot of different ones in my time. However, it is getting rather annoying having to manually update the custom desktop environment to follow a moving target, thus it would be preferable to be able to follow one of the maintained ones, however, as I pointed out, their features are being eroded, and basic functions are being removed. >> 2. The network interfaces are being bound to the user interface, such that >> if your X fails for some reason, or you are running on a text console, you >> are unable to open the wireless configuration, at least it's not obvious how >> you do it, without X running. The configuration for the network interfaces >> are so tightly bound to the user interface, such that if there is no user >> interface there are no network interfaces. >> > > This is the artifact of working in a desktop environment. If you need > more functionality then you are a power user. There is a very advanced > interface for configuring the network, we like to call it the command > line. > > Not to be picky, but in your previous post, you commented you want a > simple and advanced view. Think of the desktop as a simple view, and > the command line as your advanced view. > > I have worked with UNIX since the time where X terminals were unknown, and text terminals was the normal way of working. I know how to do it, however, the problem is the default installation of Fedora installs a lot of things which conflicts, and prevents command line configuration, as the GUI seems to try to override my "advanced" configurations, I have eventually figured out to remove the NetworkManager, and disable the GUI networking. That works, however, I find it frustrating to see that Linux is forking at this level, because it means that someone who is not a Power user (or command line freak which I'm often catagorised as), will have more difficulty in setting up a simple web server, because the network configuration is personal if you use the applet approach., Thus the person will discover that once they log off, their system is no longer online, and their webserver doesn't work. What I'm asking why not make sure, that no matter which tool you use to set up anything, that it does it fundamentally the same way, so that the tool in the GUI will change the relevant configuration file (under privileged control ofc), and the system will be able to take things down properly... I beg to differ, it is not an artifact of working in a desktop environment, but more an artifact of fundamentally choosing another approach, where everything even system configuration is focued in the GUI, rather than in the Operating System. For-instance Gnome there is the administration Network configuration, which appears to do what I'm asking, and there is the network applet configuration, which does not update the configuration files - at least I've been unable to detect the changes. So you have two views, that in principle does the exact same thing, and yet, one is a system wide configuration, the other is a local user related change. This bound to be confusing to people. >> 3. Mounts are also embedded into the user interface, rather than in the unix >> mount system, which means that the shares are not accessible for non-gui >> programs, for instance, I like to script most thing I do often, however, >> there is no way for scripts to get a hold of a drive that is mounted through >> the gui mount system (kde and gnome). >> > > You're right, they could potentially do a bit better. Except that they > do, most of your mounts should be available in /media. > > If you have a specific complaint, please file a bug report on Gnome or KDE. > > Personally I just don't use those features, what I'm trying to do here is to get people to think about what is happening, because, I can see a lot of feature forking in the system, which will make the system extremely confusing for people to start using Linux. All that is really needed is to mount things properly, and logically. eg /home/mike/mnt1 instead of /home/mike/.gvfs/blablah.. which is a hidden file. What I'm trying to do here is to point out problems with the Fedora distribution, yes some things are specific to other subsystems, but the reflect back on Fedora as a distribution. >> 4. Everything is thrown in huge collective directories, such as /usr/bin, >> /usr/lib etc, and it is a huge mess, just like windows with it's system32 >> directory, which is also a huge mess. really the /usr/bin,/bin/sbin, /lib >> etc, has very specific purposes, and should represent a core operating >> system, that is capable of being used as repair, with no major applications >> present. However even Open office is stored in these directories. >> > > This is by design. Complaining about the design isn't going to start a > debate unfortunately. > > If the design really does bother you, try Gobo. > > http://www.gobolinux.org/ > I'm not complaining I'm pointing out a problem in the system, the current "design" (as you call it), prevents the management of multiple versions of an application, as they will conflict in the package manager, I have become used to manually installing all applications that I use regularly, and thus overcoming the system limitations. The annoying part is that the limitations only arise because everything is thrown into one directory - for instance 32 bit and 64 bit packages often conflict because their documentation files conflict - and unfortunately it is often necessary to have 32 bit compatibility installed. > >> 5. More and more services are bound up in the userinterface, such as the >> pulse audio, which is started by the GUI, this means if you use 2 user >> environments, which I often do for testing, where I have X:0 and X:1 >> running, the GUIs will conflict, because you cannot run two instances of >> pulseaudio. In addition pulse audio is crap, I have yet to see any >> installation actually work without crackling, and chopping like crazy. I >> like the concept that is the basis of pulse audio, but it just does not >> work. >> > > Read the answer to #2. Also, if you have a specific complaint, file a > bug on Pulseaudio and Alsa. > Why, the problem is related to the fact that Fedora default uses Pulse Audio, however, I've yet to see a system where it works well on, though, with work-arounds it is possible to get it to work, basically there is some configuration issue on Fedora systems, where a lot of applications become impossible for non-advanced users to install. For-instance Skype, is choppy as hell, using the default configuration that Fedora 9-10 uses, it turns out you need to explicit change the input device to be hardware, not default and not pulse. Most ordinary users would give up on running Skype on Linux, and perhaps even give up on Linux, because the configuration per-default does not work. The problems have arisen since Pulse Audio was chosen as a standard for Fedora, pre Pulse-Audio, everything worked nicely, thus as I see it, it is a distribution choice that is causing the problem, PulseAudio isn't quite ready for mainstream yet, and yet it is not trivial to remove, nor to configure - makes it hostile to less experienced users, so it is a consideration for the distribution managers, not for PulseAudio. >> 6. NetworkManager which appears to be installed default, does not work with >> shared drives, because, the NetworkManager is shut down before the network >> drives are detached, and you need to modify the NetworkManager to start >> properly, before you mount the network drives. I've gotten used to explicit >> uninstalling the NetworkManager, because it just doesn't work properly. >> > > Again, you're a power user. Reorder your shutdown sequence. > Again, Yes I can, and I do, but what about less experienced users ? Are we not trying to get Linux to be mainstream ? It is not encouraging for people that things do not work properly out of the box! I know Fedora is defined as a "bleeding edge" distribution, which is all good and well however, it scares a lot of people away from the distribution. > >> It is a lengthy discussion to describe what i mean. >> >> However, if I take a sample application like firefox, it presents a >> reasonable proxy for what I mean. >> >> currently default installation of firefox on my machine installs firefox in >> these following places. >> >> /usr/lib64/firefox >> /usr/lib64/firefox-3.0.7 >> /usr/lib/mozilla >> /usr/lib64/mozilla >> /usr/share/mozilla >> /usr/bin/mozilla-plugin-config >> /usr/bin/firefox >> >> etc. >> >> All of which are related to the firefox installation. If something goes >> wrong, it's a real pain to clean it up, or even to detect what went wrong. >> The original concept for unix was to install an application such as firefox >> in either, /opt or /usr/local/. Such that the entire application was >> contained within a single installation directory, and then to use the PATH >> and LD_LIBRARY_PATH to allow the execution of the application. >> >> The standard approach with /opt or /usr/local installation also makes it >> triviel to have multiple installations, and configurations operating in >> paralellel, by simply creating. >> >> /opt/mozilla/firefox -> /opt/mozilla/firefox-3.0.7 >> /opt/mozilla/firefox-3.0.7 >> /opt/mozilla/firefox-2.0.9 >> >> A user can then easily conifgure their account to use either version of the >> application, without installation problems. >> >> Additionally using that installation method, also means that if someone >> wants to use a newer version of an application, they can download the >> source, and trivially install it in parallel to the package managed >> application, by using the --prefix option, and the installation can easily >> be removed, by simple rm -rf /opt/mozilla/firefox-3.0.7. >> >> With the current installation, it is nearly impossible, or at least very >> difficult to find out if the package manager has cleaned up properly, or if >> there is something left behind - something which is identicial to the >> problem on windows. >> > > Wrong, see Gobo if this is a feature you want. > > Using this split up file system layout is by design, it's a standard > of the Unix Way of Doing Things. Everything that ships in Fedora > and/or a 3rd party repo that is designed to integrate with the core > functionality will use this layout. /opt is for third party software > that doesn't want to behave. /usr/local is for bits that are specific > to your machine. > > If your installation fails it's because of two things. A) there is a > bug in RPM/Yum that needs to be fixed. The design goal is for these > bits to be rock solid reliable. They should never fail. > 2) Your power went out. RPM and Yum really should recover and continue > from where they left off. Handling such a use case is really a very > difficult to solve problem. If you have any concrete ideas, let's hear > them, but complaining about the file system layout is not going to > solve the problem one bit. > > > Oki, I need Firefox-2.0 installed, and Firefox-3.0 installed, hmm, they conflict, in the package manager. So I install them manually, now I also need to manage the applications manually. And so forth. Most UNIX systems, do not install the development environment - eg eclipsse, the desktop publishing (read open office) as a part of the system, but rather as 3rd part add ons. The problem as I see it, is that Fedora has decided that everything is an integral part of the operating system, which is creating the mess I'm trying to describe. Relying on Yum and RPM to do all the work, will eventually cause the same "Sanding up" of the operating system, that you can see on windows, in that not everyone cleans up properly, and eventually junk is left all over the place, rather than isolated. So basically you are saying that OpenOffice, Eclipse, Firefox, MySQL et. al. are integral parts of the operating system, and therefore are not to be installed as independent applications. Yes that is one view of the world, however, it is a lazy argument, for doing something in a bad way. > >> I'm really curious as to the reasoning for moving everything from the >> standard configuration mechanisms to the gui layer, breaking compatibility >> with scripting, and other standard UNIX featuers.. I'm also curious as to >> the reasoning for throwing everything in one huge mess in the /usr/bin, >> /bin, /sbin, etc.. As all that is achieved is to make it hard to strip the >> system back to a minimal setup. >> > > Is there anything concrete that breaks? Can you give us an example of > shell code that doesn't work in Fedora 11 anymore? > > -Yaakov > > Automatic scripting that operates on mounts created by users - sorry, user not logged, in mount point not available. Multiple ways of creating mounts, some are bound in the user interface, and has non-obvious names hidden in .gvfs (I think). Wireless configuration bound to the GUI, if you use the most obvious configuration tool, and NTP does not function because it is run before the user logs in. Network created by one user via the GUI, is taken down, before an NFS/CIFS created by another user on the system, or by the operating system, thus causing the system to hang on shutdown. Reordering startup scripts won't solve this, because once the GUI goes down and takes the network connection down, then the operating system will hang on unmounting any manually mounted mounts. Thus you can combine the manual mounting with the GUI networking, however the system does not handle the take down properly. and so forth - the list is very long. The problem is that there is a tendency to not use the normal operating system controls to take things up and down, and that results in that you are forced to use one method or another. Basically I'm pointing out that there is a consistency problem in Linux, which would scare a lot of poential users away. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at thetroubleshooters.dk Tue May 12 09:39:21 2009 From: mike at thetroubleshooters.dk (Michael Nielsen) Date: Tue, 12 May 2009 11:39:21 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: References: <4A082E70.7030904@TheTroubleshooters.dk> Message-ID: <4A0943C9.5050202@TheTroubleshooters.dk> drago01 wrote: > On Mon, May 11, 2009 at 3:56 PM, Michael Nielsen > wrote: > >> Hi, >> > > >> 3. Mounts are also embedded into the user interface, rather than in the unix >> mount system, which means that the shares are not accessible for non-gui >> programs, for instance, I like to script most thing I do often, however, >> there is no way for scripts to get a hold of a drive that is mounted through >> the gui mount system (kde and gnome). >> > > This is not true, in case of gnome you can access everything mounted > by nautilus / gvfs by accessing ~/.gvfs works with ANY app. > > I was not aware of this, as it is not obvious, and poorly documented - I have searched for info on this, however I have noticed the mounts, when running the mount command, however it is not clear if the names remain consistent. And why make the mounts hidden ? ( leading . hides the directory), seems highly illogical approach. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at thetroubleshooters.dk Tue May 12 09:42:36 2009 From: mike at thetroubleshooters.dk (Michael Nielsen) Date: Tue, 12 May 2009 11:42:36 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <1242055986.2510.3.camel@localhost.localdomain> References: <4A082E70.7030904@TheTroubleshooters.dk> <1242055986.2510.3.camel@localhost.localdomain> Message-ID: <4A09448C.3090801@TheTroubleshooters.dk> Callum Lerwick wrote: > On Mon, 2009-05-11 at 15:56 +0200, Michael Nielsen wrote: > >> IMO it is really badly time to do a "back-to-basics" approach, and to >> clean up the system. >> > > http://www.linuxfromscratch.org/ > > Start from the bottom up and show us how it's done. > I've built my own distributions (embedded etc) before, however, the critism I trying to bring out is general for Linux, and quite a few points I've brought up, are genuine problems for new users to the system. I work around the problems, and though they bug me, it doesn't take long for me to do the work arounds and get the system to work properly, however, it seems wrong to me to create a distribution that has a lot of issues, which I've seen grow, and not lessen. A lot of the conflicts that I see in the system, cause problem for non-advanced users. -------------- next part -------------- An HTML attachment was scrubbed... URL: From P at draigBrady.com Tue May 12 09:43:15 2009 From: P at draigBrady.com (=?ISO-8859-1?Q?P=E1draig_Brady?=) Date: Tue, 12 May 2009 10:43:15 +0100 Subject: Things to do this week instead of arguing about mixers In-Reply-To: <49F60312.8060709@redhat.com> References: <49F60312.8060709@redhat.com> Message-ID: <4A0944B3.6020405@draigBrady.com> Eric Sandeen wrote: > Now that we have ext4 as the new default filesystem, it'd be nice if we > can get more applications to take advantage of some of the features. > > One big feature that has already been brought up on the list[1] is file > preallocation, which allows an application to pre-allocate blocks it > knows that it will eventually write into, thereby making sure it won't > run out of space, and also generally getting a more efficient/contiguous > file layout. > [snip] > fallocate(2): > long fallocate(int fd, int mode, loff_t offset, loff_t len); > > This is directly wired to the syscall, so only succeeds on filesystems > that support it. It also takes a FALLOC_FL_KEEP_SIZE mode argument, > which allows one to allocate blocks without updating the file size if > desired (blocks can then be allocated past EOF). This call is only > wired up in very recent glibc, but it is available in F11. I tried using fallocate() on glibc-2.9.90-22. The man-pages are out of date and say the glibc interface is not available, but from inspecting the headers I came up with the test prog below. However I get a link error if I uncomment #define _FILE_OFFSET_BITS 64. What am I missing? cheers, P?draig. //#define _FILE_OFFSET_BITS 64 #define _GNU_SOURCE #include #include #include #include #include #include #include int main (int argc, char** argv) { char* endptr; off_t len = strtoll(argv[1], &endptr, 10); fprintf(stderr, "setting to %jd\n", (intmax_t)len); int ret = fallocate(1, 0, 0, len); fprintf(stderr, "ret=%d (%s)\n", ret, strerror(ret)); } From mike at thetroubleshooters.dk Tue May 12 09:57:25 2009 From: mike at thetroubleshooters.dk (Michael Nielsen) Date: Tue, 12 May 2009 11:57:25 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <1242060668.28322.85.camel@localhost.localdomain> References: <4A082E70.7030904@TheTroubleshooters.dk> <1242060668.28322.85.camel@localhost.localdomain> Message-ID: <4A094805.3090800@TheTroubleshooters.dk> Dan Williams wrote: > On Mon, 2009-05-11 at 15:56 +0200, Michael Nielsen wrote: > >> 2. The network interfaces are being bound to the user interface, such >> that if your X fails for some reason, or you are running on a text >> console, you are unable to open the wireless configuration, at least >> it's not obvious how you do it, without X running. The configuration for >> the network interfaces are so tightly bound to the user interface, such >> that if there is no user interface there are no network interfaces. >> > > This is false. > > NetworkManager will read (and write!) system network configuration for > wired & wireless devices, and can bring those devices up before login. > I think what you may be missing is an easy one-command tool to > activate/deactivate those, and that's fairly simple with dbus-send, and > yes, its something that should be written. But in now way is network > tied to a UI or unusable without a UI. > No it's not false, from the users point of view... Use the wireless connection function in gnome, and reboot - does your machine go on to the network, before you log in or after? From a users point of view, the Network is directly tied into the GUI. I have tried to find out how to get the wireless connection that can be configured under gnome or kde, to work, so that I can get NTP to function properly, and how to get fstab to mount NFS, and CIFS drives during boot. Without having to go to the command line - it is easy for me use the command line - but try to explain that to a non-power user, over the phone. There does not appear to be any obvious way to make the network configuration permanent, the nice applet for connecting to the wireless networks, does not seem to have any way to write a permanent configuration. the other graphical application under administration tools, can do it, but is no where near as easy to use. Not that it really is a big problem for me, as I usually end up disabling it, and switching to manually configuring wpa_supplicant, and the network interfaces. I've entered this debate, because I'm concerned with the perceived problems that these forks are causing, and that things are now becoming non-obvious, such as the network issue. These kinds of things are the arguments that are used for NOT using Linux. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gilboad at gmail.com Tue May 12 10:09:00 2009 From: gilboad at gmail.com (Gilboa Davara) Date: Tue, 12 May 2009 13:09:00 +0300 Subject: OpenOffice 3.1 In-Reply-To: <1242080497.2923.676.camel@adam.local.net> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <1241990992.3452.6.camel@localhost.localdomain> <6dc6523c0905101458l64811e65lb9f18216a4f93941@mail.gmail.com> <1242064968.2923.615.camel@adam.local.net> <1242072865.2923.670.camel@adam.local.net> <1242079541.3452.48.camel@localhost.localdomain> <1242080497.2923.676.camel@adam.local.net> Message-ID: <1242122940.1211.19.camel@gilboa-work-dev.localdomain> On Mon, 2009-05-11 at 15:21 -0700, Adam Williamson wrote: > On Mon, 2009-05-11 at 15:05 -0700, Jesse Keating wrote: > > On Mon, 2009-05-11 at 23:57 +0200, Kevin Kofler wrote: > > > 4. the major feature release or rewrite, e.g. KDE 3 -> 4, Amarok 1 -> 2 > > > etc. ? those come with known feature and stability/reliability regressions > > > make absolutely no sense to push as a stable update to a released distro! > > > (Of course there are some project releasing "new major versions" which are > > > not of that type, but in that case they should be handled like "minor > > > feature releases" above. But e.g. Amarok 2 is most definitely a major > > > feature release with significant code rewriting.) > > > > The problem I think we're having is that while KDE may use sane numbers > > to represent these 4 classes, not all upstreams do. But users see KDE > > do a a.b.n to a.b.n+1 or even a.b to a.b+1 and think that it's OK to do > > that with their software too, even though their upstream may do massive > > feature changes between a.b and a.b+1. > > > > Basically trying to insert numbers anywhere in this discussion is going > > to fail, and we have to stick to concepts like you outlined. For what > > its worth, I agree with the 4 classes and which are appropriate or not. > > Unfortunately I don't think everybody agrees. > > Exactly. I'm replying to Jesse to keep things compact, but to address > one point from your post: "equating "version upgrades == unstable" is > not the point. It's not ==, it's *may possibly equal*. > > As I said, one of the two practical update policies is "minimum possible > change necessary to fix the specific issue being addressed". If, say, > you want to fix a single bug in awesomeapplication 1.0, and > awesomeapplication 1.0.1 does nothing but fix that bug, then shipping > awesomeapplication 1.0.1 as an update passes the policy. It's not as > simple as saying "you can't ship any version updates". The policy is, > quite simply, as it says: you ship the minimum necessary code changes to > address the specific bug the update is intended to address. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org > http://www.happyassassin.net > Which would have left us with KDE 4 in F9 instead of KDE 4.2.2 and RHEL 5.3 would have been left with Firefox 1.5 instead of Firefox 3.0. One cannot ignore the fact the maintainer can, and should have the final decision as for what counts as a stable release and/or which features are important enough to justify the risk of a possible breakage. - Gilboa From mike at thetroubleshooters.dk Tue May 12 10:09:12 2009 From: mike at thetroubleshooters.dk (Michael Nielsen) Date: Tue, 12 May 2009 12:09:12 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <200905111040.27935.konrad@tylerc.org> References: <4A082E70.7030904@TheTroubleshooters.dk> <200905111040.27935.konrad@tylerc.org> Message-ID: <4A094AC8.9090602@TheTroubleshooters.dk> Conrad Meyer wrote: > >From this rant it seems like your operating system of choice ought to be > Slackware, not Fedora. I'm sure you'll find it much more to your liking > (crummy-to-no package management, out of date software, etc). > > Regards, > Possibly I have not explained what I'm trying to do here, I'm not blindly complaining, if it was that I'm just unhappy with Fedora, et. al., I'd build the system from source myself, I've done that before, and can do it again. However, due to some of the issues I've pointed out, I've started not using the package manager for the main components for the development work I do, because of the problem of not being able to use the package manager to maintain multiple versions of an application on a system - something that could be implemented almost trivially, by restructuring the way packages are installed. I was trying to bring some constructive critism, and to start a debate, there are things that I've noticed are problems, and I wanted to bring to the attention to people, as they are perceived by many as reasons for NOT using Linux. I could just ignore it and go about my business, much easier to do, but I'd like to see Linux thrive. Personally I like Fedora, but I don't like the way it is moving as an entity - IMO downhill since Redhat 8 (as server, and configurability), though Fedora 8 (as a desktop) was quite nice. Fedora 10 is highly unstable, I have no less than 3 systems, that comes with serious problems under Fedora 10, but works brilliantly with Fedora 8. From jdieter at gmail.com Tue May 12 10:12:58 2009 From: jdieter at gmail.com (Jonathan Dieter) Date: Tue, 12 May 2009 13:12:58 +0300 Subject: Fedora (Linux) is Destroying it self In-Reply-To: References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08381D.5030604@freenet.de> Message-ID: <1242123178.914.7.camel@jdlaptop.lesbg.loc> On Mon, 2009-05-11 at 14:35 -0400, Seth Vidal wrote: > I won't be running for the fedora board in the next round of elections. If this is because it's a thankless task, please reconsider. I really appreciate the work you've put into getting Presto up and running. You bought into someone else's idea and made it work, and, to me, that's invaluable in a board member. Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mike at thetroubleshooters.dk Tue May 12 10:26:12 2009 From: mike at thetroubleshooters.dk (Michael Nielsen) Date: Tue, 12 May 2009 12:26:12 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A086703.1080906@amiga-hardware.com> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A086703.1080906@amiga-hardware.com> Message-ID: <4A094EC4.9030506@TheTroubleshooters.dk> Ian Chapman wrote: > Michael Nielsen wrote: > > Simply not true. Right this moment I'm copying podcasts to my mp3 > player which was mounted directly by Gnome. It's accessible under > /media/disk. My external USB drive, the partitions for the other OSs I > have installed, my SD cards, camera etc are all available in a similar > way. Try to mount an NFS/CIFS, which were what i was talking about, sorry for being imprecise. > >> 4. Everything is thrown in huge collective directories, such as >> /usr/bin, /usr/lib etc, and it is a huge mess, just like windows with > > I'm surprised at this one. This is a big plus for me. As someone who > regularly has to deal with Solaris systems amongst others, I get tired > of playing guess the location of the binary, hunt the man page and > setting an ever increasing $PATH. > Actually all the install script (for the application) was to update the global login scripts, for the PATH variable, then the user would see it as if the whole system was a flat directory. It is a big disadvantage when testing, because the current scheme prevents having Firefox-2 and Firefox-3 (apache-1.3, apache-2.2 etc) installed, under package management because they contain files that conflict, similarly with 64 bit systems, where you need to install 32bit compatability software, they usually conflict, due to irrelevant documentation files conflicting. >> 5. More and more services are bound up in the userinterface, such as >> the pulse audio, which is started by the GUI, this means if you use 2 >> user > > Unfortunately Linux has suffered countless audio 'standards' and many > applications have been slow to catch up with the standard du jour, if > at all. Probably the single thing I most hate having to deal with when > it doesn't just work. Yup, I find the audio absolutely frustrating, have been trying to get skype running, with some reasonable audio quality. > >> wrong. The original concept for unix was to install an application >> such as firefox in either, /opt or /usr/local/. > > IIRC /opt was intended for self contained applications, which provide > their own tree. They are often statically compiled or depend only upon > libraries and files found in their own tree. They can be a complete > PITA to deal with. /usr/local I believe was intended to for installing > software locally to a specific machine or a group of machines without > interfering with system files or vice versa. Often the filesystems > weren't even local but NFS mounted from a server or similar. Good > package management and the fact that in general, most of the > filesystems these days are local has negated those reasons and > /usr/local is frequently (mis)used in other ways. Yes /usr/local was intended for local variations on software, so that you could install programs only on that machine, especially if you were using TBOOT (I think it was called), however, the only reason that spreading things out is hard to deal with, is because they don't update the various paths properly. I find it a huge problem, when there is a problem with system package, that I need to replace with a newer version, sometimes there are files left behind, that cause problems when you compile your own version. Also you cannot with the "everything in one dir" philosophy handle the situation where a user (or administrator) compiles a newer version from source, and there is a version installed via the package manager.. If you use the /opt approach, you can control it via softlinks, and you can have multiple versions of the same program available - I've always seen this as a strength of Unix, and a weakness of windows, where it is virtually impossible to have (for instance) IE 6, IE7, and IE 8 installed at the same time. I just find it a shame that this limitation is being adopted by Linux. > >> Such that the entire application was contained within a single >> installation directory, and then to use the PATH and LD_LIBRARY_PATH >> to allow the execution of the application. > > Exactly, I refer to the PATH hell earlier. Additionally > LD_LIBRARY_PATH is considered a security risk by many, especially when > many OSs have had alternatives for years. You can also use /etc/ld.so.conf for a more secure option. > >> I'm really curious as to the reasoning for moving everything from the >> standard configuration mechanisms to the gui layer, breaking >> compatibility with scripting, and other standard UNIX featuers. > > Curious. I maintain many Linux servers without a GUI installed. I > don't think I've had a requirement to configure anything that's > required a GUI. If by moving, you mean providing GUI tools for > configuration tasks that have traditionally required a command line, > I'm all for it. > You can avoid using the GUI (which I prefer), however, what I mean is, if you use the gui to configure the network, and you're not careful, you can find that the configuration you performed, is tied to your GUI account, and when you reboot, the settings are lost, until you log in again. I'm all for gui tools as an interface to the command line tools, and I'd applaud such an approach. I don't like the approach of creating parallel configurations, that are tied to the GUI. From mike at thetroubleshooters.dk Tue May 12 10:33:55 2009 From: mike at thetroubleshooters.dk (Michael Nielsen) Date: Tue, 12 May 2009 12:33:55 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08381D.5030604@freenet.de> Message-ID: <4A095093.5030403@TheTroubleshooters.dk> Seth Vidal wrote: > > but this isn't about the distro's long term development. > > It's a rant, a screed. It's a tirade. It's going to render zero > positive results. > > how do I know this? B/c I can, in fact, see into the near future. > > Here's what I see - a 30-40 msg thread that has no signal and all noise. > > I'm not going to bother with the rest of this thread. > > I'm speaking here not as an employee at red hat but as an elected > member of the fedora board. > > "This thread will bear no good results and I'm tired of everything > being full of bile and vitriol" > > I won't be running for the fedora board in the next round of > elections. You can run, Ralf. I hope you have great success tilting at > windmills. > > -sv > So in other words, I've noticed some problems that are creeping in, but I should shut up and not bring them to the attention of people developing the system. I do not rant, I point out problems, I describe them, though not in the detail they probably deserve, I work in the field, trying to promote Linux to the corporate users, and desktop people, and I work with the system daily. All the problems I have described are things that I run into daily, I have developed a strategy for working around the problems, and thus they do not present any problems for me, however, users without a deeper understanding of UNIX and Linux, might not be able to work around the issues. Therefore I am arguing that Linux is destroying it self. RedHat 8 had a really configurable interface, this has been slowly degraded. Fedora 8 was stable, and worked well, 9 - well sorry - never had so many problems with a linux distribution before, and 10 is not an improvement, I have 3 systems i've downgraded to Fedora 8, because fedora 10 is so unstable on these - the hardware is ok, runs everything other than Fedora 10. However, if my feedback is uninteresting, I'll leave the mailing list, and just ignore the problems. From ivazqueznet at gmail.com Tue May 12 10:37:01 2009 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Tue, 12 May 2009 06:37:01 -0400 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <234fa2210905120156h397d0125l500d9fa330bb5445@mail.gmail.com> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08C233.4020902@sapience.com> <4A093807.4010403@TheTroubleshooters.dk> <234fa2210905120156h397d0125l500d9fa330bb5445@mail.gmail.com> Message-ID: <1242124621.4183.75.camel@ignacio.ignacio.lan> On Tue, 2009-05-12 at 09:56 +0100, Ilyes Gouta wrote: > Hi, > > I think it's a good idea to not throw everything in one location. May > be we should really introduce this as a feature for the next Fedora > releases. This would also help get rid of the /usr/bin directory, > introduce more flexibility in packages management and security. > > -Ilyes Every single path you add to $PATH makes it take longer to find an executable on the system. I currently have over 750 packages on my system with files in /usr/bin; are you proposing to add over 750 paths to $PATH? -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bmr at redhat.com Tue May 12 10:49:55 2009 From: bmr at redhat.com (Bryn M. Reeves) Date: Tue, 12 May 2009 11:49:55 +0100 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A094EC4.9030506@TheTroubleshooters.dk> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A086703.1080906@amiga-hardware.com> <4A094EC4.9030506@TheTroubleshooters.dk> Message-ID: <1242125395.13505.449.camel@breeves.fab.redhat.com> On Tue, 2009-05-12 at 12:26 +0200, Michael Nielsen wrote: > It is a big disadvantage when testing, because the current scheme > prevents having Firefox-2 and Firefox-3 (apache-1.3, apache-2.2 etc) > installed, under package management because they contain files that > conflict, similarly with 64 bit systems, where you need to install 32bit > compatability software, they usually conflict, due to irrelevant > documentation files conflicting. Not true; when there are identical files shared between two packages (e.g. due to multilib) RPM does not report a conflict (the files in the file system are reference counted and are only unlinked when the last package is removed from the system). E.g.: # rpm --qf="%{name}-%{version}-%{release}.%{arch}\n" -qf /usr/share/doc/device-mapper-1.02.28/README device-mapper-1.02.28-2.el5.i386 device-mapper-1.02.28-2.el5.x86_64 Regards, Bryn. From khc at pm.waw.pl Tue May 12 10:52:56 2009 From: khc at pm.waw.pl (Krzysztof Halasa) Date: Tue, 12 May 2009 12:52:56 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A093793.2090100@TheTroubleshooters.dk> (Michael Nielsen's message of "Tue\, 12 May 2009 10\:47\:15 +0200") References: <4A082E70.7030904@TheTroubleshooters.dk> <4A093793.2090100@TheTroubleshooters.dk> Message-ID: Michael Nielsen writes: > This is called the Filesystem Hierarchy Standard, and it encodes decades of > experience organizing file systems into a standard which minimizes > differences across implementations. > > > I know of the standard, however, I really doubt the current Fedora > configuration really > follows it, I still don't see why everything needs to be thrown in > /usr/bin? The standard says binaries go to /usr/bin, so it then seems current Fedora really follows the standard :-) BTW UNIX was doing this for ages (with the long gone exception of executables in /etc). > Currently > on some installations, if you try to open them, are exceedingly heavy, I've had > smaller > machines stall out, as I try to change the application that starts when for > instance a movie > is to be played in firefox, apparently due to the amount of files in > /usr/bin. You've got many executables, you've got many files in /usr/bin. What do you want instead, that many directories (where?), each with a single file? > Actually Window$ is the system which started this "one directory per app" > stupidity. *nix has never worked that way. I guess perhaps DOS started this. > I beg to differ, having worked with several different UNIX flavours, I've yet > to see a commercial > UNIX that throws everything into one directory. Fedora doesn't throw everything into one directory either. Binaries go to one directory (actually at least four), libs go to others, shared files and directories go elsewhere etc. I wonder what different UNIX flavours you used were different? I was using several and all of them used a similar scheme. > ones in 1999, and went to Linux then. I noted the installation procedure of > not throwing everything > in one directory, before windows 3.1 was implemented, so I doubt it started > with windows. Windows, or DOS maybe, started to put all files (binaries, libs, text files, shared arch-dependent or independent :-) files in a one-per-program directory. What a mess. PATH=c:\program1;c:\program2;c:\program...999 gcc -Ic:\program1\include -Ic:\program2\include ... -Ic:\program999\include No, thanks. Though I think it had a positive side, too - it was really easy to remove a program. They didn't do any package management, you know. BTW Windows 3.1 wasn't exactly the first version. > Windows have seperated parts of the applications into specific directories, is > a good idea, Seen better. > however, > in Windows everything that is shared, is thrown into system32, and therefore > removing an installation > of a problem is nearly impossible, because there is Junk spread throughout the > system, relating to a > particular application, one of the causes for problems with windows. > > Thus if you need to run a non-packaged software, due to patches that you need > (security), you can > only hope that the package manager successfully removes everything, and does > not leave junk behind > which may, or may not affect the running of the newer compilation. Perhaps they need a better package manager? I guess they could use RPM. > Throwing everything in one directory hierarchy causes one particular problem > that I personally find > rather annoying, the inability to use the package manager system to have > multiple versions of > for-instance firefox installed on a system Nope, you can have multiple versions. The package has to be created with this requirement in mind. > The same situation can be seen when you run 64 bit systems, sometimes you need > to run something > in 32bit compatibility, however you cannot install the libraries you need > because of conflicts in the > packaging system, as - again - everything is thrown into one directory - in > this case the /usr/share/doc > directory, which means you need to find out how to force the installation of > the libraries. It would be a bug. Bi-arch (32 + 64-bit) packages are created to coexist. -- Krzysztof Halasa From emmanuel.seyman at club-internet.fr Tue May 12 11:25:42 2009 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Tue, 12 May 2009 13:25:42 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A095093.5030403@TheTroubleshooters.dk> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08381D.5030604@freenet.de> <4A095093.5030403@TheTroubleshooters.dk> Message-ID: <20090512112542.GA5124@orient.maison.lan> * Michael Nielsen [12/05/2009 13:12] : > > So in other words, I've noticed some problems that are creeping in, but > I should shut up and not bring them to the attention of people > developing the system. No, you should file bugs against the involved packages asking for these problems to be fixed. For problems that are general to the distributions (the filesystem, in your case), you should give a compelling reason for violating the FHS. In all cases, you should avoid hyperbole ("Fedora is Destroying it self") in your subject line. Offering to help solve these problems as opposed to simply whining about them is a bonus. Emmanuel From rc040203 at freenet.de Tue May 12 11:26:57 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 12 May 2009 13:26:57 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <1242065960.3452.32.camel@localhost.localdomain> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08381D.5030604@freenet.de> <4A085DDB.101@redhat.com> <4A0860B3.5030802@freenet.de> <1242065960.3452.32.camel@localhost.localdomain> Message-ID: <4A095D01.4070106@freenet.de> Jesse Keating wrote: > On Mon, 2009-05-11 at 19:30 +0200, Ralf Corsepius wrote: >> When "upstream" == "@RH", common sense and rationality seems to be >> switched off in Fedora. >> >> Updating firefox "last minute", between "F11-Preview" and "Final" from a >> "stable version" to an "unstable version" is such a case - It's beyond >> reason! > > Red Hat isn't the upstream for Firefox. I know, but the packager who is packaging unstable beta SW into Fedora is @RH. > The firefox in F11 preview was firefox-3.1-0.11.beta3.fc11. The one > currently in rawhide is firefox-3.5-0.20.beta4.fc11. Mozilla itself > changed the version from 3.1 to 3.5, but the planned contents didn't. > See > https://developer.mozilla.org/devnews/index.php/2009/03/05/firefox-31-may-become-firefox-35/ > > The update was to a /more/ stable version, a later beta release with > more fixes. May-be, from one unstable beta to another unstable beta => The mistake took place earlier. From rc040203 at freenet.de Tue May 12 11:29:04 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 12 May 2009 13:29:04 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <20090511180817.GA10057@free.fr> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08381D.5030604@freenet.de> <4A085DDB.101@redhat.com> <4A0860B3.5030802@freenet.de> <20090511180045.GR3435@mcpierce-laptop.rdu.redhat.com> <20090511180817.GA10057@free.fr> Message-ID: <4A095D80.8090502@freenet.de> Patrice Dumas wrote: > On Mon, May 11, 2009 at 02:00:45PM -0400, Darryl L. Pierce wrote: >> On Mon, May 11, 2009 at 07:30:27PM +0200, Ralf Corsepius wrote: >>> Everything? Maybe it escapes you, but it's always the same issue: >>> >>> When "upstream" == "@RH", common sense and rationality seems to be >>> switched off in Fedora. >> Red Hat's not upstream to Fedora. > > That's not what Ralf is saying. Exactly. > RH is upstream for some packages or > involved especially in upstream (for example, NetworkManager, hal, > consolekit, gdm, many gnome components...), and in that case it is > not rare that the corresponding packages end up in fedora releases > although there are features that were present in previous components > that are not already ready, or the applications are not that well > tested as shown in rawhide testing. You've got it - And named a few I have in mind, which I consider to be not to be not in a shape to base a distro on. From rc040203 at freenet.de Tue May 12 11:33:31 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 12 May 2009 13:33:31 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A095D80.8090502@freenet.de> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08381D.5030604@freenet.de> <4A085DDB.101@redhat.com> <4A0860B3.5030802@freenet.de> <20090511180045.GR3435@mcpierce-laptop.rdu.redhat.com> <20090511180817.GA10057@free.fr> <4A095D80.8090502@freenet.de> Message-ID: <4A095E8B.4050301@freenet.de> Ralf Corsepius wrote: > Patrice Dumas wrote: > You've got it - And named a few I have in mind, which I consider to be > not to be not in a shape to base a distro on. BTW: This duplicated "not to be not to be" likely is a c'n'p related-issue in FC10's thunderbird ;) From skvidal at fedoraproject.org Tue May 12 12:05:44 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 12 May 2009 08:05:44 -0400 (EDT) Subject: Fedora (Linux) is Destroying it self In-Reply-To: <1242125395.13505.449.camel@breeves.fab.redhat.com> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A086703.1080906@amiga-hardware.com> <4A094EC4.9030506@TheTroubleshooters.dk> <1242125395.13505.449.camel@breeves.fab.redhat.com> Message-ID: On Tue, 12 May 2009, Bryn M. Reeves wrote: > On Tue, 2009-05-12 at 12:26 +0200, Michael Nielsen wrote: >> It is a big disadvantage when testing, because the current scheme >> prevents having Firefox-2 and Firefox-3 (apache-1.3, apache-2.2 etc) >> installed, under package management because they contain files that >> conflict, similarly with 64 bit systems, where you need to install 32bit >> compatability software, they usually conflict, due to irrelevant >> documentation files conflicting. > > Not true; when there are identical files shared between two packages > (e.g. due to multilib) RPM does not report a conflict (the files in the > file system are reference counted and are only unlinked when the last > package is removed from the system). > > E.g.: > > # rpm --qf="%{name}-%{version}-%{release}.%{arch}\n" > -qf /usr/share/doc/device-mapper-1.02.28/README > device-mapper-1.02.28-2.el5.i386 > device-mapper-1.02.28-2.el5.x86_64 That's not a correct example. The above example is of multilib files, not of conflicting files. rpm does track conflicts and it does keep you from installing if you have actually conflicting files. a file conflict is two pkgs owning the same file where the file is not: 1. identical between the two pkgs 2. not a 64bit or 32bit binary when the other file is the matching 64bit or 32bit binary. -sv From m at cotdp.com Tue May 12 12:07:01 2009 From: m at cotdp.com (Michael Cutler) Date: Tue, 12 May 2009 12:07:01 +0000 (GMT) Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A095093.5030403@TheTroubleshooters.dk> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08381D.5030604@freenet.de> <4A095093.5030403@TheTroubleshooters.dk> Message-ID: <322597.85948.qm@web26108.mail.ukl.yahoo.com> Michael Nielsen wrote: > > So in other words, I've noticed some problems that are creeping in, but I should shut up and not > bring them to the attention of people developing the system. > > I do not rant, I point out problems, I describe them, though not in the detail they probably deserve, > I work in the field, trying to promote Linux to the corporate users, and desktop people, and I work > with the system daily. > [snip] > Firstly, I am a huge fan of the original Redhat Linux and Fedora, I have flirted with some of the other distributions, overall the Fedora Project is where I want to be. In terms of stability, reliability and feature-set - the work you guys are doing is top-notch and I would like to thank everyone that is a part of the process. However, I am inclined to agree with some of the points brought up by Michael Nielsen. It feels like in recent releases there has been a progressive 'dumbing down' of Fedora. I understand the desire to simplify the installation process, usability and configuration for Desktop profile users, but not at the cost of removing functionality that veteran Power Users have come to expect. Dismissing some of these points with statements like "you're a Power User, use the command-line" just grows resentment. Yes, it may be that I can workaround my particular issue(s) with the command-line and/or config file editing but when its a behaviour change between releases it can be frustrating to have to jump through a few dozen extra hoops just to get the machine in the same state as a fresh install from a previous release. I believe there could/should be a happy medium were both newbies and power-users can get the most out of Fedora from the *same* release CD/DVD. I work in a Research & Development group for a big corp, unfortunately the variety of the hardware I use mostly prevent me from using kickstart to clone the installations. During the testing phase for F10 I highlighted one such "dumbing down" issue in Bugzilla #468028 [1] and on this list - where the network interfaces are crippled post-install because the behaviour of the installer changed how the /etc/sysconfig/network-script/ifcfg-* files default. F10 went-to-press without a resolution to this issue and subsequently I have been manually frigging the ifcfg-* files after every single install since. Personally, one feature I would love to see resurrected from Red Hat Linux was the "Installation type" dialog, where you could choose "Laptop", "Desktop", "Workstation" or "Server" - optionally followed by the custom package selection pages. Obviously package selection can be pre-set depending on the choice, e.g. no point having Battery monitoring installed unless its a 'Laptop'. Can I suggest individual points highlighted by this email chain be raised as potential-feature-requests on F12 before they slip off the radar? Should they be lodged as a feature-request in Bugzilla or is there a more appropriate place to start the discussion? Kind Regards, -- MC [1] https://bugzilla.redhat.com/show_bug.cgi?id=468028 From skvidal at fedoraproject.org Tue May 12 12:12:34 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 12 May 2009 08:12:34 -0400 (EDT) Subject: Fedora (Linux) is Destroying it self In-Reply-To: <1242123178.914.7.camel@jdlaptop.lesbg.loc> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08381D.5030604@freenet.de> <1242123178.914.7.camel@jdlaptop.lesbg.loc> Message-ID: On Tue, 12 May 2009, Jonathan Dieter wrote: > On Mon, 2009-05-11 at 14:35 -0400, Seth Vidal wrote: > >> I won't be running for the fedora board in the next round of elections. > > > If this is because it's a thankless task, please reconsider. I really > appreciate the work you've put into getting Presto up and running. You > bought into someone else's idea and made it work, and, to me, that's > invaluable in a board member. I appreciate the kind words but I've been on the board for a long time now. Either as an elected member of an appointed member. I think it is time someone else had the opportunity to be in the position I've been holding open. -sv From kevin.kofler at chello.at Tue May 12 12:20:41 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 12 May 2009 14:20:41 +0200 Subject: OpenOffice 3.1 References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <1241990992.3452.6.camel@localhost.localdomain> <6dc6523c0905101458l64811e65lb9f18216a4f93941@mail.gmail.com> <1242064968.2923.615.camel@adam.local.net> <1242072865.2923.670.camel@adam.local.net> <1242079541.3452.48.camel@localhost.localdomain> <1242080497.2923.676.camel@adam.local.net> <1242122940.1211.19.camel@gilboa-work-dev.localdomain> Message-ID: Gilboa Davara wrote: > Which would have left us with KDE 4 in F9 instead of KDE 4.2.2 4.0.3 to be precise. Kevin Kofler From bmr at redhat.com Tue May 12 12:26:32 2009 From: bmr at redhat.com (Bryn M. Reeves) Date: Tue, 12 May 2009 13:26:32 +0100 Subject: Fedora (Linux) is Destroying it self In-Reply-To: References: <4A082E70.7030904@TheTroubleshooters.dk> <4A086703.1080906@amiga-hardware.com> <4A094EC4.9030506@TheTroubleshooters.dk> <1242125395.13505.449.camel@breeves.fab.redhat.com> Message-ID: <1242131192.13505.473.camel@breeves.fab.redhat.com> On Tue, 2009-05-12 at 08:05 -0400, Seth Vidal wrote: > On Tue, 12 May 2009, Bryn M. Reeves wrote: > > # rpm --qf="%{name}-%{version}-%{release}.%{arch}\n" > > -qf /usr/share/doc/device-mapper-1.02.28/README > > device-mapper-1.02.28-2.el5.i386 > > device-mapper-1.02.28-2.el5.x86_64 > > That's not a correct example. > > The above example is of multilib files, not of conflicting files. It's not supposed to be an example of conflicting files. It's an example of a documentation file installed by two different packages that does _not_ conflict, as that's what Michael was talking about: "similarly with 64 bit systems, where you need to install 32bit compatability software, they usually conflict, due to irrelevant documentation files conflicting." But the documentation files don't usually conflict because RPM handles them as above. If the files had different content then there would be a conflict but that is not normally the case with multilib as Michael had claimed. That's the point I was trying to make - that identical files installed to the same path by two different package do not conflict. > rpm does track conflicts and it does keep you from installing if you have > actually conflicting files. But in this case there is no conflict. Regards, Bryn. From ilyes.gouta at gmail.com Tue May 12 12:26:18 2009 From: ilyes.gouta at gmail.com (Ilyes Gouta) Date: Tue, 12 May 2009 13:26:18 +0100 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <1242124621.4183.75.camel@ignacio.ignacio.lan> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08C233.4020902@sapience.com> <4A093807.4010403@TheTroubleshooters.dk> <234fa2210905120156h397d0125l500d9fa330bb5445@mail.gmail.com> <1242124621.4183.75.camel@ignacio.ignacio.lan> Message-ID: <234fa2210905120526i364a7f25m97cbed4a0b23a1ea@mail.gmail.com> Hi, Obviously one has to set up $PATH and $LD_LIBRARY_PATH to get programs running properly. /usr/bin would be populated with scripts that do exactly that so that the change is transparent to the user. But that's really the implementation part of the idea, let's stick to the concept for the moment.. Isn't having one folder per application a nice feature? What I'm emphasizing here is separation for more flexibility. -Ilyes On Tue, May 12, 2009 at 11:37 AM, Ignacio Vazquez-Abrams wrote: > On Tue, 2009-05-12 at 09:56 +0100, Ilyes Gouta wrote: >> Hi, >> >> I think it's a good idea to not throw everything in one location. May >> be we should really introduce this as a feature for the next Fedora >> releases. This would also help get rid of the /usr/bin directory, >> introduce more flexibility in packages management and security. >> >> -Ilyes > > Every single path you add to $PATH makes it take longer to find an > executable on the system. I currently have over 750 packages on my > system with files in /usr/bin; are you proposing to add over 750 paths > to $PATH? > > -- > Ignacio Vazquez-Abrams > > PLEASE don't CC me; I'm already subscribed > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From aph at redhat.com Tue May 12 12:29:37 2009 From: aph at redhat.com (Andrew Haley) Date: Tue, 12 May 2009 13:29:37 +0100 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <234fa2210905120526i364a7f25m97cbed4a0b23a1ea@mail.gmail.com> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08C233.4020902@sapience.com> <4A093807.4010403@TheTroubleshooters.dk> <234fa2210905120156h397d0125l500d9fa330bb5445@mail.gmail.com> <1242124621.4183.75.camel@ignacio.ignacio.lan> <234fa2210905120526i364a7f25m97cbed4a0b23a1ea@mail.gmail.com> Message-ID: <4A096BB1.6060808@redhat.com> Ilyes Gouta wrote: > Obviously one has to set up $PATH and $LD_LIBRARY_PATH to get programs > running properly. /usr/bin would be populated with scripts that do > exactly that so that the change is transparent to the user. But that's > really the implementation part of the idea, let's stick to the concept > for the moment.. Isn't having one folder per application a nice > feature? IMO, no. I can't see what this would achieve. Andrew. From ivazqueznet at gmail.com Tue May 12 12:40:15 2009 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Tue, 12 May 2009 08:40:15 -0400 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <234fa2210905120526i364a7f25m97cbed4a0b23a1ea@mail.gmail.com> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08C233.4020902@sapience.com> <4A093807.4010403@TheTroubleshooters.dk> <234fa2210905120156h397d0125l500d9fa330bb5445@mail.gmail.com> <1242124621.4183.75.camel@ignacio.ignacio.lan> <234fa2210905120526i364a7f25m97cbed4a0b23a1ea@mail.gmail.com> Message-ID: <1242132015.4183.80.camel@ignacio.ignacio.lan> On Tue, 2009-05-12 at 13:26 +0100, Ilyes Gouta wrote: > Obviously one has to set up $PATH and $LD_LIBRARY_PATH to get programs > running properly. /usr/bin would be populated with scripts that do > exactly that so that the change is transparent to the user. How then is this an advantage over having the binaries in /usr/bin directly? > But that's > really the implementation part of the idea, let's stick to the concept > for the moment.. Isn't having one folder per application a nice > feature? What I'm emphasizing here is separation for more flexibility. It's real cute to be all hand-wavy and say "I think this and this and this", but at the end of the day if someone doesn't do it then it doesn't get done. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Tue May 12 12:49:50 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 12 May 2009 05:49:50 -0700 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <234fa2210905120526i364a7f25m97cbed4a0b23a1ea@mail.gmail.com> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08C233.4020902@sapience.com> <4A093807.4010403@TheTroubleshooters.dk> <234fa2210905120156h397d0125l500d9fa330bb5445@mail.gmail.com> <1242124621.4183.75.camel@ignacio.ignacio.lan> <234fa2210905120526i364a7f25m97cbed4a0b23a1ea@mail.gmail.com> Message-ID: <4A09706E.2030008@gmail.com> Ilyes Gouta wrote: > Isn't having one folder per application a nice > feature? What I'm emphasizing here is separation for more flexibility. > I don't see Fedora departing from the FHS. But perhaps you'd be interested in Gobo Linux: http://www.gobolinux.org/ -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From rjones at redhat.com Tue May 12 12:52:04 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 12 May 2009 13:52:04 +0100 Subject: [REPOST!] Split out e2fsprogs sublibraries Message-ID: <20090512125204.GA13004@amd.home.annexia.org> [I posted this before, but no one replied, so sending again to fedora-devel-list] https://bugzilla.redhat.com/show_bug.cgi?id=225406#c7 I would like to propose that e2fsprogs generate four subpackages for the independent libraries that it contains. These four libraries are used by other packages that don't need the whole of e2fsprogs-devel (eg. krb5_workstation uses libss, qpid uses libuuid, and many programs use libcom_err). Our specific use case is to help with ongoing work porting libraries to MinGW (http://fedoraproject.org/wiki/MinGW) where we would prefer to package mingw32-libuuid for mingw32-qpidc without needing to port the whole of e2fsprogs. I looked at Debian's package, and would like to propose a split along the same lines: http://packages.debian.org/source/lenny/e2fsprogs Despite the apparent complexity, there are only really four subpackages. For the Fedora package we would create: libblkid libblkid-devel libcom_err libcom_err-devel [note 1] libss libss-devel libuuid libuuid-devel There are no conflicting package names in Fedora at the moment, except for the similarly named libss7 (a library implementing Signalling System 7 telephone switching protocol). I have attached a patch against Rawhide which does the above split. I set up the dependencies so there should be no loss of functionality for users who install just e2fsprogs or e2fsprogs-devel. What remains is to advertize the split on fedora-devel-list and encourage package maintainers to replace: BuildRequires: e2fsprogs-devel with BuildRequires: lib-devel where appropriate. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw From mcepl at redhat.com Tue May 12 12:57:16 2009 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 12 May 2009 14:57:16 +0200 Subject: OpenOffice 3.1 References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <1241998651.2760.9.camel@moose> Message-ID: On 2009-05-11, 15:23 GMT, Pavel Alexeev (aka Pahan-Hubbitus) wrote: >> I believe OOo 3.1 from >> http://download.openoffice.org/other.html works on Fedora 9. >> > Cool. Can me treat it as proof what it is not break anything in system? No. I have no clue about that, and I have never used that ... I am on Rawhide. Mat?j From pbrobinson at gmail.com Tue May 12 13:03:14 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 12 May 2009 14:03:14 +0100 Subject: [REPOST!] Split out e2fsprogs sublibraries In-Reply-To: <20090512125204.GA13004@amd.home.annexia.org> References: <20090512125204.GA13004@amd.home.annexia.org> Message-ID: <5256d0b0905120603i752a6b6ej99cfd856a45593d5@mail.gmail.com> Hi Richard, > https://bugzilla.redhat.com/show_bug.cgi?id=225406#c7 > > I would like to propose that e2fsprogs generate four subpackages for > the independent libraries that it contains. ?These four libraries are > used by other packages that don't need the whole of e2fsprogs-devel > (eg. krb5_workstation uses libss, qpid uses libuuid, and many programs > use libcom_err). Great idea, there has been some confusion in the past over uuid package vs libuuid in e2fsprogs > Our specific use case is to help with ongoing work porting libraries > to MinGW (http://fedoraproject.org/wiki/MinGW) where we would prefer > to package mingw32-libuuid for mingw32-qpidc without needing to port > the whole of e2fsprogs. > > I looked at Debian's package, and would like to propose a split along > the same lines: > > ?http://packages.debian.org/source/lenny/e2fsprogs > > Despite the apparent complexity, there are only really four > subpackages. ?For the Fedora package we would create: > > ?libblkid ? ? ?libblkid-devel > ?libcom_err ? ?libcom_err-devel ? ? ? [note 1] > ?libss ? ? ? ? libss-devel > ?libuuid ? ? ? libuuid-devel > > There are no conflicting package names in Fedora at the moment, except > for the similarly named libss7 (a library implementing Signalling > System 7 telephone switching protocol). There is also the similarly named uuid which has caused some confusion in the past. > I have attached a patch against Rawhide which does the above split. ?I > set up the dependencies so there should be no loss of functionality > for users who install just e2fsprogs or e2fsprogs-devel. > > What remains is to advertize the split on fedora-devel-list and > encourage package maintainers to replace: > > ?BuildRequires: e2fsprogs-devel > > with > > ?BuildRequires: lib-devel > > where appropriate. I have a number of packages that depend on libuuid which will need to be updated. With the auto provides in most rpms I don't think they should need a rebuild straight up as they depend on libuuid.so.1 as opposed to a specific package name but only going forward so in the short term there shouldn't be breakages? Peter From kevin.kofler at chello.at Tue May 12 13:13:05 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 12 May 2009 15:13:05 +0200 Subject: Fedora (Linux) is Destroying it self References: <4A082E70.7030904@TheTroubleshooters.dk> <7f692fec0905110735tf8a1bd4u7a71d85f6de7f14b@mail.gmail.com> <4A094342.7000805@TheTroubleshooters.dk> Message-ID: Michael Nielsen wrote: > I've been setting up my own window managers for years, and I tend to do > so, however, it would be really nice > if one was able to use the work that others had done, such as the menu > system, etc that gnome, and > KDE uses, however, I do not like the default click-to-front, that I used > to be able to simply disable, > however this feature is no longer trivial to find, initially I could > still load a useful windowmanager, > and thereby replace the underlying window manager in Gnome, nor KDE for > that matter. > I prefer other window managers, such as enlightenment, fwm, etc, I've > used quite a lot of > different ones in my time. > > However, it is getting rather annoying having to manually update the > custom desktop environment > to follow a moving target, thus it would be preferable to be able to > follow one of the maintained > ones, however, as I pointed out, their features are being eroded, and > basic functions are being > removed. KDE offers that option under "Window properties" in System Settings as it always did and there are no plans to remove it. Please do not generalize your complaints about GNOME to desktop environments which have nothing to do with them, and I'd suggest trying out KDE. > I find it frustrating to see that Linux is forking at this level, because > it means that someone who is not a Power user (or command line freak > which I'm often > catagorised as), will have more difficulty in setting up a simple web > server, because the > network configuration is personal if you use the applet approach., Thus > the person will discover that > once they log off, their system is no longer online, and their webserver > doesn't work. NetworkManager now supports systemwide settings. > For-instance Gnome there is the administration Network configuration, > which appears to do what > I'm asking, and there is the network applet configuration, which does > not update > the configuration files - at least I've been unable to detect the > changes. So you > have two views, that in principle does the exact same thing, and yet, > one is a system > wide configuration, the other is a local user related change. This > bound to be > confusing to people. The latest NetworkManager in F11 allows setting up systemwide settings from the same UI which also handles per-user settings. > I'm not complaining I'm pointing out a problem in the system, the > current "design" > (as you call it), prevents the management of multiple versions of an > application, > as they will conflict in the package manager That's because it just doesn't make sense. You're expected to have one up-to-date version of the application, not dozens of old ones. > and unfortunately it is often necessary to have 32 bit compatibility > installed. For libraries maybe, but for applications, no. (If you're talking about browsers, that's what nspluginwrapper is for. And the common plugins (even the proprietary ones) even have native 64-bit versions available now.) > Most ordinary users would give up on running Skype on Linux How's that a bad thing? Death to proprietary software! Everything which discourages using it is a good thing. Especially Skype which spreads like a virus due to the social networking effect (the "all my friends use it" effect). By using Skype, not only are you hurting yourself with proprietary software, but you're also enticing all your friends to install or keep using proprietary software, it's just plain evil. >>> 6. NetworkManager which appears to be installed default, does not work >>> with shared drives, because, the NetworkManager is shut down before the >>> network drives are detached, and you need to modify the NetworkManager >>> to start properly, before you mount the network drives. I've gotten used >>> to explicit uninstalling the NetworkManager, because it just doesn't >>> work properly. >>> >> >> Again, you're a power user. Reorder your shutdown sequence. >> > Again, Yes I can, and I do, but what about less experienced users ? > Are we not > trying to get Linux to be mainstream ? "Less experienced", "mainstream" users do not use shared network drives on their self-administered machines. They may be using them at their place of work or study, but in that case it's the job of that place's experienced sysadmin to set them up. Home networks with shared drives containing essential parts of the system (and home directories are part of that) are something only power users use. Mainstream users usually only have one computer, and those more advanced ones who do have more than one computer copy files to another computer by emailing them to themselves or using a USB stick. (I personally use SFTP, which also doesn't suffer from the issues you describe, but I also consider myself a "power user".) > I need Firefox-2.0 installed, and Firefox-3.0 installed, hmm, they > conflict, in the package manager. That's normal. You should use only the latest version. Even if you're doing web development, it makes no sense to still target Firefox 2: Window$ users still on Firefox 2 get prompted to upgrade to Firefox 3 for "important security updates" by Firefox itself (I've seen that prompt on a Window$ machine, it doesn't even say it's a major version upgrade), GNU/Linux users get a current version from their distribution (e.g. all supported Fedora releases have Firefox 3.0, F11 will even ship with 3.5 beta). Better test compatibility across browsers (you can easily test Konqueror (KHTML), Arora (QtWebKit) and Midori (WebKit-GTK+) in Fedora) instead of bothering with obsolete versions of Firefox! > The problem as I see it, is that Fedora has decided that everything is > an integral part of the operating system, which is creating the mess I'm > trying to describe. This is a feature, and in fact what makes GNU/Linux so great. Everything is available in a few clicks (or a 3-word command) from the repository. > Relying on Yum and RPM to do all the work, will eventually cause the > same "Sanding up" of the operating system, that you can see on windows, in > that not everyone cleans up properly, and eventually junk is left all over > the place, rather than isolated. This is complete nonsense. The whole point of RPM is that it keeps track of everything which is installed in its database, so you CANNOT end up with junk left behind, uninstalling a package reliably removes all the files the package installed (well, except configuration in user home directories, but that's a feature, you'll want the configuration back if you reinstall the app later! And the "one directory per app" approach also doesn't address per-user configuration). The way you end up with "junk left all over the place" is by installing software from source as you're doing. Even if you use a per-package prefix, some stuff still installs things into /usr to achieve proper system integration, e.g. menu entries etc. A modern GUI OS is an integrated whole, not a bunch of apps which are not found in any menu, are not associated to any file type etc. As for command-line stuff, it also makes a lot of sense to have that all in /usr/bin, otherwise you end up with a mess like Window$ where you have to add an entry to the PATH for every single command-line app you install and you end up with dozens of directories in your PATH (and it would be hundreds in a *nix system where there's a lot more command-line stuff). Kevin Kofler From kevin.kofler at chello.at Tue May 12 13:24:47 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 12 May 2009 15:24:47 +0200 Subject: Fedora (Linux) is Destroying it self References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08C233.4020902@sapience.com> <4A093807.4010403@TheTroubleshooters.dk> <234fa2210905120156h397d0125l500d9fa330bb5445@mail.gmail.com> Message-ID: Ilyes Gouta wrote: > I think it's a good idea to not throw everything in one location. May > be we should really introduce this as a feature for the next Fedora > releases. This would also help get rid of the /usr/bin directory, > introduce more flexibility in packages management and security. Hey, April 1st was over a month ago! /usr/bin is 1. required by the FHS, 2. required because otherwise we'd end up with a huge PATH which slows down the whole system, 3. part of how *nix works, 4. directly referenced in many scripts (the #! lines require a full path, unless you use /usr/bin/env ? which also requires hardcoding /usr/bin!) and 5. just common sense. Kevin Kofler From rjones at redhat.com Tue May 12 13:27:59 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 12 May 2009 14:27:59 +0100 Subject: [REPOST!] Split out e2fsprogs sublibraries In-Reply-To: <5256d0b0905120603i752a6b6ej99cfd856a45593d5@mail.gmail.com> References: <20090512125204.GA13004@amd.home.annexia.org> <5256d0b0905120603i752a6b6ej99cfd856a45593d5@mail.gmail.com> Message-ID: <20090512132759.GA13270@amd.home.annexia.org> On Tue, May 12, 2009 at 02:03:14PM +0100, Peter Robinson wrote: [...] This bit is just advice ... > > What remains is to advertize the split on fedora-devel-list and > > encourage package maintainers to replace: > > > > ?BuildRequires: e2fsprogs-devel > > > > with > > > > ?BuildRequires: lib-devel > > > > where appropriate. > > I have a number of packages that depend on libuuid which will need to > be updated. ... so hopefully no one will need to change the BR until they are ready. > With the auto provides in most rpms I don't think they should need a > rebuild straight up as they depend on libuuid.so.1 as opposed to a > specific package name but only going forward so in the short term > there shouldn't be breakages? I'm hoping there will be no breakage at all. But since it's a big change to an important package that lots of other packages depend on, one can never tell, so if we're going to do it at all, it should be at the start of a development cycle (ie. now). Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From kevin.kofler at chello.at Tue May 12 13:30:56 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 12 May 2009 15:30:56 +0200 Subject: Fedora (Linux) is Destroying it self References: <4A082E70.7030904@TheTroubleshooters.dk> <200905111040.27935.konrad@tylerc.org> <4A094AC8.9090602@TheTroubleshooters.dk> Message-ID: Michael Nielsen wrote: > Personally I like Fedora, but I don't like the way it is moving as an > entity - IMO downhill since Redhat 8 (as server, and configurability), > though Fedora 8 (as a desktop) was quite nice. Fedora 10 is highly > unstable, I have no less than 3 systems, that comes with serious > problems under Fedora 10, but works brilliantly with Fedora 8. That's funny because F8 was the release which introduced PulseAudio (by default ? it was already available in the repository before), which is the subject of one of your rants... Kevin Kofler From rawhide at fedoraproject.org Tue May 12 13:39:29 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Tue, 12 May 2009 13:39:29 +0000 (UTC) Subject: rawhide report: 20090512 changes Message-ID: <20090512133929.4DD3B1F8214@releng2.fedora.phx.redhat.com> Compose started at Tue May 12 06:15:04 UTC 2009 Removed package cpan2rpm Removed package kio_p7zip Updated Packages: docbook-dtds-1.0-47.fc11 ------------------------ * Mon May 11 2009 Ondrej Vasik - 1.0-47 - Added requires(post) for /bin/chmod (#498680) fedora-package-config-apt-11-4 ------------------------------ * Tue May 05 2009 Axel Thimm - 11-4 - Update to F11. fedora-package-config-smart-11-17 --------------------------------- * Tue May 05 2009 Axel Thimm - 11-17 - Switch to stable release. fedora-release-11-1 ------------------- * Mon May 11 2009 Jesse Keating - 11-1 - First attempt at release candidate. - Drop the compose configs, that's in spin-kickstarts - Enable fedora and updates repo, disable rawhide gallery2-2.3-9.fc11 ------------------- * Fri May 01 2009 Jon Ciesla - 2.3-9 - Add rewrite dep for httpauth, BZ 498061. - Adopt rdieter's symlink handling suggestions from rel-eng #1674. * Tue Apr 28 2009 Jon Ciesla - 2.3-8 - pretrans script logic fix. BZ498019. giflib-4.1.6-2.fc11 ------------------- * Sat May 09 2009 Robert Scheck 4.1.6-2 - Solved multilib problems with documentation (#465208, #474538) - Removed static library from giflib-devel package (#225796 #c1) glibc-2.10.1-1 -------------- * Sun May 10 2009 Jakub Jelinek 2.10.1-1 - fix up getsgent_r and getsgnam_r exports on i?86 and ppc * Sat May 09 2009 Jakub Jelinek 2.10-2 - update from trunk - glibc 2.10 release - fix memchr on x86_64 (#499689) leonidas-backgrounds-11.0.0-1.fc11 ---------------------------------- * Sat May 09 2009 Martin Sourada - 11.0.0-1 - Include the lion design optionally on single screens as well via -lion subpackage - Split the dual screen images with lion design into -lion-dual subpackage to allow having only one of the single screens installed - Don't forget to own some all used directories not provided by other pkgs libvirt-0.6.2-8.fc11 -------------------- * Sun May 10 2009 Cole Robinson - 0.6.2-8.fc11 - Don't try to label a disk with no path (e.g. empty cdrom) (bug #499569) * Thu May 07 2009 Mark McLoughlin - 0.6.2-7.fc11 - Enable migration for qemu 0.10 (bug #499704) mesa-7.5-0.14.fc11 ------------------ * Tue May 05 2009 Dave Airlie 7.5-0.14 - radeon-rewrite.patch: fixes from upstream for rs690 + r200 * Tue Apr 28 2009 Dave Airlie 7.5-0.12 - rebase to upstream snapshot + radeon-rewrite * Tue Apr 28 2009 Dave Airlie 7.5-0.13 - radeon fix clip emits * Thu Apr 16 2009 Dave Airlie 7.5-0.11 - radeon-rewrite-fixes.patch: fix context crash in compiz + r200 fixes * Tue Apr 14 2009 Adam Jackson 7.5-0.10 - mesa-7.5-get-driver-name.patch: Fix glXGetScreenDriver for DRI2 (#495342) mock-0.9.16-1.fc11 ------------------ * Mon May 11 2009 Jesse Keating - 0.9.15-1 - Add configs for F11 (jkeating) * Mon May 11 2009 Jesse Keating - 0.9.16-1 - Make F11 and rawhide build i586 on i386 targets. selinux-policy-3.6.12-34.fc11 ----------------------------- * Mon May 11 2009 Dan Walsh 3.6.12-34 - Allow rpcd_t to send signals to kernel threads * Thu May 07 2009 Dan Walsh 3.6.12-31 - Add policy for /var/lib/fprint * Thu May 07 2009 Dan Walsh 3.6.12-33 - Fix upgrade for F10 to F11 * Tue May 05 2009 Dan Walsh 3.6.12-29 - Allow svirt to manage pci and other sysfs device data * Tue May 05 2009 Dan Walsh 3.6.12-30 -Remove duplicate line valgrind-3.4.1-3 ---------------- * Mon May 11 2009 Jakub Jelinek 3.4.1-3 - rebuilt against glibc 2.10.1 xorg-x11-xinit-1.0.9-7.fc11 --------------------------- * Fri May 08 2009 Adam Jackson 1.0.9-7 - xinit-1.0.9-unset.patch: Also unset XDG_SESSION_COOKIE in startx. (#489999) Summary: Added Packages: 0 Removed Packages: 2 Modified Packages: 14 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From a.badger at gmail.com Tue May 12 13:42:41 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 12 May 2009 06:42:41 -0700 Subject: FESco meeting summary for 20090507 In-Reply-To: <20090511215752.GC22336@nostromo.devel.redhat.com> References: <4A05D52B.7050100@gmail.com> <20090511215752.GC22336@nostromo.devel.redhat.com> Message-ID: <4A097CD1.9080407@gmail.com> Bill Nottingham wrote: > Toshio Kuratomi (a.badger at gmail.com) said: >> One thing that was mentioned was the lack of fs acls at the moment. >> After looking at what we have now, I'm not sure that fs acls fix >> anything that's not also broken currently. >> >> Currently: >> >> * the cvs repository has no fs acls >> * unix group for all directories is set to packager with a sticky group bit. >> * the cvs acl script limits who can actually commit to packages to >> @provenpackager and the specific people involved. >> >> Implementation-wise, the proposal would allow the cvs acl script to have >> @packager as another allowed group so people who are just in the >> packager group can commit to a specific package. >> >> I can see fs acls being used to lock down our repo against bugs in the >> cvs acl script or being used to replace the cvs acl script. But that >> seems to be somewhat separate from the proposal. I don't think it would >> solve anything specific to the proposal but could make things more >> secure for both the current and proposed method. >> >> notting, do you see something that I don't? > > You *could* swap the permissions so that all packages are only > provenpackager-writable, and implement packager (and owner) access > via FS acls. > > Whether that scales or not is another matter. > As long as the fs can record enough accounts I think this would scale fine. In terms of resources used, I'd imagine that it would be better for us as we could theoretically stop using the cvs acl script and rely solely on the filesystem to do the acl checking. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From sandeen at redhat.com Tue May 12 13:52:01 2009 From: sandeen at redhat.com (Eric Sandeen) Date: Tue, 12 May 2009 08:52:01 -0500 Subject: [REPOST!] Split out e2fsprogs sublibraries In-Reply-To: <20090512125204.GA13004@amd.home.annexia.org> References: <20090512125204.GA13004@amd.home.annexia.org> Message-ID: <4A097F01.5000502@redhat.com> Richard W.M. Jones wrote: > [I posted this before, but no one replied, so sending again to > fedora-devel-list] > > https://bugzilla.redhat.com/show_bug.cgi?id=225406#c7 > > I would like to propose that e2fsprogs generate four subpackages for > the independent libraries that it contains. These four libraries are > used by other packages that don't need the whole of e2fsprogs-devel > (eg. krb5_workstation uses libss, qpid uses libuuid, and many programs > use libcom_err). I'm generally open to the suggestion, but last time I had this concern... > The next problem I see is that by putting things like blkid, uuidgen, > compile_et, mk_cmds into the lib$FOO packages, they are now no longer > multilib-safe; the binaries will collide. is this going to be a subpackage-explosion? for example: uuid.rpm (with the binary tool(s)) uuid-libs.rpm uuid-devel.rpm and so on for each of the above binary+libs? -Eric From kevin.kofler at chello.at Tue May 12 13:54:12 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 12 May 2009 15:54:12 +0200 Subject: Fedora (Linux) is Destroying it self References: <4A082E70.7030904@TheTroubleshooters.dk> <4A093793.2090100@TheTroubleshooters.dk> Message-ID: Michael Nielsen wrote: > Windows have seperated parts of the applications into specific > directories, is a good idea, however, in Windows everything that is > shared, is thrown into system32, and therefore removing an installation > of a problem is nearly impossible, because there is Junk spread throughout > the system, relating to a particular application, one of the causes for > problems with windows. But it is irrelevant in Fedora because RPM doesn't leave junk around, it knows exactly what package installed any given file, and there can't be DLLs owned by more than one package (the source of DLL Hell on Window$ and part of why there remains junk left in system32), instead, shared libraries are packaged separately and dragged in as dependencies (the right way). > Thus if you need to run a non-packaged software, due to patches that you > need (security) That's a lame excuse. Security updates get pushed as quickly as possible, just use the packaged security update. Of course this assumes you aren't using an obsolete, no longer updated distribution. Time to upgrade! > you can only hope that the package manager successfully removes > everything, and does not leave junk behind which may, or may not affect > the running of the newer compilation. The package manager doesn't and shouldn't touch unpackaged programs. Don't use unpackaged programs if you don't want to lose the advantages of package management! Kevin Kofler From gilboad at gmail.com Tue May 12 14:01:36 2009 From: gilboad at gmail.com (Gilboa Davara) Date: Tue, 12 May 2009 17:01:36 +0300 Subject: OpenOffice 3.1 In-Reply-To: References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <1241990992.3452.6.camel@localhost.localdomain> <6dc6523c0905101458l64811e65lb9f18216a4f93941@mail.gmail.com> <1242064968.2923.615.camel@adam.local.net> <1242072865.2923.670.camel@adam.local.net> <1242079541.3452.48.camel@localhost.localdomain> <1242080497.2923.676.camel@adam.local.net> <1242122940.1211.19.camel@gilboa-work-dev.localdomain> Message-ID: <1242136896.1211.24.camel@gilboa-work-dev.localdomain> On Tue, 2009-05-12 at 14:20 +0200, Kevin Kofler wrote: > Gilboa Davara wrote: > > Which would have left us with KDE 4 in F9 instead of KDE 4.2.2 > > 4.0.3 to be precise. > > Kevin Kofler > I stand corrected. - Gilboa From jarod at redhat.com Tue May 12 14:01:41 2009 From: jarod at redhat.com (Jarod Wilson) Date: Tue, 12 May 2009 10:01:41 -0400 Subject: SPARC Status (Was Re: Secondary Architecture Status?) In-Reply-To: <5256d0b0905111202x2df6b773y689fe618b502315c@mail.gmail.com> References: <20090511185147.GA3256@yoda.jdub.homelinux.org> <5256d0b0905111202x2df6b773y689fe618b502315c@mail.gmail.com> Message-ID: <200905121001.42151.jarod@redhat.com> On Monday 11 May 2009 15:02:59 Peter Robinson wrote: > > I would really like to see a proliferation of secondary arches in > > Fedora, but I don't think 'workstation' is a viable usage model for > > them to get started. Most will have to focus on the type of hardware > > that actually sells for that arch, and yes I realize that can be at > > odds with some of the directions Fedora is going. > > I think there are most likely two candidates for a secondary arch > other than PPC. The first is sparc where from the server point of view > where its probably about as prolific as PPC in that regard. The second > would be arm but that is more from the NetBook/MID/Phone/STB > perspective where there are quite a few devices in the 500Mhz-1Ghz > range with 256-512Mb RAM. With the OLPC X0-1 we've proven that Fedora > can run relatively well on that sort of spec, they also tend to be > relatively cheap. Once we switch our 32-bit x86 packages from i586 to i686 for F12 (hopefully w/sse2 enabled as well), then i586 becomes a very doable secondary arch as well, if enough people are interested in keeping their clunkers running the latest-n-greatest stuff... -- Jarod Wilson jarod at redhat.com From pbrobinson at gmail.com Tue May 12 14:06:22 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 12 May 2009 15:06:22 +0100 Subject: SPARC Status (Was Re: Secondary Architecture Status?) In-Reply-To: <200905121001.42151.jarod@redhat.com> References: <20090511185147.GA3256@yoda.jdub.homelinux.org> <5256d0b0905111202x2df6b773y689fe618b502315c@mail.gmail.com> <200905121001.42151.jarod@redhat.com> Message-ID: <5256d0b0905120706o7cd11d4bhaf5858133f88293f@mail.gmail.com> >> > I would really like to see a proliferation of secondary arches in >> > Fedora, but I don't think 'workstation' is a viable usage model for >> > them to get started. ?Most will have to focus on the type of hardware >> > that actually sells for that arch, and yes I realize that can be at >> > odds with some of the directions Fedora is going. >> >> I think there are most likely two candidates for a secondary arch >> other than PPC. The first is sparc where from the server point of view >> where its probably about as prolific as PPC in that regard. The second >> would be arm but that is more from the NetBook/MID/Phone/STB >> perspective where there are quite a few devices in the 500Mhz-1Ghz >> range with 256-512Mb RAM. With the OLPC X0-1 we've proven that Fedora >> can run relatively well on that sort of spec, they also tend to be >> relatively cheap. > > Once we switch our 32-bit x86 packages from i586 to i686 for F12 > (hopefully w/sse2 enabled as well), then i586 becomes a very doable > secondary arch as well, if enough people are interested in keeping > their clunkers running the latest-n-greatest stuff... What about the million odd (not sure of the actual deployment numbers) OLPC XO clunkers out there that fall into this category? I though the whole difference between i586 and i686 was cmov and that wasn't considered a great performance boost. Peter From kevin.kofler at chello.at Tue May 12 14:06:57 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 12 May 2009 16:06:57 +0200 Subject: What is the best way to store information cross desktop References: Message-ID: Kushal Das wrote: > If one application (with GUI) wants to store informations (like > username, password, some other texts) cross desktop, what is the best > way to achieve that? > > A Gnome application can use gconf/gnome keyring or a KDE application > can use KWallet, but those two are totally desktop specific. I know > people who use Gnome don't want to run KWallet or a KDE user will not > like to use any gnome way to store information. > > I am working on Python (PyKDE4) based Wordpress blog client and I want > it to run properly on any desktop. As your app is PyKDE4, just use KWallet. There's no really desktop-independent way, as in something which would use gnome-keyring on GNOME and KWallet on KDE. There are some solutions which reinvent the wheel by adding yet another password store, but those don't improve the situation, they make it worse, because now instead of having 2 password stores, you have 3 or more! Kevin Kofler From kevin.kofler at chello.at Tue May 12 14:10:19 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 12 May 2009 16:10:19 +0200 Subject: What is the best way to store information cross desktop References: <20090512071806.GB27189@free.fr> Message-ID: Patrice Dumas wrote: > I am aware of 2 projects trying to solve that issue: > http://alumnit.ca/wiki/index.php?page=UniConf > http://www.libelektra.org/Main_Page Those are configuration frameworks, not password stores. They aren't designed to hold passwords in a secure way (encrypted, with the possibility to use a passphrase for true encryption (without a passphrase, it's trivial to reverse the obfuscation)) like KWallet and gnome-keyring are. And adding yet another framework doesn't solve the problem of there being 2 competing frameworks (KConfig vs. GConf for configuration, KWallet vs. gnome-keyring for password stores) at all, it makes it worse. Kevin Kofler From che666 at gmail.com Tue May 12 14:24:16 2009 From: che666 at gmail.com (Rudolf Kastl) Date: Tue, 12 May 2009 16:24:16 +0200 Subject: FESco meeting summary for 20090507 In-Reply-To: <1242062320.2923.586.camel@adam.local.net> References: <1242062320.2923.586.camel@adam.local.net> Message-ID: 2009/5/11 Adam Williamson : > On Sun, 2009-05-10 at 18:28 +0200, drago01 wrote: > >> The only reason people prefer to run i686 even on x86_64 is because >> "apps do not work", which is nothing but a myth. > > It's not a myth, but it's now (only quite recently) mostly outdated. > > wine has never had a decent x86-64 port, and still doesn't. > openoffice.org's x86-64 version was unusable for a long time. Running > Flash on x86-64 was a big pain for a long time (even with > nspluginwrapper) until Adobe finally released a native x86-64 plugin > (which is still technically an alpha, and really doesn't work as well as > the x86-32 plugin in some ways). Java was equally painful until OpenJDK > came along, as Sun consistently refused to release a native x86-64 Java > plugin. wine is a bad example for this. you need a 32bit wine for running 32bit windows applications. all you need to do on x86_64 though is yum install wine ;). no need to use a 32bit base os. In a few months 64 bit wine will get more traction to be able to run windows 64bit applications though. > > Those were the major issues. OO.o and Java are fixed and Flash is mostly > fixed, but wine is still valid. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org > http://www.happyassassin.net > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From bochecha at fedoraproject.org Tue May 12 14:24:41 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Tue, 12 May 2009 16:24:41 +0200 Subject: What is the best way to store information cross desktop In-Reply-To: References: <20090512071806.GB27189@free.fr> Message-ID: <2d319b780905120724s6ddfcebfif5b09a870ec4e43c@mail.gmail.com> Hi, On Tue, May 12, 2009 at 16:10, Kevin Kofler wrote: > Patrice Dumas wrote: >> I am aware of 2 projects trying to solve that issue: >> http://alumnit.ca/wiki/index.php?page=UniConf >> http://www.libelektra.org/Main_Page > > Those are configuration frameworks, not password stores. They aren't > designed to hold passwords in a secure way (encrypted, with the possibility > to use a passphrase for true encryption (without a passphrase, it's trivial > to reverse the obfuscation)) like KWallet and gnome-keyring are. > > And adding yet another framework doesn't solve the problem of there being 2 > competing frameworks (KConfig vs. GConf for configuration, KWallet vs. > gnome-keyring for password stores) at all, it makes it worse. On a side note, is there any FreeDesktop.org effort on standardizing configuration frameworks and / or password stores ? Not necessarily providing the One True Replacement for the Gnome / KDE alternatives, just providing a standard on which those alternatives could be built to work together ? Sorry to kind of hi-jack the thread, I just thought I'd ask out of interest :) Regards, ---------- Mathieu Bridon (bochecha) From jreznik at redhat.com Tue May 12 14:28:53 2009 From: jreznik at redhat.com (Jaroslav Reznik) Date: Tue, 12 May 2009 16:28:53 +0200 Subject: What is the best way to store information cross desktop In-Reply-To: References: <20090512071806.GB27189@free.fr> Message-ID: <200905121628.53852.jreznik@redhat.com> On Tuesday 12 May 2009 16:10:19 Kevin Kofler wrote: > Patrice Dumas wrote: > > I am aware of 2 projects trying to solve that issue: > > http://alumnit.ca/wiki/index.php?page=UniConf > > http://www.libelektra.org/Main_Page > > Those are configuration frameworks, not password stores. They aren't > designed to hold passwords in a secure way (encrypted, with the possibility > to use a passphrase for true encryption (without a passphrase, it's trivial > to reverse the obfuscation)) like KWallet and gnome-keyring are. > > And adding yet another framework doesn't solve the problem of there being 2 > competing frameworks (KConfig vs. GConf for configuration, KWallet vs. > gnome-keyring for password stores) at all, it makes it worse. See https://bugs.freedesktop.org/show_bug.cgi?id=16581 There's some ongoing work on cross desktop framework lead by KWallet maintainer and Gnome keyring guys. I don't like some of "all around" DBUS *Kits but for passwords storage I think it's very useful - especial for cross desktop applications like Arora browser (I know, you can respond: Arora should be KDE application and problem is solved but... :D) Jaroslav > Kevin Kofler -- Jaroslav ?ezn?k Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ From tcallawa at redhat.com Tue May 12 14:29:12 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 12 May 2009 10:29:12 -0400 Subject: SPARC Status (Was Re: Secondary Architecture Status?) In-Reply-To: <9497e9990905120025j714ffa97tb4e90040ede8792c@mail.gmail.com> References: <1241911202.24436.81.camel@macbook.infradead.org> <4A0862F1.2030608@redhat.com> <9497e9990905120025j714ffa97tb4e90040ede8792c@mail.gmail.com> Message-ID: <4A0987B8.1000401@redhat.com> On 05/12/2009 03:25 AM, Mat Booth wrote: > There isn't a lot of information on the SPARC wiki page. Is there a > currently a way to install Fedora on a SPARC so I can try it out? We have some "beta" images here: ISO: http://secondary.fedoraproject.org/pub/fedora-secondary/releases/test/9-Beta/Fedora/sparc/iso/ Netboot TFTP: http://secondary.fedoraproject.org/pub/fedora-secondary/releases/test/9-Beta/Fedora/sparc/os/images/ (Yeah, I know I said Fedora 8 before, its actually Fedora 9, sorry) ~spot From rc040203 at freenet.de Tue May 12 14:34:04 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 12 May 2009 16:34:04 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: References: <4A082E70.7030904@TheTroubleshooters.dk> <4A086703.1080906@amiga-hardware.com> <4A094EC4.9030506@TheTroubleshooters.dk> <1242125395.13505.449.camel@breeves.fab.redhat.com> Message-ID: <4A0988DC.8030103@freenet.de> Seth Vidal wrote: > > a file conflict is two pkgs owning the same file where the file is not: > 1. identical between the two pkgs > 2. not a 64bit or 32bit binary when the other file is the matching > 64bit or 32bit binary. + when its check sum matches. This has nasty effects with F11, because it has switched from md5 to sha256. This kills packages which share files, but have been built on different versions of Fedora or CentOS. One real world example, I encountered this issue with: the rpm-gpgkey package of a 3rd party repo. Ralf From loganjerry at gmail.com Tue May 12 14:36:58 2009 From: loganjerry at gmail.com (Jerry James) Date: Tue, 12 May 2009 08:36:58 -0600 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A09160F.1000403@freenet.de> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08381D.5030604@freenet.de> <870180fe0905111205x37683fa5gb246bab58a5c02a1@mail.gmail.com> <4A09160F.1000403@freenet.de> Message-ID: <870180fe0905120736k7ffeb8fey1203df7f391586ac@mail.gmail.com> On Tue, May 12, 2009 at 12:24 AM, Ralf Corsepius wrote: > To me, "meritocracy" is just a euphemism for other terms you probably don't > want to hear. This list is not the right place for a such a discussion, but I would be happy to receive your thoughts on the matter in private email, or in some other forum where it is on-topic. Regards, -- Jerry James http://www.jamezone.org/ From rjones at redhat.com Tue May 12 14:46:35 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 12 May 2009 15:46:35 +0100 Subject: [REPOST!] Split out e2fsprogs sublibraries In-Reply-To: <4A097F01.5000502@redhat.com> References: <20090512125204.GA13004@amd.home.annexia.org> <4A097F01.5000502@redhat.com> Message-ID: <20090512144635.GB12375@amd.home.annexia.org> On Tue, May 12, 2009 at 08:52:01AM -0500, Eric Sandeen wrote: > Richard W.M. Jones wrote: > > [I posted this before, but no one replied, so sending again to > > fedora-devel-list] > > > > https://bugzilla.redhat.com/show_bug.cgi?id=225406#c7 > > > > I would like to propose that e2fsprogs generate four subpackages for > > the independent libraries that it contains. These four libraries are > > used by other packages that don't need the whole of e2fsprogs-devel > > (eg. krb5_workstation uses libss, qpid uses libuuid, and many programs > > use libcom_err). > > I'm generally open to the suggestion, but last time I had this concern... > > > The next problem I see is that by putting things like blkid, uuidgen, > > compile_et, mk_cmds into the lib$FOO packages, they are now no longer > > multilib-safe; the binaries will collide. > > is this going to be a subpackage-explosion? for example: > > uuid.rpm (with the binary tool(s)) > uuid-libs.rpm > uuid-devel.rpm > > and so on for each of the above binary+libs? I just spent a bit of time trying to just build e2fsprogs for 386 on x86-64, and have come to the conclusion that multilib is even more broken than last time I tried it ... Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 75 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From berrange at redhat.com Tue May 12 14:51:02 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 12 May 2009 15:51:02 +0100 Subject: [REPOST!] Split out e2fsprogs sublibraries In-Reply-To: <4A097F01.5000502@redhat.com> References: <20090512125204.GA13004@amd.home.annexia.org> <4A097F01.5000502@redhat.com> Message-ID: <20090512145102.GC6017@redhat.com> On Tue, May 12, 2009 at 08:52:01AM -0500, Eric Sandeen wrote: > Richard W.M. Jones wrote: > > [I posted this before, but no one replied, so sending again to > > fedora-devel-list] > > > > https://bugzilla.redhat.com/show_bug.cgi?id=225406#c7 > > > > I would like to propose that e2fsprogs generate four subpackages for > > the independent libraries that it contains. These four libraries are > > used by other packages that don't need the whole of e2fsprogs-devel > > (eg. krb5_workstation uses libss, qpid uses libuuid, and many programs > > use libcom_err). > > I'm generally open to the suggestion, but last time I had this concern... > > > The next problem I see is that by putting things like blkid, uuidgen, > > compile_et, mk_cmds into the lib$FOO packages, they are now no longer > > multilib-safe; the binaries will collide. > > is this going to be a subpackage-explosion? for example: > > uuid.rpm (with the binary tool(s)) > uuid-libs.rpm > uuid-devel.rpm > > and so on for each of the above binary+libs? IMHO, having separate sub-packages for each of the command line tools is overkill. Just put the libraries in -libs & -devel, but keep all the binaries in e2fsprogs. This would avoid any multilib issues with binaries, and keep the number of sub-packages sane. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From kevin.kofler at chello.at Tue May 12 14:51:40 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 12 May 2009 16:51:40 +0200 Subject: Fedora (Linux) is Destroying it self References: <4A082E70.7030904@TheTroubleshooters.dk> <4A086703.1080906@amiga-hardware.com> <4A094EC4.9030506@TheTroubleshooters.dk> <1242125395.13505.449.camel@breeves.fab.redhat.com> <4A0988DC.8030103@freenet.de> Message-ID: Ralf Corsepius wrote: > This kills packages which share files, but have been built on different > versions of Fedora or CentOS. That's simply not allowed. Sharing files across different packages is always a packaging bug. The only legitimate use is multiple CPU architectures of the same package with the same EVR. All the other shared files are bugs and it's good that they're getting caught. Kevin Kofler From katzj at redhat.com Tue May 12 14:53:25 2009 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 12 May 2009 10:53:25 -0400 Subject: [REPOST!] Split out e2fsprogs sublibraries In-Reply-To: <20090512145102.GC6017@redhat.com> References: <20090512125204.GA13004@amd.home.annexia.org> <4A097F01.5000502@redhat.com> <20090512145102.GC6017@redhat.com> Message-ID: <20090512145320.GA65173@redhat.com> On Tuesday, May 12 2009, Daniel P. Berrange said: > On Tue, May 12, 2009 at 08:52:01AM -0500, Eric Sandeen wrote: > > Richard W.M. Jones wrote: > > > [I posted this before, but no one replied, so sending again to > > > fedora-devel-list] > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=225406#c7 > > > > > > I would like to propose that e2fsprogs generate four subpackages for > > > the independent libraries that it contains. These four libraries are > > > used by other packages that don't need the whole of e2fsprogs-devel > > > (eg. krb5_workstation uses libss, qpid uses libuuid, and many programs > > > use libcom_err). > > > > I'm generally open to the suggestion, but last time I had this concern... > > > > > The next problem I see is that by putting things like blkid, uuidgen, > > > compile_et, mk_cmds into the lib$FOO packages, they are now no longer > > > multilib-safe; the binaries will collide. The binaries won't end up colliding as rpm is (sort of) smart about handing conflicting multilib binaries like this, but ... > > is this going to be a subpackage-explosion? for example: > > > > uuid.rpm (with the binary tool(s)) > > uuid-libs.rpm > > uuid-devel.rpm > > > > and so on for each of the above binary+libs? > > IMHO, having separate sub-packages for each of the command line tools > is overkill. Just put the libraries in -libs & -devel, but keep all > the binaries in e2fsprogs. This would avoid any multilib issues with > binaries, and keep the number of sub-packages sane. This feels more reasonable anyway. Having binaries in a lib package is just a little weird Jeremy From kevin.kofler at chello.at Tue May 12 14:56:20 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 12 May 2009 16:56:20 +0200 Subject: What is the best way to store information cross desktop References: <20090512071806.GB27189@free.fr> <2d319b780905120724s6ddfcebfif5b09a870ec4e43c@mail.gmail.com> Message-ID: Mathieu Bridon (bochecha) wrote: > On a side note, is there any FreeDesktop.org effort on standardizing > configuration frameworks and / or password stores ? > > Not necessarily providing the One True Replacement for the Gnome / KDE > alternatives, just providing a standard on which those alternatives > could be built to work together ? > > Sorry to kind of hi-jack the thread, I just thought I'd ask out of > interest :) Well, it's not really off topic because it's exactly what's needed to actually solve Kushal's problem. There is a project, see Jaroslav ?ezn?k's reply. Unfortunately, nothing usable available yet. Kevin Kofler From nicolas.mailhot at laposte.net Tue May 12 15:00:21 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 12 May 2009 17:00:21 +0200 (CEST) Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A083765.6030907@redhat.com> References: <4A0814ED.60205@redhat.com> <4A0821D1.8050803@comcast.net> <4A0824B7.90106@silfreed.net> <4A083314.9020802@comcast.net> <4A0835B6.3000102@redhat.com> <4A083765.6030907@redhat.com> Message-ID: <69bccfe6e05a8587f8538949564c1e9b.squirrel@arekh.dyndns.org> Le Lun 11 mai 2009 16:34, Martin Stransky a ?crit : > > On 05/11/2009 04:27 PM, Stephen Gallagher wrote: >> On 05/11/2009 10:15 AM, David wrote: >> Ok, just so I make sure I understand your argument completely. "It's >> fine to include a pre-release copy of Thunderbird and Firefox >> because >> you can bludgeon unsupported extensions into being supported by >> following an undocumented and potentially dangerous hack." >> >> Seriously, people. This is exactly the sort of elitist bullshit that >> puts people off of using Fedora. Furthermore, it's damned >> hypocritical. > > There's Fedora 10 with Firefox 3.0 and Thunderbird 2.0 in already. > Nobody forces you to update to F11 now, when it contains those > "unstable" packages. Really, that just mean we need to find some packagers for the most popular ff/thb extensions. Having an external unmanaged software source is the actual problem here. -- Nicolas Mailhot From rc040203 at freenet.de Tue May 12 15:00:33 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 12 May 2009 17:00:33 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: References: <4A082E70.7030904@TheTroubleshooters.dk> <4A086703.1080906@amiga-hardware.com> <4A094EC4.9030506@TheTroubleshooters.dk> <1242125395.13505.449.camel@breeves.fab.redhat.com> <4A0988DC.8030103@freenet.de> Message-ID: <4A098F11.4080008@freenet.de> Kevin Kofler wrote: > Ralf Corsepius wrote: >> This kills packages which share files, but have been built on different >> versions of Fedora or CentOS. > > That's simply not allowed. Well, it had worked for ages. > Sharing files across different packages is always a packaging bug. You are simply plain wrong. > The only > legitimate use is multiple CPU architectures of the same package with the > same EVR. All the other shared files are bugs and it's good that they're > getting caught. Wrong again. From otto_rey at yahoo.com.ar Tue May 12 15:01:44 2009 From: otto_rey at yahoo.com.ar (Otto Rey) Date: Tue, 12 May 2009 08:01:44 -0700 (PDT) Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A082E70.7030904@TheTroubleshooters.dk> References: <4A082E70.7030904@TheTroubleshooters.dk> Message-ID: <3970.88406.qm@web52410.mail.re2.yahoo.com> +1 in everything!!! We must to back to basics... ----- Mensaje original ---- De: Michael Nielsen Para: fedora-devel-list at redhat.com Enviado: lunes 11 de mayo de 2009, 10:56:00 Asunto: Fedora (Linux) is Destroying it self Hi, I've been told this is the right place to place this debate starter. Not to demean the fine work that has been done in maintaining fedora, however the distribution is slowly killing itself, being destroyed by contradicting philosophies. Many of the problems have been directly copied from the Windows world. The main problems are. 1. Removal of features - the user interfaces are being dumbed down, like recently I've searched for the ability to remove the "Raise on Click" feature that is default for Gnome MetaCity, there does not appear to be any such feature anymore / argument being to simplify how it works.. Fine, create a simple view and an advanced view for the configuration tools, so that people who are clueless about any other way than the official Redmond way, can avoid being confronted with an alternative. 2. The network interfaces are being bound to the user interface, such that if your X fails for some reason, or you are running on a text console, you are unable to open the wireless configuration, at least it's not obvious how you do it, without X running. The configuration for the network interfaces are so tightly bound to the user interface, such that if there is no user interface there are no network interfaces. 3. Mounts are also embedded into the user interface, rather than in the unix mount system, which means that the shares are not accessible for non-gui programs, for instance, I like to script most thing I do often, however, there is no way for scripts to get a hold of a drive that is mounted through the gui mount system (kde and gnome). 4. Everything is thrown in huge collective directories, such as /usr/bin, /usr/lib etc, and it is a huge mess, just like windows with it's system32 directory, which is also a huge mess. really the /usr/bin,/bin/sbin, /lib etc, has very specific purposes, and should represent a core operating system, that is capable of being used as repair, with no major applications present. However even Open office is stored in these directories. 5. More and more services are bound up in the userinterface, such as the pulse audio, which is started by the GUI, this means if you use 2 user environments, which I often do for testing, where I have X:0 and X:1 running, the GUIs will conflict, because you cannot run two instances of pulseaudio. In addition pulse audio is crap, I have yet to see any installation actually work without crackling, and chopping like crazy. I like the concept that is the basis of pulse audio, but it just does not work. 6. NetworkManager which appears to be installed default, does not work with shared drives, because, the NetworkManager is shut down before the network drives are detached, and you need to modify the NetworkManager to start properly, before you mount the network drives. I've gotten used to explicit uninstalling the NetworkManager, because it just doesn't work properly. It is a lengthy discussion to describe what i mean. However, if I take a sample application like firefox, it presents a reasonable proxy for what I mean. currently default installation of firefox on my machine installs firefox in these following places. /usr/lib64/firefox /usr/lib64/firefox-3.0.7 /usr/lib/mozilla /usr/lib64/mozilla /usr/share/mozilla /usr/bin/mozilla-plugin-config /usr/bin/firefox etc. All of which are related to the firefox installation. If something goes wrong, it's a real pain to clean it up, or even to detect what went wrong. The original concept for unix was to install an application such as firefox in either, /opt or /usr/local/. Such that the entire application was contained within a single installation directory, and then to use the PATH and LD_LIBRARY_PATH to allow the execution of the application. The standard approach with /opt or /usr/local installation also makes it triviel to have multiple installations, and configurations operating in paralellel, by simply creating. /opt/mozilla/firefox -> /opt/mozilla/firefox-3.0.7 /opt/mozilla/firefox-3.0.7 /opt/mozilla/firefox-2.0.9 A user can then easily conifgure their account to use either version of the application, without installation problems. Additionally using that installation method, also means that if someone wants to use a newer version of an application, they can download the source, and trivially install it in parallel to the package managed application, by using the --prefix option, and the installation can easily be removed, by simple rm -rf /opt/mozilla/firefox-3.0.7. With the current installation, it is nearly impossible, or at least very difficult to find out if the package manager has cleaned up properly, or if there is something left behind - something which is identicial to the problem on windows. A UNIX based system is intended to have everything accessible through standard accesses, such as the file system, and the network, however, the current trend in moving away from having the system control things (which I can see is easier), breaks with the ability of scripting. If this tendency keeps going, Linux is going to become a useless mismatch of junk, that no one can really use for anything but a toy. In my opinion, the trend has been visible for about a decade, but it has really gone downhill from about rethat 7/8.. though in Fedora 8, everything worked fine on most machines that I installed on, apart from some obscure drivers, however, since Fedora 8, i've yet to have a system where the audio works properly, and with Fedora 10, the kernel Ooopses so often it's not funny, on quite a few of my machines, to such a degree that I'm recommending that people do not upgrade past Fedora 8, and I'm considering dropping the Fedora line of Linux, because it is becoming just too messy, and clumsy. The divergence between the "GUI" focused approach, and the "Server" approach is not good for Linux, as it means there will be a fork, which will be incompatible. There really isn't a good reason for this split. I am wondering is anyone else concerned about, what in my opinion, is the copying of the mistakes that Microsoft made with windows, to the Linux environment. IMO it is really badly time to do a "back-to-basics" approach, and to clean up the system. I'm really curious as to the reasoning for moving everything from the standard configuration mechanisms to the gui layer, breaking compatibility with scripting, and other standard UNIX featuers.. I'm also curious as to the reasoning for throwing everything in one huge mess in the /usr/bin, /bin, /sbin, etc.. As all that is achieved is to make it hard to strip the system back to a minimal setup. regards mike. -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list ____________________________________________________________________________________ ?Viv? la mejor experiencia en la web! Descarg? gratis el nuevo Internet Explorer 8 http://downloads.yahoo.com/ieak8/?l=ar From mcepl at redhat.com Tue May 12 15:04:55 2009 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 12 May 2009 17:04:55 +0200 Subject: 2009-05-14 - Fedora Test Day - IBus input method References: <4A082F3D.6070500@redhat.com> Message-ID: ["Followup-To:" header set to gmane.linux.redhat.fedora.testers.] On 2009-05-11, 13:59 GMT, Liam wrote: > iBus is designed to improve a number of deficiencies of scim: I had two problems with scim (and these were the reasons I always removed it immediately after installation): a) it conflicted with Compose key b) it worked poorly (not sure how) with Czech layout ... and I heard it from other people with somewhere in between layouts ... non-ASCII, but also non-real-IM-needed. Should (at least theoretically) these work in iBus? And how does it work with relation to Gnome keyboard layouts? Mat?j From kevin at scrye.com Tue May 12 15:27:36 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Tue, 12 May 2009 09:27:36 -0600 Subject: fedora-release-11-1 In-Reply-To: <4A09217F.3010200@kiewel-online.ch> References: <1242093567.3452.87.camel@localhost.localdomain> <4A09217F.3010200@kiewel-online.ch> Message-ID: <20090512092736.4a3b62bc@ohm.scrye.com> On Tue, 12 May 2009 09:13:03 +0200 Uwe Kiewel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > so what do I have to do to be on F11? > > I did my last update from rawhide on Monday, 2009-10-05, at about 9 > pm UTC. https://fedoraproject.org/wiki/Upgrading_from_pre-release_to_final Should have the answers. ;) > Thanks, > Uwe kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From mcepl at redhat.com Tue May 12 15:26:31 2009 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 12 May 2009 17:26:31 +0200 Subject: best practices for updates in stable releases (was: Re: OpenOffice 3.1) References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <4A05B234.2020608@leemhuis.info> <1241890311.2886.63.camel@localhost.localdomain> <1242054913.3452.16.camel@localhost.localdomain> <20d6441a0905110849r6b6e9537ofa343ddb27156ba1@mail.gmail.com> Message-ID: <72hod6-60q.ln1@ppp1053.in.ipex.cz> On 2009-05-11, 15:49 GMT, Jud Craft wrote: > On Mon, May 11, 2009 at 10:15 AM, Jesse Keating wrote: >> On Mon, 2009-05-11 at 13:03 +0200, Matej Cepl wrote: >> Suggestions on how to "enforce" ? > > Lock out developers who don't follow guidelines? Sanction them? > Remove their ability to push updates? > > No sass meant, I just figured that was a strange rhetorical question. > Does Fedora really not have any ability to enforce its own guidelines? Yeah, some of these ... for the really big cock ups suspending of packager's rights for some time. After all, it is not an universal human right to be able to push to Fedora CVS. Getting out of provenpackager group for less outrageous offenses. Why not? Mat?j From mcepl at redhat.com Tue May 12 15:23:32 2009 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 12 May 2009 17:23:32 +0200 Subject: OpenOffice 3.1 References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <1241990992.3452.6.camel@localhost.localdomain> <6dc6523c0905101458l64811e65lb9f18216a4f93941@mail.gmail.com> <1242064968.2923.615.camel@adam.local.net> <1242072865.2923.670.camel@adam.local.net> <1242079541.3452.48.camel@localhost.localdomain> <1242080497.2923.676.camel@adam.local.net> <1242122940.1211.19.camel@gilboa-work-dev.localdomain> Message-ID: On 2009-05-12, 10:09 GMT, Gilboa Davara wrote: > and RHEL 5.3 would have been left with Firefox 1.5 instead of > Firefox 3.0. Please, keep RHEL out of this discussioni ... there are another reasons (mainly customers breaking-in our doors with RFE) for doing things we do, which are not applicable to Fedora. Mat?j From sandeen at redhat.com Tue May 12 15:43:38 2009 From: sandeen at redhat.com (Eric Sandeen) Date: Tue, 12 May 2009 10:43:38 -0500 Subject: [REPOST!] Split out e2fsprogs sublibraries In-Reply-To: <20090512145320.GA65173@redhat.com> References: <20090512125204.GA13004@amd.home.annexia.org> <4A097F01.5000502@redhat.com> <20090512145102.GC6017@redhat.com> <20090512145320.GA65173@redhat.com> Message-ID: <4A09992A.1040906@redhat.com> Jeremy Katz wrote: > On Tuesday, May 12 2009, Daniel P. Berrange said: >> On Tue, May 12, 2009 at 08:52:01AM -0500, Eric Sandeen wrote: ... >>> is this going to be a subpackage-explosion? for example: >>> >>> uuid.rpm (with the binary tool(s)) >>> uuid-libs.rpm >>> uuid-devel.rpm >>> >>> and so on for each of the above binary+libs? >> IMHO, having separate sub-packages for each of the command line tools >> is overkill. Just put the libraries in -libs & -devel, but keep all >> the binaries in e2fsprogs. This would avoid any multilib issues with >> binaries, and keep the number of sub-packages sane. > > This feels more reasonable anyway. Having binaries in a lib package is > just a little weird Ok, will have to look at the ramifications of this, but sounds reasonable. BTW Richard, sorry it's taken so long to get going on this, I'll really try to get it in early in the F12 cycle, and thanks for the persistent legwork. :) Thanks, -Eric From mcepl at redhat.com Tue May 12 15:41:59 2009 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 12 May 2009 17:41:59 +0200 Subject: SPARC Status (Was Re: Secondary Architecture Status?) References: <1241911202.24436.81.camel@macbook.infradead.org> <4A0862F1.2030608@redhat.com> <20090511185147.GA3256@yoda.jdub.homelinux.org> <5256d0b0905111202x2df6b773y689fe618b502315c@mail.gmail.com> Message-ID: <7vhod6-60q.ln1@ppp1053.in.ipex.cz> On 2009-05-11, 19:02 GMT, Peter Robinson wrote: > I think there are most likely two candidates for a secondary > arch other than PPC. The first is sparc where from the server > point of view where its probably about as prolific as PPC in > that regard. Note my comment about PA-RISC. Mat?j From bdwheele at indiana.edu Tue May 12 15:47:05 2009 From: bdwheele at indiana.edu (Brian Wheeler) Date: Tue, 12 May 2009 11:47:05 -0400 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <3970.88406.qm@web52410.mail.re2.yahoo.com> References: <4A082E70.7030904@TheTroubleshooters.dk> <3970.88406.qm@web52410.mail.re2.yahoo.com> Message-ID: <1242143225.7490.101.camel@nibbler.dlib.indiana.edu> On Tue, 2009-05-12 at 08:01 -0700, Otto Rey wrote: > +1 in everything!!! > > We must to back to basics... > I don't see anything wrong with the way Fedora is heading. I say this as a non-redhat-affilated person, a desktop/laptop user and a sysadmin. Are there problems in some of the ways things get done? Sure, but that's true of every distro/OS (especially if the issues in question are from upstream). If the quirks of Fedora you so much, then perhaps Fedora isn't the distro for you... So, with that said, Fedora developers: Great job. Especially in light of the constant stream of "bikeshed flamewar of the week" Is there a fedora-devel list faq somewhere, like the LKML faq? It might be useful to short out some of these threads...kind of like the annual "Why don't we rewrite the Linux kernel in C++?" that shows up on lkml. I think its important to have fedora-direction discussion here, but unfortunately a lot of the "starter" messages are out of touch with practicality...or aren't aware of why things are done the way they are. Brian > > > ----- Mensaje original ---- > De: Michael Nielsen > Para: fedora-devel-list at redhat.com > Enviado: lunes 11 de mayo de 2009, 10:56:00 > Asunto: Fedora (Linux) is Destroying it self > > Hi, > > I've been told this is the right place to place this debate starter. > > > Not to demean the fine work that has been done in maintaining fedora, however the distribution is slowly killing itself, being destroyed by contradicting philosophies. Many of the problems have been directly copied from the Windows world. > > The main problems are. > > 1. Removal of features - the user interfaces are being dumbed down, like recently I've searched for the ability to remove the "Raise on Click" feature that is default for Gnome MetaCity, there does not appear to be any such feature anymore / argument being to simplify how it works.. Fine, create a simple view and an advanced view for the configuration tools, so that people who are clueless about any other way than the official Redmond way, can avoid being confronted with an alternative. > > 2. The network interfaces are being bound to the user interface, such that if your X fails for some reason, or you are running on a text console, you are unable to open the wireless configuration, at least it's not obvious how you do it, without X running. The configuration for the network interfaces are so tightly bound to the user interface, such that if there is no user interface there are no network interfaces. > > 3. Mounts are also embedded into the user interface, rather than in the unix mount system, which means that the shares are not accessible for non-gui programs, for instance, I like to script most thing I do often, however, there is no way for scripts to get a hold of a drive that is mounted through the gui mount system (kde and gnome). > > 4. Everything is thrown in huge collective directories, such as /usr/bin, /usr/lib etc, and it is a huge mess, just like windows with it's system32 directory, which is also a huge mess. really the /usr/bin,/bin/sbin, /lib etc, has very specific purposes, and should represent a core operating system, that is capable of being used as repair, with no major applications present. However even Open office is stored in these directories. > > 5. More and more services are bound up in the userinterface, such as the pulse audio, which is started by the GUI, this means if you use 2 user environments, which I often do for testing, where I have X:0 and X:1 running, the GUIs will conflict, because you cannot run two instances of pulseaudio. In addition pulse audio is crap, I have yet to see any installation actually work without crackling, and chopping like crazy. I like the concept that is the basis of pulse audio, but it just does not work. > > 6. NetworkManager which appears to be installed default, does not work with shared drives, because, the NetworkManager is shut down before the network drives are detached, and you need to modify the NetworkManager to start properly, before you mount the network drives. I've gotten used to explicit uninstalling the NetworkManager, because it just doesn't work properly. > > It is a lengthy discussion to describe what i mean. > > However, if I take a sample application like firefox, it presents a reasonable proxy for what I mean. > > currently default installation of firefox on my machine installs firefox in these following places. > > /usr/lib64/firefox > /usr/lib64/firefox-3.0.7 > /usr/lib/mozilla > /usr/lib64/mozilla > /usr/share/mozilla > /usr/bin/mozilla-plugin-config > /usr/bin/firefox > > etc. > > All of which are related to the firefox installation. If something goes wrong, it's a real pain to clean it up, or even to detect what went wrong. The original concept for unix was to install an application such as firefox in either, /opt or /usr/local/. Such that the entire application was contained within a single installation directory, and then to use the PATH and LD_LIBRARY_PATH to allow the execution of the application. > > The standard approach with /opt or /usr/local installation also makes it triviel to have multiple installations, and configurations operating in paralellel, by simply creating. > > /opt/mozilla/firefox -> /opt/mozilla/firefox-3.0.7 > /opt/mozilla/firefox-3.0.7 > /opt/mozilla/firefox-2.0.9 > > A user can then easily conifgure their account to use either version of the application, without installation problems. > > Additionally using that installation method, also means that if someone wants to use a newer version of an application, they can download the source, and trivially install it in parallel to the package managed application, by using the --prefix option, and the installation can easily be removed, by simple rm -rf /opt/mozilla/firefox-3.0.7. > > With the current installation, it is nearly impossible, or at least very difficult to find out if the package manager has cleaned up properly, or if there is something left behind - something which is identicial to the problem on windows. > > > > A UNIX based system is intended to have everything accessible through standard accesses, such as the file system, and the network, however, the current trend in moving away from having the system control things (which I can see is easier), breaks with the ability of scripting. > > If this tendency keeps going, Linux is going to become a useless mismatch of junk, that no one can really use for anything but a toy. > > In my opinion, the trend has been visible for about a decade, but it has really gone downhill from about rethat 7/8.. though in Fedora 8, everything worked fine on most machines that I installed on, apart from some obscure drivers, however, since Fedora 8, i've yet to have a system where the audio works properly, and with Fedora 10, the kernel Ooopses so often it's not funny, on quite a few of my machines, to such a degree that I'm recommending that people do not upgrade past Fedora 8, and I'm considering dropping the Fedora line of Linux, because it is becoming just too messy, and clumsy. > > The divergence between the "GUI" focused approach, and the "Server" approach is not good for Linux, as it means there will be a fork, which will be incompatible. There really isn't a good reason for this split. > > > I am wondering is anyone else concerned about, what in my opinion, is the copying of the mistakes that Microsoft made with windows, to the Linux environment. > > IMO it is really badly time to do a "back-to-basics" approach, and to clean up the system. > > I'm really curious as to the reasoning for moving everything from the standard configuration mechanisms to the gui layer, breaking compatibility with scripting, and other standard UNIX featuers.. I'm also curious as to the reasoning for throwing everything in one huge mess in the /usr/bin, /bin, /sbin, etc.. As all that is achieved is to make it hard to strip the system back to a minimal setup. > > regards > mike. > > -- fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > ____________________________________________________________________________________ > ?Viv? la mejor experiencia en la web! > Descarg? gratis el nuevo Internet Explorer 8 > http://downloads.yahoo.com/ieak8/?l=ar > From jkeating at redhat.com Tue May 12 15:47:04 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 12 May 2009 08:47:04 -0700 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A092FDC.3010200@TheTroubleshooters.dk> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A092FDC.3010200@TheTroubleshooters.dk> Message-ID: <1242143224.3452.95.camel@localhost.localdomain> On Tue, 2009-05-12 at 10:14 +0200, Michael Nielsen wrote: > Where then? > > The problem is logically related to the development path that Linux is > taking, somewhere someone must have a plan, for where Fedora is going. > > If there isn't a plan for Fedora development, then that is probably the > reason for the problems that I am concerned about. As the problems > that I'm pointing out here, could very well be the effect of chaotic > development. Try the upstream project sites for the pieces of software you have issue with. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Tue May 12 15:48:52 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 12 May 2009 08:48:52 -0700 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A09320F.9060107@TheTroubleshooters.dk> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08302A.2020705@redhat.com> <4A09320F.9060107@TheTroubleshooters.dk> Message-ID: <1242143332.3452.97.camel@localhost.localdomain> On Tue, 2009-05-12 at 10:23 +0200, Michael Nielsen wrote: > > Currently, I'm left frustrating, as from my point of view, the best > Fedora/Redhat distributions, seems to have been around Redhat 8, where > the system was relatively clean - though not as clean as I'd like. Ask yourself what you liked about RHL 8, figure out what upstream project is involved in what you like, then look at the same upstream project today and see what you don't like. I'm willing to bet that the majority if your issues are with upstream projects, and not Fedora itself, which means no matter what distribution you use, if you're using the same upstream project versions you're going to have the same dissatisfaction. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mcepl at redhat.com Tue May 12 15:44:54 2009 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 12 May 2009 17:44:54 +0200 Subject: FESco meeting summary for 20090507 References: <1242062320.2923.586.camel@adam.local.net> Message-ID: On 2009-05-11, 17:18 GMT, Adam Williamson wrote: > but wine is still valid. Except ... if you really want Windows these days, virtualization is probably more viable option (yes, I have Windows 7/build 7100 in kvm running on x86_64 host). Mat?j From sandeen at redhat.com Tue May 12 15:50:22 2009 From: sandeen at redhat.com (Eric Sandeen) Date: Tue, 12 May 2009 10:50:22 -0500 Subject: Things to do this week instead of arguing about mixers In-Reply-To: <4A0944B3.6020405@draigBrady.com> References: <49F60312.8060709@redhat.com> <4A0944B3.6020405@draigBrady.com> Message-ID: <4A099ABE.40703@redhat.com> P?draig Brady wrote: > Eric Sandeen wrote: >> Now that we have ext4 as the new default filesystem, it'd be nice if we >> can get more applications to take advantage of some of the features. >> >> One big feature that has already been brought up on the list[1] is file >> preallocation, which allows an application to pre-allocate blocks it >> knows that it will eventually write into, thereby making sure it won't >> run out of space, and also generally getting a more efficient/contiguous >> file layout. >> > > [snip] > >> fallocate(2): >> long fallocate(int fd, int mode, loff_t offset, loff_t len); >> >> This is directly wired to the syscall, so only succeeds on filesystems >> that support it. It also takes a FALLOC_FL_KEEP_SIZE mode argument, >> which allows one to allocate blocks without updating the file size if >> desired (blocks can then be allocated past EOF). This call is only >> wired up in very recent glibc, but it is available in F11. > > I tried using fallocate() on glibc-2.9.90-22. > The man-pages are out of date and say the glibc interface is not available, oops :) Mind filing a bug on that against man-pages? > but from inspecting the headers I came up with the test prog below. > However I get a link error if I uncomment #define _FILE_OFFSET_BITS 64. > What am I missing? on which arch? what's the link error? Thanks, -Eric > cheers, > P?draig. > > //#define _FILE_OFFSET_BITS 64 > #define _GNU_SOURCE > #include > #include > > #include > #include > #include > #include > #include > > int main (int argc, char** argv) > { > char* endptr; > off_t len = strtoll(argv[1], &endptr, 10); > fprintf(stderr, "setting to %jd\n", (intmax_t)len); > int ret = fallocate(1, 0, 0, len); > fprintf(stderr, "ret=%d (%s)\n", ret, strerror(ret)); > } > > > From gilboad at gmail.com Tue May 12 15:54:08 2009 From: gilboad at gmail.com (Gilboa Davara) Date: Tue, 12 May 2009 18:54:08 +0300 Subject: OpenOffice 3.1 In-Reply-To: References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <1241990992.3452.6.camel@localhost.localdomain> <6dc6523c0905101458l64811e65lb9f18216a4f93941@mail.gmail.com> <1242064968.2923.615.camel@adam.local.net> <1242072865.2923.670.camel@adam.local.net> <1242079541.3452.48.camel@localhost.localdomain> <1242080497.2923.676.camel@adam.local.net> <1242122940.1211.19.camel@gilboa-work-dev.localdomain> Message-ID: <1242143648.1211.32.camel@gilboa-work-dev.localdomain> On Tue, 2009-05-12 at 17:23 +0200, Matej Cepl wrote: > On 2009-05-12, 10:09 GMT, Gilboa Davara wrote: > > and RHEL 5.3 would have been left with Firefox 1.5 instead of > > Firefox 3.0. > > Please, keep RHEL out of this discussioni ... there are another > reasons (mainly customers breaking-in our doors with RFE) for > doing things we do, which are not applicable to Fedora. > > Mat?j > It wasn't my intention to implicate RHEL in any way. My point being that a "stable release policy" != "stagnant release policy". If the maintainer feels that a new version fixes major deficiencies in the existing version (beyond a simple bug fix) he should be allowed to push a major upgrade (given sufficient testing) even if it risk breaking existing installations. ... And if you don't trust your maintainers to make such a decision - why the hell have you given them the right to package the software to begin with? - Gilboa From mcepl at redhat.com Tue May 12 15:41:00 2009 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 12 May 2009 17:41:00 +0200 Subject: SPARC Status (Was Re: Secondary Architecture Status?) References: <1241911202.24436.81.camel@macbook.infradead.org> <4A0862F1.2030608@redhat.com> <20090511185147.GA3256@yoda.jdub.homelinux.org> Message-ID: On 2009-05-11, 18:51 GMT, Josh Boyer wrote: > I would really like to see a proliferation of secondary arches > in Fedora, but I don't think 'workstation' is a viable usage > model for them to get started. Most will have to focus on the > type of hardware that actually sells for that arch, and yes > I realize that can be at odds with some of the directions > Fedora is going. Off-topic note ... jchadima (now @RH, aka jfch) works as a hobby on porting Fedora to PA-RISC machines. Now he has three of them and they are building like crazy, except that they are now apparently stuck with some problems in glibc. It helps jfch was a teacher of jakub in CS at university :). Mat?j From cdahlin at redhat.com Tue May 12 15:57:30 2009 From: cdahlin at redhat.com (Casey Dahlin) Date: Tue, 12 May 2009 11:57:30 -0400 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A09320F.9060107@TheTroubleshooters.dk> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08302A.2020705@redhat.com> <4A09320F.9060107@TheTroubleshooters.dk> Message-ID: <4A099C6A.3030906@redhat.com> Michael Nielsen wrote: > So tell me where does one go to solve the issues that I've pointed out ? > > Feature proposals ? I'm not proposing features, I'm proposing that > Linux, re-integrates itself, so that it stops forking every where, > currently there is no less than 3-4 implementations of network > management, none of which are compatible with one-another, and only one > (the original), work in all cases. > Everything you want for networking is being worked on. NetworkManager will be the all-encompassing solution for networking in good time. Its already missing many of the flaws you accuse it of (you said elsewhere you've downgraded most of your boxes to F8, so you probably didn't notice). Your other UI complaint is upstream GNOME's problem. Try KDE[1] or go upstream. Your path complaints are just wrong. I'm not going to say anything else, other than please remember that there's someone out there who thinks that. --CJD From rc040203 at freenet.de Tue May 12 15:59:58 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 12 May 2009 17:59:58 +0200 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1242054739.3452.15.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <645d17210905071452n7da5f852s8bfc5d808a04c56b@mail.gmail.com> <1241733287.3209.61.camel@localhost.localdomain> <4A03A31C.4010003@freenet.de> <1241754133.3209.71.camel@localhost.localdomain> <4A03AF94.60605@freenet.de> <1241756375.3209.76.camel@localhost.localdomain> <4A03BB64.10006@freenet.de> <1241795563.3209.83.camel@localhost.localdomain> <4A04D350.1000904@freenet.de> <1241832771.2886.15.camel@localhost.localdomain> <4A04EAAE.50907@freenet.de> <1241836379.2886.30.camel@localhost.localdomain> <4A0812DB.2000505@freenet.de> <1242054739.3452.15.camel@localhost.localdomain> Message-ID: <4A099CFE.6060003@freenet.de> Jesse Keating wrote: > On Mon, 2009-05-11 at 13:58 +0200, Ralf Corsepius wrote: >>> We've been trying to push F11 updates for a couple days now. >> ... but you still haven't updated fedora-release, so neither mock >> doesn't pick them up. > > That's right, I wanted to make sure they hit mirrors OK before I > released a fedora-release with repo configuration pointing to them. Of > course you're free to manually turn those repos on and test it out for > yourself. > >>>> * Decouple cuttings DVDs from F11 development >>> I honestly don't understand what you're proposing here. No DVD from the release? >> No, I am proposing that rel-eng chooses a set of packages to build iso >> etc. from, while "updates" "rolls on". >> >> Or differently: rel-eng composes the "Fedora" repo from those packages >> they choose, which "updates" continues, independently from rel-eng's >> activities. >> >>> What do we have people download to get the release? >> As before ... the only difference would be "Fedora" (i.e. the set of >> packages the DVDs etc. would have been built from) would be older than >> "updates" (and/or "Everything") > > Which does nothing to help the upgrade and n-v-r case. Only if "updates" is not activated upon installation. >>> What do >>> we hand out at events? >> Openly said, ... I would hand out netboot.img's, accompanied with a yum >> repository of "Everything" ... but that's a different topic. >> >>>> * Implement rawhide/testing >>> Is this a full time thing, you always want a rawhide, and a >>> rawhide-testing, which is driven by bodhi? >> I haven't thought about all details, but I am inclined to lean towards a >> "permanent rawhide-testing". >> >> There would be times where it hardly would be used, but there can easily >> be times, when it would be heavily used (e.g. there currently is a >> proposal pending which would severely change perl's behavior (perl >> module search order and file system layout), with currently unclear >> outcome). > > How would one choose to use it? Similar to "updates-testing" yum install --enable-repo=rawhide-testing "package-i-want-to-test" etc. > Why would anyone choose to use bodhi if > they were allowed to build directly into rawhide? You mean to push a package to rawhide-testing instead of rawhide? Primary reason: Because the maintainer is aware about his package containing some "nasty"/"adventurous"/"dangerous"/"experimental" etc. changes/bugfixes, with unclear outcome and him wanting to avoid destabilizing the distro. > Should we force the > use of bodhi during freezes, and make it optional otherwise? IMO, maintainers need _one_ single package submission UI, which should be used on all occasional/in all phases of development. ATM, this would mean making bodhi mandatory and to get rid of trac etc. Ralf From mcepl at redhat.com Tue May 12 15:51:08 2009 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 12 May 2009 17:51:08 +0200 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 References: <4A0814ED.60205@redhat.com> Message-ID: On 2009-05-11, 20:11 GMT, sean darcy wrote: > With 3.x, I couldn't send mail ( reply or write ) to > newsgroups, including this one. With just downgrading > - exactly the same setup - it works. > > See https://bugzilla.redhat.com/show_bug.cgi?id=493738 Except you never told me how to reproduce it, so it CLOSED/WORKSFORME. Please, don't use it as a reason against TB. Mat?j From markmc at redhat.com Tue May 12 16:04:16 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 12 May 2009 17:04:16 +0100 Subject: best practices for updates in stable releases (was: Re: OpenOffice 3.1) In-Reply-To: <1242054913.3452.16.camel@localhost.localdomain> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <4A05B234.2020608@leemhuis.info> <1241890311.2886.63.camel@localhost.localdomain> <1242054913.3452.16.camel@localhost.localdomain> Message-ID: <1242144256.21430.4.camel@blaa> On Mon, 2009-05-11 at 08:15 -0700, Jesse Keating wrote: > On Mon, 2009-05-11 at 13:03 +0200, Matej Cepl wrote: > > > > Yes, because this is yet another case where nobody is willing to > > enforce what has been agreed upon. > > Suggestions on how to "enforce" ? rel-eng refuses to push updates which are blatantly ignoring the guidelines? i.e. follow a similar process to what we during the freeze Cheers, Mark. From mcepl at redhat.com Tue May 12 15:52:59 2009 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 12 May 2009 17:52:59 +0200 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 References: <4A0814ED.60205@redhat.com> <4A0845E8.2080805@codewiz.org> Message-ID: On 2009-05-11, 15:36 GMT, Bernie Innocenti wrote: > However, the package in Fedora is still at 3.0b2, which still > contains an IMAP bug affecting me which was fixed upstream one > month ago: > > https://bugzilla.mozilla.org/show_bug.cgi?id=480870 > > I'd be grateful if we could import the latest beta release so I can > finally stop dealing with assorted crap like Mercurial, CVS and > autoconf-2.13 when I just need a binary that will let me read my mail :-) No disputing with you ... just is there RHBZ bug for this, so I can beat TB maintainers with it? Mat?j From jkeating at redhat.com Tue May 12 16:05:52 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 12 May 2009 09:05:52 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <4A099CFE.6060003@freenet.de> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <645d17210905071452n7da5f852s8bfc5d808a04c56b@mail.gmail.com> <1241733287.3209.61.camel@localhost.localdomain> <4A03A31C.4010003@freenet.de> <1241754133.3209.71.camel@localhost.localdomain> <4A03AF94.60605@freenet.de> <1241756375.3209.76.camel@localhost.localdomain> <4A03BB64.10006@freenet.de> <1241795563.3209.83.camel@localhost.localdomain> <4A04D350.1000904@freenet.de> <1241832771.2886.15.camel@localhost.localdomain> <4A04EAAE.50907@freenet.de> <1241836379.2886.30.camel@localhost.localdomain> <4A0812DB.2000505@freenet.de> <1242054739.3452.15.camel@localhost.localdomain> <4A099CFE.6060003@freenet.de> Message-ID: <1242144352.3452.101.camel@localhost.localdomain> On Tue, 2009-05-12 at 17:59 +0200, Ralf Corsepius wrote: > > Which does nothing to help the upgrade and n-v-r case. > Only if "updates" is not activated upon installation. Anaconda doesn't support this, and even if it did, network isn't always available to people when doing the upgrade. > >> There would be times where it hardly would be used, but there can easily > >> be times, when it would be heavily used (e.g. there currently is a > >> proposal pending which would severely change perl's behavior (perl > >> module search order and file system layout), with currently unclear > >> outcome). > > > > How would one choose to use it? > > Similar to "updates-testing" > yum install --enable-repo=rawhide-testing "package-i-want-to-test" > etc. I meant how would a maintainer choose to use rawhide-testing as opposed to pure rawhide. Would they have to specifically craft a make build command with a TARGET= ? > > Why would anyone choose to use bodhi if > > they were allowed to build directly into rawhide? > You mean to push a package to rawhide-testing instead of rawhide? > > Primary reason: Because the maintainer is aware about his package > containing some "nasty"/"adventurous"/"dangerous"/"experimental" > etc. changes/bugfixes, with unclear outcome and him wanting to avoid > destabilizing the distro. > > > Should we force the > > use of bodhi during freezes, and make it optional otherwise? > IMO, maintainers need _one_ single package submission UI, which should > be used on all occasional/in all phases of development. > > ATM, this would mean making bodhi mandatory and to get rid of trac etc. My point was when do we force the use of bodhi. I would think if we forced the use of bodhi for every single package build ever we'd create a riot of angry maintainers. I agree with you that having both trac and bodhi is non-optional. We just didn't have the time/manpower to develop bodhi to a point where it could be used to drive freeze break requests. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From rjones at redhat.com Tue May 12 16:12:51 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 12 May 2009 17:12:51 +0100 Subject: [REPOST!] Split out e2fsprogs sublibraries In-Reply-To: <4A09992A.1040906@redhat.com> References: <20090512125204.GA13004@amd.home.annexia.org> <4A097F01.5000502@redhat.com> <20090512145102.GC6017@redhat.com> <20090512145320.GA65173@redhat.com> <4A09992A.1040906@redhat.com> Message-ID: <20090512161251.GA14543@amd.home.annexia.org> On Tue, May 12, 2009 at 10:43:38AM -0500, Eric Sandeen wrote: > BTW Richard, sorry it's taken so long to get going on this,[...] No problem at all Eric. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 75 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From mcepl at redhat.com Tue May 12 16:05:40 2009 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 12 May 2009 18:05:40 +0200 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 References: <4A0814ED.60205@redhat.com> <4A0821D1.8050803@comcast.net> <4A0824B7.90106@silfreed.net> <4A083314.9020802@comcast.net> <4A0835B6.3000102@redhat.com> Message-ID: On 2009-05-11, 14:27 GMT, Stephen Gallagher wrote: > Seriously, people. This is exactly the sort of elitist bullshit > that puts people off of using Fedora. Furthermore, it's damned > hypocritical. Are you aware we talk about Rawhide, right? Mat?j From P at draigBrady.com Tue May 12 16:14:59 2009 From: P at draigBrady.com (=?ISO-8859-1?Q?P=E1draig_Brady?=) Date: Tue, 12 May 2009 17:14:59 +0100 Subject: Things to do this week instead of arguing about mixers In-Reply-To: <4A099ABE.40703@redhat.com> References: <49F60312.8060709@redhat.com> <4A0944B3.6020405@draigBrady.com> <4A099ABE.40703@redhat.com> Message-ID: <4A09A083.9020609@draigBrady.com> Eric Sandeen wrote: > P?draig Brady wrote: >> I tried using fallocate() on glibc-2.9.90-22. >> The man-pages are out of date and say the glibc interface is not available, > > oops :) Mind filing a bug on that against man-pages? sure. >> but from inspecting the headers I came up with the test prog below. >> However I get a link error if I uncomment #define _FILE_OFFSET_BITS 64. >> What am I missing? > > on which arch? what's the link error? arch: 32 bit i686 error: undefined reference to `fallocate64' cheers, P?draig. From kyle at mcmartin.ca Tue May 12 16:26:36 2009 From: kyle at mcmartin.ca (Kyle McMartin) Date: Tue, 12 May 2009 12:26:36 -0400 Subject: SPARC Status (Was Re: Secondary Architecture Status?) In-Reply-To: References: <1241911202.24436.81.camel@macbook.infradead.org> <4A0862F1.2030608@redhat.com> <20090511185147.GA3256@yoda.jdub.homelinux.org> Message-ID: <20090512162635.GA23579@bombadil.infradead.org> On Tue, May 12, 2009 at 05:41:00PM +0200, Matej Cepl wrote: > On 2009-05-11, 18:51 GMT, Josh Boyer wrote: > > I would really like to see a proliferation of secondary arches > > in Fedora, but I don't think 'workstation' is a viable usage > > model for them to get started. Most will have to focus on the > > type of hardware that actually sells for that arch, and yes > > I realize that can be at odds with some of the directions > > Fedora is going. > > Off-topic note ... jchadima (now @RH, aka jfch) works as a hobby > on porting Fedora to PA-RISC machines. Now he has three of them > and they are building like crazy, except that they are now > apparently stuck with some problems in glibc. It helps jfch was > a teacher of jakub in CS at university :). > It doesn't help that currently no one is shipping NPTL for parisc, except Ubuntu, and nobody really uses Ubuntu on parisc... When Debian gains NPTL now that Carlos has finished compat support, things should get better for jchadima. r, Kyle From jkeating at redhat.com Tue May 12 16:29:04 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 12 May 2009 09:29:04 -0700 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: <1242144352.3452.101.camel@localhost.localdomain> References: <1241718097.3209.11.camel@localhost.localdomain> <23753.1241723730@sss.pgh.pa.us> <645d17210905071452n7da5f852s8bfc5d808a04c56b@mail.gmail.com> <1241733287.3209.61.camel@localhost.localdomain> <4A03A31C.4010003@freenet.de> <1241754133.3209.71.camel@localhost.localdomain> <4A03AF94.60605@freenet.de> <1241756375.3209.76.camel@localhost.localdomain> <4A03BB64.10006@freenet.de> <1241795563.3209.83.camel@localhost.localdomain> <4A04D350.1000904@freenet.de> <1241832771.2886.15.camel@localhost.localdomain> <4A04EAAE.50907@freenet.de> <1241836379.2886.30.camel@localhost.localdomain> <4A0812DB.2000505@freenet.de> <1242054739.3452.15.camel@localhost.localdomain> <4A099CFE.6060003@freenet.de> <1242144352.3452.101.camel@localhost.localdomain> Message-ID: <1242145745.3452.107.camel@localhost.localdomain> On Tue, 2009-05-12 at 09:05 -0700, Jesse Keating wrote: > > I agree with you that having both trac and bodhi is non-optional. Erm, non-optimal. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Tue May 12 16:29:42 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 12 May 2009 09:29:42 -0700 Subject: best practices for updates in stable releases (was: Re: OpenOffice 3.1) In-Reply-To: <1242144256.21430.4.camel@blaa> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <4A05B234.2020608@leemhuis.info> <1241890311.2886.63.camel@localhost.localdomain> <1242054913.3452.16.camel@localhost.localdomain> <1242144256.21430.4.camel@blaa> Message-ID: <1242145782.3452.108.camel@localhost.localdomain> On Tue, 2009-05-12 at 17:04 +0100, Mark McLoughlin wrote: > rel-eng refuses to push updates which are blatantly ignoring the > guidelines? > > i.e. follow a similar process to what we during the freeze It's hard for one person to timely review hundreds of update requests to figure out which are ignoring the guidelines and which aren't. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dimi at lattica.com Tue May 12 16:38:48 2009 From: dimi at lattica.com (Dimi Paun) Date: Tue, 12 May 2009 12:38:48 -0400 Subject: Update -> no sound Message-ID: <1242146328.3147.181.camel@dimi.lattica.com> This time I can get no sound of Firefox or Rhythmbox, despite PA running in the background. Somehow I now have 2 PA instances: [dimi at dimi ~]$ ps aux | grep pulseaudio gdm 2547 0.0 0.1 101032 4240 ? Ssl May09 0:00 /usr/bin/pulseaudio --start --log-target=syslog dimi 2699 1.0 0.4 170960 17604 ? R Lattica, Inc. From awilliam at redhat.com Tue May 12 16:41:50 2009 From: awilliam at redhat.com (Adam Williamson) Date: Tue, 12 May 2009 09:41:50 -0700 Subject: OpenOffice 3.1 In-Reply-To: <1242143648.1211.32.camel@gilboa-work-dev.localdomain> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <1241990992.3452.6.camel@localhost.localdomain> <6dc6523c0905101458l64811e65lb9f18216a4f93941@mail.gmail.com> <1242064968.2923.615.camel@adam.local.net> <1242072865.2923.670.camel@adam.local.net> <1242079541.3452.48.camel@localhost.localdomain> <1242080497.2923.676.camel@adam.local.net> <1242122940.1211.19.camel@gilboa-work-dev.localdomain> <1242143648.1211.32.camel@gilboa-work-dev.localdomain> Message-ID: <1242146510.2923.766.camel@adam.local.net> On Tue, 2009-05-12 at 18:54 +0300, Gilboa Davara wrote: > On Tue, 2009-05-12 at 17:23 +0200, Matej Cepl wrote: > > On 2009-05-12, 10:09 GMT, Gilboa Davara wrote: > > > and RHEL 5.3 would have been left with Firefox 1.5 instead of > > > Firefox 3.0. > > > > Please, keep RHEL out of this discussioni ... there are another > > reasons (mainly customers breaking-in our doors with RFE) for > > doing things we do, which are not applicable to Fedora. > It wasn't my intention to implicate RHEL in any way. > My point being that a "stable release policy" != "stagnant release > policy". If the maintainer feels that a new version fixes major > deficiencies in the existing version (beyond a simple bug fix) he should > be allowed to push a major upgrade (given sufficient testing) even if it > risk breaking existing installations. I don't really agree. There's wiggle room in *everything*, of course - Mandriva updates Firefox by major version jumps, when the old major goes out of maintenance, because on balance that's safer than trying to backport security fixes to a version of Firefox that's unsupported upstream - but at the level of setting overall policy, I wouldn't be in favour of that. But, to re-iterate, since it's easy to lose this point, I'm talking about *the theoretical 'stable' update source we don't yet have*, ONLY in the case where we decide we want one (i.e. we care about Aunt Flo). I would never have fed KDE 4.0 to Aunt Flo in the first place, and no distribution which cares about Aunt Flo did, so the discussion is a bit moot there. Mandriva, for instance, went to KDE 4 by default only with KDE 4.1, and Mandriva certainly wouldn't consider shipping KDE 4.2 as a 'stable' update for KDE 4.1. Neither would Ubuntu. You can *get* KDE 4.2 for both Mandriva and Ubuntu releases that shipped with KDE 4.1, but it's not released as a stable update, nor - IMO - should it be, *in a distribution which uses stable updates* (which, right now, Fedora isn't). > ... And if you don't trust your maintainers to make such a decision - > why the hell have you given them the right to package the software to > begin with? I don't think that follows at all. Updates policies, above all else, need to be consistent, and if you say "well, we'll try to be quite stable and safe, but ultimately it's up to the discretion of maintainers", you will never get consistency, because all maintainers are different. What Maintainer A considers a 'safe' upgrade will be different to what Maintainer B considers safe. Hence the user experience will be inconsistent. Effectively, the update process will only be as safe as the most happy-go-lucky maintainer's position - even though all other maintainers are more conservative. And that's not efficient, because you get all the drawbacks of instability from the maintainers who push whatever they like, and all the drawbacks of staleness from the maintainers who act very conservatively. This is why I say the only two policies that can really work optimally are "minimal necessary changes to fix strictly identified bugs and security flaws" or "update whatever you like". Either is valid, but both have distinct implications for the user experience, so we need to pick based on what user experience we want, and message that consistently so that users know what to expect. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From mzerqung at 0pointer.de Tue May 12 16:55:59 2009 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 12 May 2009 18:55:59 +0200 Subject: Update -> no sound In-Reply-To: <1242146328.3147.181.camel@dimi.lattica.com> References: <1242146328.3147.181.camel@dimi.lattica.com> Message-ID: <20090512165559.GA19474@tango.0pointer.de> On Tue, 12.05.09 12:38, Dimi Paun (dimi at lattica.com) wrote: > This time I can get no sound of Firefox or Rhythmbox, > despite PA running in the background. > > Somehow I now have 2 PA instances: > > [dimi at dimi ~]$ ps aux | grep pulseaudio > gdm 2547 0.0 0.1 101032 4240 ? Ssl May09 0:00 /usr/bin/pulseaudio --start --log-target=syslog > dimi 2699 1.0 0.4 170960 17604 ? R dimi 30180 0.0 0.0 4208 732 pts/5 S+ 11:35 0:00 grep pulseaudio > > I don't seem to get working sound for more than > 2 days in a row. Folks, I don't do anything > non-standard. fedora-devel is not a bug tracking system. Please file a bug about this. And please provide a proper description what is going on. Something more than "doesn't work" or "no sound". > I am asking again: is this normal rate of problems? > Filing a good bug report (after trying to diagnose > the problem) took me 1h+ last time, I just can't keep > doing that in the middle of my work day. > > A few more notes: > - I said that PA doesn't restart if killed. I was wrong. > It does, except that Flash doesn't reconnect. However, > Rhythmbox does reconnect, and I tested that several times. > Now even it doesn't want to work Flash is closed source sw, we cannot fix that. > - I did an Update, but I didn't reboot or restart. However, > my gut is telling me this is not related to the update, > but rather with another PA failure. I got an error about > some "Stream too big" or somesuch. There is no such error in PA. Please file a bug and include an exact description of the error message. > - The PA volume control shows Firefox connected, but I > get no sound. However, I can't see Rhythmbox. > > P.S. After killing the PA instance owned by me (dimi), I > got sound again out of Rhythmbox. Have you reconfigured the default gst disk? You need to make sure that "pulsesink" is the default sink. If you configure it to something else it's your own fault fi things don't work as expected anymore. Use gconf-editor and look in /system/gstreamer/0.10/default. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From packages at amiga-hardware.com Tue May 12 17:06:33 2009 From: packages at amiga-hardware.com (Ian Chapman) Date: Wed, 13 May 2009 01:06:33 +0800 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A094EC4.9030506@TheTroubleshooters.dk> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A086703.1080906@amiga-hardware.com> <4A094EC4.9030506@TheTroubleshooters.dk> Message-ID: <4A09AC99.6040902@amiga-hardware.com> Michael Nielsen wrote: >> Simply not true. Right this moment I'm copying podcasts to my mp3 >> player which was mounted directly by Gnome. It's accessible under > Try to mount an NFS/CIFS, which were what i was talking about, sorry for > being imprecise. Appears under .gvfs? At least in Gnome. I'm still failing to understand why this is a problem though. Even if as you're saying it's impossible for scripts / command line programs to access shares mounted through the GUI, then mount them the 'traditional' way. Be that via fstab, automounter or whatever. Really, what have you lost? >> Solaris systems amongst others, I get tired >> of playing guess the location of the binary, hunt the man page and >> setting an ever increasing $PATH. > Actually all the install script (for the application) was to update the > global login scripts, for the PATH variable, then the user > would see it as if the whole system was a flat directory. Seems messy to me. I have a well loaded system, 2214 packages installed. If as I think you're suggesting, most of these would be under /opt in their own tree, I can just imagine the size of $PATH. > It is a big disadvantage when testing, because the current scheme > prevents having Firefox-2 and Firefox-3 (apache-1.3, apache-2.2 etc) > installed, under package management because they contain files that > conflict, similarly with 64 bit systems, where you need to install 32bit > compatability software, they usually conflict, due to irrelevant > documentation files conflicting. It is perfectly possible to have multiple versions of a package installed, providing it meets various requirements. Most people usually have at least 2 kernel packages installed for example. The current scheme doesn't prevent what you're suggesting, it just discourages it. You are still able to install software in /opt if you wish, either from a tarball or from an rpm. In addition, I suspect there would be a serious lack of man power if you expected the Fedora packagers to maintain multiple official versions of many packages. > I find it a huge problem, when there is a problem with system package, > that I need to replace with a newer version, sometimes there are files > left behind, that cause problems when you compile your own version. RPM does a good job of cleaning up after itself. Far better than the average human chucking tarballs over the system could. The kind of problems you're describing, I've only ever really seen when people 'make install' over their system files, or don't follow the logical upgrade route. Eg, installing Foo V1 from repo A but upgrading it with Foo V2 from repo B. Sure, somebody can build a terrible RPM which is just plain nasty but that's not the norm for Fedora, nor a fault in the methodology. I've seen vendors package a tarball inside an RPM, which installs everything in the %post scripts. As far as the RPM database is concerned, all it's done is installed foo.tar.gz in /tmp. > Also you cannot with the "everything in one dir" philosophy handle the > situation where a user (or administrator) compiles a newer version from > source, and there is a version installed via the package manager.. Of course you can! Just don't install the self compiled version over the top of the packaged version. Lookup --prefix and DESTDIR=. Users can do the same in their home directory. > You can avoid using the GUI (which I prefer), however, what I mean is, > if you use the gui to configure the network, and you're not careful, you > can find that the configuration you performed, is tied to your GUI > account, and when you reboot, the settings are lost, until you log in > again. Then do it from the command line, like you prefer? What's the problem? If you're a power user, I would imagine you would know what belongs to a user's session and what is system persistent. If you're a novice user, then I would think you'd enjoy choosing your network from the NetworkManager applet and would not care that your network settings were specific to your session. > I don't like the approach of creating > parallel configurations, that are tied to the GUI. That's the whole point! UNIX has always been a multiuser system. User's have their configuration files and there are system wide configuration files. Why should all users be forced to use the system default display mode for example? Sure set a system wide default, but if one user wants 1600x1200 when they log in and another wants 1024x768, why limit it? -- Ian Chapman. From awilliam at redhat.com Tue May 12 17:06:56 2009 From: awilliam at redhat.com (Adam Williamson) Date: Tue, 12 May 2009 10:06:56 -0700 Subject: What is the best way to store information cross desktop In-Reply-To: References: <20090512071806.GB27189@free.fr> <2d319b780905120724s6ddfcebfif5b09a870ec4e43c@mail.gmail.com> Message-ID: <1242148016.2923.769.camel@adam.local.net> On Tue, 2009-05-12 at 16:56 +0200, Kevin Kofler wrote: > Mathieu Bridon (bochecha) wrote: > > On a side note, is there any FreeDesktop.org effort on standardizing > > configuration frameworks and / or password stores ? > > > > Not necessarily providing the One True Replacement for the Gnome / KDE > > alternatives, just providing a standard on which those alternatives > > could be built to work together ? > > > > Sorry to kind of hi-jack the thread, I just thought I'd ask out of > > interest :) > > Well, it's not really off topic because it's exactly what's needed to > actually solve Kushal's problem. > > There is a project, see Jaroslav ?ezn?k's reply. Unfortunately, nothing > usable available yet. For configuration frameworks, I noticed quite a lot of apps have started storing configuration data in ~/.config lately, including - on my system at least - akonadi, totem and gnome-session. But I don't know if that's something that's actually the focus of an official standardization effort anywhere, or if it's anything more than just a 'standard' place to throw freeform configuration files, or what its relationship is to uniconf / elektra... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From packages at amiga-hardware.com Tue May 12 17:08:22 2009 From: packages at amiga-hardware.com (Ian Chapman) Date: Wed, 13 May 2009 01:08:22 +0800 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <234fa2210905120526i364a7f25m97cbed4a0b23a1ea@mail.gmail.com> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08C233.4020902@sapience.com> <4A093807.4010403@TheTroubleshooters.dk> <234fa2210905120156h397d0125l500d9fa330bb5445@mail.gmail.com> <1242124621.4183.75.camel@ignacio.ignacio.lan> <234fa2210905120526i364a7f25m97cbed4a0b23a1ea@mail.gmail.com> Message-ID: <4A09AD06.9090104@amiga-hardware.com> Ilyes Gouta wrote: > Obviously one has to set up $PATH and $LD_LIBRARY_PATH to get programs > running properly. /usr/bin would be populated with scripts that do > exactly that so that the change is transparent to the user. Or you could just place the binary in /usr/bin and do away with the scripts. -- Ian Chapman. From bochecha at fedoraproject.org Tue May 12 17:15:25 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Tue, 12 May 2009 19:15:25 +0200 Subject: What is the best way to store information cross desktop In-Reply-To: <1242148016.2923.769.camel@adam.local.net> References: <20090512071806.GB27189@free.fr> <2d319b780905120724s6ddfcebfif5b09a870ec4e43c@mail.gmail.com> <1242148016.2923.769.camel@adam.local.net> Message-ID: <2d319b780905121015k787812f3u41dd98c7a6029841@mail.gmail.com> > For configuration frameworks, I noticed quite a lot of apps have started > storing configuration data in ~/.config lately, including - on my system > at least - akonadi, totem and gnome-session. But I don't know if that's > something that's actually the focus of an official standardization > effort anywhere, or if it's anything more than just a 'standard' place > to throw freeform configuration files, or what its relationship is to > uniconf / elektra... That's a XDG spec from fd.o The goal is to separate application ? config ? and ? data ?. The former goes in .config/ while the latter goes in .local/share/ This way, instead of having a bunch of ? .app ? in your home folder, you would have only 2. Also, you can often want to backup your application data (say, emails for evolution) but don't care about the configuration (think about deprecated configurations that might have bad results on a newer version of the application). This allows you to do so (but you can still chose to keep both). That's it basically. More information on the spec: http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html ---------- Mathieu Bridon (bochecha) From bnocera at redhat.com Tue May 12 17:21:47 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Tue, 12 May 2009 18:21:47 +0100 Subject: Update -> no sound In-Reply-To: <20090512165559.GA19474@tango.0pointer.de> References: <1242146328.3147.181.camel@dimi.lattica.com> <20090512165559.GA19474@tango.0pointer.de> Message-ID: <1242148907.25471.1644.camel@cookie.hadess.net> On Tue, 2009-05-12 at 18:55 +0200, Lennart Poettering wrote: > Have you reconfigured the default gst disk? You need to make sure that > "pulsesink" is the default sink. If you configure it to something else > it's your own fault fi things don't work as expected anymore. > > Use gconf-editor and look in /system/gstreamer/0.10/default. Or launch gstreamer-properties on the command-line. autoaudiosink should work just as well, and should pick up pulsesink as its first choice. From kevin.kofler at chello.at Tue May 12 17:22:52 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 12 May 2009 19:22:52 +0200 Subject: FESco meeting summary for 20090507 References: <1242062320.2923.586.camel@adam.local.net> Message-ID: Matej Cepl wrote: > Except ... if you really want Windows these days, virtualization > is probably more viable option (yes, I have Windows 7/build 7100 > in kvm running on x86_64 host). But that solution is not Free Software and it even costs money (at least if you want to do it legally). Kevin Kofler From packages at amiga-hardware.com Tue May 12 17:24:06 2009 From: packages at amiga-hardware.com (Ian Chapman) Date: Wed, 13 May 2009 01:24:06 +0800 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A09320F.9060107@TheTroubleshooters.dk> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08302A.2020705@redhat.com> <4A09320F.9060107@TheTroubleshooters.dk> Message-ID: <4A09B0B6.1070103@amiga-hardware.com> Michael Nielsen wrote: > I have spent months and years, trying to determine where I need to go to > get some attention to the issues, and perhaps som influence on the > issues that I'm pointing to here, however, I have not been able to > locate anywhere, or anyone that is even remotely interested in gaining > some sort of structure on the system. I don't mean to sound obstinate when I say this, but perhaps it's because what you're seeing as problems, many people don't. I for one see many of the things you dislike as positives for the reasons I've stated earlier. If Fedora switched to placing everything under /opt in the fashion you described and artificially limiting the desktop in the ways described earlier, I'd be dropping it like a hot potato in search of something a little more sane. -- Ian Chapman. From dimi at lattica.com Tue May 12 17:38:55 2009 From: dimi at lattica.com (Dimi Paun) Date: Tue, 12 May 2009 13:38:55 -0400 Subject: Update -> no sound In-Reply-To: <20090512165559.GA19474@tango.0pointer.de> References: <1242146328.3147.181.camel@dimi.lattica.com> <20090512165559.GA19474@tango.0pointer.de> Message-ID: <1242149935.3147.191.camel@dimi.lattica.com> On Tue, 2009-05-12 at 18:55 +0200, Lennart Poettering wrote: > Please file a bug about this. And please provide a proper description > what is going on. Something more than "doesn't work" or "no sound". I don't know more. I've already spent 1h on the problem, I can't see what else I can do. And BTW, to go through the sluggish BZ every time is just too much work. > > A few more notes: > > - I said that PA doesn't restart if killed. I was wrong. > > It does, except that Flash doesn't reconnect. However, > > Rhythmbox does reconnect, and I tested that several times. > > Now even it doesn't want to work > > Flash is closed source sw, we cannot fix that. My point was the even Rb wasn't working even if it did work in the past. > > - I did an Update, but I didn't reboot or restart. However, > > my gut is telling me this is not related to the update, > > but rather with another PA failure. I got an error about > > some "Stream too big" or somesuch. > > There is no such error in PA. Please file a bug and include an exact > description of the error message. I can't reproduce it, it may be a Gstreamer error, I don't know. > > - The PA volume control shows Firefox connected, but I > > get no sound. However, I can't see Rhythmbox. > > > > P.S. After killing the PA instance owned by me (dimi), I > > got sound again out of Rhythmbox. > > Have you reconfigured the default gst disk? You need to make sure that > "pulsesink" is the default sink. If you configure it to something else > it's your own fault fi things don't work as expected anymore. No, it's not my fault. That is the only thing that is 100% clear. I had working sound, I didn't touch anything, sound stopped working out of the blue ==> NOT MY FAULT. I had to drop to the command line and kill(1) one PA instance. > Use gconf-editor and look in /system/gstreamer/0.10/default. It's set to autoaudiosink. I've never touched this setting. -- Dimi Paun Lattica, Inc. From awilliam at redhat.com Tue May 12 17:40:58 2009 From: awilliam at redhat.com (Adam Williamson) Date: Tue, 12 May 2009 10:40:58 -0700 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <234fa2210905120526i364a7f25m97cbed4a0b23a1ea@mail.gmail.com> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08C233.4020902@sapience.com> <4A093807.4010403@TheTroubleshooters.dk> <234fa2210905120156h397d0125l500d9fa330bb5445@mail.gmail.com> <1242124621.4183.75.camel@ignacio.ignacio.lan> <234fa2210905120526i364a7f25m97cbed4a0b23a1ea@mail.gmail.com> Message-ID: <1242150058.2923.772.camel@adam.local.net> On Tue, 2009-05-12 at 13:26 +0100, Ilyes Gouta wrote: > Hi, > > Obviously one has to set up $PATH and $LD_LIBRARY_PATH to get programs > running properly. /usr/bin would be populated with scripts that do > exactly that so that the change is transparent to the user. But that's > really the implementation part of the idea, let's stick to the concept > for the moment.. Isn't having one folder per application a nice > feature? Why? I think there's an important point missing here: it's perfectly possible to package two versions of an application within a distribution packaging repository, in a way that's compliant with the FHS - if that's what you want to do. You could certainly build firefox2 and firefox3 packages that could be installed together and did not conflict, within the Fedora repositories, in a way that satisfied all Fedora packaging guidelines and the FHS. It is not inherently impossible or even particularly difficult. The reason we don't do this is not "because our filesystem layout makes it impossible" but "because we have no interest at all in providing Firefox 2 as a supported piece of software in Fedora". > What I'm emphasizing here is separation for more flexibility. I don't think it's necessary. The difference between /opt/firefox-2/firefox and /usr/bin/firefox-2 isn't as big as you seem to think. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From awilliam at redhat.com Tue May 12 17:49:07 2009 From: awilliam at redhat.com (Adam Williamson) Date: Tue, 12 May 2009 10:49:07 -0700 Subject: FESco meeting summary for 20090507 In-Reply-To: References: <1242062320.2923.586.camel@adam.local.net> Message-ID: <1242150547.2923.773.camel@adam.local.net> On Tue, 2009-05-12 at 17:44 +0200, Matej Cepl wrote: > On 2009-05-11, 17:18 GMT, Adam Williamson wrote: > > but wine is still valid. > > Except ... if you really want Windows these days, virtualization > is probably more viable option (yes, I have Windows 7/build 7100 > in kvm running on x86_64 host). Legally speaking, you need a valid Windows license to use virtualization. I have no such license for this PC, and I'm not about to go out and pay Microsoft a couple hundred dollars to buy one. But I can use wine to run a few Windows apps / games perfectly legally without it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From cdahlin at redhat.com Tue May 12 17:49:38 2009 From: cdahlin at redhat.com (Casey Dahlin) Date: Tue, 12 May 2009 13:49:38 -0400 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A094EC4.9030506@TheTroubleshooters.dk> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A086703.1080906@amiga-hardware.com> <4A094EC4.9030506@TheTroubleshooters.dk> Message-ID: <4A09B6B2.80203@redhat.com> Michael Nielsen wrote: > I just find it a shame that this limitation is being adopted by Linux. You want to remove a windows anti-feature by adopting a different windows anti-feature (per-package hierarchies)? Doing things like this in /opt is horrible and stupid. What is needed is a better alternatives system. --CJD From awilliam at redhat.com Tue May 12 17:53:40 2009 From: awilliam at redhat.com (Adam Williamson) Date: Tue, 12 May 2009 10:53:40 -0700 Subject: What is the best way to store information cross desktop In-Reply-To: <2d319b780905121015k787812f3u41dd98c7a6029841@mail.gmail.com> References: <20090512071806.GB27189@free.fr> <2d319b780905120724s6ddfcebfif5b09a870ec4e43c@mail.gmail.com> <1242148016.2923.769.camel@adam.local.net> <2d319b780905121015k787812f3u41dd98c7a6029841@mail.gmail.com> Message-ID: <1242150820.2923.774.camel@adam.local.net> On Tue, 2009-05-12 at 19:15 +0200, Mathieu Bridon (bochecha) wrote: > > For configuration frameworks, I noticed quite a lot of apps have started > > storing configuration data in ~/.config lately, including - on my system > That's a XDG spec from fd.o Thanks a lot for the explanation. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From sundaram at fedoraproject.org Tue May 12 17:59:02 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 12 May 2009 23:29:02 +0530 Subject: Update -> no sound In-Reply-To: <1242149935.3147.191.camel@dimi.lattica.com> References: <1242146328.3147.181.camel@dimi.lattica.com> <20090512165559.GA19474@tango.0pointer.de> <1242149935.3147.191.camel@dimi.lattica.com> Message-ID: <4A09B8E6.5060904@fedoraproject.org> On 05/12/2009 11:08 PM, Dimi Paun wrote: > On Tue, 2009-05-12 at 18:55 +0200, Lennart Poettering wrote: > >> Please file a bug about this. And please provide a proper description >> what is going on. Something more than "doesn't work" or "no sound". > > I don't know more. I've already spent 1h on the problem, > I can't see what else I can do. And BTW, to go through the > sluggish BZ every time is just too much work. Use http://bugz.fedoraproject.org/pulseaudio. Will make your life far better. Replace pulseaudio with the name of the srpm if you want to file or query bugs for other packages. Rahul From berrange at redhat.com Tue May 12 17:58:39 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 12 May 2009 18:58:39 +0100 Subject: Update -> no sound In-Reply-To: <4A09B8E6.5060904@fedoraproject.org> References: <1242146328.3147.181.camel@dimi.lattica.com> <20090512165559.GA19474@tango.0pointer.de> <1242149935.3147.191.camel@dimi.lattica.com> <4A09B8E6.5060904@fedoraproject.org> Message-ID: <20090512175839.GC29406@redhat.com> On Tue, May 12, 2009 at 11:29:02PM +0530, Rahul Sundaram wrote: > On 05/12/2009 11:08 PM, Dimi Paun wrote: > > On Tue, 2009-05-12 at 18:55 +0200, Lennart Poettering wrote: > > > >> Please file a bug about this. And please provide a proper description > >> what is going on. Something more than "doesn't work" or "no sound". > > > > I don't know more. I've already spent 1h on the problem, > > I can't see what else I can do. And BTW, to go through the > > sluggish BZ every time is just too much work. > > Use http://bugz.fedoraproject.org/pulseaudio. Will make your life far > better. Replace pulseaudio with the name of the srpm if you want to file > or query bugs for other packages. Those bugz URLs would be a hell of alot more useful if they skipped bugs marked 'closed' by default - make it optional to show them if desired. It just doesn't scale currently for packages with 1000's of closed bugs :-( Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From fedora-devel-list at cygnusx-1.org Tue May 12 17:59:26 2009 From: fedora-devel-list at cygnusx-1.org (Nathan Grennan) Date: Tue, 12 May 2009 10:59:26 -0700 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A0814ED.60205@redhat.com> References: <4A0814ED.60205@redhat.com> Message-ID: <4A09B8FE.4040904@cygnusx-1.org> On 05/11/2009 05:07 AM, Stephen Gallagher wrote: > OK, first off, why in $DEITY's name are we including Firefox 3.5b4 and > Thunderbird 3.0b2 in Fedora 11? These are unstable branches of the > browser and email client, and as such are supported by almost none of > the myriad of extensions available for the 3.0 and 2.0 versions, > respectively. > > I was more than a little disappointed when I upgraded my laptop to the > F11 Preview to discover that only two out of seven of my Thunderbird > extensions and three of my thirteen Firefox extensions remained functional. > > I understand that Fedora is a development OS, and I think it's a great > idea to have a firefox35 package and a thunderbird30 package, but these > SHOULD NOT be the defaults. > > Taking away the full functionality of a developer's web browser and > email client is an incredible step backwards for Fedora 11. The default > install of Fedora 11 should include the latest STABLE versions of > Firefox and Thunderbird, and then provide an OPTION to replace them with > the unstable development branch. > > I would understand if Firefox and Thunderbird were in their release > candidate phase, and we could reasonably expect that within three months > that they would hit final release. Firefox has no definitive (or even > approximate) release date scheduled, and Thunderbird is only in its > second beta. There is little-to-no guarantee that either of these > products will be deemed stable before Fedora 12, and I think it is a > severe mistake to make them the default before then. > > If nothing else, consider this an open request to the Firefox, > Thunderbird and Lightning maintainers to provide a compatibility package > that can downgrade and replace the unstable and non-extensible versions > currently in the distribution. > > I was just thinking the same thing yesterday. After trying to use thunderbird 3.0b2, I have found it unusable. I have tried a fresh .thunderbird directory and switching to the i586 version from the x86_64 version. It is still horrible. I do have huge folders with 10k+ messages in them. Thunderbird 3.0b2 seems to scan all folders and download all messages. With the fresh .thunderbird I started with a 32mb .thunderbird folder, but after leaving it over night with just one of my three accounts it was up to 2gb. https://bugzilla.redhat.com/show_bug.cgi?id=493000 From tcallawa at redhat.com Tue May 12 18:01:08 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 12 May 2009 14:01:08 -0400 Subject: Update -> no sound In-Reply-To: <20090512175839.GC29406@redhat.com> References: <1242146328.3147.181.camel@dimi.lattica.com> <20090512165559.GA19474@tango.0pointer.de> <1242149935.3147.191.camel@dimi.lattica.com> <4A09B8E6.5060904@fedoraproject.org> <20090512175839.GC29406@redhat.com> Message-ID: <4A09B964.5000905@redhat.com> On 05/12/2009 01:58 PM, Daniel P. Berrange wrote: > Those bugz URLs would be a hell of alot more useful if they skipped > bugs marked 'closed' by default - make it optional to show them if > desired. It just doesn't scale currently for packages with 1000's of > closed bugs :-( When Fedora Community launches (real soon now, I promise), we'll have this (show new/open packages only on a per package basis). ~spot From sundaram at fedoraproject.org Tue May 12 18:15:26 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 12 May 2009 23:45:26 +0530 Subject: Update -> no sound In-Reply-To: <4A09B964.5000905@redhat.com> References: <1242146328.3147.181.camel@dimi.lattica.com> <20090512165559.GA19474@tango.0pointer.de> <1242149935.3147.191.camel@dimi.lattica.com> <4A09B8E6.5060904@fedoraproject.org> <20090512175839.GC29406@redhat.com> <4A09B964.5000905@redhat.com> Message-ID: <4A09BCBE.30509@fedoraproject.org> On 05/12/2009 11:31 PM, Tom "spot" Callaway wrote: > On 05/12/2009 01:58 PM, Daniel P. Berrange wrote: >> Those bugz URLs would be a hell of alot more useful if they skipped >> bugs marked 'closed' by default - make it optional to show them if >> desired. It just doesn't scale currently for packages with 1000's of >> closed bugs :-( > > When Fedora Community launches (real soon now, I promise), we'll have > this (show new/open packages only on a per package basis). I am curious. Where is "Fedora Community" development being discussed? I see some wiki changes now and then but otherwise it is a giant silo. Rahul From sundaram at fedoraproject.org Tue May 12 18:20:44 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 12 May 2009 23:50:44 +0530 Subject: What is the best way to store information cross desktop In-Reply-To: References: Message-ID: <4A09BDFC.30300@fedoraproject.org> On 05/12/2009 10:59 AM, Kushal Das wrote: > Hi all, > > If one application (with GUI) wants to store informations (like > username, password, some other texts) cross desktop, what is the best > way to achieve that? > > A Gnome application can use gconf/gnome keyring or a KDE application > can use KWallet, but those two are totally desktop specific. I know > people who use Gnome don't want to run KWallet or a KDE user will not > like to use any gnome way to store information. > > I am working on Python (PyKDE4) based Wordpress blog client and I want > it to run properly on any desktop. Not going to happen anytime soon as there are just too many variations. Make it integrate well with KDE and forget about everything else. Don't try to please everybody. If you separate the backend code, it makes it easier for somebody else to write a different frontend that integrates it with say GNOME or Xfce or whatever. Rahul From sundaram at fedoraproject.org Tue May 12 18:26:50 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 12 May 2009 23:56:50 +0530 Subject: glibc fork ? In-Reply-To: References: <4A02F8D3.2010807@poolshark.org> <4A036082.8000107@fedoraproject.org> <20090509160428.0bf3c0e6.zaitcev@redhat.com> <1241911685.24436.93.camel@macbook.infradead.org> <4A088A8B.6070007@redhat.com> <4A08A60F.4030009@fedoraproject.org> Message-ID: <4A09BF6A.7050503@fedoraproject.org> On 05/12/2009 04:44 AM, Kevin Kofler wrote: > Rahul Sundaram wrote: >> Package http://libbsd.freedesktop.org/wiki/ > > I was crazy enough to check the license of every single source file in > there: the good news: to the best of my knowledge, the package is: > 1. Free Software and acceptable for Fedora, > 2. 100% GPL-compatible (no advertising clause or similar nonsense) and > 3. 100% non-copyleft, > so there are no license issues whatsoever. Are you or anybody else packaging this? Otherwise, if someone can confirm it is useful to them, I can give it a shot. Rahul From fedora-devel-list at cygnusx-1.org Tue May 12 18:29:44 2009 From: fedora-devel-list at cygnusx-1.org (Nathan Grennan) Date: Tue, 12 May 2009 11:29:44 -0700 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A09B8FE.4040904@cygnusx-1.org> References: <4A0814ED.60205@redhat.com> <4A09B8FE.4040904@cygnusx-1.org> Message-ID: <4A09C018.4060906@cygnusx-1.org> > I was just thinking the same thing yesterday. After trying to use > thunderbird 3.0b2, I have found it unusable. > > I have tried a fresh .thunderbird directory and switching to the i586 > version from the x86_64 version. It is still horrible. I do have huge > folders with 10k+ messages in them. Thunderbird 3.0b2 seems to scan all > folders and download all messages. With the fresh .thunderbird I started > with a 32mb .thunderbird folder, but after leaving it over night with > just one of my three accounts it was up to 2gb. > > https://bugzilla.redhat.com/show_bug.cgi?id=493000 > Thunderbird 3.0b2 seems to behave after I turn off the sync feature for each account. I think at the very least this feature needs to be turned off by default. From dimi at lattica.com Tue May 12 18:38:26 2009 From: dimi at lattica.com (Dimi Paun) Date: Tue, 12 May 2009 14:38:26 -0400 Subject: Update -> no sound In-Reply-To: <4A09B8E6.5060904@fedoraproject.org> References: <1242146328.3147.181.camel@dimi.lattica.com> <20090512165559.GA19474@tango.0pointer.de> <1242149935.3147.191.camel@dimi.lattica.com> <4A09B8E6.5060904@fedoraproject.org> Message-ID: <1242153506.3000.3.camel@dimi.lattica.com> On Tue, 2009-05-12 at 23:29 +0530, Rahul Sundaram wrote: > Use http://bugz.fedoraproject.org/pulseaudio. Will make your life far > better. Better, but still sluggish -- clicking on the "Report" link takes ~40s+ to open the new bug report page. That's ~40s too long :) (come on, it should be well subsecond to open that page) -- Dimi Paun Lattica, Inc. From sundaram at fedoraproject.org Tue May 12 18:47:07 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 13 May 2009 00:17:07 +0530 Subject: Update -> no sound In-Reply-To: <1242153506.3000.3.camel@dimi.lattica.com> References: <1242146328.3147.181.camel@dimi.lattica.com> <20090512165559.GA19474@tango.0pointer.de> <1242149935.3147.191.camel@dimi.lattica.com> <4A09B8E6.5060904@fedoraproject.org> <1242153506.3000.3.camel@dimi.lattica.com> Message-ID: <4A09C42B.3070200@fedoraproject.org> On 05/13/2009 12:08 AM, Dimi Paun wrote: > On Tue, 2009-05-12 at 23:29 +0530, Rahul Sundaram wrote: >> Use http://bugz.fedoraproject.org/pulseaudio. Will make your life far >> better. > > Better, but still sluggish -- clicking on the "Report" link > takes ~40s+ to open the new bug report page. That's ~40s too long :) > (come on, it should be well subsecond to open that page) That can be reported as a bug as well :-) Rahul From belegdol at gmail.com Tue May 12 18:46:18 2009 From: belegdol at gmail.com (Julian Sikorski) Date: Tue, 12 May 2009 20:46:18 +0200 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A09C018.4060906@cygnusx-1.org> References: <4A0814ED.60205@redhat.com> <4A09B8FE.4040904@cygnusx-1.org> <4A09C018.4060906@cygnusx-1.org> Message-ID: Nathan Grennan pisze: >> I was just thinking the same thing yesterday. After trying to use >> thunderbird 3.0b2, I have found it unusable. >> >> I have tried a fresh .thunderbird directory and switching to the i586 >> version from the x86_64 version. It is still horrible. I do have huge >> folders with 10k+ messages in them. Thunderbird 3.0b2 seems to scan all >> folders and download all messages. With the fresh .thunderbird I started >> with a 32mb .thunderbird folder, but after leaving it over night with >> just one of my three accounts it was up to 2gb. >> >> https://bugzilla.redhat.com/show_bug.cgi?id=493000 >> > > Thunderbird 3.0b2 seems to behave after I turn off the sync feature > for each account. I think at the very least this feature needs to be > turned off by default. > Afaik fetching whole messages (as opposed to headers) for IMAP accounts was an upstream decision. Julian From tcallawa at redhat.com Tue May 12 18:46:06 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 12 May 2009 14:46:06 -0400 Subject: Update -> no sound In-Reply-To: <4A09BCBE.30509@fedoraproject.org> References: <1242146328.3147.181.camel@dimi.lattica.com> <20090512165559.GA19474@tango.0pointer.de> <1242149935.3147.191.camel@dimi.lattica.com> <4A09B8E6.5060904@fedoraproject.org> <20090512175839.GC29406@redhat.com> <4A09B964.5000905@redhat.com> <4A09BCBE.30509@fedoraproject.org> Message-ID: <4A09C3EE.3000207@redhat.com> On 05/12/2009 02:15 PM, Rahul Sundaram wrote: > On 05/12/2009 11:31 PM, Tom "spot" Callaway wrote: >> On 05/12/2009 01:58 PM, Daniel P. Berrange wrote: >>> Those bugz URLs would be a hell of alot more useful if they skipped >>> bugs marked 'closed' by default - make it optional to show them if >>> desired. It just doesn't scale currently for packages with 1000's of >>> closed bugs :-( >> When Fedora Community launches (real soon now, I promise), we'll have >> this (show new/open packages only on a per package basis). > > I am curious. Where is "Fedora Community" development being discussed? I > see some wiki changes now and then but otherwise it is a giant silo. We have a mailing list: https://fedorahosted.org/mailman/listinfo/moksha We have a website: https://fedorahosted.org/fedoracommunity/ We have wiki: https://fedoraproject.org/wiki/FedoraCommunity We have regular weekly meetings (telephone) that are open to all interested parties (Mondays at 10 AM Eastern, 1400 UTC, Fedora Talk, ext 2001) We have an open code repository: https://fedorahosted.org/fedoracommunity/browser In fact, I think the only thing we're missing is a Silo. ;) ~spot From sundaram at fedoraproject.org Tue May 12 19:03:40 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 13 May 2009 00:33:40 +0530 Subject: Update -> no sound In-Reply-To: <4A09C3EE.3000207@redhat.com> References: <1242146328.3147.181.camel@dimi.lattica.com> <20090512165559.GA19474@tango.0pointer.de> <1242149935.3147.191.camel@dimi.lattica.com> <4A09B8E6.5060904@fedoraproject.org> <20090512175839.GC29406@redhat.com> <4A09B964.5000905@redhat.com> <4A09BCBE.30509@fedoraproject.org> <4A09C3EE.3000207@redhat.com> Message-ID: <4A09C80C.7000600@fedoraproject.org> On 05/13/2009 12:16 AM, Tom "spot" Callaway wrote: > We have a mailing list: https://fedorahosted.org/mailman/listinfo/moksha > We have a website: https://fedorahosted.org/fedoracommunity/ > We have wiki: https://fedoraproject.org/wiki/FedoraCommunity > We have regular weekly meetings (telephone) that are open to all > interested parties (Mondays at 10 AM Eastern, 1400 UTC, Fedora Talk, ext > 2001) > We have an open code repository: > https://fedorahosted.org/fedoracommunity/browser > > In fact, I think the only thing we're missing is a Silo. ;) Good to know all this but there is definitely a big lack of communication on this development with the rest of the Fedora community. There was a very brief mail to fedora-announce list but how much input are you getting input from Fedora maintainers whose job this is supposed to make easier? Rahul From kevin.kofler at chello.at Tue May 12 19:00:58 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 12 May 2009 21:00:58 +0200 Subject: Fedora (Linux) is Destroying it self References: <4A082E70.7030904@TheTroubleshooters.dk> <4A086703.1080906@amiga-hardware.com> <4A094EC4.9030506@TheTroubleshooters.dk> <1242125395.13505.449.camel@breeves.fab.redhat.com> <4A0988DC.8030103@freenet.de> <4A098F11.4080008@freenet.de> Message-ID: Ralf Corsepius wrote: > Well, it had worked for ages. "it had worked" != sane "it had worked" != compliant to guidelines "it had worked" != it's not broken Many things happen to "work", but are still completely broken. Kevin Kofler From dimi at lattica.com Tue May 12 19:01:41 2009 From: dimi at lattica.com (Dimi Paun) Date: Tue, 12 May 2009 15:01:41 -0400 Subject: Update -> no sound In-Reply-To: <4A09C42B.3070200@fedoraproject.org> References: <1242146328.3147.181.camel@dimi.lattica.com> <20090512165559.GA19474@tango.0pointer.de> <1242149935.3147.191.camel@dimi.lattica.com> <4A09B8E6.5060904@fedoraproject.org> <1242153506.3000.3.camel@dimi.lattica.com> <4A09C42B.3070200@fedoraproject.org> Message-ID: <1242154901.3000.4.camel@dimi.lattica.com> On Wed, 2009-05-13 at 00:17 +0530, Rahul Sundaram wrote: > That can be reported as a bug as well :-) Right! https://bugzilla.redhat.com/show_bug.cgi?id=500455 -- Dimi Paun Lattica, Inc. From cdahlin at redhat.com Tue May 12 19:05:02 2009 From: cdahlin at redhat.com (Casey Dahlin) Date: Tue, 12 May 2009 15:05:02 -0400 Subject: glibc fork ? In-Reply-To: <4A09BF6A.7050503@fedoraproject.org> References: <4A02F8D3.2010807@poolshark.org> <4A036082.8000107@fedoraproject.org> <20090509160428.0bf3c0e6.zaitcev@redhat.com> <1241911685.24436.93.camel@macbook.infradead.org> <4A088A8B.6070007@redhat.com> <4A08A60F.4030009@fedoraproject.org> <4A09BF6A.7050503@fedoraproject.org> Message-ID: <4A09C85E.3040007@redhat.com> Rahul Sundaram wrote: > On 05/12/2009 04:44 AM, Kevin Kofler wrote: >> Rahul Sundaram wrote: >>> Package http://libbsd.freedesktop.org/wiki/ >> I was crazy enough to check the license of every single source file in >> there: the good news: to the best of my knowledge, the package is: >> 1. Free Software and acceptable for Fedora, >> 2. 100% GPL-compatible (no advertising clause or similar nonsense) and >> 3. 100% non-copyleft, >> so there are no license issues whatsoever. > > Are you or anybody else packaging this? Otherwise, if someone can > confirm it is useful to them, I can give it a shot. > > Rahul > I might take it too. Might not be until the weekend before I can move on this though. --CJD From awilliam at redhat.com Tue May 12 19:08:53 2009 From: awilliam at redhat.com (Adam Williamson) Date: Tue, 12 May 2009 12:08:53 -0700 Subject: Bug lifecycle page revised / expanded Message-ID: <1242155333.2923.844.camel@adam.local.net> Hi, everyone - just a quick note that, last week, I revised / expanded the bug lifecycle page: https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow mostly I just re-ordered it in a logical fashion and extended it to cover all normal process, states and resolutions. I'd hope this can now serve as the proper reference for bug workflow for Fedora: the 'official' reference is currently https://bugzilla.redhat.com/page.cgi?id=fields.html , but that talks almost entirely about the RHEL process, not the Fedora one. I'm going to ask the Bugzilla maintainer to add a little link pointing to the Wiki page from the Bugzilla one. I guess the significant points are mostly the 'valid' resolutions, and resolving Rawhide bugs. Resolutions - the biggest point is that CURRENTRELEASE is not intended for use by Fedora. CURRENTRELEASE, for the RHEL process, does not mean what it looks like it means. What it means is: "The problem described has been fixed and only ever appeared in unsupported or unreleased products." Which really doesn't apply to Fedora at all. So, don't use it :) We could declare it to mean something different for Fedora, but that would just be needlessly confusing. The correct resolution to use for a bug in a stable release that's fixed by an update should be ERRATA, as mentioned on the page now. On the use of ERRATA - Jesse Keating informed me that this was decided against in the past on the grounds that it doesn't mean quite the same as in RHEL (Fedora doesn't issue erratas exactly), but it's a lot closer to correct than CURRENTRELEASE or NEXTRELEASE, per their RHEL definitions. So the choice is use ERRATA, which means almost the same thing, or invent yet *another* Fedora-only resolution. Which wouldn't be fun. Currently Bodhi, when used, closes bugs fixed by updates as NEXTRELEASE; I'll file an issue to switch it to ERRATA. On resolving Rawhide bugs - this was discussed in a QA meeting, and we all felt that the MODIFIED / reporter confirms fix cycle should be optional for Rawhide bugs. So, as the page now says, outside of a freeze period, you (maintainers) can go directly from ASSIGNED to CLOSED RAWHIDE if you're confident you've definitely fixed the issue, or you can take a report out of MODIFIED to CLOSED RAWHIDE if it's been sitting there for a while and no-one seems inclined to confirm the fix. This is entirely up to the maintainer's discretion, so it's up to you whether to never close the bug until it's been confirmed, use MODIFIED but close after a while if there's no feedback, or just go straight to CLOSED RAWHIDE and skip MODIFIED. Whichever works best for you. Everything else should just be an explanation of current practice and doesn't really need any comment...let me know if anything seems wrong or odd. The graphic on the page, for now, reflects only the cycle for bugs in stable releases, it doesn't quite cover the Rawhide case. It's being revised. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From kevin.kofler at chello.at Tue May 12 19:05:24 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 12 May 2009 21:05:24 +0200 Subject: glibc fork ? References: <4A02F8D3.2010807@poolshark.org> <4A036082.8000107@fedoraproject.org> <20090509160428.0bf3c0e6.zaitcev@redhat.com> <1241911685.24436.93.camel@macbook.infradead.org> <4A088A8B.6070007@redhat.com> <4A08A60F.4030009@fedoraproject.org> <4A09BF6A.7050503@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > Are you or anybody else packaging this? I'm not packaging this, so from my side you can go ahead. Kevin Kofler From kevin.kofler at chello.at Tue May 12 19:16:32 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 12 May 2009 21:16:32 +0200 Subject: OpenOffice 3.1 References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <1241990992.3452.6.camel@localhost.localdomain> <6dc6523c0905101458l64811e65lb9f18216a4f93941@mail.gmail.com> <1242064968.2923.615.camel@adam.local.net> <1242072865.2923.670.camel@adam.local.net> <1242079541.3452.48.camel@localhost.localdomain> <1242080497.2923.676.camel@adam.local.net> <1242122940.1211.19.camel@gilboa-work-dev.localdomain> <1242143648.1211.32.camel@gilboa-work-dev.localdomain> <1242146510.2923.766.camel@adam.local.net> Message-ID: Adam Williamson wrote: > and Mandriva certainly wouldn't consider shipping KDE 4.2 as a > 'stable' update for KDE 4.1. Neither would Ubuntu. You can *get* KDE 4.2 > for both Mandriva and Ubuntu releases that shipped with KDE 4.1, but > it's not released as a stable update, nor - IMO - should it be, *in a > distribution which uses stable updates* (which, right now, Fedora > isn't). The feedback we got for the 4.2 updates was almost 100% positive, we got thanked a lot for finally shipping a "usable" KDE. Now I disagree with the claim that 4.1 was not usable, but several users felt the 4.2 update was needed for it to be usable for them. > I don't think that follows at all. Updates policies, above all else, > need to be consistent, and if you say "well, we'll try to be quite > stable and safe, but ultimately it's up to the discretion of > maintainers", you will never get consistency, because all maintainers > are different. What Maintainer A considers a 'safe' upgrade will be > different to what Maintainer B considers safe. Hence the user experience > will be inconsistent. Effectively, the update process will only be as > safe as the most happy-go-lucky maintainer's position - even though all > other maintainers are more conservative. And that's not efficient, > because you get all the drawbacks of instability from the maintainers > who push whatever they like, and all the drawbacks of staleness from the > maintainers who act very conservatively. It's true that inconsistency is bad, and that's the problem with the current policy, but there's no better solution. At best, we can give more hints to the maintainers, but there's no policy which works for all packages. Hardcoded bureaucracy doesn't really work, in particular, the 2 "all or nothing" solutions you propose: > This is why I say the only two policies that can really work optimally > are "minimal necessary changes to fix strictly identified bugs and > security flaws" or "update whatever you like". Either is valid, but both > have distinct implications for the user experience, so we need to pick > based on what user experience we want, and message that consistently so > that users know what to expect. are both completely broken. The first turns Fedora into yet another "Debian stable type" distribution: this seems to be what you're advocating, but there are already several of those and Fedora would lose one of the main things it is about (being always up to date) by endorsing such a policy. The second basically turns all releases into Rawhide, which is unfortunately unsuitable for daily use. A middle ground is needed, and that's where the maintainer has to make a call. And this is why the policy is as it is now. Kevin Kofler From fedora-devel-list at cygnusx-1.org Tue May 12 19:20:04 2009 From: fedora-devel-list at cygnusx-1.org (Nathan Grennan) Date: Tue, 12 May 2009 12:20:04 -0700 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: References: <4A0814ED.60205@redhat.com> <4A09B8FE.4040904@cygnusx-1.org> <4A09C018.4060906@cygnusx-1.org> Message-ID: <4A09CBE4.4020807@cygnusx-1.org> On 05/12/2009 11:46 AM, Julian Sikorski wrote: > Nathan Grennan pisze: >>> I was just thinking the same thing yesterday. After trying to use >>> thunderbird 3.0b2, I have found it unusable. >>> >>> I have tried a fresh .thunderbird directory and switching to the i586 >>> version from the x86_64 version. It is still horrible. I do have huge >>> folders with 10k+ messages in them. Thunderbird 3.0b2 seems to scan all >>> folders and download all messages. With the fresh .thunderbird I started >>> with a 32mb .thunderbird folder, but after leaving it over night with >>> just one of my three accounts it was up to 2gb. >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=493000 >>> >> Thunderbird 3.0b2 seems to behave after I turn off the sync feature >> for each account. I think at the very least this feature needs to be >> turned off by default. >> > Afaik fetching whole messages (as opposed to headers) for IMAP accounts > was an upstream decision. I understand, but on the other hand does Fedora want a dozen bug reports over Thunderbird being useless, because of a crappy default? From wtogami at redhat.com Tue May 12 19:22:18 2009 From: wtogami at redhat.com (Warren Togami) Date: Tue, 12 May 2009 15:22:18 -0400 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A09CBE4.4020807@cygnusx-1.org> References: <4A0814ED.60205@redhat.com> <4A09B8FE.4040904@cygnusx-1.org> <4A09C018.4060906@cygnusx-1.org> <4A09CBE4.4020807@cygnusx-1.org> Message-ID: <4A09CC6A.1020001@redhat.com> On 05/12/2009 03:20 PM, Nathan Grennan wrote: > On 05/12/2009 11:46 AM, Julian Sikorski wrote: >> Nathan Grennan pisze: >>>> I was just thinking the same thing yesterday. After trying to use >>>> thunderbird 3.0b2, I have found it unusable. >>>> >>>> I have tried a fresh .thunderbird directory and switching to the i586 >>>> version from the x86_64 version. It is still horrible. I do have huge >>>> folders with 10k+ messages in them. Thunderbird 3.0b2 seems to scan all >>>> folders and download all messages. With the fresh .thunderbird I >>>> started >>>> with a 32mb .thunderbird folder, but after leaving it over night with >>>> just one of my three accounts it was up to 2gb. >>>> >>>> https://bugzilla.redhat.com/show_bug.cgi?id=493000 >>>> >>> Thunderbird 3.0b2 seems to behave after I turn off the sync feature >>> for each account. I think at the very least this feature needs to be >>> turned off by default. >>> >> Afaik fetching whole messages (as opposed to headers) for IMAP accounts >> was an upstream decision. > > I understand, but on the other hand does Fedora want a dozen bug reports > over Thunderbird being useless, because of a crappy default? > http://rawhidewatch.wordpress.com/2009/03/27/thunderbird-3-beta-huge-imap-folders-100-cpu-hang/ I don't know why, but this workaround seems to make thunderbird usable despite this problem. Warren From awilliam at redhat.com Tue May 12 19:23:15 2009 From: awilliam at redhat.com (Adam Williamson) Date: Tue, 12 May 2009 12:23:15 -0700 Subject: OpenOffice 3.1 In-Reply-To: References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <1241990992.3452.6.camel@localhost.localdomain> <6dc6523c0905101458l64811e65lb9f18216a4f93941@mail.gmail.com> <1242064968.2923.615.camel@adam.local.net> <1242072865.2923.670.camel@adam.local.net> <1242079541.3452.48.camel@localhost.localdomain> <1242080497.2923.676.camel@adam.local.net> <1242122940.1211.19.camel@gilboa-work-dev.localdomain> <1242143648.1211.32.camel@gilboa-work-dev.localdomain> <1242146510.2923.766.camel@adam.local.net> Message-ID: <1242156195.2923.847.camel@adam.local.net> On Tue, 2009-05-12 at 21:16 +0200, Kevin Kofler wrote: > It's true that inconsistency is bad, and that's the problem with the current > policy, but there's no better solution. At best, we can give more hints to > the maintainers, but there's no policy which works for all packages. > Hardcoded bureaucracy doesn't really work, in particular, the 2 "all or > nothing" solutions you propose: > > > This is why I say the only two policies that can really work optimally > > are "minimal necessary changes to fix strictly identified bugs and > > security flaws" or "update whatever you like". Either is valid, but both > > have distinct implications for the user experience, so we need to pick > > based on what user experience we want, and message that consistently so > > that users know what to expect. > > are both completely broken. The first turns Fedora into yet another "Debian > stable type" distribution: this seems to be what you're advocating, but > there are already several of those and Fedora would lose one of the main > things it is about (being always up to date) by endorsing such a policy. > The second basically turns all releases into Rawhide, which is > unfortunately unsuitable for daily use. A middle ground is needed, and > that's where the maintainer has to make a call. And this is why the policy > is as it is now. I'm not advocating either. I'm perfectly happy with either. I don't have a personal opinion on whether we should be an Aunt Flo-supporting distro or not. I can work happily with either choice, I just want to know which we are, so I can tailor my approach appropriately. :) Let's make it clear: what we're talking about as 'the second' above is basically where I think we are now. Leaving it to the maintainer's discretion is equivalent to 'ship whatever you like', because that's exactly what some maintainers do already, there's all sorts of stuff shipped out as updates for stable releases. As I said, if we actually actively want to be there, that's fine. But we have to be consistent with that, both in our approach to other things, and to messaging. We need to be telling potential and actual users, prominently, that we're *not* a Mandriva/Ubuntu/Debian stable-type distribution, and that they shouldn't use Fedora if that's what they're expecting. At present, we don't really do this. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From tcallawa at redhat.com Tue May 12 19:27:32 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 12 May 2009 15:27:32 -0400 Subject: Update -> no sound In-Reply-To: <4A09C80C.7000600@fedoraproject.org> References: <1242146328.3147.181.camel@dimi.lattica.com> <20090512165559.GA19474@tango.0pointer.de> <1242149935.3147.191.camel@dimi.lattica.com> <4A09B8E6.5060904@fedoraproject.org> <20090512175839.GC29406@redhat.com> <4A09B964.5000905@redhat.com> <4A09BCBE.30509@fedoraproject.org> <4A09C3EE.3000207@redhat.com> <4A09C80C.7000600@fedoraproject.org> Message-ID: <4A09CDA4.7060101@redhat.com> On 05/12/2009 03:03 PM, Rahul Sundaram wrote: > Good to know all this but there is definitely a big lack of > communication on this development with the rest of the Fedora community. > There was a very brief mail to fedora-announce list but how much input > are you getting input from Fedora maintainers whose job this is supposed > to make easier? Well, we did send the announce email here. We've also regularly asked for help from #fedora-devel on IRC, and presented material about our efforts at FUDCon. I'm not sure what more we can do, short of aggressively spamming everyone to LOOK AT US. ~spot From tcallawa at redhat.com Tue May 12 19:28:55 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 12 May 2009 15:28:55 -0400 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A09CBE4.4020807@cygnusx-1.org> References: <4A0814ED.60205@redhat.com> <4A09B8FE.4040904@cygnusx-1.org> <4A09C018.4060906@cygnusx-1.org> <4A09CBE4.4020807@cygnusx-1.org> Message-ID: <4A09CDF7.6040000@redhat.com> On 05/12/2009 03:20 PM, Nathan Grennan wrote: > I understand, but on the other hand does Fedora want a dozen bug reports > over Thunderbird being useless, because of a crappy default? FWIW, I don't think the Thunderbird in Fedora 11 is useless, far from it, and I have some freaking HUGE imap folders. In fact, this version is the first version that has been useful to me, without installing double-digit numbers of addons. ~spot From konrad at tylerc.org Tue May 12 19:53:01 2009 From: konrad at tylerc.org (Conrad Meyer) Date: Tue, 12 May 2009 12:53:01 -0700 Subject: FESco meeting summary for 20090507 In-Reply-To: References: Message-ID: <200905121253.01644.konrad@tylerc.org> On Tuesday 12 May 2009 10:22:52 am Kevin Kofler wrote: > Matej Cepl wrote: > > Except ... if you really want Windows these days, virtualization > > is probably more viable option (yes, I have Windows 7/build 7100 > > in kvm running on x86_64 host). > > But that solution is not Free Software and it even costs money (at least if > you want to do it legally). > > Kevin Kofler Windows 7 build 7100 is the RC, which is available to the public for free (as in $$$) for the next 10 months or so. -- Conrad Meyer From mw_triad at users.sourceforge.net Tue May 12 19:54:20 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Tue, 12 May 2009 14:54:20 -0500 Subject: Guaranteeing running code is signed In-Reply-To: <4A06FF6C.4080905@hidayahonline.org> References: <3da3b5b40905091136s3dd92954kffde00706905a850@mail.gmail.com> <2d319b780905091212x531acea1v837e28429d901601@mail.gmail.com> <3da3b5b40905091228s1acfcfa2s91d53fed72a56504@mail.gmail.com> <200905101503.35200.bjorn@xn--rombobjrn-67a.se> <4A06FF6C.4080905@hidayahonline.org> Message-ID: Basil Mohamed Gohar wrote: > On 05/10/2009 09:31 PM, Krzysztof Halasa wrote: >> Bj?rn Persson writes: >>> It's impossible to verify the security of a computer system from within the >>> system itself. If a malicious person may have had root access, then RPM, GPG, >>> SElinux and the auditing subsystem may all have been tampered with and you >>> can't trust that they tell you the truth. Reinstalling is the only way to be >>> sure. >> Sure? Someone may have planted something in a motherboard flash ROM >> (easy), in VGA flash, in CD/DVD flash, in HDD flash and/or "service" >> sectors etc. >> >> You can't be 100% sure that a brand-new hardware is clean. > > Shift this register/logic enough in one direction, and it's going to > overflow into "just trust everything"... Indeed. (I've read stuff about military testing microchips to verify that the circuitry is correct. Forget flash, eeprom, even rom; do you trust the fab plant that built your CPU?) -- Matthew ENOWIT: .sig file for this machine not set up yet From loganjerry at gmail.com Tue May 12 19:30:59 2009 From: loganjerry at gmail.com (Jerry James) Date: Tue, 12 May 2009 13:30:59 -0600 Subject: Bug lifecycle page revised / expanded In-Reply-To: <1242155333.2923.844.camel@adam.local.net> References: <1242155333.2923.844.camel@adam.local.net> Message-ID: <870180fe0905121230o77860ccrab2712ec1a23c16c@mail.gmail.com> On Tue, May 12, 2009 at 1:08 PM, Adam Williamson wrote: > Hi, everyone - just a quick note that, last week, I revised / expanded > the bug lifecycle page: > > https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow I have two questions about situations outside the realm of bug triage. Both involve package reviews. 1. Suppose I submit a package for review, and then later decide that I want to withdraw the submission for some reason. (I had this happen recently when legal problems with the package came to light.) The review bug should go to state CLOSED, but with what reason? WONTFIX? 2. Suppose I decide to review a package submission. I assign the review bug to myself. The review turns up some problems that need to be fixed. The person submitting the package doesn't respond for a long time. Now what? Do I mark the bug NEEDINFO? What if the submitter still doesn't respond? (I've got several bugs assigned to me that are currently in this state.) Thanks, -- Jerry James http://www.jamezone.org/ From loganjerry at gmail.com Tue May 12 20:04:49 2009 From: loganjerry at gmail.com (Jerry James) Date: Tue, 12 May 2009 14:04:49 -0600 Subject: Guaranteeing running code is signed In-Reply-To: References: <3da3b5b40905091136s3dd92954kffde00706905a850@mail.gmail.com> <2d319b780905091212x531acea1v837e28429d901601@mail.gmail.com> <3da3b5b40905091228s1acfcfa2s91d53fed72a56504@mail.gmail.com> <200905101503.35200.bjorn@xn--rombobjrn-67a.se> <4A06FF6C.4080905@hidayahonline.org> Message-ID: <870180fe0905121304i2def0cd2n9bcdd71cba45211f@mail.gmail.com> On Tue, May 12, 2009 at 1:54 PM, Matthew Woehlke wrote: > Indeed. (I've read stuff about military testing microchips to verify that > the circuitry is correct. Forget flash, eeprom, even rom; do you trust the > fab plant that built your CPU?) I highly recommend reading Ken Thompson's scenario: http://cm.bell-labs.com/who/ken/trust.html -- Jerry James http://www.jamezone.org/ From drago01 at gmail.com Tue May 12 20:08:20 2009 From: drago01 at gmail.com (drago01) Date: Tue, 12 May 2009 22:08:20 +0200 Subject: FESco meeting summary for 20090507 In-Reply-To: <1242150547.2923.773.camel@adam.local.net> References: <1242062320.2923.586.camel@adam.local.net> <1242150547.2923.773.camel@adam.local.net> Message-ID: On Tue, May 12, 2009 at 7:49 PM, Adam Williamson wrote: > On Tue, 2009-05-12 at 17:44 +0200, Matej Cepl wrote: >> On 2009-05-11, 17:18 GMT, Adam Williamson wrote: >> > but wine is still valid. >> >> Except ... if you really want Windows these days, virtualization >> is probably more viable option (yes, I have Windows 7/build 7100 >> in kvm running on x86_64 host). > > Legally speaking, you need a valid Windows license to use > virtualization. I have no such license for this PC, and I'm not about to > go out and pay Microsoft a couple hundred dollars to buy one. But I can > use wine to run a few Windows apps / games perfectly legally without it. Well if you want to play games virtualisation wont help you anyway, as it does not provide hardware 3D. Vmware and virtualbox do but only to a limited extend. (Our virt stack does not offer any 3D, dunno what happened to vmgl which ought to add accelerated 3D to qemu). From awilliam at redhat.com Tue May 12 20:23:46 2009 From: awilliam at redhat.com (Adam Williamson) Date: Tue, 12 May 2009 13:23:46 -0700 Subject: Bug lifecycle page revised / expanded In-Reply-To: <870180fe0905121230o77860ccrab2712ec1a23c16c@mail.gmail.com> References: <1242155333.2923.844.camel@adam.local.net> <870180fe0905121230o77860ccrab2712ec1a23c16c@mail.gmail.com> Message-ID: <1242159826.2923.851.camel@adam.local.net> On Tue, 2009-05-12 at 13:30 -0600, Jerry James wrote: > On Tue, May 12, 2009 at 1:08 PM, Adam Williamson wrote: > > Hi, everyone - just a quick note that, last week, I revised / expanded > > the bug lifecycle page: > > > > https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow > > I have two questions about situations outside the realm of bug triage. > Both involve package reviews. > > 1. Suppose I submit a package for review, and then later decide that I > want to withdraw the submission for some reason. (I had this happen > recently when legal problems with the package came to light.) The > review bug should go to state CLOSED, but with what reason? WONTFIX? > > 2. Suppose I decide to review a package submission. I assign the > review bug to myself. The review turns up some problems that need to > be fixed. The person submitting the package doesn't respond for a > long time. Now what? Do I mark the bug NEEDINFO? What if the > submitter still doesn't respond? (I've got several bugs assigned to > me that are currently in this state.) Good questions, and I'm not sure of the answers. The package review process is really a separate workflow that uses Bugzilla for convenience so it doesn't really involve Bugzappers / QA at all. Bugzappers are asked to leave package review requests entirely alone. I'll update the lifecycle page to specify that it applies only to 'conventional' Fedora bugs. For 1 I'd suggest NOTABUG, myself. For 2 I suppose, yeah, set it NEEDINFO, and close as CANTFIX or INSUFFICIENT_DATA if they seem to have disappeared. But that's just me guessing and carries zero weight, I don't know who should make an Official Declaration in this case. Resolutions aren't really super important, so don't get tied up over them. Don't spend more than a minute thinking "my word! What resolution should I use?!?!" - if you don't know and the page doesn't make it clear, just take a guess, no-one's going to die if you get it 'wrong'. It's just nice to have mostly consistent usage so we can sometimes derive useful statistics from the resolutions. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From mcepl at redhat.com Tue May 12 20:41:22 2009 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 12 May 2009 22:41:22 +0200 Subject: FESco meeting summary for 20090507 References: <1242062320.2923.586.camel@adam.local.net> <1242150547.2923.773.camel@adam.local.net> Message-ID: On 2009-05-12, 17:49 GMT, Adam Williamson wrote: > Legally speaking, you need a valid Windows license to use > virtualization. I have no such license for this PC, and I'm not about to > go out and pay Microsoft a couple hundred dollars to buy one. But I can > use wine to run a few Windows apps / games perfectly legally without it. I know, it is probably not a robust solution, but my copy of Windows 7 should work at least until March next year. And I need Windows only for getting good USB tracks so opensync would work ;-) Mat?j From mw_triad at users.sourceforge.net Tue May 12 20:47:31 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Tue, 12 May 2009 15:47:31 -0500 Subject: SPARC Status (Was Re: Secondary Architecture Status?) In-Reply-To: <4A0909BB.4030807@freenet.de> References: <1241911202.24436.81.camel@macbook.infradead.org> <4A0862F1.2030608@redhat.com> <20090511185147.GA3256@yoda.jdub.homelinux.org> <1242071724.2923.656.camel@adam.local.net> <4A0909BB.4030807@freenet.de> Message-ID: Ralf Corsepius wrote: > It likely is something worth looking into, but based on my experiences > with Fedora on my netbook, I am having doubts compiler optimizations > alone are worth a "secondary arch". > > At least on my netbook, neither "speed" or "space" (mine has a disk) are > actual problems. Is for me! :-) But I don't think -Os is the solution; the problems tend to be long dep-chains and data (and especially, the intersection of both*). data tends to be much larger than code. Better would be more breaking up of huge packages (e.g. KDE) especially where it can reduce dependencies, or even conflicting package builds to provide different sets of optional features. (* As a concrete example, I finally gave up on having kcalc installed, which allowed me to pull out foomatic. That was quite some space in that dep-chain. As another example, why does system-config-date require xulrunner? Something in F10 updates changed there and wanted to pull in quite some dependencies until I tracked down and nuked s-c-d as the responsible package.) -- Matthew ENOWIT: .sig file for this machine not set up yet From mcepl at redhat.com Tue May 12 20:42:33 2009 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 12 May 2009 22:42:33 +0200 Subject: FESco meeting summary for 20090507 References: <200905121253.01644.konrad@tylerc.org> Message-ID: On 2009-05-12, 19:53 GMT, Conrad Meyer wrote: > Windows 7 build 7100 is the RC, which is available to the > public for free (as in $$$) for the next 10 months or so. That and also I don't care about Windows that much ... when fancy hits me I will remove it anyway. Mat?j From jwboyer at gmail.com Tue May 12 20:52:19 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 12 May 2009 16:52:19 -0400 Subject: Update -> no sound In-Reply-To: <4A09C80C.7000600@fedoraproject.org> References: <1242146328.3147.181.camel@dimi.lattica.com> <20090512165559.GA19474@tango.0pointer.de> <1242149935.3147.191.camel@dimi.lattica.com> <4A09B8E6.5060904@fedoraproject.org> <20090512175839.GC29406@redhat.com> <4A09B964.5000905@redhat.com> <4A09BCBE.30509@fedoraproject.org> <4A09C3EE.3000207@redhat.com> <4A09C80C.7000600@fedoraproject.org> Message-ID: <20090512205219.GA7598@yoda.jdub.homelinux.org> On Wed, May 13, 2009 at 12:33:40AM +0530, Rahul Sundaram wrote: >On 05/13/2009 12:16 AM, Tom "spot" Callaway wrote: > >> We have a mailing list: https://fedorahosted.org/mailman/listinfo/moksha >> We have a website: https://fedorahosted.org/fedoracommunity/ >> We have wiki: https://fedoraproject.org/wiki/FedoraCommunity >> We have regular weekly meetings (telephone) that are open to all >> interested parties (Mondays at 10 AM Eastern, 1400 UTC, Fedora Talk, ext >> 2001) >> We have an open code repository: >> https://fedorahosted.org/fedoracommunity/browser >> >> In fact, I think the only thing we're missing is a Silo. ;) > >Good to know all this but there is definitely a big lack of >communication on this development with the rest of the Fedora community. >There was a very brief mail to fedora-announce list but how much input >are you getting input from Fedora maintainers whose job this is supposed >to make easier? Yes, they are. I've been asked several questions myself. Spot maintains an ungodly number of packages. I think they're getting plenty of input. Please, enough with the lack of communication. Not every project needs a big massive PR campaign or huge call for participation. Particularly in the extremely early design phases where most of the degenerates into bike shedding and pony wanting. I'd rather see a somewhat usable tool be announced than have to read another 300 emails about what someone's idea of Fedora should be. josh From bruno at wolff.to Tue May 12 20:54:40 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 12 May 2009 15:54:40 -0500 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: References: <1241832771.2886.15.camel@localhost.localdomain> <4A04EAAE.50907@freenet.de> <1241836379.2886.30.camel@localhost.localdomain> <1242062337.3452.27.camel@localhost.localdomain> <1242066123.3452.34.camel@localhost.localdomain> <1242074588.2923.673.camel@adam.local.net> Message-ID: <20090512205440.GA28258@wolff.to> On Mon, May 11, 2009 at 16:51:12 -0400, Colin Walters wrote: > > Ok, well, maybe the right thing is for the DVD images to have the > installed live RPMs also in RPM form so they can be used as a package > cache as well. Or maybe instead we figure out how to reconstruct the > RPMs from the installed image reliably (not sure what the blockers are > there). Storing them separately on the DVD is going to noticeably reduce the amount of packages that can be put on a DVD image. For some spins that might be OK. It would really hurt the live games DVD image. (Where I had been trying to get permission to use 4.7GB instead of 4.3GB.) This will also significantly increase the bandwidth needed to download the images. From mcepl at redhat.com Tue May 12 20:43:52 2009 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 12 May 2009 22:43:52 +0200 Subject: best practices for updates in stable releases (was: Re: OpenOffice 3.1) References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <4A05B234.2020608@leemhuis.info> <1241890311.2886.63.camel@localhost.localdomain> <1242054913.3452.16.camel@localhost.localdomain> <1242144256.21430.4.camel@blaa> <1242145782.3452.108.camel@localhost.localdomain> Message-ID: <8l3pd6-33u.ln1@ppp1053.in.ipex.cz> On 2009-05-12, 16:29 GMT, Jesse Keating wrote: > It's hard for one person to timely review hundreds of update > requests to figure out which are ignoring the guidelines and > which aren't. No one is blaming you, but of course I think releng should be more than just one Jesse however great you are (and you are). Mat?j From bruno at wolff.to Tue May 12 20:54:40 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 12 May 2009 15:54:40 -0500 Subject: 182 pending F11 stable updates. WTF? In-Reply-To: References: <1241832771.2886.15.camel@localhost.localdomain> <4A04EAAE.50907@freenet.de> <1241836379.2886.30.camel@localhost.localdomain> <1242062337.3452.27.camel@localhost.localdomain> <1242066123.3452.34.camel@localhost.localdomain> <1242074588.2923.673.camel@adam.local.net> Message-ID: <20090512205440.GA28258@wolff.to> On Mon, May 11, 2009 at 16:51:12 -0400, Colin Walters wrote: > > Ok, well, maybe the right thing is for the DVD images to have the > installed live RPMs also in RPM form so they can be used as a package > cache as well. Or maybe instead we figure out how to reconstruct the > RPMs from the installed image reliably (not sure what the blockers are > there). Storing them separately on the DVD is going to noticeably reduce the amount of packages that can be put on a DVD image. For some spins that might be OK. It would really hurt the live games DVD image. (Where I had been trying to get permission to use 4.7GB instead of 4.3GB.) This will also significantly increase the bandwidth needed to download the images. From jarod at redhat.com Tue May 12 21:05:20 2009 From: jarod at redhat.com (Jarod Wilson) Date: Tue, 12 May 2009 17:05:20 -0400 Subject: SPARC Status (Was Re: Secondary Architecture Status?) In-Reply-To: <5256d0b0905120706o7cd11d4bhaf5858133f88293f@mail.gmail.com> References: <200905121001.42151.jarod@redhat.com> <5256d0b0905120706o7cd11d4bhaf5858133f88293f@mail.gmail.com> Message-ID: <200905121705.20841.jarod@redhat.com> On Tuesday 12 May 2009 10:06:22 Peter Robinson wrote: > >> > I would really like to see a proliferation of secondary arches in > >> > Fedora, but I don't think 'workstation' is a viable usage model for > >> > them to get started. Most will have to focus on the type of hardware > >> > that actually sells for that arch, and yes I realize that can be at > >> > odds with some of the directions Fedora is going. > >> > >> I think there are most likely two candidates for a secondary arch > >> other than PPC. The first is sparc where from the server point of view > >> where its probably about as prolific as PPC in that regard. The second > >> would be arm but that is more from the NetBook/MID/Phone/STB > >> perspective where there are quite a few devices in the 500Mhz-1Ghz > >> range with 256-512Mb RAM. With the OLPC X0-1 we've proven that Fedora > >> can run relatively well on that sort of spec, they also tend to be > >> relatively cheap. > > > > Once we switch our 32-bit x86 packages from i586 to i686 for F12 > > (hopefully w/sse2 enabled as well), then i586 becomes a very doable > > secondary arch as well, if enough people are interested in keeping > > their clunkers running the latest-n-greatest stuff... > > What about the million odd (not sure of the actual deployment numbers) > OLPC XO clunkers out there that fall into this category? The fact the next olpc release is to be based on f11 is in fact one of the reasons f11 went i386->i586 for 32-bit x86 binaries... That camp might take a great deal of interest in an i586 secondary arch. :) > I though the > whole difference between i586 and i686 was cmov and that wasn't > considered a great performance boost. Well, that's one part of it. With luck, i686 will actually be cmov plus sse2, which is a fairly decent win. Also, Ulrich and Jakub (iirc) were rather leery of running as i586, as the i586-codepaths aren't as well exercised or optimized as i686-specific ones (I don't have any specific examples though). -- Jarod Wilson jarod at redhat.com From kraxel at redhat.com Tue May 12 21:21:44 2009 From: kraxel at redhat.com (Gerd Hoffmann) Date: Tue, 12 May 2009 23:21:44 +0200 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A09CBE4.4020807@cygnusx-1.org> References: <4A0814ED.60205@redhat.com> <4A09B8FE.4040904@cygnusx-1.org> <4A09C018.4060906@cygnusx-1.org> <4A09CBE4.4020807@cygnusx-1.org> Message-ID: <4A09E868.1000204@redhat.com> On 05/12/09 21:20, Nathan Grennan wrote: > On 05/12/2009 11:46 AM, Julian Sikorski wrote: >> Afaik fetching whole messages (as opposed to headers) for IMAP accounts >> was an upstream decision. > > I understand, but on the other hand does Fedora want a dozen bug reports > over Thunderbird being useless, because of a crappy default? Well, imap-over-slow-internet-links without aggressive local caching just doesn't fly. I really like the new 3.0beta behavior. /me used the good old SyncOnArrival extention before (with hacked version check so the 1.5 version works with 2.0 ...). cheers, Gerd From fedora-devel-list at cygnusx-1.org Tue May 12 21:26:31 2009 From: fedora-devel-list at cygnusx-1.org (Nathan Grennan) Date: Tue, 12 May 2009 14:26:31 -0700 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A09CDF7.6040000@redhat.com> References: <4A0814ED.60205@redhat.com> <4A09B8FE.4040904@cygnusx-1.org> <4A09C018.4060906@cygnusx-1.org> <4A09CBE4.4020807@cygnusx-1.org> <4A09CDF7.6040000@redhat.com> Message-ID: <4A09E987.5050800@cygnusx-1.org> On 05/12/2009 12:28 PM, Tom "spot" Callaway wrote: > On 05/12/2009 03:20 PM, Nathan Grennan wrote: >> I understand, but on the other hand does Fedora want a dozen bug reports >> over Thunderbird being useless, because of a crappy default? > > FWIW, I don't think the Thunderbird in Fedora 11 is useless, far from > it, and I have some freaking HUGE imap folders. In fact, this version is > the first version that has been useful to me, without installing > double-digit numbers of addons. Then I think you haven't seen this issue for whatever reason. For me it takes Thunderbird from the best e-mail client IMHO to the worst. On the other hand, working around this issue by disabling syncing takes it back to the best. Warren's suggested workaround would probably allow me to turn syncing back on, though even then it doesn't sound as good as just disabling syncing. I use dovecot-1.1.11-1.11.fc10.x86_64 with imap and ssl. My MailDir directory is 5.3gb. My high scoring spam folder is 3.2gb. My mail servers aren't local. All three are in colos. From fedora-devel-list at cygnusx-1.org Tue May 12 21:32:10 2009 From: fedora-devel-list at cygnusx-1.org (Nathan Grennan) Date: Tue, 12 May 2009 14:32:10 -0700 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A09E868.1000204@redhat.com> References: <4A0814ED.60205@redhat.com> <4A09B8FE.4040904@cygnusx-1.org> <4A09C018.4060906@cygnusx-1.org> <4A09CBE4.4020807@cygnusx-1.org> <4A09E868.1000204@redhat.com> Message-ID: <4A09EADA.5000903@cygnusx-1.org> On 05/12/2009 02:21 PM, Gerd Hoffmann wrote: > On 05/12/09 21:20, Nathan Grennan wrote: >> On 05/12/2009 11:46 AM, Julian Sikorski wrote: >>> Afaik fetching whole messages (as opposed to headers) for IMAP accounts >>> was an upstream decision. >> >> I understand, but on the other hand does Fedora want a dozen bug reports >> over Thunderbird being useless, because of a crappy default? > > Well, imap-over-slow-internet-links without aggressive local caching > just doesn't fly. I really like the new 3.0beta behavior. > > /me used the good old SyncOnArrival extention before (with hacked > version check so the 1.5 version works with 2.0 ...). Different usage patterns are at play. I do imap over fast internet connections, but then internet would be slow compared to during it across a LAN. I would think your folders aren't that big, because syncing huge folders would be horrible. Another thing that may be at play is the switch of the default from no sync to sync. So I didn't use syncing before, and so it wasn't a little at a time. Instead it was gigabytes all at once. Plus tens of thousands of messages at once. From sundaram at fedoraproject.org Tue May 12 21:44:49 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 13 May 2009 03:14:49 +0530 Subject: Update -> no sound In-Reply-To: <4A09CDA4.7060101@redhat.com> References: <1242146328.3147.181.camel@dimi.lattica.com> <20090512165559.GA19474@tango.0pointer.de> <1242149935.3147.191.camel@dimi.lattica.com> <4A09B8E6.5060904@fedoraproject.org> <20090512175839.GC29406@redhat.com> <4A09B964.5000905@redhat.com> <4A09BCBE.30509@fedoraproject.org> <4A09C3EE.3000207@redhat.com> <4A09C80C.7000600@fedoraproject.org> <4A09CDA4.7060101@redhat.com> Message-ID: <4A09EDD1.3020101@fedoraproject.org> On 05/13/2009 12:57 AM, Tom "spot" Callaway wrote: > On 05/12/2009 03:03 PM, Rahul Sundaram wrote: >> Good to know all this but there is definitely a big lack of >> communication on this development with the rest of the Fedora community. >> There was a very brief mail to fedora-announce list but how much input >> are you getting input from Fedora maintainers whose job this is supposed >> to make easier? > > Well, we did send the announce email here. We've also regularly asked > for help from #fedora-devel on IRC, and presented material about our > efforts at FUDCon. > > I'm not sure what more we can do, short of aggressively spamming > everyone to LOOK AT US. I can suggest a few simple things: * A test instance * A regular status report and ask for input from this list instead of just from IRC or conferences. * More developers blogging about it Rahul From stickster at gmail.com Tue May 12 21:25:40 2009 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 12 May 2009 17:25:40 -0400 Subject: Update -> no sound In-Reply-To: <20090512205219.GA7598@yoda.jdub.homelinux.org> References: <1242146328.3147.181.camel@dimi.lattica.com> <20090512165559.GA19474@tango.0pointer.de> <1242149935.3147.191.camel@dimi.lattica.com> <4A09B8E6.5060904@fedoraproject.org> <20090512175839.GC29406@redhat.com> <4A09B964.5000905@redhat.com> <4A09BCBE.30509@fedoraproject.org> <4A09C3EE.3000207@redhat.com> <4A09C80C.7000600@fedoraproject.org> <20090512205219.GA7598@yoda.jdub.homelinux.org> Message-ID: <20090512212540.GE3457@localhost.localdomain> On Tue, May 12, 2009 at 04:52:19PM -0400, Josh Boyer wrote: > On Wed, May 13, 2009 at 12:33:40AM +0530, Rahul Sundaram wrote: > >On 05/13/2009 12:16 AM, Tom "spot" Callaway wrote: > > > >> We have a mailing list: https://fedorahosted.org/mailman/listinfo/moksha > >> We have a website: https://fedorahosted.org/fedoracommunity/ > >> We have wiki: https://fedoraproject.org/wiki/FedoraCommunity > >> We have regular weekly meetings (telephone) that are open to all > >> interested parties (Mondays at 10 AM Eastern, 1400 UTC, Fedora Talk, ext > >> 2001) > >> We have an open code repository: > >> https://fedorahosted.org/fedoracommunity/browser > >> > >> In fact, I think the only thing we're missing is a Silo. ;) > > > >Good to know all this but there is definitely a big lack of > >communication on this development with the rest of the Fedora community. > >There was a very brief mail to fedora-announce list but how much input > >are you getting input from Fedora maintainers whose job this is supposed > >to make easier? > > Yes, they are. I've been asked several questions myself. Spot maintains > an ungodly number of packages. I think they're getting plenty of input. > > Please, enough with the lack of communication. Not every project needs a big > massive PR campaign or huge call for participation. Particularly in the > extremely early design phases where most of the degenerates into bike shedding > and pony wanting. I'd rather see a somewhat usable tool be announced than > have to read another 300 emails about what someone's idea of Fedora should be. I hope no one will mind, though, that the Fedora Marketing team has been preparing information on Moksha and Fedora Community to drive some additional interest around the public beta: https://fedoraproject.org/wiki/Moksha_in_Fedora_11 https://fedoraproject.org/wiki/F11_Talking_Points Rahul, I'm not sure I understand what your purpose is in this particular sub-thread. As far as I can see, everyone here is trying their hardest, and succeeding, at Doing It Right, and your issue is primarily that either you didn't see the announcement or don't have time to read all the material personally. No shame in being merely human like everyone else. I'm not even on the Moksha list myself, because as fascinating and awesome as I think it is, I'm just out of cycles. So I'm doing what I can by participating in the Marketing team's work to make sure people know what the project is, and its capabilities. Let's not waste time and breath beating up on people, most especially those undeserving of it. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From sundaram at fedoraproject.org Tue May 12 21:51:24 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 13 May 2009 03:21:24 +0530 Subject: Update -> no sound In-Reply-To: <20090512205219.GA7598@yoda.jdub.homelinux.org> References: <1242146328.3147.181.camel@dimi.lattica.com> <20090512165559.GA19474@tango.0pointer.de> <1242149935.3147.191.camel@dimi.lattica.com> <4A09B8E6.5060904@fedoraproject.org> <20090512175839.GC29406@redhat.com> <4A09B964.5000905@redhat.com> <4A09BCBE.30509@fedoraproject.org> <4A09C3EE.3000207@redhat.com> <4A09C80C.7000600@fedoraproject.org> <20090512205219.GA7598@yoda.jdub.homelinux.org> Message-ID: <4A09EF5C.3020508@fedoraproject.org> On 05/13/2009 02:22 AM, Josh Boyer wrote: > > Yes, they are. I've been asked several questions myself. Spot maintains > an ungodly number of packages. I think they're getting plenty of input. Fedora Community as a project has no connection to the number of packages Spot maintains or the input he is getting on those packages. I have no idea why you bring that up but If the burden is too large, then I suggest getting co-maintainers. > Please, enough with the lack of communication. Not every project needs a big > massive PR campaign or huge call for participation. I didn't claim otherwise. Particularly in the > extremely early design phases where most of the degenerates into bike shedding > and pony wanting. I'd rather see a somewhat usable tool be announced than > have to read another 300 emails about what someone's idea of Fedora should be. I understand your frustration with the amount of noise in this list but MyFedora was originally announced about a year back. Hardly early stages and according the Spot is about to be launched soon. If that is that not the case, let me know. Rahul From sundaram at fedoraproject.org Tue May 12 21:55:30 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 13 May 2009 03:25:30 +0530 Subject: Update -> no sound In-Reply-To: <20090512212540.GE3457@localhost.localdomain> References: <1242146328.3147.181.camel@dimi.lattica.com> <20090512165559.GA19474@tango.0pointer.de> <1242149935.3147.191.camel@dimi.lattica.com> <4A09B8E6.5060904@fedoraproject.org> <20090512175839.GC29406@redhat.com> <4A09B964.5000905@redhat.com> <4A09BCBE.30509@fedoraproject.org> <4A09C3EE.3000207@redhat.com> <4A09C80C.7000600@fedoraproject.org> <20090512205219.GA7598@yoda.jdub.homelinux.org> <20090512212540.GE3457@localhost.localdomain> Message-ID: <4A09F052.7040602@fedoraproject.org> On 05/13/2009 02:55 AM, Paul W. Frields wrote: > Rahul, I'm not sure I understand what your purpose is in this > particular sub-thread. As far as I can see, everyone here is trying > their hardest, and succeeding, at Doing It Right, and your issue is > primarily that either you didn't see the announcement or don't have > time to read all the material personally. It is not that I don't have time. I really want to know about the project and when I looked for information, I couldn't find much. I wanted to know the leads for more information and I think there is room for some simple improvements that helps others understand the progress. This is not the same as being judgemental about the project itself. If I don't think the project is important, I wouldn't even bother asking in the first place. Rahul From pbrobinson at gmail.com Tue May 12 22:04:28 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 12 May 2009 23:04:28 +0100 Subject: koji breakage for F12 builds Message-ID: <5256d0b0905121504k4768401an741dd4d0bd5cf045@mail.gmail.com> Just tried building a new package and it seems that it breaks because xfce4-notifyd conflicts with notification-daemon.... wicked the new rawhide is broken before the old rawhide is done and dusted :-) Cheers, Peter http://koji.fedoraproject.org/koji/getfile?taskID=1351516&name=root.log DEBUG util.py:280: Executing command: /usr/bin/yum --installroot /var/lib/mock/dist-f12-build-451828-72881/root/ resolvedep 'gnome-icon-theme' 'gupnp-devel' 'gtk2-devel' 'glib2-devel >= 2.12' 'e2fsprogs-devel' 'gssdp-devel' 'gupnp-av-devel' 'desktop-file-utils' 'libsoup-devel' DEBUG util.py:256: 0:gnome-icon-theme-2.26.0-2.fc11.noarch DEBUG util.py:256: 0:gupnp-devel-0.12.7-1.fc12.x86_64 DEBUG util.py:256: 0:gtk2-devel-2.16.1-4.fc11.x86_64 DEBUG util.py:256: 0:glib2-devel-2.20.1-1.fc11.x86_64 DEBUG util.py:256: 0:e2fsprogs-devel-1.41.5-1.fc12.x86_64 DEBUG util.py:256: 0:gssdp-devel-0.6.4-3.fc11.x86_64 DEBUG util.py:256: 0:gupnp-av-devel-0.4-1.fc11.x86_64 DEBUG util.py:256: 0:desktop-file-utils-0.15-7.fc11.x86_64 DEBUG util.py:256: 0:libsoup-devel-2.26.1-1.fc11.x86_64 DEBUG util.py:319: Child returncode was: 0 DEBUG backend.py:554: /usr/bin/yum --installroot /var/lib/mock/dist-f12-build-451828-72881/root/ install 'gnome-icon-theme' 'gupnp-devel' 'gtk2-devel' 'glib2-devel >= 2.12' 'e2fsprogs-devel' 'gssdp-devel' 'gupnp-av-devel' 'desktop-file-utils' 'libsoup-devel' DEBUG util.py:280: Executing command: /usr/bin/yum --installroot /var/lib/mock/dist-f12-build-451828-72881/root/ install 'gnome-icon-theme' 'gupnp-devel' 'gtk2-devel' 'glib2-devel >= 2.12' 'e2fsprogs-devel' 'gssdp-devel' 'gupnp-av-devel' 'desktop-file-utils' 'libsoup-devel' DEBUG util.py:256: xfce4-notifyd-0.1.0-1.fc12.x86_64 from build has depsolving problems DEBUG util.py:256: --> xfce4-notifyd conflicts with notification-daemon DEBUG util.py:256: Error: xfce4-notifyd conflicts with notification-daemon DEBUG util.py:256: You could try using --skip-broken to work around the problem DEBUG util.py:256: You could try running: package-cleanup --problems DEBUG util.py:256: package-cleanup --dupes DEBUG util.py:256: rpm -Va --nofiles --nodigest DEBUG util.py:256: The program package-cleanup is found in the yum-utils package. DEBUG util.py:319: Child returncode was: 1 From mw_triad at users.sourceforge.net Tue May 12 22:47:51 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Tue, 12 May 2009 17:47:51 -0500 Subject: OpenOffice 3.1 In-Reply-To: References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <1241990992.3452.6.camel@localhost.localdomain> <6dc6523c0905101458l64811e65lb9f18216a4f93941@mail.gmail.com> <1242064968.2923.615.camel@adam.local.net> <1242072865.2923.670.camel@adam.local.net> <1242079541.3452.48.camel@localhost.localdomain> <1242080497.2923.676.camel@adam.local.net> <1242122940.1211.19.camel@gilboa-work-dev.localdomain> <1242143648.1211.32.camel@gilboa-work-dev.localdomain> <1242146510.2923.766.camel@adam.local.net> Message-ID: Kevin Kofler wrote: > Adam Williamson wrote: > It's true that inconsistency is bad, and that's the problem with the current > policy, but there's no better solution. At best, we can give more hints to > the maintainers, but there's no policy which works for all packages. > Hardcoded bureaucracy doesn't really work, in particular, the 2 "all or > nothing" solutions you propose: > >> This is why I say the only two policies that can really work optimally >> are "minimal necessary changes to fix strictly identified bugs and >> security flaws" or "update whatever you like". Either is valid, but both >> have distinct implications for the user experience, so we need to pick >> based on what user experience we want, and message that consistently so >> that users know what to expect. > > are both completely broken. The first turns Fedora into yet another "Debian > stable type" distribution: this seems to be what you're advocating, but > there are already several of those and Fedora would lose one of the main > things it is about (being always up to date) by endorsing such a policy. > The second basically turns all releases into Rawhide, which is > unfortunately unsuitable for daily use. A middle ground is needed, and > that's where the maintainer has to make a call. And this is why the policy > is as it is now. For what it's worth, I agree with Adam, to the extent that I read "work optimally" as "work without excessive friction in the community". Deviate from either one, and it becomes too much a judgment call, and people's judgment is going to vary, and you have a mess. That said... I also agree that "a middle ground is needed"*. Unfortunately, that means living with threads like this one is likely inevitable. (* Yes, Adam, even after reading your reply. I don't want /any/ kind of free-for-all. I want some general exercise of discretion. OTOH, I do think we need to be clear that we're not in the "bugfix-only" camp.) -- Matthew ENOWIT: .sig file for this machine not set up yet From awilliam at redhat.com Tue May 12 23:09:09 2009 From: awilliam at redhat.com (Adam Williamson) Date: Tue, 12 May 2009 16:09:09 -0700 Subject: OpenOffice 3.1 In-Reply-To: References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <1241990992.3452.6.camel@localhost.localdomain> <6dc6523c0905101458l64811e65lb9f18216a4f93941@mail.gmail.com> <1242064968.2923.615.camel@adam.local.net> <1242072865.2923.670.camel@adam.local.net> <1242079541.3452.48.camel@localhost.localdomain> <1242080497.2923.676.camel@adam.local.net> <1242122940.1211.19.camel@gilboa-work-dev.localdomain> <1242143648.1211.32.camel@gilboa-work-dev.localdomain> <1242146510.2923.766.camel@adam.local.net> Message-ID: <1242169749.2923.883.camel@adam.local.net> On Tue, 2009-05-12 at 17:47 -0500, Matthew Woehlke wrote: > For what it's worth, I agree with Adam, to the extent that I read "work > optimally" as "work without excessive friction in the community". > Deviate from either one, and it becomes too much a judgment call, and > people's judgment is going to vary, and you have a mess. > > That said... I also agree that "a middle ground is needed"*. > Unfortunately, that means living with threads like this one is likely > inevitable. > > (* Yes, Adam, even after reading your reply. I don't want /any/ kind of > free-for-all. I want some general exercise of discretion. OTOH, I do > think we need to be clear that we're not in the "bugfix-only" camp.) To be honest I'm more or less expecting that's where we'll end up, but I'm trying to make it extremely clear what the consequences are. :) Anything that claims to be in the middle ground is far, far, far more to the 'anything goes' side of the ledger than it is the 'really stable' side of the ledger. The *only* system that works for Aunt Flo is conservative updates, because the Aunt Flo-type user needs a system that works today how it worked yesterday. Aunt Flo is going to call you if her Internet button (that's what she calls the Firefox launcher) changes color. Or, y'know, moves. I don't recommend Fedora to Aunt Flo, I wouldn't install Fedora on systems owned by my personal Aunt Flo's (come on, everyone has some. Mine get Mandriva. Or, frankly, Windows. Yours might get Ubuntu. Doesn't matter.) I think that's fine. We don't need to be everything to everyone. But as long as we're going to wind up with an update system which allows anything but minimal fixes to be pushed as official updates, Fedora isn't going to be for Aunt Flo, and we need to be up front about that. We need to tell people that, if they want a quiet life, if they're installing on a non-geek friend's system, if they're running a server, they should use something more appropriate to their goals. And any argument on this list (or anywhere else) which relies on Aunt Flo-type users to support it should be shot down with extreme prejudice. Basically, if we're not caring about Aunt Flo, we should be consistent about that. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From naheemzaffar at gmail.com Tue May 12 23:36:45 2009 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Wed, 13 May 2009 00:36:45 +0100 Subject: OpenOffice 3.1 In-Reply-To: <1242169749.2923.883.camel@adam.local.net> References: <4A034FD0.40103@gnat.ca> <1242079541.3452.48.camel@localhost.localdomain> <1242080497.2923.676.camel@adam.local.net> <1242122940.1211.19.camel@gilboa-work-dev.localdomain> <1242143648.1211.32.camel@gilboa-work-dev.localdomain> <1242146510.2923.766.camel@adam.local.net> <1242169749.2923.883.camel@adam.local.net> Message-ID: <3adc77210905121636l5f42d05di23b6479873256b1a@mail.gmail.com> 2009/5/13 Adam Williamson > I don't recommend Fedora to Aunt Flo, I wouldn't install Fedora on > systems owned by my personal Aunt Flo's (come on, everyone has some. > Mine get Mandriva. Or, frankly, Windows. Yours might get Ubuntu. Doesn't > matter.) I think that's fine. We don't need to be everything to > everyone. But as long as we're going to wind up with an update system > which allows anything but minimal fixes to be pushed as official > updates, Fedora isn't going to be for Aunt Flo, and we need to be up > front about that. We need to tell people that, if they want a quiet > life, if they're installing on a non-geek friend's system, if they're > running a server, they should use something more appropriate to their > goals. And any argument on this list (or anywhere else) which relies on > Aunt Flo-type users to support it should be shot down with extreme > prejudice. Basically, if we're not caring about Aunt Flo, we should be > consistent about that. :) > But that is not always the case though - Even Ubuntu with its conservative updates policy has suffered by the addition of new bugs in them, and the users also suffer for existing bugs which are not fixed by bugfix updates. The "fedora way" may seem more cavalier from the outset and also has a greater chance to introduce instability, however it can also result in a *more stable* distribution over its life time. (as for bikeshedding being pointless, I remember an individual coming on here and bikeshedding about how the GUI software manager should work. I even ignored the discussion as I thought the concept of it preposterous. Move forward a couple of years and frontend package management (in Fedora atleast - I do not use other distributions but I assume they have not drunk the packagekit coolaide as deeply) has been improved far beyond the capabilities I imagined it would ever go. What is important is to try to get the complainers to scratch their own itch and if the itch affects enough people, it will be sufficiently scratched.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From awilliam at redhat.com Tue May 12 23:52:15 2009 From: awilliam at redhat.com (Adam Williamson) Date: Tue, 12 May 2009 16:52:15 -0700 Subject: OpenOffice 3.1 In-Reply-To: <3adc77210905121636l5f42d05di23b6479873256b1a@mail.gmail.com> References: <4A034FD0.40103@gnat.ca> <1242079541.3452.48.camel@localhost.localdomain> <1242080497.2923.676.camel@adam.local.net> <1242122940.1211.19.camel@gilboa-work-dev.localdomain> <1242143648.1211.32.camel@gilboa-work-dev.localdomain> <1242146510.2923.766.camel@adam.local.net> <1242169749.2923.883.camel@adam.local.net> <3adc77210905121636l5f42d05di23b6479873256b1a@mail.gmail.com> Message-ID: <1242172335.2923.891.camel@adam.local.net> On Wed, 2009-05-13 at 00:36 +0100, Naheem Zaffar wrote: > But that is not always the case though - Even Ubuntu with its > conservative updates policy has suffered by the addition of new bugs > in them, and the users also suffer for existing bugs which are not > fixed by bugfix updates. Sure. I don't claim Ubuntu to be the best implementation of anything much. ;) > The "fedora way" may seem more cavalier from the outset and also has a > greater chance to introduce instability, however it can also result in > a *more stable* distribution over its life time. Stable is a word that's often misused. In this case, the important sense of stable is "does the same stuff on Tuesday as it did on Monday" - even if the stuff it did on Monday was dumb. If you make it smarter on Tuesday, you've still changed it's behaviour, and the person or script who was expecting the behaviour from Monday is stuffed. > (as for bikeshedding being pointless, I remember an individual coming > on here and bikeshedding about how the GUI software manager should > work. I even ignored the discussion as I thought the concept of it > preposterous. Move forward a couple of years and frontend package > management (in Fedora atleast - I do not use other distributions but I > assume they have not drunk the packagekit coolaide as deeply) has been > improved far beyond the capabilities I imagined it would ever go. What > is important is to try to get the complainers to scratch their own > itch and if the itch affects enough people, it will be sufficiently > scratched.) In this case it's not really an 'itch' to be scratched, it's a fundamental question of Fedora's identity, which no one person can define or change on his or her own. If I could unilaterally declare "Fedora is a project to create a great stable operating system for ordinary people!" or "Fedora is a sandbox for the development of cool new software by the technologically knowledgeable!", great, I would. But I can't. I'm just noticing that there's a fundamental identity crisis between those two poles which affects rather a lot of issues in Fedora, and we all need to get to grips with it to be able to have a focused and coherent response to those issues. I suspect the majority would go for option B, and that's probably the most sensible place for Fedora to be. But we need clarity on that. In some ways we do a good job of this - I think, for instance, http://fedoraproject.org/wiki/Overview is pretty solid, and doesn't just say "if you're human, use Fedora!". But, for instance, quite a lot of Fedora people like to talk about the 'ten million users' number, which I don't think is very helpful if we're not about an operating system for ordinary users; it'd be better to talk about some metric for the useful *results* that come out of the Fedora community. And there are frequently threads in which people explicitly or implicitly claim that we should worry about the needs of 'ordinary users' or some such catchphrase. So it's not clear. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From christoph.wickert at googlemail.com Tue May 12 23:54:56 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Wed, 13 May 2009 01:54:56 +0200 Subject: koji breakage for F12 builds In-Reply-To: <5256d0b0905121504k4768401an741dd4d0bd5cf045@mail.gmail.com> References: <5256d0b0905121504k4768401an741dd4d0bd5cf045@mail.gmail.com> Message-ID: <1242172496.3569.15.camel@localhost.localdomain> Am Dienstag, den 12.05.2009, 23:04 +0100 schrieb Peter Robinson: > Just tried building a new package and it seems that it breaks because > xfce4-notifyd conflicts with notification-daemon.... wicked the new > rawhide is broken before the old rawhide is done and dusted :-) See https://fedorahosted.org/rel-eng/ticket/1788 xfce4-notifyd conflicts with notification-daemon because both provide /usr/share/dbus-1/services/org.freedesktop.Notifications.service For compatibility they both provide a virtual desktop-notification-daemon, but ATM the "Conflicts: xfce4-notifyd" is missing from the notification-daemon package. Filed as https://bugzilla.redhat.com/show_bug.cgi?id=500513 > http://koji.fedoraproject.org/koji/getfile?taskID=1351516&name=root.log The strange thing about this log: I don't see it installing notification-daemon. So where is the problem? /me is confused Christoph From jwboyer at gmail.com Wed May 13 00:33:59 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 12 May 2009 20:33:59 -0400 Subject: Update -> no sound In-Reply-To: <4A09EF5C.3020508@fedoraproject.org> References: <1242146328.3147.181.camel@dimi.lattica.com> <1242149935.3147.191.camel@dimi.lattica.com> <4A09B8E6.5060904@fedoraproject.org> <20090512175839.GC29406@redhat.com> <4A09B964.5000905@redhat.com> <4A09BCBE.30509@fedoraproject.org> <4A09C3EE.3000207@redhat.com> <4A09C80C.7000600@fedoraproject.org> <20090512205219.GA7598@yoda.jdub.homelinux.org> <4A09EF5C.3020508@fedoraproject.org> Message-ID: <625fc13d0905121733r4087197fl5fd12062344e50cd@mail.gmail.com> On Tue, May 12, 2009 at 5:51 PM, Rahul Sundaram wrote: > On 05/13/2009 02:22 AM, Josh Boyer wrote: > >> >> Yes, they are. ?I've been asked several questions myself. ?Spot maintains >> an ungodly number of packages. ?I think they're getting plenty of input. > > Fedora Community as a project has no connection to the number of > packages Spot maintains or the input he is getting on those packages. I > have no idea why you bring that up but If the burden is too large, then > I suggest getting co-maintainers. Since you politely cut the part of your reply I was responding to, I'll clarify why I bring up Spot. You asked "but how much input are you getting input from Fedora maintainers whose job this is supposed to make easier?" Spot _is_ one of those maintainers whose job this is supposed to make easier. Having him provide input to the moksha/Fedora Community is valuable, made more so by the large number of packages he maintains. Simply an instance example of what you asked. josh From petersen at redhat.com Wed May 13 01:08:31 2009 From: petersen at redhat.com (Jens Petersen) Date: Tue, 12 May 2009 21:08:31 -0400 (EDT) Subject: Revise Inclustion of IBUS by default - Re: Final Reminder: F11 Features Not at 100% - In-Reply-To: <18385312.363721242176690326.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <965485062.363811242176911554.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Sorry for the late reply - I just saw this. ----- "Steven James Drinnan" wrote: > Like I have said previously please do not make IBUS default. I do not > believe it is mature enough. I.E Scim supports all the major input > methods such as Quick. Quick is included in the ibus-table-cangjie package in F11. Jens From petersen at redhat.com Wed May 13 01:10:01 2009 From: petersen at redhat.com (Jens Petersen) Date: Tue, 12 May 2009 21:10:01 -0400 (EDT) Subject: Ibus - Sorry In-Reply-To: <1240490087.3846.2.camel@laptap.myhome> Message-ID: <496489658.363901242177001499.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> ----- "Steven James Drinnan" wrote: > But I missed it first because it is not included by default in the > live CD. Maybe something to consider? It is. Do you mean when you start an English desktop in Live? Jens From loupgaroublond at gmail.com Wed May 13 01:10:23 2009 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Tue, 12 May 2009 21:10:23 -0400 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A092FDC.3010200@TheTroubleshooters.dk> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A092FDC.3010200@TheTroubleshooters.dk> Message-ID: <7f692fec0905121810m1b99decxafa401cbf9bfc958@mail.gmail.com> 2009/5/12 Michael Nielsen : >> I'm sure there is a place for this kind of debate but it is SURELY not the >> devel list. >> >> > > Where then? > > The problem is logically related to the development path that Linux is > taking, somewhere someone must have a plan, for where Fedora is going. > > If there isn't a plan for Fedora development, then that is probably the > reason for the problems that I am concerned about. ? As the problems that > I'm pointing out here, could very well be the effect of chaotic development. Funny how this chaotic development led to the creation of the Linux Kernel, the tool chains that surround it and the vast market it has. Even funnier is how a number of very very large corporations are heavily invested in Linux, particularly Red Hat's offerings, derivatives, and Fedora. What's out right hilarious is that these CEOs are making critical decisions about their companies based on this chaotic development that has no planned future. Seriously, it's 2009. Can we put this idea to rest, that software needs very strong plans in order to succeed. -Yaakov From seandarcy2 at gmail.com Wed May 13 01:25:20 2009 From: seandarcy2 at gmail.com (sean darcy) Date: Tue, 12 May 2009 21:25:20 -0400 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: References: <4A0814ED.60205@redhat.com> Message-ID: Matej Cepl wrote: > On 2009-05-11, 20:11 GMT, sean darcy wrote: >> With 3.x, I couldn't send mail ( reply or write ) to >> newsgroups, including this one. With just downgrading >> - exactly the same setup - it works. >> >> See https://bugzilla.redhat.com/show_bug.cgi?id=493738 > > Except you never told me how to reproduce it, so it > CLOSED/WORKSFORME. Please, don't use it as a reason against TB. > > Mat?j > Still doesn't work on my machine. sean From rc040203 at freenet.de Wed May 13 02:12:39 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 13 May 2009 04:12:39 +0200 Subject: SPARC Status (Was Re: Secondary Architecture Status?) In-Reply-To: References: <1241911202.24436.81.camel@macbook.infradead.org> <4A0862F1.2030608@redhat.com> <20090511185147.GA3256@yoda.jdub.homelinux.org> <1242071724.2923.656.camel@adam.local.net> <4A0909BB.4030807@freenet.de> Message-ID: <4A0A2C97.3010403@freenet.de> Matthew Woehlke wrote: > Ralf Corsepius wrote: >> It likely is something worth looking into, but based on my experiences >> with Fedora on my netbook, I am having doubts compiler optimizations >> alone are worth a "secondary arch". >> >> At least on my netbook, neither "speed" or "space" (mine has a disk) >> are actual problems. > > Is for me! :-) But I don't think -Os is the solution; the problems tend > to be long dep-chains and data (and especially, the intersection of > both*). Do I understand correctly, your issue is disk-space? Are you installing to a (slow?) small solid state disk? How big is it? However, I would not understand issues related to cpu-speed, because my own netbook (Intel(R) Atom(TM) CPU N270 at 1.60GHz, 1 GB RAM) easily outperforms older machines I have around. Ralf From dgboles at comcast.net Wed May 13 02:28:58 2009 From: dgboles at comcast.net (David) Date: Tue, 12 May 2009 22:28:58 -0400 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: References: <4A0814ED.60205@redhat.com> Message-ID: <4A0A306A.90106@comcast.net> On 5/12/2009 9:25 PM, sean darcy wrote: > Matej Cepl wrote: >> On 2009-05-11, 20:11 GMT, sean darcy wrote: >>> With 3.x, I couldn't send mail ( reply or write ) to newsgroups, >>> including this one. With just downgrading - exactly the same setup - >>> it works. >>> >>> See https://bugzilla.redhat.com/show_bug.cgi?id=493738 >> >> Except you never told me how to reproduce it, so it CLOSED/WORKSFORME. >> Please, don't use it as a reason against TB. >> >> Mat?j >> > Still doesn't work on my machine. Maybe you should send your machine to Mat?j so that he can see this problem and perhaps correct it? That might work since no one else has said anything that is similar to your problem. -- David From petersen at redhat.com Wed May 13 04:05:56 2009 From: petersen at redhat.com (Jens Petersen) Date: Wed, 13 May 2009 00:05:56 -0400 (EDT) Subject: 2009-05-14 - Fedora Test Day - IBus input method In-Reply-To: Message-ID: <1899006583.371871242187556489.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> ----- "Matej Cepl" wrote: > I had two problems with scim (and these were the reasons I always > removed it immediately after installation): (scim should not be noticeable if it is not running.) > a) it conflicted with Compose key > b) it worked poorly (not sure how) with Czech layout ... and > I heard it from other people with somewhere in between layouts > ... non-ASCII, but also non-real-IM-needed. > > Should (at least theoretically) these work in iBus? It would be great if you could post some test-cases. Ideally in bugzilla or even we could mention it in the test event. As far as possible we want ibus to work for all users. So if it is breaking stuff we would really like to know about it. :) > And how does it work with relation to Gnome keyboard layouts? As far as config interaction with xkb is concerned I think there is no change compared to scim here, we haven't gotten that far enough to allow tighter integration with gnome yet. Jens From poelstra at redhat.com Wed May 13 04:15:37 2009 From: poelstra at redhat.com (John Poelstra) Date: Tue, 12 May 2009 21:15:37 -0700 Subject: Upcoming Bugzilla Changes Message-ID: <4A0A4969.6070207@redhat.com> Summer is almost here and things are about to heat up (at least here in the Northern Hemisphere!) with the release of Fedora 11. With each new Fedora release comes some Bugzilla housekeeping. This e-mail is designed to let you know about two things happening around May 26, 2009 (Fedora 11 day) and what you need to do, if anything. (1) We will be automatically changing the version all rawhide bugs to Fedora 11. This will result in regular bugs reported against rawhide during the Fedora 11 development cycle being changed to version '11' instead of their current assignment, 'rawhide'. This is done in order to more accurately tell where in the lineage of releases the bug was last reported because over time 'rawhide' becomes ambiguous. Note that this procedure does not apply to bugs that are against component 'Package Review' or bugs that have the 'FutureFeature' or 'Tracking' keywords set. They will stay open as rawhide bugs indefinitely. If you do not want your bugs changed to version '11', add the FutureFeature keyword. If you need help changing a large amount of bugs manually, we'd be glad to help. Stop by #fedora-bugzappers on irc.freenode.net and we'll help you. (2) All bugs for upcoming EOL releases (at this point, Fedora 9) will get a comment on release day, explaining that one month of maintenance remains. These bugs must move to a later version if still applicable or they will be automatically closed in one month with a resolution of WONTFIX. More about these processes is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping Thanks for reading, John (for the Bug Triage team) _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From phuang at redhat.com Wed May 13 05:03:48 2009 From: phuang at redhat.com (Peng Huang) Date: Wed, 13 May 2009 13:03:48 +0800 Subject: Fwd: 2009-05-14 - Fedora Test Day - IBus input method In-Reply-To: <2042568271.371931242187603548.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> References: <2042568271.371931242187603548.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <4A0A54B4.2070403@redhat.com> > ["Followup-To:" header set to gmane.linux.redhat.fedora.testers.] > On 2009-05-11, 13:59 GMT, Liam wrote: > >> > iBus is designed to improve a number of deficiencies of scim: >> > > I had two problems with scim (and these were the reasons I always > removed it immediately after installation): > > a) it conflicted with Compose key > What's the detail of this problem? > b) it worked poorly (not sure how) with Czech layout ... and > I heard it from other people with somewhere in between layouts > ... non-ASCII, but also non-real-IM-needed. > > I think most ibus engines can only work with us-en keyboard layout too. But we have planed to integrate ibus with xkb. But this feature is for f12 or RHEL 6. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmatilai at laiskiainen.org Wed May 13 06:13:01 2009 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Wed, 13 May 2009 09:13:01 +0300 (EEST) Subject: Fedora (Linux) is Destroying it self In-Reply-To: References: <4A082E70.7030904@TheTroubleshooters.dk> <4A086703.1080906@amiga-hardware.com> <4A094EC4.9030506@TheTroubleshooters.dk> <1242125395.13505.449.camel@breeves.fab.redhat.com> <4A0988DC.8030103@freenet.de> <4A098F11.4080008@freenet.de> Message-ID: On Tue, 12 May 2009, Kevin Kofler wrote: > Ralf Corsepius wrote: >> Well, it had worked for ages. > > "it had worked" != sane > "it had worked" != compliant to guidelines > "it had worked" != it's not broken > > Many things happen to "work", but are still completely broken. >From rpm POV it's perfectly legal for any number of packages to share identical files, and that still works. What doesn't work is sharing files between packages using different file hash algorithm, so if you need to share across Centos >= 3 <-> Fedora >= 11 you need to build the package for lowest common denominator, meaning md5 file hashes. Fedora 11 changes the default algorithm from md5 to sha256 in redhat-rpm-config, producing packages that are incompatible with rpm < 4.6.0 but specs and macro configuration can override that. Whether it's against Fedora guidelines is another question, but since this was about a package from a 3rd party repository... - Panu - From mschwendt at gmail.com Wed May 13 06:43:02 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 13 May 2009 08:43:02 +0200 Subject: koji breakage for F12 builds In-Reply-To: <1242172496.3569.15.camel@localhost.localdomain> References: <5256d0b0905121504k4768401an741dd4d0bd5cf045@mail.gmail.com> <1242172496.3569.15.camel@localhost.localdomain> Message-ID: <20090513084302.1fb20a62@faldor.intranet> On Wed, 13 May 2009 01:54:56 +0200, Christoph wrote: > Am Dienstag, den 12.05.2009, 23:04 +0100 schrieb Peter Robinson: > > Just tried building a new package and it seems that it breaks because > > xfce4-notifyd conflicts with notification-daemon.... wicked the new > > rawhide is broken before the old rawhide is done and dusted :-) > > See https://fedorahosted.org/rel-eng/ticket/1788 > > xfce4-notifyd conflicts with notification-daemon because both provide > /usr/share/dbus-1/services/org.freedesktop.Notifications.service > > For compatibility they both provide a virtual > desktop-notification-daemon, but ATM the "Conflicts: xfce4-notifyd" is > missing from the notification-daemon package. Filed as > https://bugzilla.redhat.com/show_bug.cgi?id=500513 > > > http://koji.fedoraproject.org/koji/getfile?taskID=1351516&name=root.log > > The strange thing about this log: I don't see it installing > notification-daemon. So where is the problem? > > /me is confused > Christoph The output of the yum resolvedep step doesn't list xfce4-notifyd either. I don't have my notes about koji's static repos here, so I cannot find and repoquery the F-12 repodata to find out --whatrequires several of these "Provides", but... notification-daemon http://koji.fedoraproject.org/koji/rpminfo?rpmID=1199322 Provides config(notification-daemon) = 0.4.0-3.fc11 desktop-notification-daemon libstandard.so()(64bit) notification-daemon = 0.4.0-3.fc11 notification-daemon(x86-64) = 0.4.0-3.fc11 notify-daemon Can you rule out that anything in the dependency-chain pulls in notification-daemon _and_ xfce4-notify due to competing Provides? E.g. notify-daemon and desktop-notification-daemon and the package name itself, notification-daemon. That's three things one can require to get the same package. There's the risk that some dependencies are on virtual Provides while others are on package names. How are dependencies resolved in case explicit Conflicts are found? Does Yum replace equivalent packages (which provide the same thing) automatically until a transaction set no longer suffers from conflicts? From mcepl at redhat.com Wed May 13 07:09:21 2009 From: mcepl at redhat.com (Matej Cepl) Date: Wed, 13 May 2009 09:09:21 +0200 Subject: Fwd: 2009-05-14 - Fedora Test Day - IBus input method References: <2042568271.371931242187603548.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <4A0A54B4.2070403@redhat.com> Message-ID: <1a8qd6-iq8.ln1@ppp1053.in.ipex.cz> On 2009-05-13, 05:03 GMT, Peng Huang wrote: >> a) it conflicted with Compose key >> > What's the detail of this problem? I haven?t managed to have cs_CZ layout AND Compose key active in the same time. As you can see from this reply, I like ?curly quotes? and similar stuff, but I need Czech keyboard layout as well. >> b) it worked poorly (not sure how) with Czech layout ... and >> I heard it from other people with somewhere in between layouts >> ... non-ASCII, but also non-real-IM-needed. >> > I think most ibus engines can only work with us-en keyboard layout too. > But we have planed to integrate ibus with xkb. But this feature is for > f12 or RHEL 6. Translated: I shouldn't bother with iBus at all. Is that correct? Mat?j From markmc at redhat.com Wed May 13 09:00:46 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 13 May 2009 10:00:46 +0100 Subject: best practices for updates in stable releases (was: Re: OpenOffice 3.1) In-Reply-To: <1242145782.3452.108.camel@localhost.localdomain> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <4A05B234.2020608@leemhuis.info> <1241890311.2886.63.camel@localhost.localdomain> <1242054913.3452.16.camel@localhost.localdomain> <1242144256.21430.4.camel@blaa> <1242145782.3452.108.camel@localhost.localdomain> Message-ID: <1242205246.31003.17.camel@blaa> On Tue, 2009-05-12 at 09:29 -0700, Jesse Keating wrote: > On Tue, 2009-05-12 at 17:04 +0100, Mark McLoughlin wrote: > > rel-eng refuses to push updates which are blatantly ignoring the > > guidelines? > > > > i.e. follow a similar process to what we during the freeze > > It's hard for one person to timely review hundreds of update requests to > figure out which are ignoring the guidelines and which aren't. Agreed, it shouldn't fall to one person. e.g. during the freeze, I noticed at least spot, notting, warren, jwb, rdieter and yourself reviewing tag requests. I'm sure others would be happy to help too, I know I would. Cheers, Mark. From drago01 at gmail.com Wed May 13 09:05:29 2009 From: drago01 at gmail.com (drago01) Date: Wed, 13 May 2009 11:05:29 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A094342.7000805@TheTroubleshooters.dk> References: <4A082E70.7030904@TheTroubleshooters.dk> <7f692fec0905110735tf8a1bd4u7a71d85f6de7f14b@mail.gmail.com> <4A094342.7000805@TheTroubleshooters.dk> Message-ID: On Tue, May 12, 2009 at 11:37 AM, Michael Nielsen wrote: > Personally I just don't use those features, what I'm trying to do here is to > get people to > think about what is happening, because, I can see a lot of feature forking > in the system, > which will make the system extremely confusing for people to start using > Linux. > > All that is really needed is to mount things properly, and logically. eg > /home/mike/mnt1 > instead of /home/mike/.gvfs/blablah.. which is a hidden file. What did we have before ? Either you mount stuff via gnome-vfs which is ONLY accessable via gnome-vfs using apps or you mounted the stuff by hand (terminal) or via fstab (which still works and is fully supported). Now you can mount stuff via gvfs (which any app can access it) + it is integrated into the gui tools or you mount it via fstab or by hand (terminal). So what did change? We improved the GUI integrated part to work with every app without having it to be aware of it *without* changing the way that always worked. How is this wrong? From mschwendt at gmail.com Wed May 13 09:13:43 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 13 May 2009 11:13:43 +0200 Subject: Breaking deps deliberately Message-ID: <20090513111343.4d79d48f@faldor.intranet> https://admin.fedoraproject.org/updates/F10/FEDORA-2009-4696 Is it permitted to deliberately break deps in stable updates? To me it sounds as if I'm in the wrong movie. :( From rjones at redhat.com Wed May 13 09:28:52 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 13 May 2009 10:28:52 +0100 Subject: Breaking deps deliberately In-Reply-To: <20090513111343.4d79d48f@faldor.intranet> References: <20090513111343.4d79d48f@faldor.intranet> Message-ID: <20090513092852.GA22337@amd.home.annexia.org> On Wed, May 13, 2009 at 11:13:43AM +0200, Michael Schwendt wrote: > https://admin.fedoraproject.org/updates/F10/FEDORA-2009-4696 > > Is it permitted to deliberately break deps in stable updates? > To me it sounds as if I'm in the wrong movie. :( It's a brand-new package. No one will accidentally install it. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From pertusus at free.fr Wed May 13 09:37:19 2009 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 13 May 2009 11:37:19 +0200 Subject: Breaking deps deliberately In-Reply-To: <20090513092852.GA22337@amd.home.annexia.org> References: <20090513111343.4d79d48f@faldor.intranet> <20090513092852.GA22337@amd.home.annexia.org> Message-ID: <20090513093719.GB3115@free.fr> On Wed, May 13, 2009 at 10:28:52AM +0100, Richard W.M. Jones wrote: > On Wed, May 13, 2009 at 11:13:43AM +0200, Michael Schwendt wrote: > > https://admin.fedoraproject.org/updates/F10/FEDORA-2009-4696 > > > > Is it permitted to deliberately break deps in stable updates? > > To me it sounds as if I'm in the wrong movie. :( > > It's a brand-new package. No one will accidentally install it. You can install all the packages. -- Pat From xjakub at fi.muni.cz Wed May 13 09:47:44 2009 From: xjakub at fi.muni.cz (Milos Jakubicek) Date: Wed, 13 May 2009 11:47:44 +0200 Subject: Breaking deps deliberately In-Reply-To: <20090513092852.GA22337@amd.home.annexia.org> References: <20090513111343.4d79d48f@faldor.intranet> <20090513092852.GA22337@amd.home.annexia.org> Message-ID: <4A0A9740.8060803@fi.muni.cz> Dne 13.5.2009 11:28, Richard W.M. Jones wrote: > On Wed, May 13, 2009 at 11:13:43AM +0200, Michael Schwendt wrote: >> https://admin.fedoraproject.org/updates/F10/FEDORA-2009-4696 >> >> Is it permitted to deliberately break deps in stable updates? >> To me it sounds as if I'm in the wrong movie. :( > > It's a brand-new package. No one will accidentally install it. > > Rich. > This is really not an argument, the update should be purged from the repository asap. Filed the appropriate request to rel-eng: https://fedorahosted.org/rel-eng/ticket/1798 Milos From rjones at redhat.com Wed May 13 09:58:54 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 13 May 2009 10:58:54 +0100 Subject: Breaking deps deliberately In-Reply-To: <4A0A9740.8060803@fi.muni.cz> References: <20090513111343.4d79d48f@faldor.intranet> <20090513092852.GA22337@amd.home.annexia.org> <4A0A9740.8060803@fi.muni.cz> Message-ID: <20090513095814.GA22408@amd.home.annexia.org> I've discussed again backporting the required feature to qemu into Fedora 10 and it seems like we should be able to do this, so the broken dep will no longer be required. Keep calm and carry on ... Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From ml at kiewel-online.ch Wed May 13 10:09:20 2009 From: ml at kiewel-online.ch (Uwe Kiewel) Date: Wed, 13 May 2009 12:09:20 +0200 Subject: fedora-release-11-1 In-Reply-To: <20090512092736.4a3b62bc@ohm.scrye.com> References: <1242093567.3452.87.camel@localhost.localdomain> <4A09217F.3010200@kiewel-online.ch> <20090512092736.4a3b62bc@ohm.scrye.com> Message-ID: <4A0A9C50.3090205@kiewel-online.ch> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kevin Fenzi wrote: > On Tue, 12 May 2009 09:13:03 +0200 > Uwe Kiewel wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi, >> >> so what do I have to do to be on F11? >> >> I did my last update from rawhide on Monday, 2009-10-05, at about 9 >> pm UTC. > > https://fedoraproject.org/wiki/Upgrading_from_pre-release_to_final > Should have the answers. ;) > Thanks a lot. Uwe -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iQIcBAEBAgAGBQJKCpxQAAoJEEJXG7BUuynnYckP/jh4/A2W3t0Nh076XSdY5idJ IJUHy0KDEvyfZ5FeB334QyHJUeMdm1nGoToaSXxCycALYsMxmo8fBaw05JRmmEPy GSzANT57xN2IIq1YECS4ZL/w0UtJYaLHqnYGusoRXTfB+3VUD08qqiXv5hTp+8SO meQA3MYU4xFCq4kJkdbC/HE2DcXowHazOAx5GzNAdrGQ0mkHAN5O0IL3WLPFa555 og4jN6wmc2A45o61V99w/w7bwxYY+kAHiEjJ+vZvgoDItGJnZEZgofnp9lJYAbnu NMhAzTvMPh10UMR6lmKNN1wCopiFPK1BIbhOQ5GxZPHQ1LjYTGmL/LLAfVpiecJF gmK8Rc0FiQWbtrG2PDuOw38WoEGY2cyMufwUBNy6ybBXqiG/FQMSdm1ha6wfgk+Y WlArGiOko0sVq5L6yv3s7/zClR7+Bp66RICTrXGMWK2aQu8Rqe5Wj8AoHsFfaVHe Yz74GSynuOYG8vXYMC4aHhkeA1j+N4Ni4ZnxllBALtzIBPNU8i4LQ3wDzyAtObrD 9e+eQ/4sabdIULjtdOHmMwzm4k3b1x3dukw9Owe6mAcg9bu4mrRcds/2gOcTsleg T1K62bxavRQVujg6wnVdVNuTf0UwV7ObLD7I5lxR3Rj1UFSBKDNEoHyC7rpKWuia JqcXZSD5RmMOBESFEnSs =Z4xj -----END PGP SIGNATURE----- From mcepl at redhat.com Wed May 13 10:15:29 2009 From: mcepl at redhat.com (Matej Cepl) Date: Wed, 13 May 2009 12:15:29 +0200 Subject: OpenOffice 3.1 References: <4A034FD0.40103@gnat.ca> <1242079541.3452.48.camel@localhost.localdomain> <1242080497.2923.676.camel@adam.local.net> <1242122940.1211.19.camel@gilboa-work-dev.localdomain> <1242143648.1211.32.camel@gilboa-work-dev.localdomain> <1242146510.2923.766.camel@adam.local.net> <1242169749.2923.883.camel@adam.local.net> <3adc77210905121636l5f42d05di23b6479873256b1a@mail.gmail.com> <1242172335.2923.891.camel@adam.local.net> Message-ID: <17jqd6-d8i.ln1@ppp1053.in.ipex.cz> On 2009-05-12, 23:52 GMT, Adam Williamson wrote: > In this case it's not really an 'itch' to be scratched, it's a > fundamental question of Fedora's identity, which no one person can > define or change on his or her own. If I could unilaterally declare > "Fedora is a project to create a great stable operating system for > ordinary people!" or "Fedora is a sandbox for the development of cool > new software by the technologically knowledgeable!", great, I would. But > I can't. I'm just noticing that there's a fundamental identity crisis > between those two poles which affects rather a lot of issues in Fedora, > and we all need to get to grips with it to be able to have a focused and > coherent response to those issues. Well, problem I have with declaring Fedora geek-only is that I would like to have something to install for my parents/wife/geek-impaired friends. And I really don't want to install them Ubuntu -- not only because I have my doubts about its quality, but also because I would prefer them to feed with their input relevant for our stuff, and frankly because I don't want to keep in my poor mind both /etc/network/interfaces and /etc/sysconfig/network-scripts/*-cfg ;-). Currently my options are Fedora (last released just with updates) and CentOS. I tend to think more and more about CentOS for such cases, but I would really like give them something more recent and something which would directly feed into Fedora. Oh well, Mat?j From denis at poolshark.org Wed May 13 10:36:11 2009 From: denis at poolshark.org (Denis Leroy) Date: Wed, 13 May 2009 12:36:11 +0200 Subject: gstreamer-properties (was Re: Update -> no sound) In-Reply-To: <1242148907.25471.1644.camel@cookie.hadess.net> References: <1242146328.3147.181.camel@dimi.lattica.com> <20090512165559.GA19474@tango.0pointer.de> <1242148907.25471.1644.camel@cookie.hadess.net> Message-ID: <4A0AA29B.9010502@poolshark.org> On 05/12/2009 07:21 PM, Bastien Nocera wrote: > Or launch gstreamer-properties on the command-line. autoaudiosink should > work just as well, and should pick up pulsesink as its first choice. Speaking of which, why is gstreamer-properties hidden from the main menu ? > grep NoDisplay /usr/share/applications/gstreamer-properties.desktop NoDisplay=true From christoph.wickert at googlemail.com Wed May 13 10:48:21 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Wed, 13 May 2009 12:48:21 +0200 Subject: Breaking deps deliberately In-Reply-To: <20090513092852.GA22337@amd.home.annexia.org> References: <20090513111343.4d79d48f@faldor.intranet> <20090513092852.GA22337@amd.home.annexia.org> Message-ID: <1242211701.3704.1.camel@localhost.localdomain> Am Mittwoch, den 13.05.2009, 10:28 +0100 schrieb Richard W.M. Jones: > On Wed, May 13, 2009 at 11:13:43AM +0200, Michael Schwendt wrote: > > https://admin.fedoraproject.org/updates/F10/FEDORA-2009-4696 > > > > Is it permitted to deliberately break deps in stable updates? > > To me it sounds as if I'm in the wrong movie. :( > > It's a brand-new package. No one will accidentally install it. I could say the same for xfce4-notifyd, but that doesn't change the fact that it causes broken deps on the buildsys and thus makes builds fail. > Rich. Regards, Christoph From christoph.wickert at googlemail.com Wed May 13 11:15:24 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Wed, 13 May 2009 13:15:24 +0200 Subject: koji breakage for F12 builds In-Reply-To: <20090513084302.1fb20a62@faldor.intranet> References: <5256d0b0905121504k4768401an741dd4d0bd5cf045@mail.gmail.com> <1242172496.3569.15.camel@localhost.localdomain> <20090513084302.1fb20a62@faldor.intranet> Message-ID: <1242213324.3704.8.camel@localhost.localdomain> Am Mittwoch, den 13.05.2009, 08:43 +0200 schrieb Michael Schwendt: > On Wed, 13 May 2009 01:54:56 +0200, Christoph wrote: > > > Am Dienstag, den 12.05.2009, 23:04 +0100 schrieb Peter Robinson: > > > Just tried building a new package and it seems that it breaks because > > > xfce4-notifyd conflicts with notification-daemon.... wicked the new > > > rawhide is broken before the old rawhide is done and dusted :-) > > > > See https://fedorahosted.org/rel-eng/ticket/1788 > > > > xfce4-notifyd conflicts with notification-daemon because both provide > > /usr/share/dbus-1/services/org.freedesktop.Notifications.service > > > > For compatibility they both provide a virtual > > desktop-notification-daemon, but ATM the "Conflicts: xfce4-notifyd" is > > missing from the notification-daemon package. Filed as > > https://bugzilla.redhat.com/show_bug.cgi?id=500513 > > > > > http://koji.fedoraproject.org/koji/getfile?taskID=1351516&name=root.log > > > > The strange thing about this log: I don't see it installing > > notification-daemon. So where is the problem? > > > > /me is confused > > Christoph > > The output of the yum resolvedep step doesn't list xfce4-notifyd either. > > I don't have my notes about koji's static repos here, so I cannot > find and repoquery the F-12 repodata to find out --whatrequires several > of these "Provides", but... > > notification-daemon > http://koji.fedoraproject.org/koji/rpminfo?rpmID=1199322 > > Provides > config(notification-daemon) = 0.4.0-3.fc11 > desktop-notification-daemon > libstandard.so()(64bit) > notification-daemon = 0.4.0-3.fc11 > notification-daemon(x86-64) = 0.4.0-3.fc11 > notify-daemon > > Can you rule out that anything in the dependency-chain pulls in > notification-daemon _and_ xfce4-notify due to competing Provides? How would I check that? > E.g. notify-daemon and desktop-notification-daemon and the package name > itself, notification-daemon. I think the problem is, that some packages notification-deamon instead of (virtual) desktop-notification-deamon: # repoquery --repoid rawhide --whatrequires notification-daemon gnome-bluetooth-0:2.27.5-1.fc11.i586 notify-python-0:0.1.1-6.fc11.i586 notification-daemon-engine-nodoka-0:0.1.0-6.fc11.i586 system-config-printer-0:1.1.7-1.fc11.i586 ibus-0:1.1.0.20090423-1.fc11.i586 I'm going to file bugs against these packages except notification-daemon-engine-nodoka, because it only works with notification-daemon. Regards, Christoph From kevin.kofler at chello.at Wed May 13 12:28:53 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 13 May 2009 14:28:53 +0200 Subject: Ibus - Sorry References: <1240490087.3846.2.camel@laptap.myhome> <496489658.363901242177001499.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: Jens Petersen wrote: > ----- "Steven James Drinnan" wrote: >> But I missed it first because it is not included by default in the >> live CD. Maybe something to consider? > > It is. Do you mean when you start an English desktop in Live? It depends on which live CD. It's not included on the KDE live CD because there's no room for it (and because you have to post-install support for non-English languages anyway because there's no way we can fit the huge kde-l10n-* packages ? the KDE live CD comes with the fonts so you can view web pages in most languages, but that's as far as i18n support goes), sorry. Kevin Kofler From skvidal at fedoraproject.org Wed May 13 12:33:22 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 13 May 2009 08:33:22 -0400 (EDT) Subject: Breaking deps deliberately In-Reply-To: <20090513111343.4d79d48f@faldor.intranet> References: <20090513111343.4d79d48f@faldor.intranet> Message-ID: On Wed, 13 May 2009, Michael Schwendt wrote: > https://admin.fedoraproject.org/updates/F10/FEDORA-2009-4696 > > Is it permitted to deliberately break deps in stable updates? > To me it sounds as if I'm in the wrong movie. :( +1. Creating broken deps when you know they won't be corrected should not be allowed. -sv From kevin.kofler at chello.at Wed May 13 12:42:55 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 13 May 2009 14:42:55 +0200 Subject: OpenOffice 3.1 References: <4A034FD0.40103@gnat.ca> <1242079541.3452.48.camel@localhost.localdomain> <1242080497.2923.676.camel@adam.local.net> <1242122940.1211.19.camel@gilboa-work-dev.localdomain> <1242143648.1211.32.camel@gilboa-work-dev.localdomain> <1242146510.2923.766.camel@adam.local.net> <1242169749.2923.883.camel@adam.local.net> <3adc77210905121636l5f42d05di23b6479873256b1a@mail.gmail.com> Message-ID: Naheem Zaffar wrote: > But that is not always the case though - Even Ubuntu with its conservative > updates policy has suffered by the addition of new bugs in them, and the > users also suffer for existing bugs which are not fixed by bugfix updates. > > The "fedora way" may seem more cavalier from the outset and also has a > greater chance to introduce instability, however it can also result in a > *more stable* distribution over its life time. +1 Kernel bug in Ubuntu => You're stuck with it for the next 6 months. Oh, and it's not just Ubuntu. At least they release often. In Debian stable, you're stuck with it for a couple years! Kernel bug in Fedora => Chances are the next update from the kernel stable branch a few days later fixes it, or if not, chances are the next rebase to the next kernel a few weeks later fixes it. Kevin Kofler From kevin.kofler at chello.at Wed May 13 12:55:04 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 13 May 2009 14:55:04 +0200 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 References: <4A0814ED.60205@redhat.com> <4A09B8FE.4040904@cygnusx-1.org> <4A09C018.4060906@cygnusx-1.org> <4A09CBE4.4020807@cygnusx-1.org> Message-ID: Nathan Grennan wrote: > I understand, but on the other hand does Fedora want a dozen bug > reports over Thunderbird being useless, because of a crappy default? The problem is that Fedora can't change anything in Thunderbird (nor Firefox) without upstream buy-in because the maintainer refuses to rename the programs and thus we're bound by Mozilla's strict (and IMHO completely unreasonable and unacceptable in the Free Software world) trademark policy. I'm really fed up of all the special treatment Mozilla is getting over this, for example the xulrunner/firefox/thunderbird stack is now the ONLY one excluded from provenpackager commits, if all projects worked like this (i.e. required upstream's approval for every single patch), Fedora would be completely unmaintainable. I really don't see why we don't just rename Firefox and Thunderbird like Debian is doing. (Well, I think I see it ? conflict of interest anyone? (*) ? but I don't see that as being a valid reason.) (*) check who the primary maintainer of Firefox and Thunderbird in Fedora is and who he's involved with, draw your own conclusions... Kevin Kofler From sundaram at fedoraproject.org Wed May 13 13:00:21 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 13 May 2009 18:30:21 +0530 Subject: Update -> no sound In-Reply-To: <625fc13d0905121733r4087197fl5fd12062344e50cd@mail.gmail.com> References: <1242146328.3147.181.camel@dimi.lattica.com> <1242149935.3147.191.camel@dimi.lattica.com> <4A09B8E6.5060904@fedoraproject.org> <20090512175839.GC29406@redhat.com> <4A09B964.5000905@redhat.com> <4A09BCBE.30509@fedoraproject.org> <4A09C3EE.3000207@redhat.com> <4A09C80C.7000600@fedoraproject.org> <20090512205219.GA7598@yoda.jdub.homelinux.org> <4A09EF5C.3020508@fedoraproject.org> <625fc13d0905121733r4087197fl5fd12062344e50cd@mail.gmail.com> Message-ID: <4A0AC465.2050604@fedoraproject.org> On 05/13/2009 06:03 AM, Josh Boyer wrote: > Spot _is_ one of those maintainers whose job this is supposed to make > easier. Having him provide input to the moksha/Fedora Community is > valuable, made more so by the large number of packages he maintains. > > Simply an instance example of what you asked. Ah, I see. As much as I respect Spot and his expertise on this, I think a diverse set of people providing input is much better than one but atleast now I understand what you were you getting at. Thanks. Rahul From kevin.kofler at chello.at Wed May 13 13:01:39 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 13 May 2009 15:01:39 +0200 Subject: Update -> no sound References: <1242146328.3147.181.camel@dimi.lattica.com> <20090512165559.GA19474@tango.0pointer.de> <1242149935.3147.191.camel@dimi.lattica.com> <4A09B8E6.5060904@fedoraproject.org> <20090512175839.GC29406@redhat.com> Message-ID: Daniel P. Berrange wrote: > Those bugz URLs would be a hell of alot more useful if they skipped > bugs marked 'closed' by default - make it optional to show them if > desired. It just doesn't scale currently for packages with 1000's of > closed bugs :-( I disagree. IMHO hiding closed bugs by default is the most annoying bug/misfeature of Bugzilla and a few other bug trackers. It leads to people filing duplicates because they don't see that their issue already got fixed (they just don't have the fix yet for whatever reason), was found not to be a valid bug or was found to be an issue elsewhere (upstream/downstream/in third-party software/wherever). Kevin Kofler From drago01 at gmail.com Wed May 13 13:02:15 2009 From: drago01 at gmail.com (drago01) Date: Wed, 13 May 2009 15:02:15 +0200 Subject: Breaking deps deliberately In-Reply-To: References: <20090513111343.4d79d48f@faldor.intranet> Message-ID: On Wed, May 13, 2009 at 2:33 PM, Seth Vidal wrote: > > > On Wed, 13 May 2009, Michael Schwendt wrote: > >> https://admin.fedoraproject.org/updates/F10/FEDORA-2009-4696 >> >> Is it permitted to deliberately break deps in stable updates? >> To me it sounds as if I'm in the wrong movie. :( > > +1. > > Creating broken deps when you know they won't be corrected should not be > allowed. +1 One more reason why we need depchecking before pushing updates. From bnocera at redhat.com Wed May 13 13:02:18 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Wed, 13 May 2009 14:02:18 +0100 Subject: gstreamer-properties (was Re: Update -> no sound) In-Reply-To: <4A0AA29B.9010502@poolshark.org> References: <1242146328.3147.181.camel@dimi.lattica.com> <20090512165559.GA19474@tango.0pointer.de> <1242148907.25471.1644.camel@cookie.hadess.net> <4A0AA29B.9010502@poolshark.org> Message-ID: <1242219738.25471.6379.camel@cookie.hadess.net> On Wed, 2009-05-13 at 12:36 +0200, Denis Leroy wrote: > On 05/12/2009 07:21 PM, Bastien Nocera wrote: > > Or launch gstreamer-properties on the command-line. autoaudiosink should > > work just as well, and should pick up pulsesink as its first choice. > > Speaking of which, why is gstreamer-properties hidden from the main menu ? > > > grep NoDisplay /usr/share/applications/gstreamer-properties.desktop > NoDisplay=true Because it's a piece of crap that you shouldn't even need to care about :) It's a debug/developer tool, not an end-user tool. From jameshubbard at gmail.com Wed May 13 13:04:16 2009 From: jameshubbard at gmail.com (James Hubbard) Date: Wed, 13 May 2009 09:04:16 -0400 Subject: OpenOffice 3.1 In-Reply-To: <17jqd6-d8i.ln1@ppp1053.in.ipex.cz> References: <4A034FD0.40103@gnat.ca> <1242143648.1211.32.camel@gilboa-work-dev.localdomain> <1242146510.2923.766.camel@adam.local.net> <1242169749.2923.883.camel@adam.local.net> <3adc77210905121636l5f42d05di23b6479873256b1a@mail.gmail.com> <1242172335.2923.891.camel@adam.local.net> <17jqd6-d8i.ln1@ppp1053.in.ipex.cz> Message-ID: On Wed, May 13, 2009 at 6:15 AM, Matej Cepl wrote: > Well, problem I have with declaring Fedora geek-only is that > I would like to have something to install for my > parents/wife/geek-impaired friends. And I really don't want to > install them Ubuntu -- not only because I have my doubts about > its quality, but also because I would prefer them to feed with > their input relevant for our stuff, and frankly because I don't > want to keep in my poor mind both /etc/network/interfaces and > /etc/sysconfig/network-scripts/*-cfg ;-). > > Currently my options are Fedora (last released just with updates) > and CentOS. I tend to think more and more about CentOS for such > cases, but I would really like give them something more recent > and something which would directly feed into Fedora. That's fine. You can continue to do that. I don't think that anyone minds that at all. Fedora is on the computers that my wife uses, but I'm there to help when she needs it. You just have to realize that you may need to help them. I want to minimize the time spent "fixing" Aunt Flo's computer. She just wants it to work and won't be doing anything technical. When she calls to ask for some help with setting up bridged networking so her virtual machine can get it's own IP address, I'll think about helping to use tools to that will make it easier. Fedora's EOL policy is too short and the older packages in CentOS leave something to be desired. I don't know how wireless support is in CentOS 5.3. If it equates to what wireless support was pre-F7, I don't want to have to help someone with that mess. Fedora and Ubuntu are working out of the box on most of the equipment that I have tested it on lately. I like using Fedora. Fedora updates the packages more frequently, giving me access to things that I want/need. Ubuntu provides more stability and is more suited for those users that need it. I'm okay with that. Until someone steps up and answers Adam's question about Fedora's targeted user, this debate will continue. I've not seen anyone do that yet. The section "Is Fedora for me" on the overview page is the closest thing that I've seen. I don't believe that Aunt Flo meets the criteria. From bnocera at redhat.com Wed May 13 13:15:10 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Wed, 13 May 2009 14:15:10 +0100 Subject: koji breakage for F12 builds In-Reply-To: <1242213324.3704.8.camel@localhost.localdomain> References: <5256d0b0905121504k4768401an741dd4d0bd5cf045@mail.gmail.com> <1242172496.3569.15.camel@localhost.localdomain> <20090513084302.1fb20a62@faldor.intranet> <1242213324.3704.8.camel@localhost.localdomain> Message-ID: <1242220510.25471.6431.camel@cookie.hadess.net> On Wed, 2009-05-13 at 13:15 +0200, Christoph Wickert wrote: > > E.g. notify-daemon and desktop-notification-daemon and the package name > > itself, notification-daemon. > > I think the problem is, that some packages notification-deamon instead > of (virtual) desktop-notification-deamon: > > # repoquery --repoid rawhide --whatrequires notification-daemon > gnome-bluetooth-0:2.27.5-1.fc11.i586 > notify-python-0:0.1.1-6.fc11.i586 > notification-daemon-engine-nodoka-0:0.1.0-6.fc11.i586 > system-config-printer-0:1.1.7-1.fc11.i586 > ibus-0:1.1.0.20090423-1.fc11.i586 > > I'm going to file bugs against these packages except > notification-daemon-engine-nodoka, because it only works with > notification-daemon. Except that I don't see why those would cause problems during the build, when they're not even getting installed in the buildroots. The problem was/is that libnotify-devel requires a desktop-notification-daemon (via libnotify itself), and yum will install both packages that provide it. From sundaram at fedoraproject.org Wed May 13 13:25:44 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 13 May 2009 18:55:44 +0530 Subject: Who Fedora isn't for (Was: Re: OpenOffice 3.1) In-Reply-To: References: <4A034FD0.40103@gnat.ca> <1242143648.1211.32.camel@gilboa-work-dev.localdomain> <1242146510.2923.766.camel@adam.local.net> <1242169749.2923.883.camel@adam.local.net> <3adc77210905121636l5f42d05di23b6479873256b1a@mail.gmail.com> <1242172335.2923.891.camel@adam.local.net> <17jqd6-d8i.ln1@ppp1053.in.ipex.cz> Message-ID: <4A0ACA58.2090604@fedoraproject.org> On 05/13/2009 06:34 PM, James Hubbard wrote: > Until someone steps up and answers Adam's question about Fedora's > targeted user, this debate will continue. I've not seen anyone do > that yet. The section "Is Fedora for me" on the overview page is the > closest thing that I've seen. I don't believe that Aunt Flo meets the > criteria. No. It doesn't unless someone is willing to sit through and help setup her system in a controlled manner and willing to upgrade every year atleast. Let's be clear. Lifecycle is a small part of the equation. Fedora doesn't deal with proprietary software or patent encumbered codecs and hence unlikely to be useful on its own for new users without some assistance. If we need to be explicit about this on our overview page, I can do that. Rahul From stickster at gmail.com Wed May 13 13:23:49 2009 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 13 May 2009 09:23:49 -0400 Subject: Update -> no sound In-Reply-To: <4A0AC465.2050604@fedoraproject.org> References: <4A09B8E6.5060904@fedoraproject.org> <20090512175839.GC29406@redhat.com> <4A09B964.5000905@redhat.com> <4A09BCBE.30509@fedoraproject.org> <4A09C3EE.3000207@redhat.com> <4A09C80C.7000600@fedoraproject.org> <20090512205219.GA7598@yoda.jdub.homelinux.org> <4A09EF5C.3020508@fedoraproject.org> <625fc13d0905121733r4087197fl5fd12062344e50cd@mail.gmail.com> <4A0AC465.2050604@fedoraproject.org> Message-ID: <20090513132349.GD3391@localhost.localdomain> On Wed, May 13, 2009 at 06:30:21PM +0530, Rahul Sundaram wrote: > On 05/13/2009 06:03 AM, Josh Boyer wrote: > > > Spot _is_ one of those maintainers whose job this is supposed to make > > easier. Having him provide input to the moksha/Fedora Community is > > valuable, made more so by the large number of packages he maintains. > > > > Simply an instance example of what you asked. > > Ah, I see. As much as I respect Spot and his expertise on this, I think > a diverse set of people providing input is much better than one but > atleast now I understand what you were you getting at. Thanks. I see other people in the public mailing list who are maintainers as well: https://admin.fedoraproject.org/pkgdb/users/packages/lmacken https://admin.fedoraproject.org/pkgdb/users/packages/herlo https://admin.fedoraproject.org/pkgdb/users/packages/johnp I'm sure the team would be happy to have more people providing constructive input, but saying there's only one involved is incorrect. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From sundaram at fedoraproject.org Wed May 13 13:37:52 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 13 May 2009 19:07:52 +0530 Subject: Update -> no sound In-Reply-To: <20090513132349.GD3391@localhost.localdomain> References: <4A09B8E6.5060904@fedoraproject.org> <20090512175839.GC29406@redhat.com> <4A09B964.5000905@redhat.com> <4A09BCBE.30509@fedoraproject.org> <4A09C3EE.3000207@redhat.com> <4A09C80C.7000600@fedoraproject.org> <20090512205219.GA7598@yoda.jdub.homelinux.org> <4A09EF5C.3020508@fedoraproject.org> <625fc13d0905121733r4087197fl5fd12062344e50cd@mail.gmail.com> <4A0AC465.2050604@fedoraproject.org> <20090513132349.GD3391@localhost.localdomain> Message-ID: <4A0ACD30.4030902@fedoraproject.org> On 05/13/2009 06:53 PM, Paul W. Frields wrote: > I'm sure the team would be happy to have more people providing > constructive input, but saying there's only one involved is incorrect. I am well aware of more than one person working on the project and for a long time. I am not claiming that Spot is the only package maintainer in the group but to expand on what I said, diversity is the key. For others to consider giving input, a demo instance needs to be running and visible to others. If it close to completion, then now would be a good time. Rahul From mcepl at redhat.com Wed May 13 13:40:22 2009 From: mcepl at redhat.com (Matej Cepl) Date: Wed, 13 May 2009 15:40:22 +0200 Subject: OpenOffice 3.1 References: <4A034FD0.40103@gnat.ca> <1242143648.1211.32.camel@gilboa-work-dev.localdomain> <1242146510.2923.766.camel@adam.local.net> <1242169749.2923.883.camel@adam.local.net> <3adc77210905121636l5f42d05di23b6479873256b1a@mail.gmail.com> <1242172335.2923.891.camel@adam.local.net> <17jqd6-d8i.ln1@ppp1053.in.ipex.cz> Message-ID: <67vqd6-5ao.ln1@ppp1053.in.ipex.cz> On 2009-05-13, 13:04 GMT, James Hubbard wrote: > If it equates to what wireless support was pre-F7, I No, fortunately, RHEL is not Debian/stable. Mat?j From rjones at redhat.com Wed May 13 13:47:45 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 13 May 2009 14:47:45 +0100 Subject: Breaking deps deliberately In-Reply-To: References: <20090513111343.4d79d48f@faldor.intranet> Message-ID: <20090513134744.GA19304@amd.home.annexia.org> On Wed, May 13, 2009 at 03:02:15PM +0200, drago01 wrote: > One more reason why we need depchecking before pushing updates. You might want to start by changing the packaging guidelines so that broken dependencies are actually outlawed. You'll notice that they are not outlawed at the moment. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw From johannbg at hi.is Wed May 13 13:50:50 2009 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Wed, 13 May 2009 13:50:50 +0000 Subject: Who Fedora isn't for (Was: Re: OpenOffice 3.1) In-Reply-To: <4A0ACA58.2090604@fedoraproject.org> References: <4A034FD0.40103@gnat.ca> <1242143648.1211.32.camel@gilboa-work-dev.localdomain> <1242146510.2923.766.camel@adam.local.net> <1242169749.2923.883.camel@adam.local.net> <3adc77210905121636l5f42d05di23b6479873256b1a@mail.gmail.com> <1242172335.2923.891.camel@adam.local.net> <17jqd6-d8i.ln1@ppp1053.in.ipex.cz> <4A0ACA58.2090604@fedoraproject.org> Message-ID: <4A0AD03A.7070703@hi.is> On 05/13/2009 01:25 PM, Rahul Sundaram wrote: > On 05/13/2009 06:34 PM, James Hubbard wrote: > > >> Until someone steps up and answers Adam's question about Fedora's >> targeted user, this debate will continue. I've not seen anyone do >> that yet. The section "Is Fedora for me" on the overview page is the >> closest thing that I've seen. I don't believe that Aunt Flo meets the >> criteria. >> > > No. It doesn't unless someone is willing to sit through and help setup > her system in a controlled manner and willing to upgrade every year > atleast. Let's be clear. Lifecycle is a small part of the equation. > Fedora doesn't deal with proprietary software or patent encumbered > codecs and hence unlikely to be useful on its own for new users without > some assistance. > > If we need to be explicit about this on our overview page, I can do that. > > While your added fix the Download page add all the *DE we have since you just confirmed that Fedora is not targeted at novice end user hence it's safe to presume the audience that Fedora is targeted against has the ability and means to choose... JBG -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: johannbg.vcf Type: text/x-vcard Size: 356 bytes Desc: not available URL: From sundaram at fedoraproject.org Wed May 13 13:55:43 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 13 May 2009 19:25:43 +0530 Subject: Breaking deps deliberately In-Reply-To: <20090513134744.GA19304@amd.home.annexia.org> References: <20090513111343.4d79d48f@faldor.intranet> <20090513134744.GA19304@amd.home.annexia.org> Message-ID: <4A0AD15F.6040300@fedoraproject.org> On 05/13/2009 07:17 PM, Richard W.M. Jones wrote: > On Wed, May 13, 2009 at 03:02:15PM +0200, drago01 wrote: >> One more reason why we need depchecking before pushing updates. > > You might want to start by changing the packaging guidelines so that > broken dependencies are actually outlawed. You'll notice that they > are not outlawed at the moment. What do you mean by outlawed? Isn't it common sense that breaking dependencies is not allowed? Rahul From pmatilai at laiskiainen.org Wed May 13 13:51:30 2009 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Wed, 13 May 2009 16:51:30 +0300 (EEST) Subject: Update -> no sound In-Reply-To: References: <1242146328.3147.181.camel@dimi.lattica.com> <20090512165559.GA19474@tango.0pointer.de> <1242149935.3147.191.camel@dimi.lattica.com> <4A09B8E6.5060904@fedoraproject.org> <20090512175839.GC29406@redhat.com> Message-ID: On Wed, 13 May 2009, Kevin Kofler wrote: > Daniel P. Berrange wrote: >> Those bugz URLs would be a hell of alot more useful if they skipped >> bugs marked 'closed' by default - make it optional to show them if >> desired. It just doesn't scale currently for packages with 1000's of >> closed bugs :-( > > I disagree. IMHO hiding closed bugs by default is the most annoying > bug/misfeature of Bugzilla and a few other bug trackers. It leads to people > filing duplicates because they don't see that their issue already got fixed > (they just don't have the fix yet for whatever reason), was found not to be > a valid bug or was found to be an issue elsewhere (upstream/downstream/in > third-party software/wherever). Showing recently (think of "last 3-6 months" or maybe even "for currently maintained distro versions") closed bugs might indeed help avoiding gazillion dupes on some occasions but having to stare at all the closed bugs since Fedora Core 1 era by default serves little purpose IMO. - Panu - From jwboyer at gmail.com Wed May 13 13:52:09 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 13 May 2009 09:52:09 -0400 Subject: Breaking deps deliberately In-Reply-To: References: <20090513111343.4d79d48f@faldor.intranet> Message-ID: <20090513135208.GA1850@yoda.jdub.homelinux.org> On Wed, May 13, 2009 at 03:02:15PM +0200, drago01 wrote: >On Wed, May 13, 2009 at 2:33 PM, Seth Vidal wrote: >> >> >> On Wed, 13 May 2009, Michael Schwendt wrote: >> >>> https://admin.fedoraproject.org/updates/F10/FEDORA-2009-4696 >>> >>> Is it permitted to deliberately break deps in stable updates? >>> To me it sounds as if I'm in the wrong movie. :( >> >> +1. >> >> Creating broken deps when you know they won't be corrected should not be >> allowed. > >+1 > >One more reason why we need depchecking before pushing updates. Not that I disagree, but let me elaborate on what that would entail. 1) All the stuff that already happens today for updates. This takes roughly an hour or so to get the set of updates signed and the push started. The push itself takes roughly 7-8 hours with f9,f10,f11 testing and stable. I'm already pushing updates almost 5 days a week, so doing it more frequently isn't going to help much. Particularly when there are typically between 70-150 pending updates every day. The mash time only grows as the repos grow larger from new packages. 2) In addition to 1 above, we'd now have to run a depcheck on the resulting repos. If it finds no problems, great! Continue with the push. If it has dependency issues, fail. Take the packages that have dep errors, and automatically revoke those update requests in bodhi. The start over again. Except it's not that easy. Because in order to mash the repos, we need the packages to move tags in koji. So now we have to roll back those tag operations too. And we also have to trim those packages out of the push list. The bodhi state machine cannot cope with any of this today. I don't believe dep checking can be done on update submission (at least not easily), because in order to do that we need a repo to run it against and the update might be relying on other pending updates that aren't in the repos yet. The way to get them in the repo is to mash it... (Doing test/throw-away mash->dep checks would just be sort of silly due to the time it takes and the ever fluctuating pending updates list). 3) We would need some significant code changes to bodhi and possibly mash to get all of that. That code is thoroughly understood by exactly 1 person. Another person (me) is trying to grok it in his spare time, but it's rather involved and the bodhi setup on the infrastructure machines is a bit convoluted. Having people jump in to help would be awesome, but it is not a trivial task. So it's easy to say "we should dep check before pushing". And I'll even agree we should. However, in reality there is a _lot_ of work that needs to be done to make that even remotely possible. I'm certainly open to other suggestions on how to accomplish this. I would love if someone would tell me how stupid I am and how it can be done more easily. However, I am growing slightly tired of people saying we should 'do it' (or worse, ranting about it) without having a clue on what needs to be done to actually do it or even volunteering to help. Hopefully those that want to see this happen will read over the strawman above and put some collective brain/muscle power behind it. josh From jwboyer at gmail.com Wed May 13 13:55:28 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 13 May 2009 09:55:28 -0400 Subject: Breaking deps deliberately In-Reply-To: <20090513134744.GA19304@amd.home.annexia.org> References: <20090513111343.4d79d48f@faldor.intranet> <20090513134744.GA19304@amd.home.annexia.org> Message-ID: <20090513135528.GB1850@yoda.jdub.homelinux.org> On Wed, May 13, 2009 at 02:47:45PM +0100, Richard W.M. Jones wrote: >On Wed, May 13, 2009 at 03:02:15PM +0200, drago01 wrote: >> One more reason why we need depchecking before pushing updates. > >You might want to start by changing the packaging guidelines so that >broken dependencies are actually outlawed. You'll notice that they >are not outlawed at the moment. Mostly because we try not to write guidelines that seem to cover what most people consider common sense.... josh From sundaram at fedoraproject.org Wed May 13 14:01:42 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 13 May 2009 19:31:42 +0530 Subject: Who Fedora isn't for (Was: Re: OpenOffice 3.1) In-Reply-To: <4A0AD03A.7070703@hi.is> References: <4A034FD0.40103@gnat.ca> <1242143648.1211.32.camel@gilboa-work-dev.localdomain> <1242146510.2923.766.camel@adam.local.net> <1242169749.2923.883.camel@adam.local.net> <3adc77210905121636l5f42d05di23b6479873256b1a@mail.gmail.com> <1242172335.2923.891.camel@adam.local.net> <17jqd6-d8i.ln1@ppp1053.in.ipex.cz> <4A0ACA58.2090604@fedoraproject.org> <4A0AD03A.7070703@hi.is> Message-ID: <4A0AD2C6.8090709@fedoraproject.org> On 05/13/2009 07:20 PM, "J?hann B. Gu?mundsson" wrote: > > While your added fix the Download page add all the *DE we have > since you just confirmed that Fedora is not targeted at novice end user > hence it's safe to presume the audience that Fedora is targeted against > has the ability and means to choose... If you have feedback on the website, esp the static pages, please post to fedora-websites list instead. I can't help with that. Keep this discussion limited to the wiki, please. Rahul From rjones at redhat.com Wed May 13 13:57:28 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 13 May 2009 14:57:28 +0100 Subject: Breaking deps deliberately In-Reply-To: <4A0AD15F.6040300@fedoraproject.org> References: <20090513111343.4d79d48f@faldor.intranet> <20090513134744.GA19304@amd.home.annexia.org> <4A0AD15F.6040300@fedoraproject.org> Message-ID: <20090513135728.GA19428@amd.home.annexia.org> On Wed, May 13, 2009 at 07:25:43PM +0530, Rahul Sundaram wrote: > On 05/13/2009 07:17 PM, Richard W.M. Jones wrote: > > On Wed, May 13, 2009 at 03:02:15PM +0200, drago01 wrote: > >> One more reason why we need depchecking before pushing updates. > > > > You might want to start by changing the packaging guidelines so that > > broken dependencies are actually outlawed. You'll notice that they > > are not outlawed at the moment. > > What do you mean by outlawed? Isn't it common sense that breaking > dependencies is not allowed? Not really. The dependency in any case wasn't "broken", it just wasn't satisfied by any package in Fedora 10 (although it was by packages in Fedora 11+). Someone else already mentioned a theoretical case where a package might depend on libdvdcss, which would have both legal and technical issues. If you want to say that the repository shouldn't have broken dependencies, then it should say so in the packaging guidelines. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From sundaram at fedoraproject.org Wed May 13 14:07:29 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 13 May 2009 19:37:29 +0530 Subject: Breaking deps deliberately In-Reply-To: <20090513135728.GA19428@amd.home.annexia.org> References: <20090513111343.4d79d48f@faldor.intranet> <20090513134744.GA19304@amd.home.annexia.org> <4A0AD15F.6040300@fedoraproject.org> <20090513135728.GA19428@amd.home.annexia.org> Message-ID: <4A0AD421.7060308@fedoraproject.org> On 05/13/2009 07:27 PM, Richard W.M. Jones wrote: > Not really. > > The dependency in any case wasn't "broken", it just wasn't satisfied > by any package in Fedora 10 (although it was by packages in Fedora 11+). You are dabbling in semantics. If can't do yum install foo, then yes that means you broke the dependency. It doesn't matter if the dependency is resolved by pulling in packages from Rawhide since we don't support that. > Someone else already mentioned a theoretical case where a package > might depend on libdvdcss, which would have both legal and technical > issues. If a package has a build-time dependency on libdvdcss, it wouldn't be even allowed in Fedora due to the existing licensing guidelines. If it is a optional run-time dependency, we don't need to bother about them. This is a completely separate case. Rahul From mike at cchtml.com Wed May 13 14:06:09 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Wed, 13 May 2009 09:06:09 -0500 Subject: Breaking deps deliberately In-Reply-To: <20090513135728.GA19428@amd.home.annexia.org> References: <20090513111343.4d79d48f@faldor.intranet> <20090513134744.GA19304@amd.home.annexia.org> <4A0AD15F.6040300@fedoraproject.org> <20090513135728.GA19428@amd.home.annexia.org> Message-ID: <4A0AD3D1.1060306@cchtml.com> -------- Original Message -------- Subject: Re: Breaking deps deliberately From: Richard W.M. Jones To: Development discussions related to Fedora Date: 05/13/2009 08:57 AM > > Not really. > > The dependency in any case wasn't "broken", it just wasn't satisfied > by any package in Fedora 10 (although it was by packages in Fedora 11+). > Is it OK to pull RHEL 5 packages for RHEL 4? RH 9 packages for RHEL 5? Sure, you can do this on your own time, but making an official package in the public repository depend on this action? Nuts. Come on Richard, you should know better. From james at fedoraproject.org Wed May 13 14:15:53 2009 From: james at fedoraproject.org (James Antill) Date: Wed, 13 May 2009 10:15:53 -0400 Subject: koji breakage for F12 builds In-Reply-To: <1242220510.25471.6431.camel@cookie.hadess.net> References: <5256d0b0905121504k4768401an741dd4d0bd5cf045@mail.gmail.com> <1242172496.3569.15.camel@localhost.localdomain> <20090513084302.1fb20a62@faldor.intranet> <1242213324.3704.8.camel@localhost.localdomain> <1242220510.25471.6431.camel@cookie.hadess.net> Message-ID: <1242224153.10107.27.camel@code.and.org> On Wed, 2009-05-13 at 14:15 +0100, Bastien Nocera wrote: > On Wed, 2009-05-13 at 13:15 +0200, Christoph Wickert wrote: > > I think the problem is, that some packages notification-deamon instead > > of (virtual) desktop-notification-deamon: [...] > Except that I don't see why those would cause problems during the build, > when they're not even getting installed in the buildroots. > > The problem was/is that libnotify-devel requires a > desktop-notification-daemon (via libnotify itself), and yum will install > both packages that provide it. How did you come to this conclusion? I'm not saying it's impossible, but the above seems unlikely unless yum picks one on the virtual provides hit and then it gets an explicit requires on the other (which isn't the same thing). -- James Antill Fedora From jameshubbard at gmail.com Wed May 13 14:15:55 2009 From: jameshubbard at gmail.com (James Hubbard) Date: Wed, 13 May 2009 10:15:55 -0400 Subject: Who Fedora isn't for (Was: Re: OpenOffice 3.1) In-Reply-To: <4A0ACA58.2090604@fedoraproject.org> References: <4A034FD0.40103@gnat.ca> <1242146510.2923.766.camel@adam.local.net> <1242169749.2923.883.camel@adam.local.net> <3adc77210905121636l5f42d05di23b6479873256b1a@mail.gmail.com> <1242172335.2923.891.camel@adam.local.net> <17jqd6-d8i.ln1@ppp1053.in.ipex.cz> <4A0ACA58.2090604@fedoraproject.org> Message-ID: On Wed, May 13, 2009 at 9:25 AM, Rahul Sundaram wrote: > On 05/13/2009 06:34 PM, James Hubbard wrote: > >> Until someone steps up and answers Adam's question about Fedora's >> targeted user, this debate will continue. ?I've not seen anyone do >> that yet. The section "Is Fedora for me" on the overview page is the >> closest thing that I've seen. ?I don't believe that Aunt Flo meets the >> criteria. > > No. It doesn't unless someone is willing to sit through and help setup > her system in a controlled manner and willing to upgrade every year > atleast. Let's be clear. Lifecycle is a small part of the equation. > Fedora doesn't deal with proprietary software or patent encumbered > codecs and hence unlikely to be useful on its own for new users without > some assistance. > > If we need to be explicit about this on our overview page, I can do that. Commentary about proprietary software probably isn't needed. Proprietary software will come with guidelines for OS support. Technically savvy Fedora users can figure it out if they're able to run it on their systems. Since Fedora does ship multimedia capable software, it would probably be a good idea to provide some statement about proprietary/patent encumbered codecs. I think being explicit in target user expectations is a good idea. It seems like bike shedding, but it comes up enough that it's probably a good idea. From skvidal at fedoraproject.org Wed May 13 14:14:31 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 13 May 2009 10:14:31 -0400 (EDT) Subject: Breaking deps deliberately In-Reply-To: <20090513135728.GA19428@amd.home.annexia.org> References: <20090513111343.4d79d48f@faldor.intranet> <20090513134744.GA19304@amd.home.annexia.org> <4A0AD15F.6040300@fedoraproject.org> <20090513135728.GA19428@amd.home.annexia.org> Message-ID: On Wed, 13 May 2009, Richard W.M. Jones wrote: > > Not really. > > The dependency in any case wasn't "broken", it just wasn't satisfied > by any package in Fedora 10 (although it was by packages in Fedora 11+). > > Someone else already mentioned a theoretical case where a package > might depend on libdvdcss, which would have both legal and technical > issues. > > If you want to say that the repository shouldn't have broken > dependencies, then it should say so in the packaging guidelines. > Fine - then I'll propose a new rule that will retroactively apply to ALL packages: "No broken dependencies are allowed for package or update (including updates-testing) for any given release version of the fedora linux distribution." and I think we need to ask if your provenpackager status should be re-evaluated. -sv From wolfy at nobugconsulting.ro Wed May 13 14:16:29 2009 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Wed, 13 May 2009 17:16:29 +0300 Subject: Breaking deps deliberately In-Reply-To: <20090513135528.GB1850@yoda.jdub.homelinux.org> References: <20090513111343.4d79d48f@faldor.intranet> <20090513134744.GA19304@amd.home.annexia.org> <20090513135528.GB1850@yoda.jdub.homelinux.org> Message-ID: <4A0AD63D.5030606@nobugconsulting.ro> Josh Boyer wrote: > On Wed, May 13, 2009 at 02:47:45PM +0100, Richard W.M. Jones wrote: > >> On Wed, May 13, 2009 at 03:02:15PM +0200, drago01 wrote: >> >>> One more reason why we need depchecking before pushing updates. >>> >> You might want to start by changing the packaging guidelines so that >> broken dependencies are actually outlawed. You'll notice that they >> are not outlawed at the moment. >> > > Mostly because we try not to write guidelines that seem to cover what most > people consider common sense.... > it seems that in some parts of the world common sense is overrated, so probably we should add those cases to the guidelines,too Wolfy " what? you want to install a package in F10 and you did not enable the F11 repo ?! geeee, the new common sense says you should have all Fn + rawhide enabled !! " From rjones at redhat.com Wed May 13 14:20:48 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 13 May 2009 15:20:48 +0100 Subject: Breaking deps deliberately In-Reply-To: References: <20090513111343.4d79d48f@faldor.intranet> <20090513134744.GA19304@amd.home.annexia.org> <4A0AD15F.6040300@fedoraproject.org> <20090513135728.GA19428@amd.home.annexia.org> Message-ID: <20090513142048.GA19610@amd.home.annexia.org> On Wed, May 13, 2009 at 10:14:31AM -0400, Seth Vidal wrote: > Fine - then I'll propose a new rule that will retroactively apply to ALL > packages: > > "No broken dependencies are allowed for package or update (including > updates-testing) for any given release version of the fedora linux > distribution." Sounds like a sensible guideline? > and I think we need to ask if your provenpackager status should be > re-evaluated. For what? Breaking a non-existant guideline in order to help people who kept asking me for Fedora 10 support for libguestfs? Maybe we should 'discipline' people for breaking other unwritten rules too, such as adding packages to Fedora when sitting in bed or not correctly dressed. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From markmc at redhat.com Wed May 13 14:21:35 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 13 May 2009 15:21:35 +0100 Subject: Breaking deps deliberately In-Reply-To: <20090513134744.GA19304@amd.home.annexia.org> References: <20090513111343.4d79d48f@faldor.intranet> <20090513134744.GA19304@amd.home.annexia.org> Message-ID: <1242224495.27745.10.camel@blaa> On Wed, 2009-05-13 at 14:47 +0100, Richard W.M. Jones wrote: > On Wed, May 13, 2009 at 03:02:15PM +0200, drago01 wrote: > > One more reason why we need depchecking before pushing updates. > > You might want to start by changing the packaging guidelines so that > broken dependencies are actually outlawed. You'll notice that they > are not outlawed at the moment. http://fedoraproject.org/wiki/PackageMaintainers/Package_update_guidelines "These are not intended to be prescriptive rules. Package maintainers are expected to to exercise their own common sense and good judgement." There seems to be some consensus that avoiding broken dependencies falls under "common sense and good judgement". Cheers, Mark. From skvidal at fedoraproject.org Wed May 13 14:22:23 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 13 May 2009 10:22:23 -0400 (EDT) Subject: Breaking deps deliberately In-Reply-To: <20090513142048.GA19610@amd.home.annexia.org> References: <20090513111343.4d79d48f@faldor.intranet> <20090513134744.GA19304@amd.home.annexia.org> <4A0AD15F.6040300@fedoraproject.org> <20090513135728.GA19428@amd.home.annexia.org> <20090513142048.GA19610@amd.home.annexia.org> Message-ID: On Wed, 13 May 2009, Richard W.M. Jones wrote: > > Sounds like a sensible guideline? > >> and I think we need to ask if your provenpackager status should be >> re-evaluated. > > For what? Breaking a non-existant guideline in order to help people > who kept asking me for Fedora 10 support for libguestfs? Maybe we > should 'discipline' people for breaking other unwritten rules too, > such as adding packages to Fedora when sitting in bed or not correctly > dressed. > I think it is implicit within the definition of 'provenpackager' that you understand the basic rules of how the system works. You couldn't be a 'provenphysicist' for example without understanding the laws of thermodynamics. -sv From rjones at redhat.com Wed May 13 14:27:42 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 13 May 2009 15:27:42 +0100 Subject: Breaking deps deliberately In-Reply-To: References: <20090513111343.4d79d48f@faldor.intranet> <20090513134744.GA19304@amd.home.annexia.org> <4A0AD15F.6040300@fedoraproject.org> <20090513135728.GA19428@amd.home.annexia.org> <20090513142048.GA19610@amd.home.annexia.org> Message-ID: <20090513142742.GB19610@amd.home.annexia.org> On Wed, May 13, 2009 at 10:22:23AM -0400, Seth Vidal wrote: > You couldn't be a 'provenphysicist' for example without understanding the > laws of thermodynamics. At least the laws of thermodynamics are written down ... It seriously was not obvious to me that a broken dependency in some out-of-the-way package, in an older version of Fedora, that I added to *help Fedora users*, would be a problem. Someone could easily do the same thing in future. If broken dependencies are so unacceptable, then it should be added to the packaging guidelines. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 75 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From itamar at ispbrasil.com.br Wed May 13 14:28:17 2009 From: itamar at ispbrasil.com.br (Itamar Reis Peixoto) Date: Wed, 13 May 2009 11:28:17 -0300 Subject: Breaking deps deliberately In-Reply-To: References: <20090513111343.4d79d48f@faldor.intranet> <20090513134744.GA19304@amd.home.annexia.org> <4A0AD15F.6040300@fedoraproject.org> <20090513135728.GA19428@amd.home.annexia.org> <20090513142048.GA19610@amd.home.annexia.org> Message-ID: this is a non produtive discussion Richard is doing the best for fedora. On Wed, May 13, 2009 at 11:22 AM, Seth Vidal wrote: > > > On Wed, 13 May 2009, Richard W.M. Jones wrote: > >> >> Sounds like a sensible guideline? >> >>> and I think we need to ask if your provenpackager ?status should be >>> re-evaluated. >> >> For what? ?Breaking a non-existant guideline in order to help people >> who kept asking me for Fedora 10 support for libguestfs? ?Maybe we >> should 'discipline' people for breaking other unwritten rules too, >> such as adding packages to Fedora when sitting in bed or not correctly >> dressed. >> > > I think it is implicit within the definition of 'provenpackager' that you > understand the basic rules of how the system works. > > You couldn't be a 'provenphysicist' for example without understanding the > laws of thermodynamics. > > -sv > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- ------------ Itamar Reis Peixoto e-mail/msn: itamar at ispbrasil.com.br sip: itamar at ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 From pbrobinson at gmail.com Wed May 13 14:28:35 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 13 May 2009 15:28:35 +0100 Subject: koji breakage for F12 builds In-Reply-To: <1242224153.10107.27.camel@code.and.org> References: <5256d0b0905121504k4768401an741dd4d0bd5cf045@mail.gmail.com> <1242172496.3569.15.camel@localhost.localdomain> <20090513084302.1fb20a62@faldor.intranet> <1242213324.3704.8.camel@localhost.localdomain> <1242220510.25471.6431.camel@cookie.hadess.net> <1242224153.10107.27.camel@code.and.org> Message-ID: <5256d0b0905130728s5f936092sf4a788dad4c83a2c@mail.gmail.com> >> > I think the problem is, that some packages ?notification-deamon instead >> > of (virtual) desktop-notification-deamon: > [...] >> Except that I don't see why those would cause problems during the build, >> when they're not even getting installed in the buildroots. >> >> The problem was/is that libnotify-devel requires a >> desktop-notification-daemon (via libnotify itself), and yum will install >> both packages that provide it. > > ?How did you come to this conclusion? > ?I'm not saying it's impossible, but the above seems unlikely unless yum > picks one on the virtual provides hit and then it gets an explicit > requires on the other (which isn't the same thing). I thought it basically installed the first in the list. EG If you hit a require for /usr/sbin/sendmail it installs exim by default I think. Peter From drago01 at gmail.com Wed May 13 14:28:45 2009 From: drago01 at gmail.com (drago01) Date: Wed, 13 May 2009 16:28:45 +0200 Subject: Breaking deps deliberately In-Reply-To: <20090513134744.GA19304@amd.home.annexia.org> References: <20090513111343.4d79d48f@faldor.intranet> <20090513134744.GA19304@amd.home.annexia.org> Message-ID: On Wed, May 13, 2009 at 3:47 PM, Richard W.M. Jones wrote: > On Wed, May 13, 2009 at 03:02:15PM +0200, drago01 wrote: >> One more reason why we need depchecking before pushing updates. > > You might want to start by changing the packaging guidelines so that > broken dependencies are actually outlawed. ?You'll notice that they > are not outlawed at the moment. > Not everything has to be written down somewhere ... but it seems that many people needs this ... oh well lets add another 100 pages of guidelines for things that are simply common sense. From petersen at redhat.com Wed May 13 14:35:19 2009 From: petersen at redhat.com (Jens Petersen) Date: Wed, 13 May 2009 10:35:19 -0400 (EDT) Subject: 2009-05-14 - Fedora Test Day - IBus input method In-Reply-To: <750770781.422321242225126689.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <1571861921.422801242225319706.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> ----- "Matej Cepl" wrote: > I haven?t managed to have cs_CZ layout AND Compose key active in > the same time. As you can see from this reply, I like ?curly > quotes? and similar stuff, but I need Czech keyboard layout as > well. Please file bug and we can look more into it. > >> b) it worked poorly (not sure how) with Czech layout ... and > >> I heard it from other people with somewhere in between layouts > >> ... non-ASCII, but also non-real-IM-needed. Ditto - Martin says something similar. > > I think most ibus engines can only work with us-en keyboard layout > too. > > But we have planed to integrate ibus with xkb. But this feature is > for > > f12 or RHEL 6. > > Translated: I shouldn't bother with iBus at all. Is that correct? I think he means some of the input-methods currently assume a US layout. Which language are you trying to use ibus (scim) for? Jens From ajax at redhat.com Wed May 13 14:37:19 2009 From: ajax at redhat.com (Adam Jackson) Date: Wed, 13 May 2009 10:37:19 -0400 Subject: rpm hashes In-Reply-To: References: <4A082E70.7030904@TheTroubleshooters.dk> <4A086703.1080906@amiga-hardware.com> <4A094EC4.9030506@TheTroubleshooters.dk> <1242125395.13505.449.camel@breeves.fab.redhat.com> <4A0988DC.8030103@freenet.de> <4A098F11.4080008@freenet.de> Message-ID: <1242225439.21675.81.camel@atropine.boston.devel.redhat.com> On Wed, 2009-05-13 at 09:13 +0300, Panu Matilainen wrote: > From rpm POV it's perfectly legal for any number of packages to share > identical files, and that still works. What doesn't work is sharing files > between packages using different file hash algorithm, so if you need to > share across Centos >= 3 <-> Fedora >= 11 you need to build the package > for lowest common denominator, meaning md5 file hashes. Fedora 11 changes > the default algorithm from md5 to sha256 in redhat-rpm-config, producing > packages that are incompatible with rpm < 4.6.0 but specs and macro > configuration can override that. > > Whether it's against Fedora guidelines is another question, but since this > was about a package from a 3rd party repository... It would have been really, _really_ nice if sha256 was merely another hash that could be in the payload, instead of forcing you to pick one or the other. For that matter, it would still be really really nice. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Wed May 13 14:36:45 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 13 May 2009 10:36:45 -0400 (EDT) Subject: Breaking deps deliberately In-Reply-To: <20090513142742.GB19610@amd.home.annexia.org> References: <20090513111343.4d79d48f@faldor.intranet> <20090513134744.GA19304@amd.home.annexia.org> <4A0AD15F.6040300@fedoraproject.org> <20090513135728.GA19428@amd.home.annexia.org> <20090513142048.GA19610@amd.home.annexia.org> <20090513142742.GB19610@amd.home.annexia.org> Message-ID: On Wed, 13 May 2009, Richard W.M. Jones wrote: > At least the laws of thermodynamics are written down ... > > It seriously was not obvious to me that a broken dependency in some > out-of-the-way package, in an older version of Fedora, that I added to > *help Fedora users*, would be a problem. > > Someone could easily do the same thing in future. If broken > dependencies are so unacceptable, then it should be added to the > packaging guidelines. I really don't care. Not breaking deps is common sense. And if you are in provenpackager and do NOT have that common sense, then I don't think you are a provenpackager. let me make this clear so there is no confusion: INTENTIONALLY BREAKING DEPENDENCIES IS NOT ALLOWED. I'll be bringing your provenpackager status up for the next fesco meeting. -sv From rjones at redhat.com Wed May 13 14:38:31 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 13 May 2009 15:38:31 +0100 Subject: Breaking deps deliberately In-Reply-To: <20090513142048.GA19610@amd.home.annexia.org> References: <20090513111343.4d79d48f@faldor.intranet> <20090513134744.GA19304@amd.home.annexia.org> <4A0AD15F.6040300@fedoraproject.org> <20090513135728.GA19428@amd.home.annexia.org> <20090513142048.GA19610@amd.home.annexia.org> Message-ID: <20090513143831.GA19725@amd.home.annexia.org> On Wed, May 13, 2009 at 03:20:48PM +0100, Richard W.M. Jones wrote: > On Wed, May 13, 2009 at 10:14:31AM -0400, Seth Vidal wrote: > > Fine - then I'll propose a new rule that will retroactively apply to ALL > > packages: > > > > "No broken dependencies are allowed for package or update (including > > updates-testing) for any given release version of the fedora linux > > distribution." > > Sounds like a sensible guideline? ^^ For some reason a question mark appeared there. It should be 'Sounds like a sensible guideline.' Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw From tcallawa at redhat.com Wed May 13 14:43:23 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 13 May 2009 10:43:23 -0400 Subject: Update -> no sound In-Reply-To: <4A0ACD30.4030902@fedoraproject.org> References: <4A09B8E6.5060904@fedoraproject.org> <20090512175839.GC29406@redhat.com> <4A09B964.5000905@redhat.com> <4A09BCBE.30509@fedoraproject.org> <4A09C3EE.3000207@redhat.com> <4A09C80C.7000600@fedoraproject.org> <20090512205219.GA7598@yoda.jdub.homelinux.org> <4A09EF5C.3020508@fedoraproject.org> <625fc13d0905121733r4087197fl5fd12062344e50cd@mail.gmail.com> <4A0AC465.2050604@fedoraproject.org> <20090513132349.GD3391@localhost.localdomain> <4A0ACD30.4030902@fedoraproject.org> Message-ID: <4A0ADC8B.3050307@redhat.com> On 05/13/2009 09:37 AM, Rahul Sundaram wrote: > On 05/13/2009 06:53 PM, Paul W. Frields wrote: > >> I'm sure the team would be happy to have more people providing >> constructive input, but saying there's only one involved is incorrect. > > I am well aware of more than one person working on the project and for a > long time. I am not claiming that Spot is the only package maintainer in > the group but to expand on what I said, diversity is the key. For others > to consider giving input, a demo instance needs to be running and > visible to others. If it close to completion, then now would be a good > time. Demo instance is running and visible to others. We have not been aggressively advertising it because: A) It is a test instance, and the performance is non on-par with what it will be when we go live. We didn't want to spend time wading through the "OMG THIS IS SLOWER THAN BUGZLILLA!!!1!" B) We have been constantly cycling it as we've been fixing blocker bugs. The last thing we wanted was for anyone to think they could depend on it. C) Anyone who asked to see it has been pointed to it (several folks have asked). So, without further ado and the above caveats, look at our pre-beta test instance: https://publictest16.fedoraproject.org/community/ We know lots of stuff is broken, we have a pile of blocker bugs open in our trac instance. Please don't rely on this test instance for anything. ~spot From jussi.lehtola at iki.fi Wed May 13 14:29:44 2009 From: jussi.lehtola at iki.fi (Jussi Lehtola) Date: Wed, 13 May 2009 17:29:44 +0300 Subject: Breaking deps deliberately In-Reply-To: References: <20090513111343.4d79d48f@faldor.intranet> <20090513134744.GA19304@amd.home.annexia.org> <4A0AD15F.6040300@fedoraproject.org> <20090513135728.GA19428@amd.home.annexia.org> <20090513142048.GA19610@amd.home.annexia.org> Message-ID: <1242224984.3144.5.camel@localhost.localdomain> On Wed, 2009-05-13 at 10:22 -0400, Seth Vidal wrote: > > On Wed, 13 May 2009, Richard W.M. Jones wrote: > > > > > Sounds like a sensible guideline? > > > >> and I think we need to ask if your provenpackager status should be > >> re-evaluated. > > > > For what? Breaking a non-existant guideline in order to help people > > who kept asking me for Fedora 10 support for libguestfs? Maybe we > > should 'discipline' people for breaking other unwritten rules too, > > such as adding packages to Fedora when sitting in bed or not correctly > > dressed. Funny, I could have sworn I've seen a mention somewhere that Fedora packages cannot have Requires: on packages not available in Fedora (e.g. 3rd party repos), but I can't seem to find it now. > I think it is implicit within the definition of 'provenpackager' that you > understand the basic rules of how the system works. +1 > You couldn't be a 'provenphysicist' for example without understanding the > laws of thermodynamics. +1 from a professional physicist -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From walters at verbum.org Wed May 13 14:29:19 2009 From: walters at verbum.org (Colin Walters) Date: Wed, 13 May 2009 10:29:19 -0400 Subject: Breaking deps deliberately In-Reply-To: <20090513135208.GA1850@yoda.jdub.homelinux.org> References: <20090513111343.4d79d48f@faldor.intranet> <20090513135208.GA1850@yoda.jdub.homelinux.org> Message-ID: On Wed, May 13, 2009 at 9:52 AM, Josh Boyer wrote: > So it's easy to say "we should dep check before pushing". ?And I'll even agree > we should. ?However, in reality there is a _lot_ of work that needs to be done > to make that even remotely possible. Would it be easier to do more extensive checks only for say security updates? Maybe we could consider splitting fedora-updates into two repos; fedora-updates-security and fedora-updates-all? From rjones at redhat.com Wed May 13 14:48:12 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 13 May 2009 15:48:12 +0100 Subject: Breaking deps deliberately In-Reply-To: References: <20090513134744.GA19304@amd.home.annexia.org> <4A0AD15F.6040300@fedoraproject.org> <20090513135728.GA19428@amd.home.annexia.org> <20090513142048.GA19610@amd.home.annexia.org> <20090513142742.GB19610@amd.home.annexia.org> Message-ID: <20090513144812.GA19757@amd.home.annexia.org> On Wed, May 13, 2009 at 10:36:45AM -0400, Seth Vidal wrote: > I'll be bringing your provenpackager status up for the next fesco meeting. I should note for the record here that I never asked to be a provenpackager, or wanted to be one, or have ever used the ability. I was made a pp because it is a requirement so I could sponsor kalev. I don't know why someone needs to be a pp in order to sponsor. It doesn't seem to be necessary AFAICT. http://bpepple.fedorapeople.org/fesco/FESCo-2009-04-10.html Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 75 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From christoph.wickert at googlemail.com Wed May 13 14:49:59 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Wed, 13 May 2009 16:49:59 +0200 Subject: Breaking deps deliberately In-Reply-To: <20090513142742.GB19610@amd.home.annexia.org> References: <20090513111343.4d79d48f@faldor.intranet> <20090513134744.GA19304@amd.home.annexia.org> <4A0AD15F.6040300@fedoraproject.org> <20090513135728.GA19428@amd.home.annexia.org> <20090513142048.GA19610@amd.home.annexia.org> <20090513142742.GB19610@amd.home.annexia.org> Message-ID: <1242226199.3704.33.camel@localhost.localdomain> Am Mittwoch, den 13.05.2009, 15:27 +0100 schrieb Richard W.M. Jones: > On Wed, May 13, 2009 at 10:22:23AM -0400, Seth Vidal wrote: > > You couldn't be a 'provenphysicist' for example without understanding the > > laws of thermodynamics. > > At least the laws of thermodynamics are written down ... So are package maintainer responsibilities as well as QA criteria: "In Rawhide, updates to packages may cause other packages to have broken dependencies. Maintainers will be alerted when this happens, and should work to rebuild their packages with all due haste. Broken dependencies may leave end user systems in a state where no updates will be applied. In order to keep the distribution in a reasonable state, someone will step in and rebuild packages that have had dependency issues for some time, but package maintainers should not rely on these rebuilds." http://fedoraproject.org/wiki/Package_maintainer_responsibilities#Track_dependency_issues_in_a_timely_manner "* The distribution SHOULD not contain any broken EVR paths (i.e. packages that RPM considers "older" than those in the previous release). * The distribution SHOULD not contain any broken dependencies." https://fedoraproject.org/wiki/QA/ReleaseCriteria#Package_Sanity Regards, Christoph From kevin.kofler at chello.at Wed May 13 14:57:07 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 13 May 2009 16:57:07 +0200 Subject: Breaking deps deliberately References: <20090513111343.4d79d48f@faldor.intranet> <20090513134744.GA19304@amd.home.annexia.org> <4A0AD15F.6040300@fedoraproject.org> <20090513135728.GA19428@amd.home.annexia.org> <4A0AD421.7060308@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > If a package has a build-time dependency on libdvdcss, it wouldn't be > even allowed in Fedora due to the existing licensing guidelines. If it > is a optional run-time dependency, we don't need to bother about them. > This is a completely separate case. But if you write Requires: libdvdcss to enforce the runtime dependency, then the package would build, but it still wouldn't be acceptable. It would be a case of a broken dependency. Kevin Kofler From kevin.kofler at chello.at Wed May 13 15:04:40 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 13 May 2009 17:04:40 +0200 Subject: Breaking deps deliberately References: <20090513111343.4d79d48f@faldor.intranet> <20090513135208.GA1850@yoda.jdub.homelinux.org> Message-ID: Colin Walters wrote: > Would it be easier to do more extensive checks only for say security > updates? Maybe we could consider splitting fedora-updates into two > repos; fedora-updates-security and fedora-updates-all? That doesn't really work, because security updates in Fedora are usually not "security only" updates, but also have other changes, depend on non-security updates, both obsolete and get obsoleted by non-security updates etc. Having 2 separate updates repos would mean maintaining 2 separate branches of packages like Adam Williamson is describing, one with security updates only and one with the rest. That doubles the maintainer workload and doesn't help the case of security updates for the packages from "all" (because the packages in "security" would have only the security fix and not the changes previously done in "all"). Kevin Kofler From drago01 at gmail.com Wed May 13 15:15:56 2009 From: drago01 at gmail.com (drago01) Date: Wed, 13 May 2009 17:15:56 +0200 Subject: Breaking deps deliberately In-Reply-To: References: <20090513111343.4d79d48f@faldor.intranet> <20090513135208.GA1850@yoda.jdub.homelinux.org> Message-ID: On Wed, May 13, 2009 at 5:04 PM, Kevin Kofler wrote: > Colin Walters wrote: >> Would it be easier to do more extensive checks only for say security >> updates? ?Maybe we could consider splitting fedora-updates into two >> repos; fedora-updates-security and fedora-updates-all? > > That doesn't really work, because security updates in Fedora are usually > not "security only" updates, but also have other changes, depend on > non-security updates, both obsolete and get obsoleted by non-security > updates etc. Having 2 separate updates repos would mean maintaining 2 > separate branches of packages like Adam Williamson is describing, one with > security updates only and one with the rest. That doubles the maintainer > workload and doesn't help the case of security updates for the packages > from "all" (because the packages in "security" would have only the security > fix and not the changes previously done in "all"). + it wont solve anything anway .. if the a dep is broken yum will abort the whole transaction not only for the repo with the broken deps. From skvidal at fedoraproject.org Wed May 13 15:18:26 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 13 May 2009 11:18:26 -0400 (EDT) Subject: Breaking deps deliberately In-Reply-To: References: <20090513111343.4d79d48f@faldor.intranet> <20090513135208.GA1850@yoda.jdub.homelinux.org> Message-ID: On Wed, 13 May 2009, drago01 wrote: > On Wed, May 13, 2009 at 5:04 PM, Kevin Kofler wrote: >> Colin Walters wrote: >>> Would it be easier to do more extensive checks only for say security >>> updates? ?Maybe we could consider splitting fedora-updates into two >>> repos; fedora-updates-security and fedora-updates-all? >> >> That doesn't really work, because security updates in Fedora are usually >> not "security only" updates, but also have other changes, depend on >> non-security updates, both obsolete and get obsoleted by non-security >> updates etc. Having 2 separate updates repos would mean maintaining 2 >> separate branches of packages like Adam Williamson is describing, one with >> security updates only and one with the rest. That doubles the maintainer >> workload and doesn't help the case of security updates for the packages >> from "all" (because the packages in "security" would have only the security >> fix and not the changes previously done in "all"). > > + it wont solve anything anway .. if the a dep is broken yum will > abort the whole transaction not only for the repo with the broken > deps. well yum --skip-broken should be able to handle some of the broken deps - depending on how deeply broken things are. -sv From rjones at redhat.com Wed May 13 15:30:14 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 13 May 2009 16:30:14 +0100 Subject: Breaking deps deliberately In-Reply-To: <1242226199.3704.33.camel@localhost.localdomain> References: <20090513134744.GA19304@amd.home.annexia.org> <4A0AD15F.6040300@fedoraproject.org> <20090513135728.GA19428@amd.home.annexia.org> <20090513142048.GA19610@amd.home.annexia.org> <20090513142742.GB19610@amd.home.annexia.org> <1242226199.3704.33.camel@localhost.localdomain> Message-ID: <20090513153014.GA20064@amd.home.annexia.org> On Wed, May 13, 2009 at 04:49:59PM +0200, Christoph Wickert wrote: > "* The distribution SHOULD not contain any broken EVR paths (i.e. > packages that RPM considers "older" than those in the previous release). > * The distribution SHOULD not contain any broken dependencies." > https://fedoraproject.org/wiki/QA/ReleaseCriteria#Package_Sanity Yeah, that's not a packaging guideline though is it. That's a set of release criteria that the QA team use. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw From walters at verbum.org Wed May 13 15:37:15 2009 From: walters at verbum.org (Colin Walters) Date: Wed, 13 May 2009 11:37:15 -0400 Subject: Breaking deps deliberately In-Reply-To: References: <20090513111343.4d79d48f@faldor.intranet> <20090513135208.GA1850@yoda.jdub.homelinux.org> Message-ID: On Wed, May 13, 2009 at 11:04 AM, Kevin Kofler wrote: > Colin Walters wrote: >> Would it be easier to do more extensive checks only for say security >> updates? ?Maybe we could consider splitting fedora-updates into two >> repos; fedora-updates-security and fedora-updates-all? > > That doesn't really work, because security updates in Fedora are usually > not "security only" updates, but also have other changes, Well, "other changes" most often wouldn't break depsolving I'd think. > depend on > non-security updates, Can this be banned? It doesn't seem particularly onerous to also make your dependencies security updates. > both obsolete and get obsoleted by non-security > updates etc. This one seems like it should definitely be banned in a stable update. > Having 2 separate updates repos would mean maintaining 2 > separate branches of packages like Adam Williamson is describing, one with > security updates only and one with the rest. That doubles the maintainer > workload and doesn't help the case of security updates for the packages > from "all" (because the packages in "security" would have only the security > fix and not the changes previously done in "all"). Hmm, I wasn't thinking of separate CVS branches. In other words if there was a kernel security update, then a regular update, then another security, the new security update would *always* include the regular update. From walters at verbum.org Wed May 13 15:40:26 2009 From: walters at verbum.org (Colin Walters) Date: Wed, 13 May 2009 11:40:26 -0400 Subject: Breaking deps deliberately In-Reply-To: References: <20090513111343.4d79d48f@faldor.intranet> <20090513135208.GA1850@yoda.jdub.homelinux.org> Message-ID: On Wed, May 13, 2009 at 11:15 AM, drago01 wrote: > On Wed, May 13, 2009 at 5:04 PM, Kevin Kofler wrote: >> Colin Walters wrote: >>> Would it be easier to do more extensive checks only for say security >>> updates? ?Maybe we could consider splitting fedora-updates into two >>> repos; fedora-updates-security and fedora-updates-all? >> >> That doesn't really work, because security updates in Fedora are usually >> not "security only" updates, but also have other changes, depend on >> non-security updates, both obsolete and get obsoleted by non-security >> updates etc. Having 2 separate updates repos would mean maintaining 2 >> separate branches of packages like Adam Williamson is describing, one with >> security updates only and one with the rest. That doubles the maintainer >> workload and doesn't help the case of security updates for the packages >> from "all" (because the packages in "security" would have only the security >> fix and not the changes previously done in "all"). > > + it wont solve anything anway .. if the a dep is broken yum will > abort the whole transaction not only for the repo with the broken > deps. Good point, though this one is solvable client-side. In the current desktop experience you choose whether to install just security or everything every time. We could make that setting default to persistent, so that people who choose to do only security will have their yum configuration changed to disable updates-all. From tcallawa at redhat.com Wed May 13 15:42:55 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 13 May 2009 11:42:55 -0400 Subject: Fedora Community Pre-Beta Testing Message-ID: <4A0AEA7F.4060302@redhat.com> Since the previous post was buried in a thread about sound issues (are all emails on fedora-devel-list about sound issues), and I suspect that many of you have tuned out on a lot of those awful threads, I wanted to repost it where it might get seen. Fedora Community is a project with grand visions, tempered with mostly sane milestones. Our first milestone is focused on Fedora packagers, providing them with the information to help them be productive and minimize the need to jump between the various Fedora web tools (koji, bodhi, FAS, PKGDB, bugzilla). We've built it on top of Moksha, which you can read all about here: https://fedorahosted.org/moksha/ The Fedora Community demo instance is running and visible to others. We have not been aggressively advertising it up to this point because: A) It is a test instance, and the performance is non on-par with what it will be when we go live. We didn't want to spend time wading through the "OMG THIS IS SLOWER THAN BUGZLILLA!!!1!" B) We have been constantly cycling it as we've been fixing blocker bugs. The last thing we wanted was for anyone to think they could depend on it. C) Anyone who asked to see it has been pointed to it (several folks have asked). So, without further ado and the above caveats, look at our pre-beta test instance: https://publictest16.fedoraproject.org/community/ We know lots of stuff is broken, we have a pile of blocker bugs open in our trac instance. Please don't rely on this test instance for anything. For more information about Fedora Community, please look at: http://fedoraproject.org/wiki/FedoraCommunity Thanks, ~spot P.S. Our second milestone will be codename "Workflows". Got a workflow that you'd like to see the Fedora Community application handle? Either email it to me or join the moksha mailing list and suggest it there. From tcallawa at redhat.com Wed May 13 15:43:12 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 13 May 2009 11:43:12 -0400 Subject: Fedora Community Pre-Beta Testing Message-ID: <4A0AEA90.8020900@redhat.com> Since the previous post was buried in a thread about sound issues (are all emails on fedora-devel-list about sound issues), and I suspect that many of you have tuned out on a lot of those awful threads, I wanted to repost it where it might get seen. Fedora Community is a project with grand visions, tempered with mostly sane milestones. Our first milestone is focused on Fedora packagers, providing them with the information to help them be productive and minimize the need to jump between the various Fedora web tools (koji, bodhi, FAS, PKGDB, bugzilla). We've built it on top of Moksha, which you can read all about here: https://fedorahosted.org/moksha/ The Fedora Community demo instance is running and visible to others. We have not been aggressively advertising it up to this point because: A) It is a test instance, and the performance is non on-par with what it will be when we go live. We didn't want to spend time wading through the "OMG THIS IS SLOWER THAN BUGZLILLA!!!1!" B) We have been constantly cycling it as we've been fixing blocker bugs. The last thing we wanted was for anyone to think they could depend on it. C) Anyone who asked to see it has been pointed to it (several folks have asked). So, without further ado and the above caveats, look at our pre-beta test instance: https://publictest16.fedoraproject.org/community/ We know lots of stuff is broken, we have a pile of blocker bugs open in our trac instance. Please don't rely on this test instance for anything. For more information about Fedora Community, please look at: http://fedoraproject.org/wiki/FedoraCommunity Thanks, ~spot P.S. Our second milestone will be codename "Workflows". Got a workflow that you'd like to see the Fedora Community application handle? Either email it to me or join the moksha mailing list and suggest it there. From mike at cchtml.com Wed May 13 15:55:55 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Wed, 13 May 2009 10:55:55 -0500 Subject: Breaking deps deliberately In-Reply-To: References: <20090513111343.4d79d48f@faldor.intranet> <20090513135208.GA1850@yoda.jdub.homelinux.org> Message-ID: <4A0AED8B.5050909@cchtml.com> -------- Original Message -------- Subject: Re: Breaking deps deliberately From: Colin Walters To: Development discussions related to Fedora Date: 05/13/2009 10:40 AM > > Good point, though this one is solvable client-side. In the current > desktop experience you choose whether to install just security or > everything every time. We could make that setting default to > persistent, so that people who choose to do only security will have > their yum configuration changed to disable updates-all. > I'm not sure why you think we need entirely separate repos for this kind of action. PackageKit is aware of update levels. Bug fix, security fix, or regular feature update. You could add functionality to PackageKit that allows you default the type of updates you want instead of all updates. Right now you can just manually uncheck the updates you do not want, so if they don't have a red icon next to them. In fact, I think the notification window you get that says "Security Updates only" would get you on your way. From awilliam at redhat.com Wed May 13 16:16:48 2009 From: awilliam at redhat.com (Adam Williamson) Date: Wed, 13 May 2009 09:16:48 -0700 Subject: Who Fedora isn't for (Was: Re: OpenOffice 3.1) In-Reply-To: References: <4A034FD0.40103@gnat.ca> <1242146510.2923.766.camel@adam.local.net> <1242169749.2923.883.camel@adam.local.net> <3adc77210905121636l5f42d05di23b6479873256b1a@mail.gmail.com> <1242172335.2923.891.camel@adam.local.net> <17jqd6-d8i.ln1@ppp1053.in.ipex.cz> <4A0ACA58.2090604@fedoraproject.org> Message-ID: <1242231408.2923.898.camel@adam.local.net> On Wed, 2009-05-13 at 10:15 -0400, James Hubbard wrote: > I think being explicit in target user expectations is a good idea. It > seems like bike shedding, but it comes up enough that it's probably a > good idea. Yeah, it really isn't. I'm coming up against this *all the time*. Simple example - we're reviewing important issues for release. Imagine a bug which affects, say, five pretty popular models of Intel graphics card. They completely fail to work on boot to X - you just get a black screen. But it can easily be worked around by adding 'nomodeset' as a kernel parameter. Is that a really critical issue? It depends! If we're a distro for Aunt Flo, yes, it is. We can't go telling Aunt Flo to stick 'nomodeset' on the kernel command line. Or, at least, we should try really hard not to. If we're not a distro for Aunt Flo, it's not very important at all. If you're not Aunt Flo you should bloody well be able to figure that out yourself, or at least you should be comfortable reading the release notes or poking someone on IRC, and not at all fazed by the answer "oh, yeah, just throw 'nomodeset' in as a kernel parameter". That's just one example, it comes up all the time. And, where this thread came in - it's a very important factor in the 'what should updates policy be' question. It's important in the 'what kind of questions should the installer ask' issue. It's important all over the place. I find it tricky to work on QA or packaging stuff without knowing who our target audience is. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From lili at redhat.com Wed May 13 16:16:52 2009 From: lili at redhat.com (Liam) Date: Thu, 14 May 2009 00:16:52 +0800 Subject: 2009-05-14 - Fedora Test Day - IBus input method In-Reply-To: <4A082F3D.6070500@redhat.com> References: <4A082F3D.6070500@redhat.com> Message-ID: <4A0AF274.3080602@redhat.com> Greetings testers, A lot of thanks for those who have provide some encountered issues before test day. We will confirm these issues in test day. Come on, join #fedora-qa , let's have the exciting experience for ibus on F11 today. A liveCD will be ready for us, see more from: https://fedoraproject.org/wiki/Test_Day:2009-05-14_iBus Thanks Liam Liam ??: > Greetings testers, > > IBus input method - Ibus has been rewritten in C, and provides a simple, > clean default system for changing the way international users input > information into a Fedora system. > Most of the work on iBus is being done upstream by Huang Peng. This > feature proposal covers moving from scim to ibus as the default input > method framework for Fedora 11 > iBus is designed to improve a number of deficiencies of scim: > > * Ibus has been rewritten in C. Scim written in C++ using STL has > problems with weak symbol conflicts without the added complexity and > lower stability of the scim-bridge layer to workaround that. > * It is possible to write client and engines for ibus in any language > that supports dbus bindings. > * ibus loads engines on demand rather than all installed engines as scim > does, which improves the startup time and memory footprint. > * scim loads engines as dl-modules so a problem in any engine can take > down scim, whereas in ibus because the processes are separated only a > faulty process will die leaving rest of the system working normally. > * The architecture of ibus is bus-centric and so much closer to the CJK > OSS Forum Workgroup 3 draft "Specification of IM engine Service Provider > Interface" architecture, which might be supportable in the future. > > I'd like to invite you to join #fedora-qa this Thursday, May 14, 2009 to > test Ibus input method.Get more details from: > https://fedoraproject.org/wiki/Test_Day:2009-05-14_iBus > > Thanks, > Liam > > From rawhide at fedoraproject.org Wed May 13 16:22:20 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Wed, 13 May 2009 16:22:20 +0000 (UTC) Subject: rawhide report: 20090513 changes Message-ID: <20090513162220.49B271F820A@releng2.fedora.phx.redhat.com> Compose started at Wed May 13 06:15:05 UTC 2009 Updated Packages: dhcp-4.1.0-20.fc11 ------------------ * Wed May 06 2009 David Cantrell - 12:4.1.0-20 - Obsolete libdhcp4client <= 12:4.0.0-34.fc10 (#499290) dhcpv6-1.2.0-2.fc11 ------------------- * Wed May 06 2009 David Cantrell - 1.2.0-2 - Obsolete libdhcp6client <= 1.0.22-1.fc10 (#499290) file-5.03-1.fc11 ---------------- * Tue May 12 2009 Daniel Novotny 5.03-1 - new upstream version generic-logos-11.0.1-1.fc11 --------------------------- * Tue May 12 2009 Bill Nottingham - 11.0.1-1 - Add new plymouth artwork (#500239) kernel-2.6.29.3-140.fc11 ------------------------ * Tue May 12 2009 Josef Bacik - bring btrfs uptodate with mainline * Tue May 12 2009 Kyle McMartin 2.6.29.3-139 - git-bluetooth.patch: suck in three more fixes from 2.6.30. * Tue May 12 2009 Kyle McMartin 2.6.29.3-140 - git-bluetooth-fixes.patch: fix build error in backport from previous commit. * Mon May 11 2009 Kyle McMartin 2.6.29.3-137 - net-revert-forcedeth-power-down-phy-when-interface-is.patch: Attempt to fix forcedeth failures, (#484505) * Sat May 09 2009 Chuck Ebbert 2.6.29.3-136 - Add more verbose debug messages for bug #498401 * Fri May 08 2009 Kyle McMartin 2.6.29.2-134 - linux-2.6-mm-lru-dont-evict-mapped-executable-pages.patch linux-2.6-mm-lru-evict-streaming-io-pages-first.patch Add VM patches from Rik to fix responsiveness, tested on the rawhide kernel. * Fri May 08 2009 Kyle McMartin 2.6.29.3-135 - Linux 2.6.29.3 - Merged patches: linux-2.6-x86-64-fix-fpu-corruption-with-signals-and-preemption.patch linux-2.6-ath9k-Fix-FIF_BCN_PRBRESP_PROMISC-handling.patch drm-intel-g41.patch drm-intel-tiled-front.patch - Rebased patches: drm-next.patch - pci ids rejects linux-2.6-utrace.patch - fs/proc/array.c rejects linux-2.6-execshield.patch - fs/proc/array.c, drop useless hunk, dropped already in rawhide. linux-2.6-iommu-fixes.patch - single merged patch from series. * Thu May 07 2009 Ben Skeggs 2.6.29.2-131 - drm-nouveau.patch: fix bar1 mtrr size * Thu May 07 2009 Kristian H??gsberg 2.6.29.2-132 - drm intel fixes: Add PCI IDs for G41, fix tiling after resume. * Thu May 07 2009 Adam Jackson - drm-intel-debugfs-ringbuffer.patch: Add debugfs support for intel_gpu_dump utility. leonidas-kde-theme-11.0.1-1.fc11 -------------------------------- * Tue May 12 2009 Jaroslav Reznik 11.0.0-1 - synchronize versioning with leonidas-backgrounds - leonidas lion and landscape theme * Tue May 12 2009 Jaroslav Reznik 11.0.1-1 - reenable icon labels * Mon May 11 2009 Jaroslav Reznik 0.2.5-1 - text overflow (bz#498630) nss-3.12.3-4.fc11 ----------------- * Fri May 08 2009 Kai Engert - 3.12.3-4 - add conflicts info in order to fix bug 499436 pykickstart-1.53-1.fc11 ----------------------- * Wed Apr 29 2009 Chris Lumens - 1.53-1 - Move lineno= from KSOptionParser.__init__ to parse_args (#497149). (clumens) - Use the F11 version of the partition command. (clumens) - Remove the --start and --end options since anaconda no longer uses them. (clumens) - Remove a broken test case. (clumens) trac-git-plugin-0.11.0.2-4.20090511svn5396.fc11 ----------------------------------------------- * Mon May 11 2009 Jesse Keating - 0.11.0.2-1.20090511svn5396 - Update for trac 0.11. Drop patches as those are in the 0.11 branch. * Mon May 11 2009 Jesse Keating - 0.11.0.2-2.20090511svn5396 - Drop COPYING, it doesn't make it into the tarball. wesnoth-1.6.2-1.fc11 -------------------- * Tue May 12 2009 Jon Ciesla - 1.6.2-1 - 1.6.2 maintenance release. xorg-x11-drv-geode-2.11.2-1.fc11 -------------------------------- * Tue May 12 2009 Chris Ball 2.11.2-1 - fix crasher bug due to EXA ABI change: RHBZ #500086 Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 11 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From jkeating at redhat.com Wed May 13 16:22:25 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 13 May 2009 09:22:25 -0700 Subject: Breaking deps deliberately In-Reply-To: <4A0AED8B.5050909@cchtml.com> References: <20090513111343.4d79d48f@faldor.intranet> <20090513135208.GA1850@yoda.jdub.homelinux.org> <4A0AED8B.5050909@cchtml.com> Message-ID: <1242231745.6282.3.camel@localhost.localdomain> On Wed, 2009-05-13 at 10:55 -0500, Michael Cronenworth wrote: > I'm not sure why you think we need entirely separate repos for this kind > of action. PackageKit is aware of update levels. Bug fix, security fix, > or regular feature update. You could add functionality to PackageKit > that allows you default the type of updates you want instead of all > updates. Right now you can just manually uncheck the updates you do not > want, so if they don't have a red icon next to them. In fact, I think > the notification window you get that says "Security Updates only" would > get you on your way. The problem here is that packages get multiple updates. Lets say update 1 is non security. Update 2 is security. Updates 3 and 4 are non security. User Bob does a fresh install, and in order to get the security update, he has to update to update 4, which has 3 non security updates rolled into it. He might as well just update everything. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kevin at scrye.com Wed May 13 16:24:08 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 13 May 2009 10:24:08 -0600 Subject: Bug lifecycle page revised / expanded In-Reply-To: <870180fe0905121230o77860ccrab2712ec1a23c16c@mail.gmail.com> References: <1242155333.2923.844.camel@adam.local.net> <870180fe0905121230o77860ccrab2712ec1a23c16c@mail.gmail.com> Message-ID: <20090513102408.76bd182d@ohm.scrye.com> On Tue, 12 May 2009 13:30:59 -0600 Jerry James wrote: > On Tue, May 12, 2009 at 1:08 PM, Adam Williamson > wrote: > > Hi, everyone - just a quick note that, last week, I revised / > > expanded the bug lifecycle page: > > > > https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow > > I have two questions about situations outside the realm of bug triage. > Both involve package reviews. > > 1. Suppose I submit a package for review, and then later decide that I > want to withdraw the submission for some reason. (I had this happen > recently when legal problems with the package came to light.) The > review bug should go to state CLOSED, but with what reason? WONTFIX? Yes. See: https://fedoraproject.org/wiki/Package_Review_Process > 2. Suppose I decide to review a package submission. I assign the > review bug to myself. The review turns up some problems that need to > be fixed. The person submitting the package doesn't respond for a > long time. Now what? Do I mark the bug NEEDINFO? What if the > submitter still doesn't respond? (I've got several bugs assigned to > me that are currently in this state.) https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews kevin > Thanks, -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From cmadams at hiwaay.net Wed May 13 16:24:40 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 13 May 2009 11:24:40 -0500 Subject: GRUB menu for options (was: Re: Who Fedora isn't for (Was: Re: OpenOffice 3.1)) In-Reply-To: <1242231408.2923.898.camel@adam.local.net> References: <1242169749.2923.883.camel@adam.local.net> <3adc77210905121636l5f42d05di23b6479873256b1a@mail.gmail.com> <1242172335.2923.891.camel@adam.local.net> <17jqd6-d8i.ln1@ppp1053.in.ipex.cz> <4A0ACA58.2090604@fedoraproject.org> <1242231408.2923.898.camel@adam.local.net> Message-ID: <20090513162440.GB1167976@hiwaay.net> Once upon a time, Adam Williamson said: > Is that a really critical issue? It depends! If we're a distro for Aunt > Flo, yes, it is. We can't go telling Aunt Flo to stick 'nomodeset' on > the kernel command line. Or, at least, we should try really hard not to. Completely off-topic, but this is something that has been kicking around in my head for a long time: would it be possible to extend GRUB to have a secondary menu of kernel options like "nomodeset", "relabel", etc.? Basically have the common debugging and error-recovery type options in a pre-set menu (maybe shared among all "Linux kernel type" entries). This would make it a little easier (and less typo-prone) for the average person to access these options. This would be something kind of like the Windows boot process, where if you hold a key (or whatever it is), you can get the "Safe mode", "Normal boot", etc. menu. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jkeating at redhat.com Wed May 13 16:26:19 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 13 May 2009 09:26:19 -0700 Subject: best practices for updates in stable releases (was: Re: OpenOffice 3.1) In-Reply-To: <1242205246.31003.17.camel@blaa> References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <4A05B234.2020608@leemhuis.info> <1241890311.2886.63.camel@localhost.localdomain> <1242054913.3452.16.camel@localhost.localdomain> <1242144256.21430.4.camel@blaa> <1242145782.3452.108.camel@localhost.localdomain> <1242205246.31003.17.camel@blaa> Message-ID: <1242231979.6282.4.camel@localhost.localdomain> On Wed, 2009-05-13 at 10:00 +0100, Mark McLoughlin wrote: > Agreed, it shouldn't fall to one person. > > e.g. during the freeze, I noticed at least spot, notting, warren, jwb, > rdieter and yourself reviewing tag requests. I'm sure others would be > happy to help too, I know I would. They are all regular members of the release engineering team. That team is an open team, anybody is welcome to join, and I'd love for more people to join and help out. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Wed May 13 16:28:43 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 13 May 2009 09:28:43 -0700 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: References: <4A0814ED.60205@redhat.com> <4A09B8FE.4040904@cygnusx-1.org> <4A09C018.4060906@cygnusx-1.org> <4A09CBE4.4020807@cygnusx-1.org> Message-ID: <1242232123.6282.5.camel@localhost.localdomain> On Wed, 2009-05-13 at 14:55 +0200, Kevin Kofler wrote: > The problem is that Fedora can't change anything in Thunderbird (nor > Firefox) without upstream buy-in because the maintainer refuses to rename > the programs and thus we're bound by Mozilla's strict (and IMHO completely > unreasonable and unacceptable in the Free Software world) trademark policy. You do realize that Fedora's trademark policy is even "worse" ? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mw_triad at users.sourceforge.net Wed May 13 16:37:28 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 13 May 2009 11:37:28 -0500 Subject: SPARC Status (Was Re: Secondary Architecture Status?) In-Reply-To: <4A0A2C97.3010403@freenet.de> References: <1241911202.24436.81.camel@macbook.infradead.org> <4A0862F1.2030608@redhat.com> <20090511185147.GA3256@yoda.jdub.homelinux.org> <1242071724.2923.656.camel@adam.local.net> <4A0909BB.4030807@freenet.de> <4A0A2C97.3010403@freenet.de> Message-ID: Ralf Corsepius wrote: > Matthew Woehlke wrote: >> Ralf Corsepius wrote: >>> It likely is something worth looking into, but based on my >>> experiences with Fedora on my netbook, I am having doubts compiler >>> optimizations alone are worth a "secondary arch". >>> >>> At least on my netbook, neither "speed" or "space" (mine has a disk) >>> are actual problems. >> >> Is for me! :-) But I don't think -Os is the solution; the problems >> tend to be long dep-chains and data (and especially, the intersection >> of both*). > > Do I understand correctly, your issue is disk-space? Are you installing > to a (slow?) small solid state disk? Yes and yes (although only running updates does slowness seem to be a problem; IIRC read speed on SSD's usually exceeds write speed by quite a bit). > How big is it? I have a little under 3 GB for / and /boot (same partition). The rest is /home on a separate partition. > However, I would not understand issues related to cpu-speed, because my > own netbook (Intel(R) Atom(TM) CPU N270 at 1.60GHz, 1 GB RAM) easily > outperforms older machines I have around. Yes. Sorry, I should have been more clear; "space" is the problem. Speed not so much; as you say, performance is very adequate :-). It's just the process of trying to cram as much usable stuff as possible into the tiny SSD that can be challenging. (For example, I'm running KDE, and both OOo and Firefox are too big to comfortably fit.) Having said that... if I bought another netbook today, I would probably still stay with an SSD (though I would look for a 16 GB). It's nice to not worry about the drive crashing due to vibration :-). -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- "So long, and thanks for all the fish" -- the dolphins (from Douglas Adams' HHGttG) From loganjerry at gmail.com Wed May 13 16:40:45 2009 From: loganjerry at gmail.com (Jerry James) Date: Wed, 13 May 2009 10:40:45 -0600 Subject: Bug lifecycle page revised / expanded In-Reply-To: <20090513102408.76bd182d@ohm.scrye.com> References: <1242155333.2923.844.camel@adam.local.net> <870180fe0905121230o77860ccrab2712ec1a23c16c@mail.gmail.com> <20090513102408.76bd182d@ohm.scrye.com> Message-ID: <870180fe0905130940o32b0148drda18ab96b086f10@mail.gmail.com> On Wed, May 13, 2009 at 10:24 AM, Kevin Fenzi wrote: > Yes. See: > https://fedoraproject.org/wiki/Package_Review_Process Aha. I've actually read that page, but that particular point failed to penetrate my thick skull, it seems. > https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews I've somehow managed to avoid finding this page. I clearly need to spend some more time digging through the wiki to see what else I can find. Thanks, Kevin! -- Jerry James http://www.jamezone.org/ From mw_triad at users.sourceforge.net Wed May 13 16:46:31 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 13 May 2009 11:46:31 -0500 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: References: <4A0814ED.60205@redhat.com> <4A09B8FE.4040904@cygnusx-1.org> <4A09C018.4060906@cygnusx-1.org> <4A09CBE4.4020807@cygnusx-1.org> Message-ID: Kevin Kofler wrote: > Nathan Grennan wrote: >> I understand, but on the other hand does Fedora want a dozen bug >> reports over Thunderbird being useless, because of a crappy default? > > The problem is that Fedora can't change anything in Thunderbird (nor > Firefox) without upstream buy-in because the maintainer refuses to rename > the programs and thus we're bound by Mozilla's strict (and IMHO completely > unreasonable and unacceptable in the Free Software world) trademark policy. What's to stop someone ITP'ing* icecat? Get it in the repo, and go from there. If you can't work /with/ the maintainer(s), work around them. (* Intent To Package. Yeah, I'm borrowing Cygwin terminology, sorry. Not sure what the equivalent in Fedora slang would be.) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- "So long, and thanks for all the fish" -- the dolphins (from Douglas Adams' HHGttG) From a.badger at gmail.com Wed May 13 16:15:57 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 13 May 2009 09:15:57 -0700 Subject: Breaking deps deliberately In-Reply-To: References: <20090513111343.4d79d48f@faldor.intranet> <20090513135208.GA1850@yoda.jdub.homelinux.org> Message-ID: <4A0AF23D.9090000@gmail.com> Colin Walters wrote: > On Wed, May 13, 2009 at 11:15 AM, drago01 wrote: >> + it wont solve anything anway .. if the a dep is broken yum will >> abort the whole transaction not only for the repo with the broken >> deps. > > Good point, though this one is solvable client-side. In the current > desktop experience you choose whether to install just security or > everything every time. We could make that setting default to > persistent, so that people who choose to do only security will have > their yum configuration changed to disable updates-all. > The basics of that can work but not unless there's serverside changes as well. If the security update needs something from the updates-all repo then the updates-all repo will need to be enabled client-side. To do what you want sanely and disable the updates-all repo, bodhi would need to grow the ability to recursively pull deps from the updates repo into the security repo (in addition to merely tossing out packages that have unsatisfied deps). -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From kwizart at gmail.com Wed May 13 16:52:05 2009 From: kwizart at gmail.com (Nicolas Chauvet) Date: Wed, 13 May 2009 18:52:05 +0200 Subject: rpms/xfce4-notifyd/F-11 xfce4-notifyd.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2 In-Reply-To: <20090506234831.C430970108@cvs1.fedora.phx.redhat.com> References: <20090506234831.C430970108@cvs1.fedora.phx.redhat.com> Message-ID: 2009/5/7 Christoph Wickert : > Author: cwickert > .... > --- NEW FILE xfce4-notifyd.spec --- > # Review: https://bugzilla.redhat.com/show_bug.cgi?id=499282 > > Name: ? ? ? ? ? xfce4-notifyd > Version: ? ? ? ?0.1.0 > Release: ? ? ? ?1%{?dist} > Summary: ? ? ? ?Simple notification daemon for Xfce > > Group: ? ? ? ? ?User Interface/Desktops > License: ? ? ? ?GPLv2 > URL: ? ? ? ? ? ?http://spuriousinterrupt.org/projects/xfce4-notifyd > Source0: ? ? ? ?http://spuriousinterrupt.org/files/xfce4-notifyd/xfce4-notifyd-%{version}.tar.bz2 > BuildRoot: ? ? ?%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) > > BuildRequires: ?gtk2-devel >= 2.10.0 > BuildRequires: ?libxfcegui4-devel >= 4.5.90 > BuildRequires: ?xfconf-devel >= 4.5.90 > BuildRequires: ?dbus-glib-devel >= 0.72 > BuildRequires: ?libglade2-devel >= 2.6.0 > BuildRequires: ?libsexy-devel >= 0.1.6 > BuildRequires: ?desktop-file-utils > BuildRequires: ?intltool > Requires: ? ? ? dbus > Requires: ? ? ? hicolor-icon-theme > # the package conflicts with Gnome's notification-daemon > Conflicts: ? ? ?notification-daemon > # but also provides > Provides: ? ? ? desktop-notification-daemon > # and obsoletes all notification-daemon-xfce releases > Obsoletes: ? ? ?notification-daemon-xfce <= 0.3.7 ^^ And now from the root.log for building a package on F12: ------------------------------- DEBUG util.py:280: Executing command: /usr/bin/yum --installroot /var/lib/mock/dist-f12-build-452465-72955/root/ install 'pth-devel' 'libX11-devel' 'doxygen' 'xosd-devel' 'ncurses-devel' 'lirc-devel' 'libXext-devel' 'graphviz' 'libusb-devel' 'libtool' 'docbook-dtds' 'openldap-devel' 'svgalib-devel' 'xmlto' 'nfs-utils-lib-devel' DEBUG util.py:256: xfce4-notifyd-0.1.0-1.fc12.i586 from build has depsolving problems DEBUG util.py:256: --> xfce4-notifyd conflicts with notification-daemon DEBUG util.py:256: Error: xfce4-notifyd conflicts with notification-daemon DEBUG util.py:319: Child returncode was: 1 ------------------------------- Why xfce4-notifyd believe it is better than notification-daemon ? From christoph.wickert at googlemail.com Wed May 13 17:03:03 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Wed, 13 May 2009 19:03:03 +0200 Subject: rpms/xfce4-notifyd/F-11 xfce4-notifyd.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2 In-Reply-To: References: <20090506234831.C430970108@cvs1.fedora.phx.redhat.com> Message-ID: <1242234183.10712.3.camel@localhost.localdomain> Am Mittwoch, den 13.05.2009, 18:52 +0200 schrieb Nicolas Chauvet: > 2009/5/7 Christoph Wickert : > > Author: cwickert > > > .... > > --- NEW FILE xfce4-notifyd.spec --- > > # Review: https://bugzilla.redhat.com/show_bug.cgi?id=499282 > > > > Name: xfce4-notifyd > > Version: 0.1.0 > > Release: 1%{?dist} > > Summary: Simple notification daemon for Xfce > > > > Group: User Interface/Desktops > > License: GPLv2 > > URL: http://spuriousinterrupt.org/projects/xfce4-notifyd > > Source0: http://spuriousinterrupt.org/files/xfce4-notifyd/xfce4-notifyd-%{version}.tar.bz2 > > BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) > > > > BuildRequires: gtk2-devel >= 2.10.0 > > BuildRequires: libxfcegui4-devel >= 4.5.90 > > BuildRequires: xfconf-devel >= 4.5.90 > > BuildRequires: dbus-glib-devel >= 0.72 > > BuildRequires: libglade2-devel >= 2.6.0 > > BuildRequires: libsexy-devel >= 0.1.6 > > BuildRequires: desktop-file-utils > > BuildRequires: intltool > > Requires: dbus > > Requires: hicolor-icon-theme > > # the package conflicts with Gnome's notification-daemon > > Conflicts: notification-daemon > > # but also provides > > Provides: desktop-notification-daemon > > # and obsoletes all notification-daemon-xfce releases > > Obsoletes: notification-daemon-xfce <= 0.3.7 > ^^ What's wrong with obsoleing notification-daemon-xfce? Note that notification-deamon-xfce != notification-daemon. > And now from the root.log for building a package on F12: > ------------------------------- > DEBUG util.py:280: Executing command: /usr/bin/yum --installroot > /var/lib/mock/dist-f12-build-452465-72955/root/ install 'pth-devel' > 'libX11-devel' 'doxygen' 'xosd-devel' 'ncurses-devel' 'lirc-devel' > 'libXext-devel' 'graphviz' 'libusb-devel' 'libtool' 'docbook-dtds' > 'openldap-devel' 'svgalib-devel' 'xmlto' 'nfs-utils-lib-devel' > DEBUG util.py:256: xfce4-notifyd-0.1.0-1.fc12.i586 from build has > depsolving problems > DEBUG util.py:256: --> xfce4-notifyd conflicts with notification-daemon > DEBUG util.py:256: Error: xfce4-notifyd conflicts with notification-daemon > DEBUG util.py:319: Child returncode was: 1 > ------------------------------- > > Why xfce4-notifyd believe it is better than notification-daemon ? It doesn't, so do I. Yum does, because some packages have hardcoded notification-daemon instead of it's virtual provides for desktop-notification-daemon. Please read the "koji breakage for F12 builds" thread for more info. Regards, Christoph From mtasaka at ioa.s.u-tokyo.ac.jp Wed May 13 17:08:03 2009 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 14 May 2009 02:08:03 +0900 Subject: koji breakage for F12 builds In-Reply-To: <1242172496.3569.15.camel@localhost.localdomain> References: <5256d0b0905121504k4768401an741dd4d0bd5cf045@mail.gmail.com> <1242172496.3569.15.camel@localhost.localdomain> Message-ID: <4A0AFE73.2060207@ioa.s.u-tokyo.ac.jp> Christoph Wickert wrote, at 05/13/2009 08:54 AM +9:00: > Am Dienstag, den 12.05.2009, 23:04 +0100 schrieb Peter Robinson: >> Just tried building a new package and it seems that it breaks because >> xfce4-notifyd conflicts with notification-daemon.... wicked the new >> rawhide is broken before the old rawhide is done and dusted :-) > > See https://fedorahosted.org/rel-eng/ticket/1788 > > xfce4-notifyd conflicts with notification-daemon because both provide > /usr/share/dbus-1/services/org.freedesktop.Notifications.service > > For compatibility they both provide a virtual > desktop-notification-daemon, but ATM the "Conflicts: xfce4-notifyd" is > missing from the notification-daemon package. Filed as > https://bugzilla.redhat.com/show_bug.cgi?id=500513 > >> http://koji.fedoraproject.org/koji/getfile?taskID=1351516&name=root.log > > The strange thing about this log: I don't see it installing > notification-daemon. So where is the problem? > > /me is confused > Christoph Well, I saw that ucommon (which I reviewed and accepted) won't build on dist-f12 with the same issue. http://koji.fedoraproject.org/koji/buildinfo?buildID=102002 yum debug log (debuglevel = 3) shows that: ----------------------------------------------------------------- DEBUG: --> Processing Dependency: fedora-gnome-theme >= 8.0.0 for package: libgnome DEBUG: Matched fedora-gnome-theme-8.0.0-9.fc11.noarch to require for fedora-gnome-theme DEBUG: TSINFO: Marking fedora-gnome-theme-8.0.0-9.fc11.noarch as install for libgnome-2.26.0-1.fc11.i586 DEBUG: --> Processing Dependency: notification-daemon-engine-nodoka for package: fedora-gnome-theme DEBUG: Matched notification-daemon-engine-nodoka-0.1.0-6.fc11.i586 to require for notification-daemon-engine-nodoka DEBUG: TSINFO: Marking notification-daemon-engine-nodoka-0.1.0-6.fc11.i586 as install for fedora-gnome-theme-8.0.0-9.fc11.noarch --> Processing Dependency: notification-daemon for package: notification-daemon-engine-nodoka Matched notification-daemon-0.4.0-3.fc11.i586 to require for notification-daemon TSINFO: Marking notification-daemon-0.4.0-3.fc11.i586 as install for notification-daemon-engine-nodoka-0.1.0-6.fc11.i586 DEBUG: ---> Package libnotify.i586 0:0.4.5-2.fc11 set to be updated DEBUG: --> Processing Dependency: desktop-notification-daemon for package: libnotify DEBUG: Matched xfce4-notifyd-0.1.0-1.fc12.i586 to require for desktop-notification-daemon DEBUG: Matched notification-daemon-0.4.0-3.fc11.i586 to require for desktop-notification-daemon DEBUG: TSINFO: Marking xfce4-notifyd-0.1.0-1.fc12.i586 as install for libnotify-0.4.5-2.fc11.i586 Error: xfce4-notifyd conflicts with notification-daemon --------------------------------------------------------------- Full log: http://mtasaka.fedorapeople.org/mock-fc12-conflicts/MOCK-ucommon.log Regards, Mamoru From kwizart at gmail.com Wed May 13 17:17:19 2009 From: kwizart at gmail.com (Nicolas Chauvet) Date: Wed, 13 May 2009 19:17:19 +0200 Subject: koji breakage for F12 builds In-Reply-To: <1242224153.10107.27.camel@code.and.org> References: <5256d0b0905121504k4768401an741dd4d0bd5cf045@mail.gmail.com> <1242172496.3569.15.camel@localhost.localdomain> <20090513084302.1fb20a62@faldor.intranet> <1242213324.3704.8.camel@localhost.localdomain> <1242220510.25471.6431.camel@cookie.hadess.net> <1242224153.10107.27.camel@code.and.org> Message-ID: 2009/5/13 James Antill : > On Wed, 2009-05-13 at 14:15 +0100, Bastien Nocera wrote: >> On Wed, 2009-05-13 at 13:15 +0200, Christoph Wickert wrote: >> > I think the problem is, that some packages ?notification-deamon instead >> > of (virtual) desktop-notification-deamon: > [...] >> Except that I don't see why those would cause problems during the build, >> when they're not even getting installed in the buildroots. >> >> The problem was/is that libnotify-devel requires a >> desktop-notification-daemon (via libnotify itself), and yum will install >> both packages that provide it. > > ?How did you come to this conclusion? > ?I'm not saying it's impossible, but the above seems unlikely unless yum > picks one on the virtual provides hit and then it gets an explicit > requires on the other (which isn't the same thing). xfce4-notifyd : 12 characters notification-daemon: 19 characters Short name wins! xfce4-notifyd is picked unless something within the dependencies is hardcoded to notification-daemon. And that's how xfce4 won the battle for the default desktop in the rpm world... Nicolas (kwizart) From mtasaka at ioa.s.u-tokyo.ac.jp Wed May 13 17:26:41 2009 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 14 May 2009 02:26:41 +0900 Subject: koji breakage for F12 builds In-Reply-To: <1242213324.3704.8.camel@localhost.localdomain> References: <5256d0b0905121504k4768401an741dd4d0bd5cf045@mail.gmail.com> <1242172496.3569.15.camel@localhost.localdomain> <20090513084302.1fb20a62@faldor.intranet> <1242213324.3704.8.camel@localhost.localdomain> Message-ID: <4A0B02D1.9090102@ioa.s.u-tokyo.ac.jp> Christoph Wickert wrote, at 05/13/2009 08:15 PM +9:00: > Am Mittwoch, den 13.05.2009, 08:43 +0200 schrieb Michael Schwendt: >> On Wed, 13 May 2009 01:54:56 +0200, Christoph wrote: >> >>> Am Dienstag, den 12.05.2009, 23:04 +0100 schrieb Peter Robinson: >>>> Just tried building a new package and it seems that it breaks because >>>> xfce4-notifyd conflicts with notification-daemon.... wicked the new >>>> rawhide is broken before the old rawhide is done and dusted :-) >>> See https://fedorahosted.org/rel-eng/ticket/1788 >>> >>> xfce4-notifyd conflicts with notification-daemon because both provide >>> /usr/share/dbus-1/services/org.freedesktop.Notifications.service >>> >>> For compatibility they both provide a virtual >>> desktop-notification-daemon, but ATM the "Conflicts: xfce4-notifyd" is >>> missing from the notification-daemon package. Filed as >>> https://bugzilla.redhat.com/show_bug.cgi?id=500513 >>> >>>> http://koji.fedoraproject.org/koji/getfile?taskID=1351516&name=root.log >>> The strange thing about this log: I don't see it installing >>> notification-daemon. So where is the problem? >>> >>> /me is confused >>> Christoph >> The output of the yum resolvedep step doesn't list xfce4-notifyd either. >> >> I don't have my notes about koji's static repos here, so I cannot >> find and repoquery the F-12 repodata to find out --whatrequires several >> of these "Provides", but... >> >> notification-daemon >> http://koji.fedoraproject.org/koji/rpminfo?rpmID=1199322 >> >> Provides >> config(notification-daemon) = 0.4.0-3.fc11 >> desktop-notification-daemon >> libstandard.so()(64bit) >> notification-daemon = 0.4.0-3.fc11 >> notification-daemon(x86-64) = 0.4.0-3.fc11 >> notify-daemon >> >> Can you rule out that anything in the dependency-chain pulls in >> notification-daemon _and_ xfce4-notify due to competing Provides? > > How would I check that? > >> E.g. notify-daemon and desktop-notification-daemon and the package name >> itself, notification-daemon. > > I think the problem is, that some packages notification-deamon instead > of (virtual) desktop-notification-deamon: > > # repoquery --repoid rawhide --whatrequires notification-daemon > gnome-bluetooth-0:2.27.5-1.fc11.i586 > notify-python-0:0.1.1-6.fc11.i586 > notification-daemon-engine-nodoka-0:0.1.0-6.fc11.i586 > system-config-printer-0:1.1.7-1.fc11.i586 > ibus-0:1.1.0.20090423-1.fc11.i586 > > I'm going to file bugs against these packages except > notification-daemon-engine-nodoka, because it only works with > notification-daemon. > > Regards, > Christoph Well, this won't work for this issue, because: - With yum shorter name will win depsolving game, so "Requires: desktop-notification-deamon" will always pull "xfce4-notify" in. - On the other hand, with your idea yum resolver says libgnome will install notification-daemon with the following chain: libgnome -> fedora-gnome-theme -> notification-daemon-engine-nodoka -> notification-daemon So when libnotify and libgnome are to be installed, for example, conflicts can never be solved... Regards, Mamoru From christoph.wickert at googlemail.com Wed May 13 17:28:41 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Wed, 13 May 2009 19:28:41 +0200 Subject: koji breakage for F12 builds In-Reply-To: <1242220510.25471.6431.camel@cookie.hadess.net> References: <5256d0b0905121504k4768401an741dd4d0bd5cf045@mail.gmail.com> <1242172496.3569.15.camel@localhost.localdomain> <20090513084302.1fb20a62@faldor.intranet> <1242213324.3704.8.camel@localhost.localdomain> <1242220510.25471.6431.camel@cookie.hadess.net> Message-ID: <1242235721.10712.18.camel@localhost.localdomain> Am Mittwoch, den 13.05.2009, 14:15 +0100 schrieb Bastien Nocera: > On Wed, 2009-05-13 at 13:15 +0200, Christoph Wickert wrote: > > > > E.g. notify-daemon and desktop-notification-daemon and the package name > > > itself, notification-daemon. > > > > I think the problem is, that some packages notification-deamon instead > > of (virtual) desktop-notification-deamon: > > > > # repoquery --repoid rawhide --whatrequires notification-daemon > > gnome-bluetooth-0:2.27.5-1.fc11.i586 > > notify-python-0:0.1.1-6.fc11.i586 > > notification-daemon-engine-nodoka-0:0.1.0-6.fc11.i586 > > system-config-printer-0:1.1.7-1.fc11.i586 > > ibus-0:1.1.0.20090423-1.fc11.i586 > > > > I'm going to file bugs against these packages except > > notification-daemon-engine-nodoka, because it only works with > > notification-daemon. FYI: https://bugzilla.redhat.com/show_bug.cgi?id=500585 https://bugzilla.redhat.com/show_bug.cgi?id=500586 https://bugzilla.redhat.com/show_bug.cgi?id=500587 https://bugzilla.redhat.com/show_bug.cgi?id=500588 > > Except that I don't see why those would cause problems during the build, > when they're not even getting installed in the buildroots. > > The problem was/is that libnotify-devel requires a > desktop-notification-daemon (via libnotify itself), and yum will install > both packages that provide it. Why both? I expect it to stop resolving deps as soon as one is able to provide it. Regards, Christoph From Matt_Domsch at dell.com Wed May 13 17:30:51 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 13 May 2009 12:30:51 -0500 Subject: transition a few packages to new owners Message-ID: <20090513173051.GB12695@auslistsprd01.us.dell.com> I'd like to transition a few packages to new owners. If you are interested, please apply in the pkgdb and I'll transfer them to you. aiccu -- SixXS Automatic IPv6 Connectivity Client Utility gpp -- GNOME Photo Printer oggvideotools -- Toolbox for manipulating Ogg video files perl-GnuPG-Interface -- Perl interface to GnuPG pgp-tools -- Collection of several utilities related to OpenPGP Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From christoph.wickert at googlemail.com Wed May 13 17:37:13 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Wed, 13 May 2009 19:37:13 +0200 Subject: koji breakage for F12 builds In-Reply-To: References: <5256d0b0905121504k4768401an741dd4d0bd5cf045@mail.gmail.com> <1242172496.3569.15.camel@localhost.localdomain> <20090513084302.1fb20a62@faldor.intranet> <1242213324.3704.8.camel@localhost.localdomain> <1242220510.25471.6431.camel@cookie.hadess.net> <1242224153.10107.27.camel@code.and.org> Message-ID: <1242236233.10712.28.camel@localhost.localdomain> Am Mittwoch, den 13.05.2009, 19:17 +0200 schrieb Nicolas Chauvet: > 2009/5/13 James Antill : > > On Wed, 2009-05-13 at 14:15 +0100, Bastien Nocera wrote: > >> On Wed, 2009-05-13 at 13:15 +0200, Christoph Wickert wrote: > >> > I think the problem is, that some packages notification-deamon instead > >> > of (virtual) desktop-notification-deamon: > > [...] > >> Except that I don't see why those would cause problems during the build, > >> when they're not even getting installed in the buildroots. > >> > >> The problem was/is that libnotify-devel requires a > >> desktop-notification-daemon (via libnotify itself), and yum will install > >> both packages that provide it. > > > > How did you come to this conclusion? > > I'm not saying it's impossible, but the above seems unlikely unless yum > > picks one on the virtual provides hit and then it gets an explicit > > requires on the other (which isn't the same thing). > > xfce4-notifyd : 12 characters > notification-daemon: 19 characters > Short name wins! This is only partly true as Seth pointed out on this list just recently (not sure which topic it was though): IIRC short name wins only applies if both packages provide *exactly* the same thing, and this shouldn't be the case here. > xfce4-notifyd is picked unless something within the > dependencies is hardcoded to notification-daemon. There *are* packages explicitly requiring notification-daemon, so this needs to be rephrased: Why is xfce4-notifyd choosen *although* (!= "unless") some packages are hardcoding notification-daemon, which already satisfies all requirements? Regards, Christoph From awilliam at redhat.com Wed May 13 17:42:47 2009 From: awilliam at redhat.com (Adam Williamson) Date: Wed, 13 May 2009 10:42:47 -0700 Subject: Breaking deps deliberately In-Reply-To: <20090513153014.GA20064@amd.home.annexia.org> References: <20090513134744.GA19304@amd.home.annexia.org> <4A0AD15F.6040300@fedoraproject.org> <20090513135728.GA19428@amd.home.annexia.org> <20090513142048.GA19610@amd.home.annexia.org> <20090513142742.GB19610@amd.home.annexia.org> <1242226199.3704.33.camel@localhost.localdomain> <20090513153014.GA20064@amd.home.annexia.org> Message-ID: <1242236567.2923.902.camel@adam.local.net> On Wed, 2009-05-13 at 16:30 +0100, Richard W.M. Jones wrote: > On Wed, May 13, 2009 at 04:49:59PM +0200, Christoph Wickert wrote: > > "* The distribution SHOULD not contain any broken EVR paths (i.e. > > packages that RPM considers "older" than those in the previous release). > > * The distribution SHOULD not contain any broken dependencies." > > https://fedoraproject.org/wiki/QA/ReleaseCriteria#Package_Sanity > > Yeah, that's not a packaging guideline though is it. That's a set of > release criteria that the QA team use. For the record, the QA team reckons that pushing updates with intentionally broken dependencies is extremely silly, and in the Glorious Future, autoqa will complain if you do it. Just say no, kids. (This correspondent thinks it's not really necessary to go after rwjones' provenpackager status / competence / sanity, though. Just MHO.) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From seg at haxxed.com Wed May 13 17:48:04 2009 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 13 May 2009 12:48:04 -0500 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A09320F.9060107@TheTroubleshooters.dk> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08302A.2020705@redhat.com> <4A09320F.9060107@TheTroubleshooters.dk> Message-ID: <1242236884.5155.16.camel@localhost.localdomain> On Tue, 2009-05-12 at 10:23 +0200, Michael Nielsen wrote: > The only path forward, as I can see is to create one's own > distribution, which seems like a major over kill. Such drastic changes are never going to be made in Fedora itself first. Forking a prototype is the only way I see for anything like this to move forwards. Talk is cheap, show us how it's done. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From christoph.wickert at googlemail.com Wed May 13 17:50:59 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Wed, 13 May 2009 19:50:59 +0200 Subject: koji breakage for F12 builds In-Reply-To: <4A0B02D1.9090102@ioa.s.u-tokyo.ac.jp> References: <5256d0b0905121504k4768401an741dd4d0bd5cf045@mail.gmail.com> <1242172496.3569.15.camel@localhost.localdomain> <20090513084302.1fb20a62@faldor.intranet> <1242213324.3704.8.camel@localhost.localdomain> <4A0B02D1.9090102@ioa.s.u-tokyo.ac.jp> Message-ID: <1242237059.10712.35.camel@localhost.localdomain> Am Donnerstag, den 14.05.2009, 02:26 +0900 schrieb Mamoru Tasaka: > Christoph Wickert wrote, at 05/13/2009 08:15 PM +9:00: > > > > I think the problem is, that some packages notification-deamon instead > > of (virtual) desktop-notification-deamon: > > > > # repoquery --repoid rawhide --whatrequires notification-daemon > > gnome-bluetooth-0:2.27.5-1.fc11.i586 > > notify-python-0:0.1.1-6.fc11.i586 > > notification-daemon-engine-nodoka-0:0.1.0-6.fc11.i586 > > system-config-printer-0:1.1.7-1.fc11.i586 > > ibus-0:1.1.0.20090423-1.fc11.i586 > > > > I'm going to file bugs against these packages except > > notification-daemon-engine-nodoka, because it only works with > > notification-daemon. > > > > Regards, > > Christoph > > Well, this won't work for this issue, because: > - With yum shorter name will win depsolving game, so "Requires: > desktop-notification-deamon" will always pull "xfce4-notify" in. Why that? Seth pointed out that yum will only fall back to shorter name when all other criteria fail, and one of them was that both packages have exactly the same Provides: > - On the other hand, with your idea yum resolver says libgnome > will install notification-daemon with the following chain: > libgnome -> fedora-gnome-theme -> notification-daemon-engine-nodoka > -> notification-daemon Just like Spot in the rel-eng ticket I ask: Why does a lib *require* fedora-gnome-theme? Just because it's the default theme in /etc/gconf/schemas/desktop_gnome_interface.schemas? > So when libnotify and libgnome are to be installed, for example, > conflicts can never be solved... Thanks for this explanation, but what am I supposed to do now? All I can offer is to remove xfce4-notifyd for now, but this is only a workaround and not a solution. Regards, Christoph From kevin.kofler at chello.at Wed May 13 18:02:34 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 13 May 2009 20:02:34 +0200 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 References: <4A0814ED.60205@redhat.com> <4A09B8FE.4040904@cygnusx-1.org> <4A09C018.4060906@cygnusx-1.org> <4A09CBE4.4020807@cygnusx-1.org> Message-ID: Matthew Woehlke wrote: > What's to stop someone ITP'ing* icecat? Get it in the repo, and go from > there. If you can't work /with/ the maintainer(s), work around them. Then we'd have 2 packages with the same software, and then there's also the problem of xulrunner being locked down as well (and that's a library used by a lot of stuff). > (* Intent To Package. Yeah, I'm borrowing Cygwin terminology, sorry. Not > sure what the equivalent in Fedora slang would be.) Submitting for review. Kevin Kofler From jkeating at redhat.com Wed May 13 18:06:00 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 13 May 2009 11:06:00 -0700 Subject: koji breakage for F12 builds In-Reply-To: <1242236233.10712.28.camel@localhost.localdomain> References: <5256d0b0905121504k4768401an741dd4d0bd5cf045@mail.gmail.com> <1242172496.3569.15.camel@localhost.localdomain> <20090513084302.1fb20a62@faldor.intranet> <1242213324.3704.8.camel@localhost.localdomain> <1242220510.25471.6431.camel@cookie.hadess.net> <1242224153.10107.27.camel@code.and.org> <1242236233.10712.28.camel@localhost.localdomain> Message-ID: <1242237960.6282.27.camel@localhost.localdomain> On Wed, 2009-05-13 at 19:37 +0200, Christoph Wickert wrote: > > There *are* packages explicitly requiring notification-daemon, so this > needs to be rephrased: Why is xfce4-notifyd choosen *although* (!= > "unless") some packages are hardcoding notification-daemon, which > already satisfies all requirements? Likely because when yum is doing it's depsolving, it first hit a generic requires, before it hit anything that specifically required notification-daemon. So the shorter name got in, then later it found the specific requires and had to bring in notification-daemon. Then conflict. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kevin.kofler at chello.at Wed May 13 18:07:36 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 13 May 2009 20:07:36 +0200 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 References: <4A0814ED.60205@redhat.com> <4A09B8FE.4040904@cygnusx-1.org> <4A09C018.4060906@cygnusx-1.org> <4A09CBE4.4020807@cygnusx-1.org> <1242232123.6282.5.camel@localhost.localdomain> Message-ID: Jesse Keating wrote: > You do realize that Fedora's trademark policy is even "worse" ? But we don't expect all third parties to go through the trademark approval process (and they don't or even can't, for different reasons), we have them ship generic logos, the new Fedora Remix artwork (which also has a policy to follow, but a less strict one when it comes to modification of the software than Firefox!) or their own logos instead. I don't see why we shouldn't do the same for Firefox. Kevin Kofler From mtasaka at ioa.s.u-tokyo.ac.jp Wed May 13 18:10:23 2009 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 14 May 2009 03:10:23 +0900 Subject: koji breakage for F12 builds In-Reply-To: <1242237059.10712.35.camel@localhost.localdomain> References: <5256d0b0905121504k4768401an741dd4d0bd5cf045@mail.gmail.com> <1242172496.3569.15.camel@localhost.localdomain> <20090513084302.1fb20a62@faldor.intranet> <1242213324.3704.8.camel@localhost.localdomain> <4A0B02D1.9090102@ioa.s.u-tokyo.ac.jp> <1242237059.10712.35.camel@localhost.localdomain> Message-ID: <4A0B0D0F.6050904@ioa.s.u-tokyo.ac.jp> Christoph Wickert wrote, at 05/14/2009 02:50 AM +9:00: > Am Donnerstag, den 14.05.2009, 02:26 +0900 schrieb Mamoru Tasaka: >> Christoph Wickert wrote, at 05/13/2009 08:15 PM +9:00: >>> I think the problem is, that some packages notification-deamon instead >>> of (virtual) desktop-notification-deamon: >>> >>> # repoquery --repoid rawhide --whatrequires notification-daemon >>> gnome-bluetooth-0:2.27.5-1.fc11.i586 >>> notify-python-0:0.1.1-6.fc11.i586 >>> notification-daemon-engine-nodoka-0:0.1.0-6.fc11.i586 >>> system-config-printer-0:1.1.7-1.fc11.i586 >>> ibus-0:1.1.0.20090423-1.fc11.i586 >>> >>> I'm going to file bugs against these packages except >>> notification-daemon-engine-nodoka, because it only works with >>> notification-daemon. >>> >>> Regards, >>> Christoph >> Well, this won't work for this issue, because: >> - With yum shorter name will win depsolving game, so "Requires: >> desktop-notification-deamon" will always pull "xfce4-notify" in. > > Why that? Seth pointed out that yum will only fall back to shorter name > when all other criteria fail, and one of them was that both packages > have exactly the same Provides: See http://mtasaka.fedorapeople.org/mock-fc12-conflicts/MOCK-ucommon.log Here how yum tried to resolve dependency is shown. For this case, as yum goes on to resolve dependency: - First yum finds that some package requires "desktop-notification-daemon" so yum decides to pull in xfce4-notify (as shorter name wins) i.e. at this stage yum sees no packages having explicit "Requires: notification-daemon" - Then yum proceeds, tries to resolve dependency again, then yum finds out that one package has "Requires: notification-daemon" explicitly. So yum have to add "notification-daemon" at this stage. i.e. something like race condition. >> - On the other hand, with your idea yum resolver says libgnome >> will install notification-daemon with the following chain: >> libgnome -> fedora-gnome-theme -> notification-daemon-engine-nodoka >> -> notification-daemon > > Just like Spot in the rel-eng ticket I ask: Why does a lib *require* > fedora-gnome-theme? Just because it's the default theme > in /etc/gconf/schemas/desktop_gnome_interface.schemas? Please ask libgnome maintainer. It may be because of the reason you mentioned here, or there may be another reason... I think this type of Requires is fully left to how the maintainer thinks currently. > Thanks for this explanation, but what am I supposed to do now? All I can > offer is to remove xfce4-notifyd for now, but this is only a workaround > and not a solution. > > Regards, > Christoph Perhaps providing alternatives mechanism is one of the solutions. Regards, Mamoru From kevin.kofler at chello.at Wed May 13 18:13:53 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 13 May 2009 20:13:53 +0200 Subject: koji breakage for F12 builds References: <5256d0b0905121504k4768401an741dd4d0bd5cf045@mail.gmail.com> <1242172496.3569.15.camel@localhost.localdomain> Message-ID: Christoph Wickert wrote: > xfce4-notifyd conflicts with notification-daemon because both provide > /usr/share/dbus-1/services/org.freedesktop.Notifications.service Easy "solution": rename the file to: /usr/share/dbus-1/services/xfce-org.freedesktop.Notifications.service that way you don't need an RPM-level Conflicts and it'll still work. This is what PolicyKit-kde does. That said, this also means that if both are installed, D-Bus will just pick a semi-random one at runtime (basically, it depends on which got installed first, because that's first in a directory listing). For the PolicyKit-gnome vs. PolicyKit-kde stuff, we fixed all the packages to depend on a virtual Provides so we can just not install PolicyKit-gnome at all on the KDE spin. But it's not that great a solution. See also: https://bugzilla.redhat.com/show_bug.cgi?id=484945 for more on this. Kevin Kofler From kevin.kofler at chello.at Wed May 13 18:18:03 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 13 May 2009 20:18:03 +0200 Subject: Breaking deps deliberately References: <20090513111343.4d79d48f@faldor.intranet> <20090513135208.GA1850@yoda.jdub.homelinux.org> Message-ID: Colin Walters wrote: > Can this be banned? It doesn't seem particularly onerous to also make > your dependencies security updates. No. Many libraries are only one-way compatible. A lot of stuff won't work if you don't have some of the other updates (which is also why selective updating is broken by design and why our update announcements should include the old blurb from the RHL Errata which asked to make sure all previously released errata have been applied). Kevin Kofler From Jochen at herr-schmitt.de Wed May 13 18:23:16 2009 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 13 May 2009 20:23:16 +0200 Subject: transition a few packages to new owners In-Reply-To: <20090513173051.GB12695@auslistsprd01.us.dell.com> References: <20090513173051.GB12695@auslistsprd01.us.dell.com> Message-ID: <4A0B1014.1050403@herr-schmitt.de> Matt Domsch schrieb: > pgp-tools -- Collection of several utilities related to OpenPGP > I would like to take pgp-tools. Best Regards: Jochen Schmitt From konrad at tylerc.org Wed May 13 18:29:01 2009 From: konrad at tylerc.org (Conrad Meyer) Date: Wed, 13 May 2009 11:29:01 -0700 Subject: transition a few packages to new owners In-Reply-To: <20090513173051.GB12695@auslistsprd01.us.dell.com> References: <20090513173051.GB12695@auslistsprd01.us.dell.com> Message-ID: <200905131129.01576.konrad@tylerc.org> On Wednesday 13 May 2009 10:30:51 am Matt Domsch wrote: > I'd like to transition a few packages to new owners. If you are > interested, please apply in the pkgdb and I'll transfer them to you. > > aiccu -- SixXS Automatic IPv6 Connectivity Client Utility > gpp -- GNOME Photo Printer > oggvideotools -- Toolbox for manipulating Ogg video files > perl-GnuPG-Interface -- Perl interface to GnuPG > pgp-tools -- Collection of several utilities related to OpenPGP > > Thanks, > Matt > > -- > Matt Domsch > Linux Technology Strategist, Dell Office of the CTO > linux.dell.com & www.dell.com/linux I'll take aiccu. Regards, -- Conrad Meyer From Matt_Domsch at dell.com Wed May 13 18:34:06 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 13 May 2009 13:34:06 -0500 Subject: transition a few packages to new owners In-Reply-To: <200905131129.01576.konrad@tylerc.org> References: <20090513173051.GB12695@auslistsprd01.us.dell.com> <200905131129.01576.konrad@tylerc.org> Message-ID: <20090513183406.GA18564@auslistsprd01.us.dell.com> On Wed, May 13, 2009 at 11:29:01AM -0700, Conrad Meyer wrote: > On Wednesday 13 May 2009 10:30:51 am Matt Domsch wrote: > > I'd like to transition a few packages to new owners. If you are > > interested, please apply in the pkgdb and I'll transfer them to you. > > > > aiccu -- SixXS Automatic IPv6 Connectivity Client Utility > > gpp -- GNOME Photo Printer > > oggvideotools -- Toolbox for manipulating Ogg video files > > perl-GnuPG-Interface -- Perl interface to GnuPG > > pgp-tools -- Collection of several utilities related to OpenPGP > > > > Thanks, > > Matt > > > > -- > > Matt Domsch > > Linux Technology Strategist, Dell Office of the CTO > > linux.dell.com & www.dell.com/linux > > I'll take aiccu. Thanks Conrad. Marek also said he would, so the two of you can co-maintain if you wish. Also be advised there is an aiccu announce mailing list https://noc.sixxs.net/mailman/listinfo/aiccu-announce you'll want to join. This software updates very infrequently, so announcements are roughly every few years. :-) -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From Matt_Domsch at dell.com Wed May 13 18:34:59 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 13 May 2009 13:34:59 -0500 Subject: transition a few packages to new owners In-Reply-To: <4A0B1014.1050403@herr-schmitt.de> References: <20090513173051.GB12695@auslistsprd01.us.dell.com> <4A0B1014.1050403@herr-schmitt.de> Message-ID: <20090513183459.GB18564@auslistsprd01.us.dell.com> On Wed, May 13, 2009 at 08:23:16PM +0200, Jochen Schmitt wrote: > Matt Domsch schrieb: > >pgp-tools -- Collection of several utilities related to OpenPGP > > > I would like to take pgp-tools. thanks Jochen. the latest is currently sitting in updates-testing for 9, 10, 11, if you wish to look and then promote to stable. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From lsof at nodata.co.uk Wed May 13 18:40:08 2009 From: lsof at nodata.co.uk (nodata) Date: Wed, 13 May 2009 20:40:08 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <1242060668.28322.85.camel@localhost.localdomain> References: <4A082E70.7030904@TheTroubleshooters.dk> <1242060668.28322.85.camel@localhost.localdomain> Message-ID: <1242240008.2316.2.camel@prague> Am Montag, den 11.05.2009, 12:51 -0400 schrieb Dan Williams: > This is false. Then please could you publicise this. Every Red Hat sys admin I know is concerned about the over-guisation of Red Hat linux. The command line is one of Linux's core strengths, the focus on the gui sends out the wrong signal. > NetworkManager will read (and write!) system network configuration for > wired & wireless devices, and can bring those devices up before login. > I think what you may be missing is an easy one-command tool to > activate/deactivate those, and that's fairly simple with dbus-send, and > yes, its something that should be written. But in now way is network > tied to a UI or unusable without a UI. From mw_triad at users.sourceforge.net Wed May 13 18:46:38 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 13 May 2009 13:46:38 -0500 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: References: <4A0814ED.60205@redhat.com> <4A09B8FE.4040904@cygnusx-1.org> <4A09C018.4060906@cygnusx-1.org> <4A09CBE4.4020807@cygnusx-1.org> Message-ID: Kevin Kofler wrote: > Matthew Woehlke wrote: >> What's to stop someone ITP'ing* icecat? Get it in the repo, and go from >> there. If you can't work /with/ the maintainer(s), work around them. > > Then we'd have 2 packages with the same software, So? glibc and eglibc? :-) (I was actually thinking that this situation sounds rather similar to that...) > and then there's also the problem of xulrunner being locked down as > well (and that's a library used by a lot of stuff). Why is xulrunner locked down? If it uses Mozilla trademarks, presumably they can be removed (I'd guess they'd have to be to build icecat, so I assume this is possible). If it needs to change, ITP/SFR an opened version at the same time as icecat. If it can be used as-is, we could start with icecat and wait for that to gain some traction, thus taking on the stack on one part at a time. Maybe we get lucky and success of icecat convinces the xulrunner maintainer to open things up. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- "So long, and thanks for all the fish" -- the dolphins (from Douglas Adams' HHGttG) From bochecha at fedoraproject.org Wed May 13 18:47:43 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Wed, 13 May 2009 20:47:43 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <1242240008.2316.2.camel@prague> References: <4A082E70.7030904@TheTroubleshooters.dk> <1242060668.28322.85.camel@localhost.localdomain> <1242240008.2316.2.camel@prague> Message-ID: <2d319b780905131147r14143d5ev97ed5be9cff50773@mail.gmail.com> > The command line is one of Linux's core strengths, the focus on the gui > sends out the wrong signal. But command line tools are already there and are really powerful (as you say, that's one of our core strength). No one says command line should disappear, that would be a complete nonsense. And development of those tools is not abandoned, that would be terrible. Gui and desktop on the other hand have historically been one of Linux' weakness (at least from a ? normal ? end user point of view). What is wrong with trying to improve our weaknesses ? Regards, ---------- Mathieu Bridon (bochecha) From caillon at redhat.com Wed May 13 18:59:22 2009 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 13 May 2009 11:59:22 -0700 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: References: <4A0814ED.60205@redhat.com> <4A09B8FE.4040904@cygnusx-1.org> <4A09C018.4060906@cygnusx-1.org> <4A09CBE4.4020807@cygnusx-1.org> Message-ID: <4A0B188A.5000500@redhat.com> On 05/13/2009 05:55 AM, Kevin Kofler wrote: > Nathan Grennan wrote: >> I understand, but on the other hand does Fedora want a dozen bug >> reports over Thunderbird being useless, because of a crappy default? > > The problem is that Fedora can't change anything in Thunderbird (nor > Firefox) without upstream buy-in because the maintainer refuses to rename > the programs and thus we're bound by Mozilla's strict (and IMHO completely > unreasonable and unacceptable in the Free Software world) trademark policy. Actually, Fedora policy is to stick with upstream. I did not create that policy, though I do agree with it and abide by it. Forking is not my idea of playing nicely with upstream. Additionally, Mozilla's policy is very similar to Fedora's policy. If you find such policies offensive, you may wish to read Fedora's policy and re-evaluate your participation in the project. Note that I am not recommending that, but if you feel strongly about this, then you need to do what you need to do. > I'm really fed up of all the special treatment Mozilla is getting over this, > for example the xulrunner/firefox/thunderbird stack is now the ONLY one > excluded from provenpackager commits, if all projects worked like this > (i.e. required upstream's approval for every single patch), Fedora would be > completely unmaintainable. Please do not confuse me with upstream. I am the one who is ultimately accountable for the package. Patches require MY approval. As far as maintainability goes though, I don't see how adding a bunch of patches to a package helps that. Keeping the patch set minimal is critical for maintainability across the stack. Other distributions adding patches is the reason why some gecko-using projects have autoconf files check for Debian patches, else proceed as normal. Maintainability, woo! > I really don't see why we don't just rename > Firefox and Thunderbird like Debian is doing. This sounds like an issue you ought to raise to the Fedora Board. In the interest of full disclosure, I am currently serving on the Fedora Board. But you're assuming that if I am forced to rename the package, I would maintain it differently. The package's name or trademarks have no bearing on whether I think that adding random patches to an intricate chunk of code like a web browser will have a net negative effect on the web, the maintainability of the package, the maintainability of the related stack, and relations with upstream. > (*) check who the primary maintainer of Firefox and Thunderbird in Fedora is > and who he's involved with, draw your own conclusions... Erm? What do any of my special lady friends have to do with this? From maxamillion at gmail.com Wed May 13 19:04:42 2009 From: maxamillion at gmail.com (Adam Miller) Date: Wed, 13 May 2009 14:04:42 -0500 Subject: Orphaned packages (Re: FESco meeting summary for 20090507) In-Reply-To: <1241994683.3552.8.camel@localhost.localdomain> References: <4A05BF03.6070508@fi.muni.cz> <1241891211.9577.0.camel@localhost.localdomain> <1241994683.3552.8.camel@localhost.localdomain> Message-ID: I will take firestarter, its still a relatively popular package and I actually continue to use it on my desktop at home (because I'm lazy). If it comes to a point that we need to retire the package then I am willing to do so but I would like to keep it alive if we can. I've checked bugzilla and there do appear to be a couple bugs against it and I will try to start looking into getting those fixed here shortly. -Adam -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From maxamillion at gmail.com Wed May 13 18:50:53 2009 From: maxamillion at gmail.com (Adam Miller) Date: Wed, 13 May 2009 13:50:53 -0500 Subject: transition a few packages to new owners In-Reply-To: <20090513183459.GB18564@auslistsprd01.us.dell.com> References: <20090513173051.GB12695@auslistsprd01.us.dell.com> <4A0B1014.1050403@herr-schmitt.de> <20090513183459.GB18564@auslistsprd01.us.dell.com> Message-ID: I would like oggvideotools. -Adam -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From james at fedoraproject.org Wed May 13 19:37:16 2009 From: james at fedoraproject.org (James Antill) Date: Wed, 13 May 2009 15:37:16 -0400 Subject: Breaking deps deliberately In-Reply-To: <1242231745.6282.3.camel@localhost.localdomain> References: <20090513111343.4d79d48f@faldor.intranet> <20090513135208.GA1850@yoda.jdub.homelinux.org> <4A0AED8B.5050909@cchtml.com> <1242231745.6282.3.camel@localhost.localdomain> Message-ID: <1242243436.10107.48.camel@code.and.org> On Wed, 2009-05-13 at 09:22 -0700, Jesse Keating wrote: > On Wed, 2009-05-13 at 10:55 -0500, Michael Cronenworth wrote: > > I'm not sure why you think we need entirely separate repos for this kind > > of action. PackageKit is aware of update levels. Bug fix, security fix, > > or regular feature update. You could add functionality to PackageKit > > that allows you default the type of updates you want instead of all > > updates. Right now you can just manually uncheck the updates you do not > > want, so if they don't have a red icon next to them. In fact, I think > > the notification window you get that says "Security Updates only" would > > get you on your way. > > The problem here is that packages get multiple updates. Lets say update > 1 is non security. Update 2 is security. Updates 3 and 4 are non > security. User Bob does a fresh install, and in order to get the > security update, he has to update to update 4, which has 3 non security > updates rolled into it. He might as well just update everything. yum update-minimal --security ...this doesn't work in Fedora because we only ship one version of the package. Also PK can't do a minimal-update. But creating separate repos. will not help this problem, IMNSHO. -- James Antill Fedora From james at fedoraproject.org Wed May 13 19:47:49 2009 From: james at fedoraproject.org (James Antill) Date: Wed, 13 May 2009 15:47:49 -0400 Subject: koji breakage for F12 builds In-Reply-To: References: <5256d0b0905121504k4768401an741dd4d0bd5cf045@mail.gmail.com> <1242172496.3569.15.camel@localhost.localdomain> <20090513084302.1fb20a62@faldor.intranet> <1242213324.3704.8.camel@localhost.localdomain> <1242220510.25471.6431.camel@cookie.hadess.net> <1242224153.10107.27.camel@code.and.org> Message-ID: <1242244069.10107.53.camel@code.and.org> On Wed, 2009-05-13 at 19:17 +0200, Nicolas Chauvet wrote: > 2009/5/13 James Antill : > > On Wed, 2009-05-13 at 14:15 +0100, Bastien Nocera wrote: > >> The problem was/is that libnotify-devel requires a > >> desktop-notification-daemon (via libnotify itself), and yum will install > >> both packages that provide it. > > > > How did you come to this conclusion? > > xfce4-notifyd : 12 characters > notification-daemon: 19 characters > Short name wins! xfce4-notifyd is picked unless something within the > dependencies is hardcoded to notification-daemon. > > And that's how xfce4 won the battle for the default desktop in the rpm world... Yes, but there yum is installing _one_ package for the provide ... it later installs the other provide due to an explicit requires. But this isn't the same thing as saying yum is installing both for the single provide, which is what I read Bastien as saying. Just removing the explicit requires should fix mock, and presumably something would be added to comps. so that the non-xfce version is installed explicitly for installs. I did a "best providers" patch a few months ago now, to solve this exact kind of problem: http://james.fedorapeople.org/yum/patches/yum-best-providers-metadata.patch ...getting that into yum for Fedora 12 should be possible, as long as Fedora rel-eng want it. -- James Antill Fedora From jkeating at redhat.com Wed May 13 19:55:02 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 13 May 2009 12:55:02 -0700 Subject: Breaking deps deliberately In-Reply-To: <1242243436.10107.48.camel@code.and.org> References: <20090513111343.4d79d48f@faldor.intranet> <20090513135208.GA1850@yoda.jdub.homelinux.org> <4A0AED8B.5050909@cchtml.com> <1242231745.6282.3.camel@localhost.localdomain> <1242243436.10107.48.camel@code.and.org> Message-ID: <1242244502.6282.29.camel@localhost.localdomain> On Wed, 2009-05-13 at 15:37 -0400, James Antill wrote: > yum update-minimal --security > > ...this doesn't work in Fedora because we only ship one version of the > package. Also PK can't do a minimal-update. > But creating separate repos. will not help this problem, IMNSHO. Well not only do we only ship one version, but we only have one CVS branch too, so often the security fixes get applied on top of previous feature updates. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From khc at pm.waw.pl Wed May 13 20:15:12 2009 From: khc at pm.waw.pl (Krzysztof Halasa) Date: Wed, 13 May 2009 22:15:12 +0200 Subject: Guaranteeing running code is signed In-Reply-To: (Matthew Woehlke's message of "Tue\, 12 May 2009 14\:54\:20 -0500") References: <3da3b5b40905091136s3dd92954kffde00706905a850@mail.gmail.com> <2d319b780905091212x531acea1v837e28429d901601@mail.gmail.com> <3da3b5b40905091228s1acfcfa2s91d53fed72a56504@mail.gmail.com> <200905101503.35200.bjorn@xn--rombobjrn-67a.se> <4A06FF6C.4080905@hidayahonline.org> Message-ID: Matthew Woehlke writes: > Indeed. (I've read stuff about military testing microchips to verify > that the circuitry is correct. Forget flash, eeprom, even rom; do you > trust the fab plant that built your CPU?) In this case all users would equally be affected (and are, who knows how many unknown bugs the CPU has), but the chance of someone using an unknown CPU bug to break into a particular system is really small. OTOH, a chance that someone who already broke into a system will do that again (with flash ROMs etc. especially modified for this purpose during the first break-in) may be considerable. -- Krzysztof Halasa From opensource at till.name Wed May 13 20:32:28 2009 From: opensource at till.name (Till Maas) Date: Wed, 13 May 2009 22:32:28 +0200 Subject: Fedora Community Pre-Beta Testing In-Reply-To: <4A0AEA7F.4060302@redhat.com> References: <4A0AEA7F.4060302@redhat.com> Message-ID: <200905132232.35752.opensource@till.name> On Mi Mai 13 2009, Tom "spot" Callaway wrote: > So, without further ado and the above caveats, look at our pre-beta test > instance: > > https://publictest16.fedoraproject.org/community/ I hope this is only misleading, but it looks to me that this test application demands the original FAS username/password from testers, which are then sent via an connection where the certificate cannot be easily verified by the testers. Also it is a bad idea to use these very important credentials in an application that may still have security flaws, because it is still in development. Last but not least this is also a bad education for the users that get used to provide their credentials to untrustworthy websites. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From Matt_Domsch at dell.com Wed May 13 20:34:42 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 13 May 2009 15:34:42 -0500 Subject: transition a few packages to new owners In-Reply-To: References: <20090513173051.GB12695@auslistsprd01.us.dell.com> <4A0B1014.1050403@herr-schmitt.de> <20090513183459.GB18564@auslistsprd01.us.dell.com> Message-ID: <20090513203442.GA7709@auslistsprd01.us.dell.com> On Wed, May 13, 2009 at 01:50:53PM -0500, Adam Miller wrote: > I would like oggvideotools. Thank you. I've approved you and orphaned it, please take ownership in the pkgdb. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From tcallawa at redhat.com Wed May 13 20:38:54 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 13 May 2009 16:38:54 -0400 Subject: Fedora Community Pre-Beta Testing In-Reply-To: <200905132232.35752.opensource@till.name> References: <4A0AEA7F.4060302@redhat.com> <200905132232.35752.opensource@till.name> Message-ID: <4A0B2FDE.1090906@redhat.com> On 05/13/2009 04:32 PM, Till Maas wrote: > I hope this is only misleading, but it looks to me that this test application > demands the original FAS username/password from testers, which are then sent > via an connection where the certificate cannot be easily verified by the > testers. Also it is a bad idea to use these very important credentials in an > application that may still have security flaws, because it is still in > development. Last but not least this is also a bad education for the users > that get used to provide their credentials to untrustworthy websites. I'm not entirely sure I follow this logic. Lots of things authenticate against FAS. The source code for every bit of this web application is open source and available for review. Do you trust Bodhi? How about pkgdb? Or koji? Barring some specific security vulnerability (which you haven't pointed out), this criticism seems unfounded. ~spot From lsof at nodata.co.uk Wed May 13 20:41:00 2009 From: lsof at nodata.co.uk (nodata) Date: Wed, 13 May 2009 22:41:00 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <2d319b780905131147r14143d5ev97ed5be9cff50773@mail.gmail.com> References: <4A082E70.7030904@TheTroubleshooters.dk> <1242060668.28322.85.camel@localhost.localdomain> <1242240008.2316.2.camel@prague> <2d319b780905131147r14143d5ev97ed5be9cff50773@mail.gmail.com> Message-ID: <1242247260.2316.5.camel@prague> Am Mittwoch, den 13.05.2009, 20:47 +0200 schrieb Mathieu Bridon (bochecha): > > The command line is one of Linux's core strengths, the focus on the gui > > sends out the wrong signal. > > But command line tools are already there and are really powerful (as > you say, that's one of our core strength). No one says command line > should disappear, that would be a complete nonsense. And development > of those tools is not abandoned, that would be terrible. > > Gui and desktop on the other hand have historically been one of Linux' > weakness (at least from a ? normal ? end user point of view). What is > wrong with trying to improve our weaknesses ? What is wrong with it is that we stop promoting one of the strength's of linux. Show me a red hat magazine article on managing network manager with the cli. > > Regards, > > > ---------- > > Mathieu Bridon (bochecha) > From maxamillion at gmail.com Wed May 13 20:36:51 2009 From: maxamillion at gmail.com (Adam Miller) Date: Wed, 13 May 2009 15:36:51 -0500 Subject: transition a few packages to new owners In-Reply-To: <20090513203442.GA7709@auslistsprd01.us.dell.com> References: <20090513173051.GB12695@auslistsprd01.us.dell.com> <4A0B1014.1050403@herr-schmitt.de> <20090513183459.GB18564@auslistsprd01.us.dell.com> <20090513203442.GA7709@auslistsprd01.us.dell.com> Message-ID: Taken ownership, thank you. I've also joined the mailing list of the upstream project. -Adam -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From skvidal at fedoraproject.org Wed May 13 20:42:47 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 13 May 2009 16:42:47 -0400 (EDT) Subject: Fedora (Linux) is Destroying it self In-Reply-To: <1242247260.2316.5.camel@prague> References: <4A082E70.7030904@TheTroubleshooters.dk> <1242060668.28322.85.camel@localhost.localdomain> <1242240008.2316.2.camel@prague> <2d319b780905131147r14143d5ev97ed5be9cff50773@mail.gmail.com> <1242247260.2316.5.camel@prague> Message-ID: On Wed, 13 May 2009, nodata wrote: > Am Mittwoch, den 13.05.2009, 20:47 +0200 schrieb Mathieu Bridon > (bochecha): >>> The command line is one of Linux's core strengths, the focus on the gui >>> sends out the wrong signal. >> >> But command line tools are already there and are really powerful (as >> you say, that's one of our core strength). No one says command line >> should disappear, that would be a complete nonsense. And development >> of those tools is not abandoned, that would be terrible. >> >> Gui and desktop on the other hand have historically been one of Linux' >> weakness (at least from a ? normal ? end user point of view). What is >> wrong with trying to improve our weaknesses ? > > What is wrong with it is that we stop promoting one of the strength's of > linux. Show me a red hat magazine article on managing network manager > with the cli. If you were interested in writing one I think that would be most welcome and responded to warmly. -sv From johannbg at hi.is Wed May 13 20:39:40 2009 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Wed, 13 May 2009 20:39:40 +0000 Subject: Fedora Community Pre-Beta Testing In-Reply-To: <4A0B2FDE.1090906@redhat.com> References: <4A0AEA7F.4060302@redhat.com> <200905132232.35752.opensource@till.name> <4A0B2FDE.1090906@redhat.com> Message-ID: <4A0B300C.6000107@hi.is> On 05/13/2009 08:38 PM, Tom "spot" Callaway wrote: > On 05/13/2009 04:32 PM, Till Maas wrote: > >> I hope this is only misleading, but it looks to me that this test application >> demands the original FAS username/password from testers, which are then sent >> via an connection where the certificate cannot be easily verified by the >> testers. Also it is a bad idea to use these very important credentials in an >> application that may still have security flaws, because it is still in >> development. Last but not least this is also a bad education for the users >> that get used to provide their credentials to untrustworthy websites. >> > > I'm not entirely sure I follow this logic. Lots of things authenticate > against FAS. The source code for every bit of this web application is > open source and available for review. Do you trust Bodhi? How about > pkgdb? Or koji? Barring some specific security vulnerability (which you > haven't pointed out), this criticism seems unfounded. > Will it be possible to give karma points and comment on updates-testing and rawhide components and possible give feed back from test day's/cases ? -- Viking-Ice One of my gods has a hammer your's was nailed to a cross You do the math! -------------- next part -------------- An HTML attachment was scrubbed... URL: From orion at cora.nwra.com Wed May 13 20:49:38 2009 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 13 May 2009 14:49:38 -0600 Subject: Determine time of last keystroke and mouse movement Message-ID: <4A0B3262.2090702@cora.nwra.com> Is there anyway for periodic (cron like) job running as root on Fedora 10 (and up) to determine time of the last keypress and mouse movement? Back in the day I could look at the access time of /dev/tty7, but this appears to be no longer the case (even when moving to /dev/tty1 to account for the vt1 X shift). Any ideas on how to determine this would be greatly appreciated. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From jaredsmith at jaredsmith.net Wed May 13 20:50:06 2009 From: jaredsmith at jaredsmith.net (Jared Smith) Date: Wed, 13 May 2009 16:50:06 -0400 Subject: Database SIG? In-Reply-To: <1242082378.30883.73.camel@radiator.bos.redhat.com> References: <1242082378.30883.73.camel@radiator.bos.redhat.com> Message-ID: On Mon, May 11, 2009 at 6:52 PM, David Malcolm wrote: > Would anyone else be interested in a database special-interest-group > within Fedora? ?I don't see one at http://fedoraproject.org/wiki/SIGs Sure... I'll bite. I don't have as much free time as I'd like these days, but I'm a database nut, and would be happy to learn more and help others learn more as well. -Jared Smith From lsof at nodata.co.uk Wed May 13 20:57:29 2009 From: lsof at nodata.co.uk (nodata) Date: Wed, 13 May 2009 22:57:29 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: References: <4A082E70.7030904@TheTroubleshooters.dk> <1242060668.28322.85.camel@localhost.localdomain> <1242240008.2316.2.camel@prague> <2d319b780905131147r14143d5ev97ed5be9cff50773@mail.gmail.com> <1242247260.2316.5.camel@prague> Message-ID: <1242248249.2316.7.camel@prague> Am Mittwoch, den 13.05.2009, 16:42 -0400 schrieb Seth Vidal: > > On Wed, 13 May 2009, nodata wrote: > > > Am Mittwoch, den 13.05.2009, 20:47 +0200 schrieb Mathieu Bridon > > (bochecha): > >>> The command line is one of Linux's core strengths, the focus on the gui > >>> sends out the wrong signal. > >> > >> But command line tools are already there and are really powerful (as > >> you say, that's one of our core strength). No one says command line > >> should disappear, that would be a complete nonsense. And development > >> of those tools is not abandoned, that would be terrible. > >> > >> Gui and desktop on the other hand have historically been one of Linux' > >> weakness (at least from a ? normal ? end user point of view). What is > >> wrong with trying to improve our weaknesses ? > > > > What is wrong with it is that we stop promoting one of the strength's of > > linux. Show me a red hat magazine article on managing network manager > > with the cli. > > > If you were interested in writing one I think that would be most welcome > and responded to warmly. > > -sv Last time I asked, I was told that no such cli interface existed, and that it was planned. I have no real life experience of using this tool, nor how it fits into the big picture. I too would welcome an article, but I'm not the right person to write it. From a.badger at gmail.com Wed May 13 20:57:20 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 13 May 2009 13:57:20 -0700 Subject: Fedora (Linux) is Destroying it self In-Reply-To: References: <4A082E70.7030904@TheTroubleshooters.dk> <1242060668.28322.85.camel@localhost.localdomain> <1242240008.2316.2.camel@prague> <2d319b780905131147r14143d5ev97ed5be9cff50773@mail.gmail.com> <1242247260.2316.5.camel@prague> Message-ID: <4A0B3430.8080902@gmail.com> Seth Vidal wrote: > > > On Wed, 13 May 2009, nodata wrote: >> What is wrong with it is that we stop promoting one of the strength's of >> linux. Show me a red hat magazine article on managing network manager >> with the cli. > > > If you were interested in writing one I think that would be most welcome > and responded to warmly. > nirik (Kevin Fenzi) has just packaged up the cnetwork-manager program. "c" stands for command line in this case. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From opensource at till.name Wed May 13 20:58:25 2009 From: opensource at till.name (Till Maas) Date: Wed, 13 May 2009 22:58:25 +0200 Subject: Fedora Community Pre-Beta Testing In-Reply-To: <4A0B2FDE.1090906@redhat.com> References: <4A0AEA7F.4060302@redhat.com> <200905132232.35752.opensource@till.name> <4A0B2FDE.1090906@redhat.com> Message-ID: <200905132258.37063.opensource@till.name> On Mi Mai 13 2009, Tom "spot" Callaway wrote: > On 05/13/2009 04:32 PM, Till Maas wrote: > > I hope this is only misleading, but it looks to me that this test > > application demands the original FAS username/password from testers, > > which are then sent via an connection where the certificate cannot be > > easily verified by the testers. Also it is a bad idea to use these very > > important credentials in an application that may still have security > > flaws, because it is still in development. Last but not least this is > > also a bad education for the users that get used to provide their > > credentials to untrustworthy websites. > > I'm not entirely sure I follow this logic. Lots of things authenticate > against FAS. The source code for every bit of this web application is > open source and available for review. Do you trust Bodhi? How about > pkgdb? Or koji? Barring some specific security vulnerability (which you > haven't pointed out), this criticism seems unfounded. Koji requires a client SSL certificate for authentication, therefore afaik an attacker can only get access to the koji web interface using a man in the middle attack, i.e. changing the SSL certifcate of the koji webinterface atfter gettin in between the user and the webinterface. This is e.g. often easily possbile in networks of conferences. The other webservices (pkgdb and Bodhi) use a SSL certificate by a well know CA, therefore webbrowsers on Fedora systems can easier verify the certificate. Except of course in case the attacker posseses a rouge CA certifcate, that is signed by other CAs that are unluckily shipped with Fedora. Also I trust Bodhi, Koji and the Pkgdb more, because they are not announced to be trustworthy by their developers. You wrote in the announcement: | Please don't rely on this test instance for anything. For me this means, that one cannot rely on the test instane for protecting highly sensitive data, which the FAS credentials imho are. Also not using a good SSL certificate is already a first indication that security is not (yet) important for the test instance. The certificate seems not to be even signed by some private Fedora CA. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From notting at redhat.com Wed May 13 21:00:44 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 13 May 2009 17:00:44 -0400 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <1242248249.2316.7.camel@prague> References: <4A082E70.7030904@TheTroubleshooters.dk> <1242060668.28322.85.camel@localhost.localdomain> <1242240008.2316.2.camel@prague> <2d319b780905131147r14143d5ev97ed5be9cff50773@mail.gmail.com> <1242247260.2316.5.camel@prague> <1242248249.2316.7.camel@prague> Message-ID: <20090513210044.GA21048@nostromo.devel.redhat.com> nodata (lsof at nodata.co.uk) said: > > If you were interested in writing one I think that would be most welcome > > and responded to warmly. > > Last time I asked, I was told that no such cli interface existed, and > that it was planned. I have no real life experience of using this tool, > nor how it fits into the big picture. I too would welcome an article, > but I'm not the right person to write it. There is currently cnetworkmanager, written by an OpenSUSE developer. However, it's python, and therefore may not be suitable for *all* command-line/console-based usage (specifically, I'd love ifup/ifdown to be able to kick NM if it's running to DTRT, but I don't intend to require python to do so). I suspect a C/C++ version will be written if someone has the time/inclination. Bill From tcallawa at redhat.com Wed May 13 21:03:24 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 13 May 2009 17:03:24 -0400 Subject: Fedora Community Pre-Beta Testing In-Reply-To: <200905132258.37063.opensource@till.name> References: <4A0AEA7F.4060302@redhat.com> <200905132232.35752.opensource@till.name> <4A0B2FDE.1090906@redhat.com> <200905132258.37063.opensource@till.name> Message-ID: <4A0B359C.7000409@redhat.com> On 05/13/2009 04:58 PM, Till Maas wrote: > Also I trust Bodhi, Koji and the Pkgdb more, because they are not announced to > be trustworthy by their developers. You wrote in the announcement: > > | Please don't rely on this test instance for anything. So, to summarize, you're interpreting that as a statement of insecurity? Far from it. I meant it more as a statement of "there are bugs, some functionality doesn't work right". ~spot From dmalcolm at redhat.com Wed May 13 21:05:26 2009 From: dmalcolm at redhat.com (David Malcolm) Date: Wed, 13 May 2009 17:05:26 -0400 Subject: Database SIG? In-Reply-To: References: <1242082378.30883.73.camel@radiator.bos.redhat.com> Message-ID: <1242248726.30026.21.camel@radiator.bos.redhat.com> On Wed, 2009-05-13 at 16:50 -0400, Jared Smith wrote: > On Mon, May 11, 2009 at 6:52 PM, David Malcolm wrote: > > Would anyone else be interested in a database special-interest-group > > within Fedora? I don't see one at http://fedoraproject.org/wiki/SIGs > > Sure... I'll bite. I don't have as much free time as I'd like these > days, but I'm a database nut, and would be happy to learn more and > help others learn more as well. > Awesome! I'm in a similar position. I spent some time yesterday trying to gather a list of all Free database software (where "database" is only loosely defined), by going through bugzilla, and doing web searches. Current list (very raw) is here: https://fedoraproject.org/wiki/User:Dmalcolm/DatabaseSoftware (Many of the review requests seem to have successfully completed) Did I miss anything? If anyone is feeling energetic, feel free to hack on that list and improve it. The classifications are rather arbitrary (and wrong in places) Dave From a.badger at gmail.com Wed May 13 21:16:37 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 13 May 2009 14:16:37 -0700 Subject: Fedora Community Pre-Beta Testing In-Reply-To: <4A0B2FDE.1090906@redhat.com> References: <4A0AEA7F.4060302@redhat.com> <200905132232.35752.opensource@till.name> <4A0B2FDE.1090906@redhat.com> Message-ID: <4A0B38B5.6040704@gmail.com> Tom "spot" Callaway wrote: > On 05/13/2009 04:32 PM, Till Maas wrote: >> I hope this is only misleading, but it looks to me that this test application >> demands the original FAS username/password from testers, which are then sent >> via an connection where the certificate cannot be easily verified by the >> testers. Also it is a bad idea to use these very important credentials in an >> application that may still have security flaws, because it is still in >> development. Last but not least this is also a bad education for the users >> that get used to provide their credentials to untrustworthy websites. > > I'm not entirely sure I follow this logic. Lots of things authenticate > against FAS. The source code for every bit of this web application is > open source and available for review. Do you trust Bodhi? How about > pkgdb? Or koji? Barring some specific security vulnerability (which you > haven't pointed out), this criticism seems unfounded. > The SSL certificate for all of bodhi, pkgdb, mirrormanager, and fas are the same. When you give your password to any of these entities, you are trusting that single SSL certificate. The SSL certificate is signed by a trusted entity whose business it is to assign certificates to organizations. Additionally, all of these apps are available from a common domain name: admin.fedoraproject.org. So the cookies that hold your authentication tokens and are passed back and forth to the server are available to each of those apps anyway. On the other hand, publictest16 is on a separate server. The server has an SSL certificate that's self signed. Additionally, the server has a different set of people who can log into it with possibly different trust than the main servers. With other servers that we host on publictest machines we have them use a test instance of FAS. I'm not sure that that will work with F-community due to the way it has to tie into a lot of other production services but it definitely isn't a good idea to encourage people to type their FAS password into non-production machines. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From pbrobinson at gmail.com Wed May 13 21:25:35 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 13 May 2009 22:25:35 +0100 Subject: FESco meeting summary for 20090507 In-Reply-To: <4A088A97.2030604@gmail.com> References: <5256d0b0905101512m5dae0071jad00fe7d735cf284@mail.gmail.com> <4A088A97.2030604@gmail.com> Message-ID: <5256d0b0905131425m3eafdc1focc5c28baee439213@mail.gmail.com> >> Looking through the orphaned package list there looks to be quite a >> list of dead packages there as well. What is the process for marking >> them dead in the pgkdb or do they just hang around as orphaned in case >> someone wants to revive them. The gstreamer08 ones are some that come >> to mind. I know I have ownership of a package as well that is dead >> (replaced by other packages) and has gone through the dead package >> process, is there a process for the pkgdb part of that? >> > There will be but there isn't yet. ?I'm testing and working out bugs in > a large packagedb update now. ?It has support for retiring packages. > We'll probably have to write some new supporting scripts to go along > with that (to push retired package information from packagedb into koji, > maybe to do the dead.package stuff from the packagedb rather than > manually by the maintainer, etc). Looking at pkgdb it might be useful for the package owner to be able to put a note against the package that is displayed in the package info page. Peter From opensource at till.name Wed May 13 21:26:37 2009 From: opensource at till.name (Till Maas) Date: Wed, 13 May 2009 23:26:37 +0200 Subject: Fedora Community Pre-Beta Testing In-Reply-To: <4A0B359C.7000409@redhat.com> References: <4A0AEA7F.4060302@redhat.com> <200905132258.37063.opensource@till.name> <4A0B359C.7000409@redhat.com> Message-ID: <200905132326.47989.opensource@till.name> On Mi Mai 13 2009, Tom "spot" Callaway wrote: > On 05/13/2009 04:58 PM, Till Maas wrote: > > Also I trust Bodhi, Koji and the Pkgdb more, because they are not > > announced to > > > > be trustworthy by their developers. You wrote in the announcement: > > | Please don't rely on this test instance for anything. > > So, to summarize, you're interpreting that as a statement of insecurity? > Far from it. I meant it more as a statement of "there are bugs, some > functionality doesn't work right". No, this summary lacks the important fact that the password is not transfered via a secured connection. The problem that the application itself may have security vulnerabilities is only one reason, why it is not a good idea to test it with the real FAS passwords. Another reason I can think of, is that these passwords may be disclosed to the people that debug the tested application or that they are logged somewhere, because usually the logging on testing setups is more verbose than on stable ones. Even on the stable fedora wiki setup FAS passwords were logged by accident. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From jleddy at redhat.com Wed May 13 21:26:40 2009 From: jleddy at redhat.com (James M. Leddy) Date: Wed, 13 May 2009 17:26:40 -0400 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <20090513210044.GA21048@nostromo.devel.redhat.com> References: <4A082E70.7030904@TheTroubleshooters.dk> <1242060668.28322.85.camel@localhost.localdomain> <1242240008.2316.2.camel@prague> <2d319b780905131147r14143d5ev97ed5be9cff50773@mail.gmail.com> <1242247260.2316.5.camel@prague> <1242248249.2316.7.camel@prague> <20090513210044.GA21048@nostromo.devel.redhat.com> Message-ID: <4A0B3B10.2010105@redhat.com> Bill Nottingham wrote: > nodata (lsof at nodata.co.uk) said: >>> If you were interested in writing one I think that would be most welcome >>> and responded to warmly. >> Last time I asked, I was told that no such cli interface existed, and >> that it was planned. I have no real life experience of using this tool, >> nor how it fits into the big picture. I too would welcome an article, >> but I'm not the right person to write it. > > There is currently cnetworkmanager, written by an OpenSUSE developer. > However, it's python, and therefore may not be suitable for *all* > command-line/console-based usage (specifically, I'd love ifup/ifdown > to be able to kick NM if it's running to DTRT, but I don't intend to > require python to do so). I suspect a C/C++ version will be > written if someone has the time/inclination. I did start a C version (for a very short time, I gave up after just listing the networks). If anyone is actually interested in pursuing this I may be able to start up again, depending on motivation. http://nm-cli.svn.sourceforge.net/viewvc/nm-cli/src/ It's about 17 months old, I doubt it works. Regarding topic, though I agree that a number of his points are invalid, in general things are almost getting automated to the point where they are confusing. For example, for a while ago udev scripts were calling ifconfig down on interfaces, and I had to explain to a friend of mine why this was happening (at the time, I didn't even know it was udev but suspected it). Another time I saw talk of using udev to start initscritps (bluetooth iirc), and though i don't object to this is if is done in some standardized way with a framework set around it, the way it was being hacked out for F11 seemed backwards (usually initscripts load modules) and actually made me cringe. I actually don't object to "doing the right thing" (desktop control of mounting media, bluetooth, keyboards etc...), but it must be done in a way that doesn't confound a large percentage of long time linux users. > > Bill > -- James M. Leddy Technical Account Manager Red Hat Inc. From sundaram at fedoraproject.org Wed May 13 21:32:55 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 14 May 2009 03:02:55 +0530 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: References: <4A0814ED.60205@redhat.com> <4A09B8FE.4040904@cygnusx-1.org> <4A09C018.4060906@cygnusx-1.org> <4A09CBE4.4020807@cygnusx-1.org> <1242232123.6282.5.camel@localhost.localdomain> Message-ID: <4A0B3C87.3050300@fedoraproject.org> On 05/13/2009 11:37 PM, Kevin Kofler wrote: > Jesse Keating wrote: >> You do realize that Fedora's trademark policy is even "worse" ? > > But we don't expect all third parties to go through the trademark approval > process (and they don't or even can't, for different reasons), we have them > ship generic logos, the new Fedora Remix artwork (which also has a policy > to follow, but a less strict one when it comes to modification of the > software than Firefox!) or their own logos instead. I don't see why we > shouldn't do the same for Firefox. Firefox already allows easy rebranding. If you want to fork, you can take advantage of that but what exactly do you want to patch that Mozilla is not allowing you to do? Rahul From lsof at nodata.co.uk Wed May 13 21:29:30 2009 From: lsof at nodata.co.uk (nodata) Date: Wed, 13 May 2009 23:29:30 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A0B3430.8080902@gmail.com> References: <4A082E70.7030904@TheTroubleshooters.dk> <1242060668.28322.85.camel@localhost.localdomain> <1242240008.2316.2.camel@prague> <2d319b780905131147r14143d5ev97ed5be9cff50773@mail.gmail.com> <1242247260.2316.5.camel@prague> <4A0B3430.8080902@gmail.com> Message-ID: <1242250170.2316.9.camel@prague> Am Mittwoch, den 13.05.2009, 13:57 -0700 schrieb Toshio Kuratomi: > Seth Vidal wrote: > > > > > > On Wed, 13 May 2009, nodata wrote: > > >> What is wrong with it is that we stop promoting one of the strength's of > >> linux. Show me a red hat magazine article on managing network manager > >> with the cli. > > > > > > If you were interested in writing one I think that would be most welcome > > and responded to warmly. > > > nirik (Kevin Fenzi) has just packaged up the cnetwork-manager program. > "c" stands for command line in this case. > > -Toshio Thanks a lot. I didn't know about this, I thought we were meant to use nm-tool. But I think this demonstrates a point I made, because the command line tool came last :( From caillon at redhat.com Wed May 13 21:36:01 2009 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 13 May 2009 14:36:01 -0700 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A0B3C87.3050300@fedoraproject.org> References: <4A0814ED.60205@redhat.com> <4A09B8FE.4040904@cygnusx-1.org> <4A09C018.4060906@cygnusx-1.org> <4A09CBE4.4020807@cygnusx-1.org> <1242232123.6282.5.camel@localhost.localdomain> <4A0B3C87.3050300@fedoraproject.org> Message-ID: <4A0B3D41.3070504@redhat.com> On 05/13/2009 02:32 PM, Rahul Sundaram wrote: > On 05/13/2009 11:37 PM, Kevin Kofler wrote: >> Jesse Keating wrote: >>> You do realize that Fedora's trademark policy is even "worse" ? >> >> But we don't expect all third parties to go through the trademark approval >> process (and they don't or even can't, for different reasons), we have them >> ship generic logos, the new Fedora Remix artwork (which also has a policy >> to follow, but a less strict one when it comes to modification of the >> software than Firefox!) or their own logos instead. I don't see why we >> shouldn't do the same for Firefox. > > Firefox already allows easy rebranding. If you want to fork, you can > take advantage of that but what exactly do you want to patch that > Mozilla is not allowing you to do? Better yet, what bug have you filed against the Fedora package that I have refused to patch locally without good reason? Sending things to be fixed upstream and waiting for upstream to take the fix is not uncommon for any package in the distro. From skvidal at fedoraproject.org Wed May 13 21:34:26 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 13 May 2009 17:34:26 -0400 (EDT) Subject: Fedora (Linux) is Destroying it self In-Reply-To: <1242250170.2316.9.camel@prague> References: <4A082E70.7030904@TheTroubleshooters.dk> <1242060668.28322.85.camel@localhost.localdomain> <1242240008.2316.2.camel@prague> <2d319b780905131147r14143d5ev97ed5be9cff50773@mail.gmail.com> <1242247260.2316.5.camel@prague> <4A0B3430.8080902@gmail.com> <1242250170.2316.9.camel@prague> Message-ID: On Wed, 13 May 2009, nodata wrote: > > Thanks a lot. I didn't know about this, I thought we were meant to use > nm-tool. > > But I think this demonstrates a point I made, because the command line > tool came last :( And I think this demonstrates a point made in open source software development for years. Patches Cheerfully accepted. :) -sv From a.badger at gmail.com Wed May 13 21:37:21 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 13 May 2009 14:37:21 -0700 Subject: FESco meeting summary for 20090507 In-Reply-To: <5256d0b0905131425m3eafdc1focc5c28baee439213@mail.gmail.com> References: <5256d0b0905101512m5dae0071jad00fe7d735cf284@mail.gmail.com> <4A088A97.2030604@gmail.com> <5256d0b0905131425m3eafdc1focc5c28baee439213@mail.gmail.com> Message-ID: <4A0B3D91.6060504@gmail.com> Peter Robinson wrote: >> There will be but there isn't yet. I'm testing and working out bugs in >> a large packagedb update now. It has support for retiring packages. >> We'll probably have to write some new supporting scripts to go along >> with that (to push retired package information from packagedb into koji, >> maybe to do the dead.package stuff from the packagedb rather than >> manually by the maintainer, etc). > > Looking at pkgdb it might be useful for the package owner to be able > to put a note against the package that is displayed in the package > info page. > That's a good idea. Do you think something specific to the retired package process - like the text that we ask maintainers to add to dead.package currently? Or do you think that we'd want such text always? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From ajax at redhat.com Wed May 13 21:38:39 2009 From: ajax at redhat.com (Adam Jackson) Date: Wed, 13 May 2009 17:38:39 -0400 Subject: Determine time of last keystroke and mouse movement In-Reply-To: <4A0B3262.2090702@cora.nwra.com> References: <4A0B3262.2090702@cora.nwra.com> Message-ID: <1242250719.21675.164.camel@atropine.boston.devel.redhat.com> On Wed, 2009-05-13 at 14:49 -0600, Orion Poplawski wrote: > Is there anyway for periodic (cron like) job running as root on Fedora > 10 (and up) to determine time of the last keypress and mouse movement? > Back in the day I could look at the access time of /dev/tty7, but this > appears to be no longer the case (even when moving to /dev/tty1 to > account for the vt1 X shift). Any ideas on how to determine this would > be greatly appreciated. You want the IDLETIME XSync counter in the running X session. Gnome already uses this to determine session idleness. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From pbrobinson at gmail.com Wed May 13 21:46:22 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 13 May 2009 22:46:22 +0100 Subject: FESco meeting summary for 20090507 In-Reply-To: <4A0B3D91.6060504@gmail.com> References: <5256d0b0905101512m5dae0071jad00fe7d735cf284@mail.gmail.com> <4A088A97.2030604@gmail.com> <5256d0b0905131425m3eafdc1focc5c28baee439213@mail.gmail.com> <4A0B3D91.6060504@gmail.com> Message-ID: <5256d0b0905131446j1aac35dao16b9edf231c3f34a@mail.gmail.com> >>> There will be but there isn't yet. ?I'm testing and working out bugs in >>> a large packagedb update now. ?It has support for retiring packages. >>> We'll probably have to write some new supporting scripts to go along >>> with that (to push retired package information from packagedb into koji, >>> maybe to do the dead.package stuff from the packagedb rather than >>> manually by the maintainer, etc). >> >> Looking at pkgdb it might be useful for the package owner to be able >> to put a note against the package that is displayed in the package >> info page. >> > That's a good idea. ?Do you think something specific to the retired > package process - like the text that we ask maintainers to add to > dead.package currently? ?Or do you think that we'd want such text always? I was thinking just a general memo field. It could be used to note that the package is dead but could be easily used by the package owner to make some other note about the package, whether it be to document something about upstream or something that you wouldn't usually keep in the spec file which seems the only other place to store things about a package. Peter From rjones at redhat.com Wed May 13 22:08:39 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 13 May 2009 23:08:39 +0100 Subject: Breaking deps deliberately In-Reply-To: <20090513142742.GB19610@amd.home.annexia.org> References: <20090513111343.4d79d48f@faldor.intranet> <20090513134744.GA19304@amd.home.annexia.org> <4A0AD15F.6040300@fedoraproject.org> <20090513135728.GA19428@amd.home.annexia.org> <20090513142048.GA19610@amd.home.annexia.org> <20090513142742.GB19610@amd.home.annexia.org> Message-ID: <20090513220839.GA22106@amd.home.annexia.org> On Wed, May 13, 2009 at 03:27:42PM +0100, Richard W.M. Jones wrote: > Someone could easily do the same thing in future. If broken > dependencies are so unacceptable, then it should be added to the > packaging guidelines. I added this as an agenda item for the FESCo meeting: https://fedorahosted.org/fesco/ticket/147 "Meeting agenda item: No broken dependencies should be a packaging guideline" Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From sundaram at fedoraproject.org Wed May 13 22:18:51 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 14 May 2009 03:48:51 +0530 Subject: Breaking deps deliberately In-Reply-To: <20090513220839.GA22106@amd.home.annexia.org> References: <20090513111343.4d79d48f@faldor.intranet> <20090513134744.GA19304@amd.home.annexia.org> <4A0AD15F.6040300@fedoraproject.org> <20090513135728.GA19428@amd.home.annexia.org> <20090513142048.GA19610@amd.home.annexia.org> <20090513142742.GB19610@amd.home.annexia.org> <20090513220839.GA22106@amd.home.annexia.org> Message-ID: <4A0B474B.5090001@fedoraproject.org> On 05/14/2009 03:38 AM, Richard W.M. Jones wrote: > On Wed, May 13, 2009 at 03:27:42PM +0100, Richard W.M. Jones wrote: >> Someone could easily do the same thing in future. If broken >> dependencies are so unacceptable, then it should be added to the >> packaging guidelines. > > I added this as an agenda item for the FESCo meeting: > > https://fedorahosted.org/fesco/ticket/147 > "Meeting agenda item: No broken dependencies should be a packaging guideline" Just a note. If you want to propose a packaging guideline modification, the process is outlined at http://fedoraproject.org/wiki/Packaging/Committee#Guideline_Change_Procedure There is no need to bring up such a simple change to FESCo. Just submit a draft. Rahul From orion at cora.nwra.com Wed May 13 22:24:26 2009 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 13 May 2009 16:24:26 -0600 Subject: Determine time of last keystroke and mouse movement In-Reply-To: <1242250719.21675.164.camel@atropine.boston.devel.redhat.com> References: <4A0B3262.2090702@cora.nwra.com> <1242250719.21675.164.camel@atropine.boston.devel.redhat.com> Message-ID: <4A0B489A.4040104@cora.nwra.com> Adam Jackson wrote: > On Wed, 2009-05-13 at 14:49 -0600, Orion Poplawski wrote: >> Is there anyway for periodic (cron like) job running as root on Fedora >> 10 (and up) to determine time of the last keypress and mouse movement? >> Back in the day I could look at the access time of /dev/tty7, but this >> appears to be no longer the case (even when moving to /dev/tty1 to >> account for the vt1 X shift). Any ideas on how to determine this would >> be greatly appreciated. > > You want the IDLETIME XSync counter in the running X session. Gnome > already uses this to determine session idleness. > > - ajax > That assumes running inside the X session though right? This is a system process started at boot. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From a.badger at gmail.com Wed May 13 22:28:53 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 13 May 2009 15:28:53 -0700 Subject: Breaking deps deliberately In-Reply-To: <20090513220839.GA22106@amd.home.annexia.org> References: <20090513111343.4d79d48f@faldor.intranet> <20090513134744.GA19304@amd.home.annexia.org> <4A0AD15F.6040300@fedoraproject.org> <20090513135728.GA19428@amd.home.annexia.org> <20090513142048.GA19610@amd.home.annexia.org> <20090513142742.GB19610@amd.home.annexia.org> <20090513220839.GA22106@amd.home.annexia.org> Message-ID: <4A0B49A5.2050003@gmail.com> Richard W.M. Jones wrote: > On Wed, May 13, 2009 at 03:27:42PM +0100, Richard W.M. Jones wrote: >> Someone could easily do the same thing in future. If broken >> dependencies are so unacceptable, then it should be added to the >> packaging guidelines. > > I added this as an agenda item for the FESCo meeting: > > https://fedorahosted.org/fesco/ticket/147 > "Meeting agenda item: No broken dependencies should be a packaging guideline" > Additions to the Packaging Guidelines are a Fedora Packaging Committee item, not FESCo. However, this sounds a bit more like a Fedora Policy that FESCo would decide rather than a Packaging Guideline. And in fact, there's already a variety of FESCo policies that address this issue as pointed out by others on this thread. So your next step depends on whether you want it to be in the actual Guidelines or just want it spelled out clearer in FESCo policy. If you want a Guideline... I think that no broken dependencies is a fairly obvious thing. What's the rationale for including it in the Guidelines? Do any other distributions have it in their Guidelines? Do any other distributions purposefully add broken dependencies to their repositories (So that you wouldn't be able to install it without pointing at a second source for a package)? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From christoph.wickert at googlemail.com Thu May 14 00:09:52 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Thu, 14 May 2009 02:09:52 +0200 Subject: koji breakage for F12 builds In-Reply-To: References: <5256d0b0905121504k4768401an741dd4d0bd5cf045@mail.gmail.com> <1242172496.3569.15.camel@localhost.localdomain> Message-ID: <1242259792.10712.36.camel@localhost.localdomain> Am Mittwoch, den 13.05.2009, 20:13 +0200 schrieb Kevin Kofler: > Christoph Wickert wrote: > > xfce4-notifyd conflicts with notification-daemon because both provide > > /usr/share/dbus-1/services/org.freedesktop.Notifications.service > > Easy "solution": rename the file to: > /usr/share/dbus-1/services/xfce-org.freedesktop.Notifications.service > that way you don't need an RPM-level Conflicts and it'll still work. Done. All problems should be fixed now, if not please let me know. Regards, Christoph From seg at haxxed.com Thu May 14 00:42:18 2009 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 13 May 2009 19:42:18 -0500 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <234fa2210905120526i364a7f25m97cbed4a0b23a1ea@mail.gmail.com> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A08C233.4020902@sapience.com> <4A093807.4010403@TheTroubleshooters.dk> <234fa2210905120156h397d0125l500d9fa330bb5445@mail.gmail.com> <1242124621.4183.75.camel@ignacio.ignacio.lan> <234fa2210905120526i364a7f25m97cbed4a0b23a1ea@mail.gmail.com> Message-ID: <1242261738.5155.25.camel@localhost.localdomain> On Tue, 2009-05-12 at 13:26 +0100, Ilyes Gouta wrote: > Hi, > > Obviously one has to set up $PATH and $LD_LIBRARY_PATH to get programs > running properly. /usr/bin would be populated with scripts that do > exactly that so that the change is transparent to the user. But that's > really the implementation part of the idea, let's stick to the concept > for the moment.. Isn't having one folder per application a nice > feature? What I'm emphasizing here is separation for more flexibility. You're almost there. What you really want is something like OSX bundles: http://en.wikipedia.org/wiki/Bundle_%28NEXTSTEP%29 Like say, klik or glick: http://en.wikipedia.org/wiki/Klik_%28packaging_method%29 http://www.gnome.org/~alexl/glick/ glick is even written by a redhatter. OMFG glick looks like exactly what I've been looking for. I'm building glick right now so I can play with it... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mclasen at redhat.com Thu May 14 01:00:46 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 13 May 2009 21:00:46 -0400 Subject: PolicyKit changes in F12 Message-ID: <1242262846.9432.9.camel@localhost.localdomain> Just a heads-up: We hope to land a new PolicyKit version (which will turn into 1.0, eventually) in F12 soon. The new version simplifies the API and will require PolicyKit-using application to be ported. For more information, have a look at the feature page: http://fedoraproject.org/wiki/Features/PolicyKitOne It also has pointers to api docs and a (terse) porting guide. We already have a collection of patches for quite a few PolicyKit-using apps, so the transitions should be relatively painless. Matthias From tony at bakeyournoodle.com Thu May 14 01:16:29 2009 From: tony at bakeyournoodle.com (Tony Breeds) Date: Thu, 14 May 2009 11:16:29 +1000 Subject: Determine time of last keystroke and mouse movement In-Reply-To: <4A0B3262.2090702@cora.nwra.com> References: <4A0B3262.2090702@cora.nwra.com> Message-ID: <20090514011629.GW16602@bilbo.ozlabs.org> On Wed, May 13, 2009 at 02:49:38PM -0600, Orion Poplawski wrote: > Is there anyway for periodic (cron like) job running as root on Fedora > 10 (and up) to determine time of the last keypress and mouse movement? > Back in the day I could look at the access time of /dev/tty7, but this > appears to be no longer the case (even when moving to /dev/tty1 to > account for the vt1 X shift). Any ideas on how to determine this would > be greatly appreciated. I'm sure you can write something to read (and log) /dev/input/* This daemon could be started at system boot and /shouldn't/ interfere with system opperation. Yours Tony From kevin.kofler at chello.at Thu May 14 03:48:05 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 14 May 2009 05:48:05 +0200 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 References: <4A0814ED.60205@redhat.com> <4A09B8FE.4040904@cygnusx-1.org> <4A09C018.4060906@cygnusx-1.org> <4A09CBE4.4020807@cygnusx-1.org> Message-ID: Matthew Woehlke wrote: > Why is xulrunner locked down? Presumably because otherwise the trademarked builds of Firefox wouldn't have been allowed to use the system xulrunner at all. A lot of the Firefox behavior is actually implemented in xulrunner, not firefox. And there's ongoing work to allow building Thunderbird against a system xulrunner as well. Kevin Kofler From kevin.kofler at chello.at Thu May 14 03:51:25 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 14 May 2009 05:51:25 +0200 Subject: Fedora (Linux) is Destroying it self References: <4A082E70.7030904@TheTroubleshooters.dk> <1242060668.28322.85.camel@localhost.localdomain> <1242240008.2316.2.camel@prague> <2d319b780905131147r14143d5ev97ed5be9cff50773@mail.gmail.com> <1242247260.2316.5.camel@prague> <1242248249.2316.7.camel@prague> <20090513210044.GA21048@nostromo.devel.redhat.com> Message-ID: Bill Nottingham wrote: > However, it's python, and therefore may not be suitable for *all* > command-line/console-based usage (specifically, I'd love ifup/ifdown > to be able to kick NM if it's running to DTRT, but I don't intend to > require python to do so). It's pretty hard to use Fedora without Python anyway, as yum and other basic stuff is written in Python. Kevin Kofler From caillon at redhat.com Thu May 14 04:47:18 2009 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 13 May 2009 21:47:18 -0700 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <1242250170.2316.9.camel@prague> References: <4A082E70.7030904@TheTroubleshooters.dk> <1242060668.28322.85.camel@localhost.localdomain> <1242240008.2316.2.camel@prague> <2d319b780905131147r14143d5ev97ed5be9cff50773@mail.gmail.com> <1242247260.2316.5.camel@prague> <4A0B3430.8080902@gmail.com> <1242250170.2316.9.camel@prague> Message-ID: <4A0BA256.2080606@redhat.com> On 05/13/2009 02:29 PM, nodata wrote: > Am Mittwoch, den 13.05.2009, 13:57 -0700 schrieb Toshio Kuratomi: >> nirik (Kevin Fenzi) has just packaged up the cnetwork-manager program. >> "c" stands for command line in this case. >> >> -Toshio > > Thanks a lot. I didn't know about this, I thought we were meant to use > nm-tool. > > But I think this demonstrates a point I made, because the command line > tool came last :( Though, if someone had come by and made a new CLI tool for managing networks a few years ago, would people really decide to switch their CLI tool because of it? Would it have gotten the development and user community behind it to support its development? My guess is probably not, especially given there were several CLI tools that attempted to do the automation back when NM first came out. People are picky about their command line tools. What happened happened, and probably couldn't have happened any other way. From bruno at wolff.to Thu May 14 05:40:33 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Thu, 14 May 2009 00:40:33 -0500 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A0BA256.2080606@redhat.com> References: <4A082E70.7030904@TheTroubleshooters.dk> <1242060668.28322.85.camel@localhost.localdomain> <1242240008.2316.2.camel@prague> <2d319b780905131147r14143d5ev97ed5be9cff50773@mail.gmail.com> <1242247260.2316.5.camel@prague> <4A0B3430.8080902@gmail.com> <1242250170.2316.9.camel@prague> <4A0BA256.2080606@redhat.com> Message-ID: <20090514054033.GB21431@wolff.to> On Wed, May 13, 2009 at 21:47:18 -0700, Christopher Aillon wrote: > > Though, if someone had come by and made a new CLI tool for managing > networks a few years ago, would people really decide to switch their CLI > tool because of it? Would it have gotten the development and user > community behind it to support its development? My guess is probably > not, especially given there were several CLI tools that attempted to do > the automation back when NM first came out. People are picky about > their command line tools. What happened happened, and probably couldn't > have happened any other way. There was a change a few years ago. ip replaced ifconfig and route. Before that ipchains was replaced by iptables. There is an iptables replacement undergoing development now. From jkeating at redhat.com Thu May 14 05:59:36 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 13 May 2009 22:59:36 -0700 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <20090514054033.GB21431@wolff.to> References: <4A082E70.7030904@TheTroubleshooters.dk> <1242060668.28322.85.camel@localhost.localdomain> <1242240008.2316.2.camel@prague> <2d319b780905131147r14143d5ev97ed5be9cff50773@mail.gmail.com> <1242247260.2316.5.camel@prague> <4A0B3430.8080902@gmail.com> <1242250170.2316.9.camel@prague> <4A0BA256.2080606@redhat.com> <20090514054033.GB21431@wolff.to> Message-ID: <1242280776.6282.55.camel@localhost.localdomain> On Thu, 2009-05-14 at 00:40 -0500, Bruno Wolff III wrote: > There was a change a few years ago. ip replaced ifconfig and route. Really? Seems that ip hasn't really taken hold much. ipchains was forced out and there was no option there. I bet iptables won't go away unless it's forced out too. I'd love to see a thread started to force out ifconfig and route. That'd be good times. No, wait, that other thing. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Thu May 14 06:00:29 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 14 May 2009 08:00:29 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A0BA256.2080606@redhat.com> References: <4A082E70.7030904@TheTroubleshooters.dk> <1242060668.28322.85.camel@localhost.localdomain> <1242240008.2316.2.camel@prague> <2d319b780905131147r14143d5ev97ed5be9cff50773@mail.gmail.com> <1242247260.2316.5.camel@prague> <4A0B3430.8080902@gmail.com> <1242250170.2316.9.camel@prague> <4A0BA256.2080606@redhat.com> Message-ID: <4A0BB37D.2060105@freenet.de> Christopher Aillon wrote: > On 05/13/2009 02:29 PM, nodata wrote: >> Am Mittwoch, den 13.05.2009, 13:57 -0700 schrieb Toshio Kuratomi: >>> nirik (Kevin Fenzi) has just packaged up the cnetwork-manager program. >>> "c" stands for command line in this case. >>> >>> -Toshio >> >> Thanks a lot. I didn't know about this, I thought we were meant to use >> nm-tool. >> >> But I think this demonstrates a point I made, because the command line >> tool came last :( > > Though, if someone had come by and made a new CLI tool for managing > networks a few years ago, would people really decide to switch their CLI > tool because of it? Would it have gotten the development and user > community behind it to support its development? Well, probably not, because ... a) Those people who wanted something like "NM", are not the same people who want CLI-tools. b) For those people wanting CLI-tools, NM is just a series of regressions and problems, something which doesn't deserve to be taken seriously. They _turned away_ from using and supporting NM, may-be even from using Fedora, in particular since NM tries to replace networking scripts. c) "network scripts" had not been that bad as some people might want them to appear. They suffered from bugs and poor maintenance, but that's it. As long as NM had been optional, the CLI-folks didn't see a need to get involved. In short: IMO, NM and network-scripts are/were addressing different user audiences and use-cases. Neither one actually meets both audiences' demands. Before NM, the "dial-on demand/single-user/desktop" users were dissatisfied, now the "static connection/multi-users/server" users are dissatisfied. Unfortunately, the latter are likely a much smaller group than the former (Accused to be "corner-cases"), which has allowed NM to win, and now is the cause to ruck-sack it to meet the CLI-user's demands. > My guess is probably > not, especially given there were several CLI tools that attempted to do > the automation back when NM first came out. People are picky about > their command line tools. What happened happened, and probably couldn't > have happened any other way. It could have ... it would have been a matter of will. Instead, RH actively supported the NetworkManager devs, despite the criticism NM had received and still receives (Other distros went different ways). IMO, we are now actually discussing to work around to the flaws NM suffers from and to tweak it into something "usable". Ralf From awilliam at redhat.com Thu May 14 06:02:50 2009 From: awilliam at redhat.com (Adam Williamson) Date: Wed, 13 May 2009 23:02:50 -0700 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <20090514054033.GB21431@wolff.to> References: <4A082E70.7030904@TheTroubleshooters.dk> <1242060668.28322.85.camel@localhost.localdomain> <1242240008.2316.2.camel@prague> <2d319b780905131147r14143d5ev97ed5be9cff50773@mail.gmail.com> <1242247260.2316.5.camel@prague> <4A0B3430.8080902@gmail.com> <1242250170.2316.9.camel@prague> <4A0BA256.2080606@redhat.com> <20090514054033.GB21431@wolff.to> Message-ID: <1242280970.2923.918.camel@adam.local.net> On Thu, 2009-05-14 at 00:40 -0500, Bruno Wolff III wrote: > On Wed, May 13, 2009 at 21:47:18 -0700, > Christopher Aillon wrote: > > > > Though, if someone had come by and made a new CLI tool for managing > > networks a few years ago, would people really decide to switch their CLI > > tool because of it? Would it have gotten the development and user > > community behind it to support its development? My guess is probably > > not, especially given there were several CLI tools that attempted to do > > the automation back when NM first came out. People are picky about > > their command line tools. What happened happened, and probably couldn't > > have happened any other way. > > There was a change a few years ago. ip replaced ifconfig and route. Er, it did? I'm still using ifconfig and route. They appear to work. :) The joys of backwards compatibility! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From rjones at redhat.com Thu May 14 07:46:05 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 14 May 2009 08:46:05 +0100 Subject: Breaking deps deliberately In-Reply-To: <4A0B49A5.2050003@gmail.com> References: <20090513134744.GA19304@amd.home.annexia.org> <4A0AD15F.6040300@fedoraproject.org> <20090513135728.GA19428@amd.home.annexia.org> <20090513142048.GA19610@amd.home.annexia.org> <20090513142742.GB19610@amd.home.annexia.org> <20090513220839.GA22106@amd.home.annexia.org> <4A0B49A5.2050003@gmail.com> Message-ID: <20090514074605.GA24489@amd.home.annexia.org> On Wed, May 13, 2009 at 03:28:53PM -0700, Toshio Kuratomi wrote: > Do any other distributions purposefully add broken dependencies to their > repositories (So that you wouldn't be able to install it without > pointing at a second source for a package)? Debian allows them, and they have a special program called 'equivs' which you can use to locally compile packages in order to satisfy such broken dependencies: http://www.debian.org/doc/manuals/apt-howto/ch-helpers.en.html Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From pmatilai at laiskiainen.org Thu May 14 07:46:25 2009 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 14 May 2009 10:46:25 +0300 (EEST) Subject: rpm hashes In-Reply-To: <1242225439.21675.81.camel@atropine.boston.devel.redhat.com> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A086703.1080906@amiga-hardware.com> <4A094EC4.9030506@TheTroubleshooters.dk> <1242125395.13505.449.camel@breeves.fab.redhat.com> <4A0988DC.8030103@freenet.de> <4A098F11.4080008@freenet.de> <1242225439.21675.81.camel@atropine.boston.devel.redhat.com> Message-ID: On Wed, 13 May 2009, Adam Jackson wrote: > On Wed, 2009-05-13 at 09:13 +0300, Panu Matilainen wrote: > >> From rpm POV it's perfectly legal for any number of packages to share >> identical files, and that still works. What doesn't work is sharing files >> between packages using different file hash algorithm, so if you need to >> share across Centos >= 3 <-> Fedora >= 11 you need to build the package >> for lowest common denominator, meaning md5 file hashes. Fedora 11 changes >> the default algorithm from md5 to sha256 in redhat-rpm-config, producing >> packages that are incompatible with rpm < 4.6.0 but specs and macro >> configuration can override that. >> >> Whether it's against Fedora guidelines is another question, but since this >> was about a package from a 3rd party repository... > > It would have been really, _really_ nice if sha256 was merely another > hash that could be in the payload, instead of forcing you to pick one or > the other. For that matter, it would still be really really nice. Could it have been done that way? Yes, and if it were just per-package hash then certainly it would've been done that way. But remember this is per-file data, storing two (and when the day comes when sha256 is considered insufficient, three etc) hashes per file adds a non-trivial amount of header bloat. Having the md5 hashes too would've been nice for backwards compatibility but actually using them for file conflict calculations would mean (in addition to the header bloat): - considerable increase in memory use - falling back to md5 for conflict resolution would void the supposed extra security of the better hash - Panu - From a.badger at gmail.com Thu May 14 08:37:48 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 14 May 2009 01:37:48 -0700 Subject: Breaking deps deliberately In-Reply-To: <20090514074605.GA24489@amd.home.annexia.org> References: <20090513134744.GA19304@amd.home.annexia.org> <4A0AD15F.6040300@fedoraproject.org> <20090513135728.GA19428@amd.home.annexia.org> <20090513142048.GA19610@amd.home.annexia.org> <20090513142742.GB19610@amd.home.annexia.org> <20090513220839.GA22106@amd.home.annexia.org> <4A0B49A5.2050003@gmail.com> <20090514074605.GA24489@amd.home.annexia.org> Message-ID: <4A0BD85C.4040307@gmail.com> Richard W.M. Jones wrote: > On Wed, May 13, 2009 at 03:28:53PM -0700, Toshio Kuratomi wrote: >> Do any other distributions purposefully add broken dependencies to their >> repositories (So that you wouldn't be able to install it without >> pointing at a second source for a package)? > > Debian allows them, Where is the documentation of this policy? because... > and they have a special program called 'equivs' > which you can use to locally compile packages in order to satisfy such > broken dependencies: > > http://www.debian.org/doc/manuals/apt-howto/ch-helpers.en.html > This just explains how the equivs command works and how a user can use it if they've installed a piece of software from outside the packaging system and then want to list it as being available to the package manager. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From a.badger at gmail.com Thu May 14 09:27:42 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 14 May 2009 02:27:42 -0700 Subject: PackageDB-0.4 test instance Message-ID: <4A0BE40E.205@gmail.com> A while back I mentioned that there was going to be a new PackageDB that had some API visible changes. Most notably that the PackageDB was going to start returning and taking only usernames and groupnames instead of the mixture of username/groupname and userid/groupid. This version of the packagedb has settled enough that I have a test instance up in our staging environment. You can access it here: https://admin.stg.fedoraproject.org/pkgdb/ There are likely to be many bugs (I've already encountered some bugs in the treatment of orphaned packages). Please feel free to report them directly to me for now. If you have scripts that access the packagedb, now would be a good time to start testing whether the scripts work with the new version out of the box or need porting. The userid => username switch is likely to be the biggest change. Most code that needs porting for this should be simpler after the porting is done. There has also been some work to the authentication code and a few minor changes to the API. If you think you are running into problems here and need me to look at how your code can be ported to work with the new version feel free to contact me via IRC (abadger1999) or email. Note on security: This test instance is running in our staging environment. The staging environment has a valid SSL certificate and very closely mirrors what is in the production environment. The servers here authenticate against a staging FAS server. This server is populated with data from the production environment but is allowed to diverge. So if you trust that the staging environment is as secure as the production environment (Most things are the same but staging is built to test changes to our environment before they go to production) you can use your normal fas username/password. If you'd rather not use your fas password, you can go to: https://admin.stg.fedoraproject.org/accounts/user/resetpass to reset your password in the staging environment. Note that some links on the FAS pages (notably, the "Forgot Password?" and "Sign Up" links point to the real FAS server instead of the staging account server due to how our templating currently works. Be sure when you are making changes that the URL is for https://admin.stg.fedoraproject.org rather than https://admin.fedoraproject.org. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From rjones at redhat.com Thu May 14 09:28:36 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 14 May 2009 10:28:36 +0100 Subject: Breaking deps deliberately In-Reply-To: <4A0BD85C.4040307@gmail.com> References: <4A0AD15F.6040300@fedoraproject.org> <20090513135728.GA19428@amd.home.annexia.org> <20090513142048.GA19610@amd.home.annexia.org> <20090513142742.GB19610@amd.home.annexia.org> <20090513220839.GA22106@amd.home.annexia.org> <4A0B49A5.2050003@gmail.com> <20090514074605.GA24489@amd.home.annexia.org> <4A0BD85C.4040307@gmail.com> Message-ID: <20090514092836.GA24826@amd.home.annexia.org> On Thu, May 14, 2009 at 01:37:48AM -0700, Toshio Kuratomi wrote: > Richard W.M. Jones wrote: > > On Wed, May 13, 2009 at 03:28:53PM -0700, Toshio Kuratomi wrote: > >> Do any other distributions purposefully add broken dependencies to their > >> repositories (So that you wouldn't be able to install it without > >> pointing at a second source for a package)? > > > > Debian allows them, > Where is the documentation of this policy? because... > > > and they have a special program called 'equivs' > > which you can use to locally compile packages in order to satisfy such > > broken dependencies: > > > > http://www.debian.org/doc/manuals/apt-howto/ch-helpers.en.html > > > This just explains how the equivs command works and how a user can use > it if they've installed a piece of software from outside the packaging > system and then want to list it as being available to the package manager. This is getting a bit off-topic, but anyhow ... The Debian Reference Manual suggests using equivs: http://www.debian.org/doc/manuals/reference/ch-package.en.html#s-apt-trouble The Debian Policy Manual contains explicit rules about broken dependencies here: http://www.debian.org/doc/debian-policy/ch-archive.html#s-sections As you can see, in Debian's main repository they explicitly disallow broken deps for certain types of deps, but Debian has quite a complex dependency system, so this doesn't apply for things like "Suggests" and "Enhances". BTW "Recommends" was added to the above list in Debian Lenny - previous releases of Debian allowed main packages to Recommend packages outside main. Anyway, I think my point is not that we should care about what Debian does, but that we should make what is and isn't allowed explicit in the Fedora packaging guidelines. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From a.badger at gmail.com Thu May 14 09:36:40 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 14 May 2009 02:36:40 -0700 Subject: Fedora Community Pre-Beta Testing In-Reply-To: <200905132326.47989.opensource@till.name> References: <4A0AEA7F.4060302@redhat.com> <200905132258.37063.opensource@till.name> <4A0B359C.7000409@redhat.com> <200905132326.47989.opensource@till.name> Message-ID: <4A0BE628.1090305@gmail.com> Till Maas wrote: > No, this summary lacks the important fact that the password is not transfered > via a secured connection. The problem that the application itself may have > security vulnerabilities is only one reason, why it is not a good idea to test > it with the real FAS passwords. Another reason I can think of, is that these > passwords may be disclosed to the people that debug the tested application or > that they are logged somewhere, because usually the logging on testing setups > is more verbose than on stable ones. Even on the stable fedora wiki setup FAS > passwords were logged by accident. > After discussion with mmcgrath, lmacken, and spot we've decided that to mitigate this, we're going to get the Fedora Community application into the staging environment. The staging environment closely mirrors the production environment, has a valid SSL certificate, and authenticates against a test FAS instance that is populated with production data but can diverge (ie, you can change your password in the staging FAS so you do not have to use your real FAS password with the staging environment). However, there are a lot of packages that make up Fedora Community and several core pieces that we are not presently running in production. So it may be a while before we get the necessary packages through Fedora review, installed, configured in puppet, decided on secure configurations, and setup in the staging environment. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From mschwendt at gmail.com Thu May 14 09:47:03 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 14 May 2009 11:47:03 +0200 Subject: Breaking deps deliberately In-Reply-To: <20090513220839.GA22106@amd.home.annexia.org> References: <20090513111343.4d79d48f@faldor.intranet> <20090513134744.GA19304@amd.home.annexia.org> <4A0AD15F.6040300@fedoraproject.org> <20090513135728.GA19428@amd.home.annexia.org> <20090513142048.GA19610@amd.home.annexia.org> <20090513142742.GB19610@amd.home.annexia.org> <20090513220839.GA22106@amd.home.annexia.org> Message-ID: <20090514114703.6ea61d2d@faldor.intranet> On Wed, 13 May 2009 23:08:39 +0100, Richard wrote: > On Wed, May 13, 2009 at 03:27:42PM +0100, Richard W.M. Jones wrote: > > Someone could easily do the same thing in future. If broken > > dependencies are so unacceptable, then it should be added to the > > packaging guidelines. > > I added this as an agenda item for the FESCo meeting: > > https://fedorahosted.org/fesco/ticket/147 > "Meeting agenda item: No broken dependencies should be a packaging guideline" > Am I reading your EPEL 5 libguestfs package changelog right? You've created the same broken dep also for EPEL 5. And in response to this thread you have released malfunctioning software instead? %changelog +* Wed May 13 2009 Richard Jones - 1.0.23-9 +- Remove the runtime requires on non-existant package. It'll just fail + instead. Btw, the F-10 update would have had a higher %release than the F-11 update (1.0.21-4.fc10 > 1.0.21-3.fc11). From mschwendt at gmail.com Thu May 14 10:01:18 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 14 May 2009 10:01:18 -0000 Subject: Broken dependencies in Fedora 9 - 2009-05-14 Message-ID: <20090514100118.5713.68819@faldor.intranet> ====================================================================== The results in this summary consider Test Updates! ====================================================================== Summary of broken packages (by src.rpm name): aasaver brasero cas cyphesis emma gadget inn kbiof livecd-tools mediawiki-SpecialInterwiki nfoview openvas-libraries paraview perl-Test-AutoBuild php reinteract sear Summary of broken packages (by primary owner): adam.stokes AT gmail com cas berrange AT redhat com perl-Test-AutoBuild denis AT poolshark org brasero extras-orphan AT fedoraproject org aasaver kbiof fabian AT bernewireless net nfoview huzaifas AT redhat com openvas-libraries jorton AT redhat com php (2 co-owners) katzj AT redhat com livecd-tools (2 co-owners) nigjones AT redhat com mediawiki-SpecialInterwiki orion AT cora.nwra com paraview (1 co-owner) otaylor AT redhat com reinteract (1 co-owner) ovasik AT redhat com inn overholt AT redhat com emma simon AT schampijer de gadget (1 co-owner) wart AT kobold org cyphesis (1 co-owner) sear (1 co-owner) ====================================================================== Broken packages in fedora-9-i386: aasaver-0.3.2-3.fc9.i386 requires libkscreensaver.so.4 brasero-0.7.1-3.fc9.i386 requires libburn.so.0 cyphesis-selinux-0.5.15-6.fc9.i386 requires cyphesis = 0:0.5.15-6.fc9 kbiof-0.3-3.fc9.i386 requires libkscreensaver.so.4 sear-0.6.3-10.fc9.i386 requires libmercator-0.2.so.4 ====================================================================== Broken packages in fedora-9-ppc: aasaver-0.3.2-3.fc9.ppc requires libkscreensaver.so.4 brasero-0.7.1-3.fc9.ppc requires libburn.so.0 cyphesis-selinux-0.5.15-6.fc9.ppc requires cyphesis = 0:0.5.15-6.fc9 kbiof-0.3-3.fc9.ppc requires libkscreensaver.so.4 paraview-3.2.1-6.fc9.ppc64 requires paraview-data = 0:3.2.1-6.fc9 paraview-mpi-3.2.1-6.fc9.ppc64 requires paraview-data = 0:3.2.1-6.fc9 php-devel-5.2.5-7.fc9.ppc64 requires php = 0:5.2.5-7.fc9 sear-0.6.3-10.fc9.ppc requires libmercator-0.2.so.4 ====================================================================== Broken packages in fedora-9-ppc64: aasaver-0.3.2-3.fc9.ppc64 requires libkscreensaver.so.4()(64bit) brasero-0.7.1-3.fc9.ppc64 requires libburn.so.0()(64bit) cyphesis-selinux-0.5.15-6.fc9.ppc64 requires cyphesis = 0:0.5.15-6.fc9 kbiof-0.3-3.fc9.ppc64 requires libkscreensaver.so.4()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 sear-0.6.3-10.fc9.ppc64 requires libmercator-0.2.so.4()(64bit) ====================================================================== Broken packages in fedora-9-x86_64: aasaver-0.3.2-3.fc9.x86_64 requires libkscreensaver.so.4()(64bit) brasero-0.7.1-3.fc9.x86_64 requires libburn.so.0()(64bit) cyphesis-selinux-0.5.15-6.fc9.x86_64 requires cyphesis = 0:0.5.15-6.fc9 kbiof-0.3-3.fc9.x86_64 requires libkscreensaver.so.4()(64bit) paraview-3.2.1-6.fc9.i386 requires paraview-data = 0:3.2.1-6.fc9 paraview-mpi-3.2.1-6.fc9.i386 requires paraview-data = 0:3.2.1-6.fc9 php-devel-5.2.5-7.fc9.i386 requires php = 0:5.2.5-7.fc9 sear-0.6.3-10.fc9.x86_64 requires libmercator-0.2.so.4()(64bit) ====================================================================== Broken packages in fedora-updates-9-i386: cyphesis-0.5.15-8.fc9.i386 requires libmercator-0.2.so.4 mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc9.noarch requires mediawiki < 0:1.11 openvas-libraries-1.0.2-2.fc9.i386 requires libresolv.so.2(GLIBC_PRIVATE) ====================================================================== Broken packages in fedora-updates-9-ppc: cyphesis-0.5.15-8.fc9.ppc requires libmercator-0.2.so.4 mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc9.noarch requires mediawiki < 0:1.11 openvas-libraries-1.0.2-2.fc9.ppc requires libresolv.so.2(GLIBC_PRIVATE) openvas-libraries-1.0.2-2.fc9.ppc64 requires libresolv.so.2(GLIBC_PRIVATE)(64bit) ====================================================================== Broken packages in fedora-updates-9-ppc64: cyphesis-0.5.15-8.fc9.ppc64 requires libmercator-0.2.so.4()(64bit) emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 gadget-0.0.3-2.fc9.noarch requires ejabberd livecd-tools-017.2-1.fc9.ppc64 requires yaboot mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc9.noarch requires mediawiki < 0:1.11 openvas-libraries-1.0.2-2.fc9.ppc64 requires libresolv.so.2(GLIBC_PRIVATE)(64bit) ====================================================================== Broken packages in fedora-updates-9-x86_64: cyphesis-0.5.15-8.fc9.x86_64 requires libmercator-0.2.so.4()(64bit) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc9.noarch requires mediawiki < 0:1.11 openvas-libraries-1.0.2-2.fc9.i386 requires libresolv.so.2(GLIBC_PRIVATE) openvas-libraries-1.0.2-2.fc9.x86_64 requires libresolv.so.2(GLIBC_PRIVATE)(64bit) ====================================================================== Broken packages in fedora-updates-testing-9-i386: inn-2.4.4-2.fc9.i386 requires libstorage.so.2 inn-2.4.4-2.fc9.i386 requires libinnhist.so.2 nfoview-1.4-3.fc9.noarch requires terminus-fonts reinteract-0.5.0-2.noarch requires python-matplotlib >= 0:0.98.0 ====================================================================== Broken packages in fedora-updates-testing-9-ppc: cas-0.14-10.fc9.noarch requires crash inn-2.4.4-2.fc9.ppc requires libstorage.so.2 inn-2.4.4-2.fc9.ppc requires libinnhist.so.2 inn-2.4.4-2.fc9.ppc64 requires libinnhist.so.2()(64bit) inn-2.4.4-2.fc9.ppc64 requires libstorage.so.2()(64bit) nfoview-1.4-3.fc9.noarch requires terminus-fonts reinteract-0.5.0-2.noarch requires python-matplotlib >= 0:0.98.0 ====================================================================== Broken packages in fedora-updates-testing-9-ppc64: inn-2.4.4-2.fc9.ppc64 requires libinnhist.so.2()(64bit) inn-2.4.4-2.fc9.ppc64 requires libstorage.so.2()(64bit) nfoview-1.4-3.fc9.noarch requires terminus-fonts reinteract-0.5.0-2.noarch requires python-matplotlib >= 0:0.98.0 ====================================================================== Broken packages in fedora-updates-testing-9-x86_64: inn-2.4.4-2.fc9.i386 requires libstorage.so.2 inn-2.4.4-2.fc9.i386 requires libinnhist.so.2 inn-2.4.4-2.fc9.x86_64 requires libinnhist.so.2()(64bit) inn-2.4.4-2.fc9.x86_64 requires libstorage.so.2()(64bit) nfoview-1.4-3.fc9.noarch requires terminus-fonts reinteract-0.5.0-2.noarch requires python-matplotlib >= 0:0.98.0 From drago01 at gmail.com Thu May 14 10:02:53 2009 From: drago01 at gmail.com (drago01) Date: Thu, 14 May 2009 12:02:53 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: References: <4A082E70.7030904@TheTroubleshooters.dk> <1242060668.28322.85.camel@localhost.localdomain> <1242240008.2316.2.camel@prague> <2d319b780905131147r14143d5ev97ed5be9cff50773@mail.gmail.com> <1242247260.2316.5.camel@prague> <1242248249.2316.7.camel@prague> <20090513210044.GA21048@nostromo.devel.redhat.com> Message-ID: On Thu, May 14, 2009 at 5:51 AM, Kevin Kofler wrote: > Bill Nottingham wrote: >> However, it's python, and therefore may not be suitable for *all* >> command-line/console-based usage (specifically, I'd love ifup/ifdown >> to be able to kick NM if it's running to DTRT, but I don't intend to >> require python to do so). > > It's pretty hard to use Fedora without Python anyway, as yum and other basic > stuff is written in Python. But we don't really want to use python at bootup (slow the boot process even more). From rjones at redhat.com Thu May 14 10:26:23 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 14 May 2009 11:26:23 +0100 Subject: Breaking deps deliberately In-Reply-To: <20090514114703.6ea61d2d@faldor.intranet> References: <20090513134744.GA19304@amd.home.annexia.org> <4A0AD15F.6040300@fedoraproject.org> <20090513135728.GA19428@amd.home.annexia.org> <20090513142048.GA19610@amd.home.annexia.org> <20090513142742.GB19610@amd.home.annexia.org> <20090513220839.GA22106@amd.home.annexia.org> <20090514114703.6ea61d2d@faldor.intranet> Message-ID: <20090514102623.GA25246@amd.home.annexia.org> On Thu, May 14, 2009 at 11:47:03AM +0200, Michael Schwendt wrote: > On Wed, 13 May 2009 23:08:39 +0100, Richard wrote: > > > On Wed, May 13, 2009 at 03:27:42PM +0100, Richard W.M. Jones wrote: > > > Someone could easily do the same thing in future. If broken > > > dependencies are so unacceptable, then it should be added to the > > > packaging guidelines. > > > > I added this as an agenda item for the FESCo meeting: > > > > https://fedorahosted.org/fesco/ticket/147 > > "Meeting agenda item: No broken dependencies should be a packaging guideline" > > > > Am I reading your EPEL 5 libguestfs package changelog right? You've > created the same broken dep also for EPEL 5. And in response to this thread > you have released malfunctioning software instead? It now fails at runtime with an error message saying that vmchannel is not supported by that version of qemu. There's also an open bug to get the relevant bits backported into RHEL 5.4: https://bugzilla.redhat.com/show_bug.cgi?id=497625 Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 75 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From a.badger at gmail.com Thu May 14 10:43:01 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 14 May 2009 03:43:01 -0700 Subject: Breaking deps deliberately In-Reply-To: <20090514092836.GA24826@amd.home.annexia.org> References: <4A0AD15F.6040300@fedoraproject.org> <20090513135728.GA19428@amd.home.annexia.org> <20090513142048.GA19610@amd.home.annexia.org> <20090513142742.GB19610@amd.home.annexia.org> <20090513220839.GA22106@amd.home.annexia.org> <4A0B49A5.2050003@gmail.com> <20090514074605.GA24489@amd.home.annexia.org> <4A0BD85C.4040307@gmail.com> <20090514092836.GA24826@amd.home.annexia.org> Message-ID: <4A0BF5B5.2090602@gmail.com> Richard W.M. Jones wrote: > On Thu, May 14, 2009 at 01:37:48AM -0700, Toshio Kuratomi wrote: >> Richard W.M. Jones wrote: >>> On Wed, May 13, 2009 at 03:28:53PM -0700, Toshio Kuratomi wrote: >>>> Do any other distributions purposefully add broken dependencies to their >>>> repositories (So that you wouldn't be able to install it without >>>> pointing at a second source for a package)? >>> Debian allows them, >> Where is the documentation of this policy? because... >> >>> and they have a special program called 'equivs' >>> which you can use to locally compile packages in order to satisfy such >>> broken dependencies: >>> >>> http://www.debian.org/doc/manuals/apt-howto/ch-helpers.en.html >>> >> This just explains how the equivs command works and how a user can use >> it if they've installed a piece of software from outside the packaging >> system and then want to list it as being available to the package manager. > > This is getting a bit off-topic, but anyhow ... > > The Debian Reference Manual suggests using equivs: > > http://www.debian.org/doc/manuals/reference/ch-package.en.html#s-apt-trouble > This one suffers the same problem as the equivs page you gave earlier. It's talking about troubleshooting a system that has dep problems in the installed system. It's not defining the policy for the package repository. There's a variety of ways that a package can become a broken dep over time without being one in the repository. One example: Fedora-1 Install foo that depends on libbar.so.1 Fedora-2 foo is no longer provided in the repository. Only libbar.so.2 If you upgrade from Fedora-1 to Fedora-2 you have a broken dep on your system for libbar.so.1. This is not because of broken deps inside of the repository. It's because you have an old program installed from before the time that libbar was upgraded to a new version. > The Debian Policy Manual contains explicit rules about broken > dependencies here: > > http://www.debian.org/doc/debian-policy/ch-archive.html#s-sections > > As you can see, in Debian's main repository they explicitly disallow > broken deps for certain types of deps, but Debian has quite a complex > dependency system, so this doesn't apply for things like "Suggests" > and "Enhances". BTW "Recommends" was added to the above list in > Debian Lenny - previous releases of Debian allowed main packages to > Recommend packages outside main. > This one's better. It actually contains policy about what should not go into a repository. The first thing that strikes me is that actual broken dependencies are disallowed in the "main" repository. "Suggests", "Enhances" are not useful here as they are things that neither cause a program to fail or cause a packaging transaction to fail. So Debian is in agreement with us on this point. The second thing that I see is that Debian has a contrib repository. This repository allows packages which require things that aren't in the repository in order to build or execute. We don't have anything like this repository and never have. Perhaps if you didn't suffer through the Fedora Founding Flamewars this is not obvious, though? > Anyway, I think my point is not that we should care about what Debian > does, but that we should make what is and isn't allowed explicit in > the Fedora packaging guidelines. > After skimming the Debian Policy Manual, I think pointing out a way that we differ from Debian might help. This is the Abstract of the Debian Policy Manual: """ Abstract This manual describes the policy requirements for the Debian GNU/Linux distribution. This includes the structure and contents of the Debian archive and several design issues of the operating system, as well as technical requirements that each package must satisfy to be included in the distribution. """ In Fedora the Packaging Guidelines and Packaging Committee are responsible for defining the "technical requirements that each package must satisfy". But the rest of this, in particular the "structure and contents of the" archive, is the responsibility of FESCo, releng, the Board, and the policy pages that they create. Defining whether a package is allowed to depend on something that cannot be satisfied from the repositories for that distribution is a decision about the contents of the repositories. That should be defined in a FESCo Policy page. Others have pointed you at multiple places where the distro policy states that unresolvable deps are not okay. If you think those are insufficient you probably want to come up with something for FESCo to state that would clarify that. OTOH, if you think that it's clear that unresolvable dependencies are not allowed in Fedora but are just unclear on how to tell if your code is creating one, you can bring language to clarify that to the Packaging Committee to add to the Packaging Guidelines. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From rjones at redhat.com Thu May 14 10:54:42 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 14 May 2009 11:54:42 +0100 Subject: Breaking deps deliberately In-Reply-To: <4A0BF5B5.2090602@gmail.com> References: <20090513142048.GA19610@amd.home.annexia.org> <20090513142742.GB19610@amd.home.annexia.org> <20090513220839.GA22106@amd.home.annexia.org> <4A0B49A5.2050003@gmail.com> <20090514074605.GA24489@amd.home.annexia.org> <4A0BD85C.4040307@gmail.com> <20090514092836.GA24826@amd.home.annexia.org> <4A0BF5B5.2090602@gmail.com> Message-ID: <20090514105442.GA25400@amd.home.annexia.org> On Thu, May 14, 2009 at 03:43:01AM -0700, Toshio Kuratomi wrote: > In Fedora the Packaging Guidelines and Packaging Committee are > responsible for defining the "technical requirements that each package > must satisfy". But the rest of this, in particular the "structure and > contents of the" archive, is the responsibility of FESCo, releng, the > Board, and the policy pages that they create. Defining whether a > package is allowed to depend on something that cannot be satisfied from > the repositories for that distribution is a decision about the contents > of the repositories. That should be defined in a FESCo Policy page. > Others have pointed you at multiple places where the distro policy > states that unresolvable deps are not okay. If you think those are > insufficient you probably want to come up with something for FESCo to > state that would clarify that. It sounds like what we need is a FESCo policy in that case. However you're going to have to help me out here, because I can't find any FESCo "policy pages" except for one about elections and other about package maintainers. I'm quite probably looking in entirely the wrong place. This was my Google search: http://www.google.co.uk/search?q=site%3Afedoraproject.org+fesco+policy [I just found another one on about new Features] What are the steps I should take to propose a policy? I already created a trac ticket: https://fedorahosted.org/fesco/ticket/147 Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From dominik at greysector.net Thu May 14 13:01:59 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 14 May 2009 15:01:59 +0200 Subject: FESco meeting summary for 20090507 In-Reply-To: References: Message-ID: <20090514130158.GA7053@mokona.greysector.net> On Saturday, 09 May 2009 at 19:24, Jon Stanley wrote: > FESCo meeting summary for 2009/05/08 > > == Members Present == > > * Jon Stanley (jds2001) > * Kevin Fenzi (nirik) > * Dan Horak (sharkcz) > * Josh Boyer (jwb) > * Brian Pepple (bpepple) > * Bill Nottingham (notting) > * David Woodhouse (dwmw2) > * Jarod Wilson (j-rod) > > == Members Absent == > > * Dennis Gilmore (dgilmore) [...] > == Maven upgrade == > > Rel-eng brought a proposal during the open floor to allow the > inclusion of packages in a special tag (something like dist-f12-maven) > in preparation for the maven upgrade that had yet to be through a > formal package review. These packages are not yet in a state suitable > for inclusion in Fedora, and the Java team would prefer to get them > functional prior to cleaning up the packaging. FESCo approved this > propsal, with the caveat that the packages have to go through a > mini-review prior to inclusiion in this tag and therefore being used > in buildroots. This mini-review will be defined by FPC, and will > include things such as checking for lack of binaries, and legal > concerns. As a packager and a member of the FPC, I think it is a very bad idea to let packages in without proper review. I'd like to hear the very convincing arguments which I expect were presented directly to some FESCo members but were not included in the IRC meeting log for why this was allowed and why the packages in question (which ones, exactly?) couldn't go through the usual hoops like all new packages. I don't see why the Java team (who, exactly?) or anyone else should be allowed to import packages into Fedora CVS without proper review. I also expect this will be brought up in similar cases in the future with the justification that "we did this before". Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From walters at verbum.org Thu May 14 13:08:16 2009 From: walters at verbum.org (Colin Walters) Date: Thu, 14 May 2009 09:08:16 -0400 Subject: Determine time of last keystroke and mouse movement In-Reply-To: <4A0B489A.4040104@cora.nwra.com> References: <4A0B3262.2090702@cora.nwra.com> <1242250719.21675.164.camel@atropine.boston.devel.redhat.com> <4A0B489A.4040104@cora.nwra.com> Message-ID: On Wed, May 13, 2009 at 6:24 PM, Orion Poplawski wrote: > That assumes running inside the X session though right? ?This is a system > process started at boot. You can use ConsoleKit to watch for new login sessions, and from it also retrieve the address (DISPLAY) of the X server. You'll need the .Xauthority file from the user's home directory to authenticate. From rc040203 at freenet.de Thu May 14 13:44:21 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 14 May 2009 15:44:21 +0200 Subject: FESco meeting summary for 20090507 In-Reply-To: <20090514130158.GA7053@mokona.greysector.net> References: <20090514130158.GA7053@mokona.greysector.net> Message-ID: <4A0C2035.5040304@freenet.de> Dominik 'Rathann' Mierzejewski wrote: > On Saturday, 09 May 2009 at 19:24, Jon Stanley wrote: >> FESCo meeting summary for 2009/05/08 >> >> == Members Present == >> >> * Jon Stanley (jds2001) >> * Kevin Fenzi (nirik) >> * Dan Horak (sharkcz) >> * Josh Boyer (jwb) >> * Brian Pepple (bpepple) >> * Bill Nottingham (notting) >> * David Woodhouse (dwmw2) >> * Jarod Wilson (j-rod) >> >> == Members Absent == >> >> * Dennis Gilmore (dgilmore) > [...] >> == Maven upgrade == >> >> Rel-eng brought a proposal during the open floor to allow the >> inclusion of packages in a special tag (something like dist-f12-maven) >> in preparation for the maven upgrade that had yet to be through a >> formal package review. These packages are not yet in a state suitable >> for inclusion in Fedora, and the Java team would prefer to get them >> functional prior to cleaning up the packaging. FESCo approved this >> propsal, with the caveat that the packages have to go through a >> mini-review prior to inclusiion in this tag and therefore being used >> in buildroots. This mini-review will be defined by FPC, and will >> include things such as checking for lack of binaries, and legal >> concerns. > > As a packager and a member of the FPC, I think it is a very bad idea to let > packages in without proper review. +1 > I'd like to hear the very convincing > arguments which I expect were presented directly to some FESCo members > but were not included in the IRC meeting log for why this was allowed and > why the packages in question (which ones, exactly?) couldn't go through > the usual hoops like all new packages. > I don't see why the Java team (who, exactly?) or anyone else should > be allowed to import packages into Fedora CVS without proper review. > > I also expect this will be brought up in similar cases in the future > with the justification that "we did this before". I don't see why these people can't use an external VCS/repository, like probably many developer groups do. Ralf From pertusus at free.fr Thu May 14 14:12:03 2009 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 14 May 2009 16:12:03 +0200 Subject: FESco meeting summary for 20090507 In-Reply-To: <4A0C2035.5040304@freenet.de> References: <20090514130158.GA7053@mokona.greysector.net> <4A0C2035.5040304@freenet.de> Message-ID: <20090514141203.GB11456@free.fr> On Thu, May 14, 2009 at 03:44:21PM +0200, Ralf Corsepius wrote: >> >> I also expect this will be brought up in similar cases in the future >> with the justification that "we did this before". > I don't see why these people can't use an external VCS/repository, like > probably many developer groups do. I can see many a for a group of developper to use the fedora infra for something else than the main distro: it simply lowers the cost to set up a VCS/build servers/repository. If there was a guide to set up build system like the fedora build system in some minutes (with authentication against the FAS), then this wouldn't be needed, but in the mean time, it could be useful. -- Pat From pertusus at free.fr Thu May 14 14:14:42 2009 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 14 May 2009 16:14:42 +0200 Subject: FESco meeting summary for 20090507 In-Reply-To: <20090514141203.GB11456@free.fr> References: <20090514130158.GA7053@mokona.greysector.net> <4A0C2035.5040304@freenet.de> <20090514141203.GB11456@free.fr> Message-ID: <20090514141442.GD11456@free.fr> On Thu, May 14, 2009 at 04:12:03PM +0200, Patrice Dumas wrote: > On Thu, May 14, 2009 at 03:44:21PM +0200, Ralf Corsepius wrote: > >> > >> I also expect this will be brought up in similar cases in the future > >> with the justification that "we did this before". > > I don't see why these people can't use an external VCS/repository, like > > probably many developer groups do. > > I can see many a for a group of developper to use the fedora infra ^^^^^ many reasons > for something else than the main distro: it simply lowers the cost to set > up a VCS/build servers/repository. > > If there was a guide to set up build system like the fedora build system > in some minutes (with authentication against the FAS), then this wouldn't > be needed, but in the mean time, it could be useful. > > -- > Pat > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From jonstanley at gmail.com Thu May 14 14:18:07 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Thu, 14 May 2009 10:18:07 -0400 Subject: Breaking deps deliberately In-Reply-To: <20090514105442.GA25400@amd.home.annexia.org> References: <20090513142742.GB19610@amd.home.annexia.org> <20090513220839.GA22106@amd.home.annexia.org> <4A0B49A5.2050003@gmail.com> <20090514074605.GA24489@amd.home.annexia.org> <4A0BD85C.4040307@gmail.com> <20090514092836.GA24826@amd.home.annexia.org> <4A0BF5B5.2090602@gmail.com> <20090514105442.GA25400@amd.home.annexia.org> Message-ID: On Thu, May 14, 2009 at 6:54 AM, Richard W.M. Jones wrote: > However you're going to have to help me out here, because I can't find > any FESCo "policy pages" except for one about elections and other > about package maintainers. ?I'm quite probably looking in entirely the I'll admit (and take the blame for the fact) that FESCo has been particularly bad in the past about writing down policy that we've enacted (which is not much). For example, I need to write a new page on how to rename a package. But the "no broken deps" rule already exists in the release criteria[1]. If perhaps a link to them from somewhere else on the wiki is appropriate, that doesn't cost us anything obviously, though I'd be most interested in where you'd like to see it linked from. [1] https://fedoraproject.org/wiki/QA/ReleaseCriteria#Package_Sanity From rjones at redhat.com Thu May 14 14:27:07 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 14 May 2009 15:27:07 +0100 Subject: Breaking deps deliberately In-Reply-To: References: <20090513142742.GB19610@amd.home.annexia.org> <20090513220839.GA22106@amd.home.annexia.org> <4A0B49A5.2050003@gmail.com> <20090514074605.GA24489@amd.home.annexia.org> <4A0BD85C.4040307@gmail.com> <20090514092836.GA24826@amd.home.annexia.org> <4A0BF5B5.2090602@gmail.com> <20090514105442.GA25400@amd.home.annexia.org> Message-ID: <20090514142707.GA26254@amd.home.annexia.org> On Thu, May 14, 2009 at 10:18:07AM -0400, Jon Stanley wrote: > On Thu, May 14, 2009 at 6:54 AM, Richard W.M. Jones wrote: > > > However you're going to have to help me out here, because I can't find > > any FESCo "policy pages" except for one about elections and other > > about package maintainers. ?I'm quite probably looking in entirely the > > I'll admit (and take the blame for the fact) that FESCo has been > particularly bad in the past about writing down policy that we've > enacted (which is not much). For example, I need to write a new page > on how to rename a package. But the "no broken deps" rule already > exists in the release criteria[1]. If perhaps a link to them from > somewhere else on the wiki is appropriate, that doesn't cost us > anything obviously, though I'd be most interested in where you'd like > to see it linked from. > > [1] https://fedoraproject.org/wiki/QA/ReleaseCriteria#Package_Sanity I think surely from the packaging guidelines, because (speaking for myself anyway), that's the place I go to to find out how packages should be made. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From pertusus at free.fr Thu May 14 14:30:34 2009 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 14 May 2009 16:30:34 +0200 Subject: Breaking deps deliberately In-Reply-To: <20090514142707.GA26254@amd.home.annexia.org> References: <20090513142742.GB19610@amd.home.annexia.org> <20090513220839.GA22106@amd.home.annexia.org> <4A0B49A5.2050003@gmail.com> <20090514074605.GA24489@amd.home.annexia.org> <4A0BD85C.4040307@gmail.com> <20090514092836.GA24826@amd.home.annexia.org> <4A0BF5B5.2090602@gmail.com> <20090514105442.GA25400@amd.home.annexia.org> <20090514142707.GA26254@amd.home.annexia.org> Message-ID: <20090514143034.GE11456@free.fr> On Thu, May 14, 2009 at 03:27:07PM +0100, Richard W.M. Jones wrote: > > I think surely from the packaging guidelines, because (speaking for > myself anyway), that's the place I go to to find out how packages > should be made. I think that it is not a packaging guideline, but a policy. The problem, in my opinion, is that the policies are in a bad state since ages, and even more after the wiki reorganization. -- Pat From langel at redhat.com Thu May 14 14:42:02 2009 From: langel at redhat.com (Lillian Angel) Date: Thu, 14 May 2009 10:42:02 -0400 Subject: Where to post an experimental package? (java-1.7.0-openjdk) Message-ID: <4A0C2DBA.4080502@redhat.com> Hi, On May 21, Sun plans on releasing a preview of JDK7[1]. We (the OpenJDK team) would like to create a java-1.7.0-openjdk package for experimental and testing purposes. A few options were we create the fedora rpms and submit them to rpmfusion (or similar), host them on a my personal fedora page, or get the package into Fedora. I am wondering what some other acceptable options are. I am not keen on getting this package pushed into Fedora since java-1.6.0-openjdk already exists, and jdk7 will not be stable until sometime after Feb 2010[1]. Suggestions? Thanks, Lillian [1] http://openjdk.java.net/projects/jdk7/milestones/ From Jochen at herr-schmitt.de Thu May 14 14:43:32 2009 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 14 May 2009 16:43:32 +0200 Subject: transition a few packages to new owners In-Reply-To: <20090513183459.GB18564@auslistsprd01.us.dell.com> References: <20090513173051.GB12695@auslistsprd01.us.dell.com> <4A0B1014.1050403@herr-schmitt.de> <20090513183459.GB18564@auslistsprd01.us.dell.com> Message-ID: <0MKxQS-1M4c9a1SqB-0002S4@mrelayeu.kundenserver.de> On Wed, 13 May 2009 13:34:59 -0500, you wrote: > >the latest is currently sitting in updates-testing for 9, 10, 11, if >you wish to look and then promote to stable. I have taken ownership of the packages, but I'm unable to maks the updtes as stable. It may be nice, if you can try to release the updates as stable. Best Regards: Jochen Schmitt From pbrobinson at gmail.com Thu May 14 14:45:47 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 14 May 2009 15:45:47 +0100 Subject: Where to post an experimental package? (java-1.7.0-openjdk) In-Reply-To: <4A0C2DBA.4080502@redhat.com> References: <4A0C2DBA.4080502@redhat.com> Message-ID: <5256d0b0905140745p6667ec08v106e9e40c0e9378c@mail.gmail.com> > On May 21, Sun plans on releasing a preview of JDK7[1]. We (the OpenJDK > team) would like to create a java-1.7.0-openjdk package for experimental and > testing purposes. A few options were we create the fedora rpms and submit > them to rpmfusion (or similar), host them on a my personal fedora page, or > get the package into Fedora. > > I am wondering what some other acceptable options are. I am not keen on > getting this package pushed into Fedora since java-1.6.0-openjdk already > exists, and jdk7 will not be stable until sometime after Feb 2010[1]. > > Suggestions? Is it possible to do a dist-f12-openjdk17 branch in koji similar to what was done for python 2.6 so its then easy to merge mainline. Or possibly a fedorahosted project? Peter From sundaram at fedoraproject.org Thu May 14 14:53:17 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 14 May 2009 20:23:17 +0530 Subject: Where to post an experimental package? (java-1.7.0-openjdk) In-Reply-To: <4A0C2DBA.4080502@redhat.com> References: <4A0C2DBA.4080502@redhat.com> Message-ID: <4A0C305D.5050406@fedoraproject.org> On 05/14/2009 08:12 PM, Lillian Angel wrote: > Hi, > > On May 21, Sun plans on releasing a preview of JDK7[1]. We (the OpenJDK > team) would like to create a java-1.7.0-openjdk package for experimental > and testing purposes. A few options were we create the fedora rpms and > submit them to rpmfusion (or similar), host them on a my personal fedora > page, or get the package into Fedora. > > I am wondering what some other acceptable options are. I am not keen on > getting this package pushed into Fedora since java-1.6.0-openjdk already > exists, and jdk7 will not be stable until sometime after Feb 2010[1]. > > Suggestions? Create a repo in your fedorapeople.org account? Rahul From ajax at redhat.com Thu May 14 14:52:22 2009 From: ajax at redhat.com (Adam Jackson) Date: Thu, 14 May 2009 10:52:22 -0400 Subject: rpm hashes In-Reply-To: References: <4A082E70.7030904@TheTroubleshooters.dk> <4A086703.1080906@amiga-hardware.com> <4A094EC4.9030506@TheTroubleshooters.dk> <1242125395.13505.449.camel@breeves.fab.redhat.com> <4A0988DC.8030103@freenet.de> <4A098F11.4080008@freenet.de> <1242225439.21675.81.camel@atropine.boston.devel.redhat.com> Message-ID: <1242312742.21675.264.camel@atropine.boston.devel.redhat.com> On Thu, 2009-05-14 at 10:46 +0300, Panu Matilainen wrote: > On Wed, 13 May 2009, Adam Jackson wrote: > > It would have been really, _really_ nice if sha256 was merely another > > hash that could be in the payload, instead of forcing you to pick one or > > the other. For that matter, it would still be really really nice. > > Could it have been done that way? Yes, and if it were just per-package > hash then certainly it would've been done that way. But remember this is > per-file data, storing two (and when the day comes when sha256 is > considered insufficient, three etc) hashes per file adds a non-trivial > amount of header bloat. 32 bytes per file, plus another four for the header tag, unless I have my math wildly wrong and/or I'm misremembering how hashes are stored. My F11 machine has 430910 files over 2167 packages, so that extra metadata comes to a massive 14.8M, compared to 11.6G of actual payload. I have trouble getting worked up over this. The point about having to store arbitrarily many hashes is certainly fair, but a) sha512 is only twice as large as sha256, and 0.2% overhead is still not a lot, b) that seems like a distro policy question. > Having the md5 hashes too would've been nice for backwards compatibility > but actually using them for file conflict calculations would mean (in > addition to the header bloat): > - considerable increase in memory use I just don't buy this at all. The checksums are computed as part of the stdio stream, and any competent implementation of a SHA-like algorithm requires storage that's O(n) on the size of the hash, not on the size of the file. So you'd need whatever the overhead is for the additional metadata on the package you're currently inspecting, plus no more than a page for the additional work area for the second hash. (I assume here that fileconflict checks are done one package at a time, not by loading all packages into memory and then checking them for conflicts, since the latter would be unusable.) Oh, I guess there's also a case where you have to check for fileconflicts among multiple packages in the same transaction laying down the same files. Handwave, same problem really. > - falling back to md5 for conflict resolution would void the supposed > extra security of the better hash So there's two cases, if rpm would let you carry both hashes. 1 is where the file on disk has both MD5 and SHA256 sums, and the new package has only MD5. You already trust the package on disk, because you already installed it; so compute the SHA256 of the file you're about to lay down! Now you have both hashes, and you can compare them both. The odds of defeating this are the odds of finding a payload that collides for both MD5 and SHA256, which can't possibly be lower than the odds of finding a collision for just SHA256 itself. 2 is where the file on disk has only MD5, and the package you're about to install has both. If you have an rpm that only understands MD5, then whatever, you just ignore the SHA256 hash. If you have an rpm that understands both, then you have options. If you're being sensible, you do the same thing as for case 1, which is to generate the SHA256 of the disk file that's implicitly already trusted and compare both sums, and presumably you only got to this point because you trust the GPG key that signed the package you're about to install, so, good enough. (There's a flaw here if the file on disk is modified. I could see arguments here for any of rpmnew/rpmsave/fileconflict as the "right thing", which I leave to someone more detail-oriented than I am.) If you're in FIPS mode - that is, if you're _not_ being sensible - then you fail the transaction, which you ought rightly do anyway since oh no the package on disk is only hashed with MD5, you're already in trouble. For the case where there's N hashes and not just the two, I think this has a straightforward generalization, assuming you have an internal strict ordering of hash strength. Margin too small to contain it, etc. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From rawhide at fedoraproject.org Thu May 14 15:34:45 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Thu, 14 May 2009 15:34:45 +0000 (UTC) Subject: rawhide report: 20090514 changes Message-ID: <20090514153445.A75411F8209@releng2.fedora.phx.redhat.com> Compose started at Thu May 14 06:15:05 UTC 2009 Updated Packages: anaconda-11.5.0.52-1.fc11 ------------------------- * Wed May 13 2009 David Cantrell - 11.5.0.52-1 - Add a Mac OS boot line to yaboot.conf (#499964). (clumens) - Catch IOError when enabling repos (#500439). (clumens) - Use a newer version of the kickstart Partition command. (clumens) - Fix a traceback when installing over previous installs on PPC (#499963). (clumens) - Fix a typo when probing exception disks. (clumens) - Add support for --noformat too. (clumens) - Add support for --onpart, --ondrive, and --useexisting. (clumens) - Make the storage.writeKS method useful and called from instdata (#493703). (clumens) - Add writeKS methods to the device objects. (clumens) - Add writeKS methods to all the format objects. (clumens) - upd-instroot: Add gdbserver (ajax) - Remove text-mode syslinux help (katzj) - If clearPartType is None, don't attempt to clear a device (#499321). (clumens) - Only set clearpart data if the command was provided in the kickstart file. (clumens) - Override previously defined mountpoints in kickstart (#499746). (clumens) - Yet another font package name has changed (#499322). (clumens) - Set new mountpoint correctly for existing encrypted LVs. (#496363) (dlehman) - Once a partition is part of another device it cannot be modified. (#496760) (dlehman) - Maintain request sort order by using req_disks instead of parents. (dlehman) - Do not set a parent on the /mnt/sysimage/dev bind mount object (#499724). (clumens) - Skip .pyc files in subdirectories when running make updates. (clumens) - Remove 'lowres' option. (ajax) - Run tune2fs on newly formatted ext[34] filesystems. (#495476) (dlehman) fedora-release-notes-11.0.0-2.fc11 ---------------------------------- * Wed May 13 2009 Paul W. Frields - 11.0.0-2 - Fix homepage content * Thu May 07 2009 John J. McDonough - 11.0.0-1 - Update for Fedora 11 release candidate gdm-2.26.1-10.fc11 ------------------ * Wed May 13 2009 Ray Strode - 1:2.26.1-10 - Update multi-stack patch to fix bug 499272 * Fri May 08 2009 Ray Strode - 1:2.26.1-9 - Redo patch from -8 since patch misapplies the other one. * Thu May 07 2009 Ray Strode - 1:2.26.1-8 - Hopefully fix bug 499272 (weird behavior when typing init 3 from within the session) gnome-settings-daemon-2.26.1-5.fc11 ----------------------------------- * Wed May 13 2009 Matthias Clasen - 2.26.1-5 - Enable touchpad edge scrolling by default gupnp-tools-0.7.1-3.fc11 ------------------------ * Tue May 12 2009 Peter Robinson 0.7.1-1 - New upstream release * Tue May 12 2009 Peter Robinson 0.7.1-2 - Remove the glade files now that it uses GTKBuilder * Tue May 12 2009 Peter Robinson 0.7.1-3 - and add the GTKBuilder replacements java-1.5.0-gcj-1.5.0.0-28.fc11 ------------------------------ * Tue May 12 2009 Stepan Kasal 1.5.0.0-28 - another attempt to rebuild, adding a workaround for #500314 * Fri Apr 03 2009 Karsten Hopp 1.5.0.0-27 - update workaround patch to fix rebuild problems * Wed Feb 25 2009 Fedora Release Engineering - 1.5.0.0-26 - Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild kpackagekit-0.4.0-7.fc11 ------------------------ * Tue Apr 28 2009 Luk???? Tinkl - 0.4.0-7 - upstream patch to fix catalog loading (#493061) ruby-RMagick-2.9.1-3.fc11 ------------------------- * Thu May 14 2009 Mamoru Tasaka - 2.9.1-3 - F-11: Rebuild against new ImageMagick - Make ImageMagick requirement very strict (bug 500565) scipy-0.7.0-3.fc11 ------------------ * Tue Apr 07 2009 Jef Spaleta - 0.7.0-3 - Add f2py requires to prepared for numpy packaging split sunbird-1.0-0.3.20090302hg.fc11 ------------------------------- * Tue May 12 2009 Lubomir Rintel - 1.0-0.3.20090302hg - Fix migration window size (0x0 is considered too small by some) (#499346) system-config-printer-1.1.7-4.fc11 ---------------------------------- * Wed May 13 2009 Tim Waugh 1.1.7-4 - Changed requirement on notification-daemon to desktop-notification-daemon to allow for other implementations (bug #500587). * Tue Apr 21 2009 Kevin Kofler 1.1.7-2 - Move files required by system-config-printer-kde to -libs (#496646) * Tue Apr 21 2009 Tim Waugh 1.1.7-3 - Moved them back again, as they are not part of the exported interface (bug #496808). thunderbird-3.0-2.3.beta2.fc11 ------------------------------ * Wed May 13 2009 Christopher Aillon - 3.0-2.3 - Fix startup crash when imap server sends list response with trailing delimiter * Mon Mar 30 2009 Jan Horak - 3.0-2.2.beta2 - Fixed open-browser.sh to use xdg-open instead of gnome-open yakuake-2.9.4-3.fc11 -------------------- * Fri Apr 17 2009 Johan Cwiklinski 2.9.4-3 - Fix crash with QT 4.5 Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 13 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From jkeating at redhat.com Thu May 14 15:55:01 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 14 May 2009 08:55:01 -0700 Subject: Where to post an experimental package? (java-1.7.0-openjdk) In-Reply-To: <4A0C2DBA.4080502@redhat.com> References: <4A0C2DBA.4080502@redhat.com> Message-ID: <1242316501.6282.56.camel@localhost.localdomain> On Thu, 2009-05-14 at 10:42 -0400, Lillian Angel wrote: > > On May 21, Sun plans on releasing a preview of JDK7[1]. We (the OpenJDK > team) would like to create a java-1.7.0-openjdk package for experimental > and testing purposes. A few options were we create the fedora rpms and > submit them to rpmfusion (or similar), host them on a my personal fedora > page, or get the package into Fedora. > > I am wondering what some other acceptable options are. I am not keen on > getting this package pushed into Fedora since java-1.6.0-openjdk already > exists, and jdk7 will not be stable until sometime after Feb 2010[1]. > > Suggestions? How many packages will this consist of, and will there be interdependencies (IE will you need to use one of these new packages to build another new package)? By far the easiest route is to do a scratch build of the package in question, gather the resulting rpms and put them in a repo on your fedorapeople page. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Thu May 14 15:55:53 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 14 May 2009 17:55:53 +0200 Subject: FESco meeting summary for 20090507 In-Reply-To: <20090514141203.GB11456@free.fr> References: <20090514130158.GA7053@mokona.greysector.net> <4A0C2035.5040304@freenet.de> <20090514141203.GB11456@free.fr> Message-ID: <4A0C3F09.8070400@freenet.de> Patrice Dumas wrote: > On Thu, May 14, 2009 at 03:44:21PM +0200, Ralf Corsepius wrote: >>> I also expect this will be brought up in similar cases in the future >>> with the justification that "we did this before". >> I don't see why these people can't use an external VCS/repository, like >> probably many developer groups do. > > I can see many a for a group of developper to use the fedora infra > for something else than the main distro: it simply lowers the cost to set > up a VCS/build servers/repository. Rubbish - It simply shifts cost and efforts around, adding further technical complexity. To me, their plan is nothing but an intention to abuse a dedicated system for purposes out side of the system's purposes. FESCO was in error to agree to this plan. Ralf From pertusus at free.fr Thu May 14 16:06:03 2009 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 14 May 2009 18:06:03 +0200 Subject: FESco meeting summary for 20090507 In-Reply-To: <4A0C3F09.8070400@freenet.de> References: <20090514130158.GA7053@mokona.greysector.net> <4A0C2035.5040304@freenet.de> <20090514141203.GB11456@free.fr> <4A0C3F09.8070400@freenet.de> Message-ID: <20090514160603.GH11456@free.fr> On Thu, May 14, 2009 at 05:55:53PM +0200, Ralf Corsepius wrote: > Rubbish - It simply shifts cost and efforts around, adding further > technical complexity. > > To me, their plan is nothing but an intention to abuse a dedicated > system for purposes out side of the system's purposes. I think that it is up to the infras/releng team to say so, after a discussion with the requesters. And FESCo then should verify their decision, but I don't think that outsiders from those teams (especially me or you) can really assess the relative costs of using the fedora infra versus not using it for this specific review requests preparations. -- Pat From jkeating at redhat.com Thu May 14 16:30:33 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 14 May 2009 09:30:33 -0700 Subject: FESco meeting summary for 20090507 In-Reply-To: <4A0C3F09.8070400@freenet.de> References: <20090514130158.GA7053@mokona.greysector.net> <4A0C2035.5040304@freenet.de> <20090514141203.GB11456@free.fr> <4A0C3F09.8070400@freenet.de> Message-ID: <1242318633.6282.77.camel@localhost.localdomain> On Thu, 2009-05-14 at 17:55 +0200, Ralf Corsepius wrote: > FESCO was in error to agree to this plan. Maybe you should run for FESCo to prevent such egregious errors from happening in the future. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Thu May 14 17:00:22 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 14 May 2009 19:00:22 +0200 Subject: FESco meeting summary for 20090507 In-Reply-To: <1242318633.6282.77.camel@localhost.localdomain> References: <20090514130158.GA7053@mokona.greysector.net> <4A0C2035.5040304@freenet.de> <20090514141203.GB11456@free.fr> <4A0C3F09.8070400@freenet.de> <1242318633.6282.77.camel@localhost.localdomain> Message-ID: <4A0C4E26.5090403@freenet.de> Jesse Keating wrote: > On Thu, 2009-05-14 at 17:55 +0200, Ralf Corsepius wrote: >> FESCO was in error to agree to this plan. > > Maybe you should run for FESCo to prevent such egregious errors from > happening in the future. Thanks, but I am not interested. From xose.vazquez at gmail.com Thu May 14 17:08:47 2009 From: xose.vazquez at gmail.com (Xose Vazquez Perez) Date: Thu, 14 May 2009 19:08:47 +0200 Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for glibc Message-ID: <4A0C501F.7000603@gmail.com> Mike McGrath wrote: > K, so we have a "might miss functionality". I think we can be more > specific then that. I'm not trying to be annoying about this, more > realistic about the changes that have been proposed actually getting in > place. It's going to have to be a _real_ good reason for the types of > code changes you guys are talking about which is essentially: in glibc: /* Support for utimensat syscall was added in 2.6.22, on alpha and s390 only after 2.6.22-rc1. */ /* Support for private futexes was added in 2.6.22. */ /* Support for fallocate was added in 2.6.23, on s390 only after 2.6.23-rc1. */ /* Support for various CLOEXEC and NONBLOCK flags was added for x86, x86-64, PPC, IA-64, SPARC< and S390 in 2.6.23. */ /* Support for ADJ_OFFSET_SS_READ was added in 2.6.24. */ /* Support for various CLOEXEC and NONBLOCK flags was added for x86, x86-64, PPC, IA-64, and SPARC in 2.6.27. */ /* Support for the accept4 syscall was added in 2.6.28. */ /* Support for the FUTEX_CLOCK_REALTIME flag was added in 2.6.29. */ /* Support for the AT_RANDOM auxiliary vector entry was added in 2.6.29. */ /* Support for preadv and pwritev was added in 2.6.30. */ > "Change koji/mock to create virtual machines on demand" [1] > > "change our non-xen builders to become xen" > > "Build differently x86/x86_64 then all of the other archs" You can try first x86 and x86_64. PPC can wait a bit. > "test test test" > > I'm not even sure this is a realistic F12 or F13 request as far a timing > goes. > > -Mike > > [1] This is epic btw. what a shame! fedora should be autohosted from day ONE! -thanks- regards, -- Polycommander, Erkowit, Urquiola, Andros Patria, Cason, Aegean Sea, Prestige, ... From rc040203 at freenet.de Thu May 14 17:20:27 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 14 May 2009 19:20:27 +0200 Subject: FESco meeting summary for 20090507 In-Reply-To: <20090514160603.GH11456@free.fr> References: <20090514130158.GA7053@mokona.greysector.net> <4A0C2035.5040304@freenet.de> <20090514141203.GB11456@free.fr> <4A0C3F09.8070400@freenet.de> <20090514160603.GH11456@free.fr> Message-ID: <4A0C52DB.6040004@freenet.de> Patrice Dumas wrote: > On Thu, May 14, 2009 at 05:55:53PM +0200, Ralf Corsepius wrote: >> Rubbish - It simply shifts cost and efforts around, adding further >> technical complexity. >> >> To me, their plan is nothing but an intention to abuse a dedicated >> system for purposes out side of the system's purposes. > > I think that it is up to the infras/releng team to say so, after a discussion > with the requesters. So far, we still have free speech? > And FESCo then should verify their decision, but I > don't think that outsiders from those teams (especially me or you) can > really assess the relative costs of using the fedora infra versus not using > it for this specific review requests preparations. No comment. From langel at redhat.com Thu May 14 17:28:32 2009 From: langel at redhat.com (Lillian Angel) Date: Thu, 14 May 2009 13:28:32 -0400 Subject: Where to post an experimental package? (java-1.7.0-openjdk) In-Reply-To: <1242316501.6282.56.camel@localhost.localdomain> References: <4A0C2DBA.4080502@redhat.com> <1242316501.6282.56.camel@localhost.localdomain> Message-ID: <4A0C54C0.1010605@redhat.com> Jesse Keating wrote: > On Thu, 2009-05-14 at 10:42 -0400, Lillian Angel wrote: > >> On May 21, Sun plans on releasing a preview of JDK7[1]. We (the OpenJDK >> team) would like to create a java-1.7.0-openjdk package for experimental >> and testing purposes. A few options were we create the fedora rpms and >> submit them to rpmfusion (or similar), host them on a my personal fedora >> page, or get the package into Fedora. >> >> I am wondering what some other acceptable options are. I am not keen on >> getting this package pushed into Fedora since java-1.6.0-openjdk already >> exists, and jdk7 will not be stable until sometime after Feb 2010[1]. >> >> Suggestions? >> > > How many packages will this consist of, and will there be > interdependencies (IE will you need to use one of these new packages to > build another new package)? > 6 or 7 packages in total. No interdependencies. > By far the easiest route is to do a scratch build of the package in > question, gather the resulting rpms and put them in a repo on your > fedorapeople page. Thanks, I think that is what we will do. Cheers, Lillian From jlaska at redhat.com Thu May 14 18:07:04 2009 From: jlaska at redhat.com (James Laska) Date: Thu, 14 May 2009 14:07:04 -0400 Subject: Thunderbird 3 Test Day TODAY Message-ID: <1242324424.6793.226.camel@flatline.devel.redhat.com> Greetings folks, Apologies for the late notice, but word just came in that there is a Thunderbird 3 test event today. Packages are provided for Fedora 9 through Fedora 11. Any thunderbird users/testers interested in participating are welcome to join the event over at https://wiki.mozilla.org/Thunderbird:QA_TestDay:2009-05-14. Thanks, James -------- Forwarded Message -------- > Subject: Thunderbird 3 Test Day, TODAY > Date: Thu, 14 May 2009 08:47:51 -0700 > > Mozilla is having a Linux test day for Thunderbird 3 today, May 14, 2009. > > The good news is that the test day is happening with distro-built > packages. The better news is that I've prepared Thunderbird 3 snapshot > packages not only for Fedora 11, but also Fedora 10 and even Fedora 9, > so you can help test without upgrading! > > Download a build and join us on IRC at irc.mozilla.org, #bugday > > More details and builds are available here: > > https://wiki.mozilla.org/Thunderbird:QA_TestDay:2009-05-14 > > Apologies for the late notice, but this got decided on last minute. > > Hope to see folks there. Happy testing. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mike at cchtml.com Thu May 14 18:18:24 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Thu, 14 May 2009 13:18:24 -0500 Subject: Thunderbird 3 Test Day TODAY In-Reply-To: <1242324424.6793.226.camel@flatline.devel.redhat.com> References: <1242324424.6793.226.camel@flatline.devel.redhat.com> Message-ID: <4A0C6070.5010709@cchtml.com> -------- Original Message -------- Subject: Thunderbird 3 Test Day TODAY From: James Laska To: fedora-test-list at redhat.com Date: 05/14/2009 01:07 PM > Greetings folks, > > Apologies for the late notice, but word just came in that there is a > Thunderbird 3 test event today. Packages are provided for Fedora 9 > through Fedora 11. > > Any thunderbird users/testers interested in participating are welcome to > join the event over at > https://wiki.mozilla.org/Thunderbird:QA_TestDay:2009-05-14. After that -devel thread I think we should hear from the following: Stephen Gallagher Bernie Innocenti Sean Darcy Nathan Grennan These folks reported issues with 3.0b2. Some louder than others. If you want your issues fixed, now is the time to participate in a test day. From Matt_Domsch at dell.com Thu May 14 18:43:20 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Thu, 14 May 2009 13:43:20 -0500 Subject: transition a few packages to new owners In-Reply-To: <0MKxQS-1M4c9a1SqB-0002S4@mrelayeu.kundenserver.de> References: <20090513173051.GB12695@auslistsprd01.us.dell.com> <4A0B1014.1050403@herr-schmitt.de> <20090513183459.GB18564@auslistsprd01.us.dell.com> <0MKxQS-1M4c9a1SqB-0002S4@mrelayeu.kundenserver.de> Message-ID: <20090514184320.GC18564@auslistsprd01.us.dell.com> On Thu, May 14, 2009 at 04:43:32PM +0200, Jochen Schmitt wrote: > On Wed, 13 May 2009 13:34:59 -0500, you wrote: > > > >the latest is currently sitting in updates-testing for 9, 10, 11, if > >you wish to look and then promote to stable. > > I have taken ownership of the packages, but I'm unable to maks > the updtes as stable. It may be nice, if you can try to release > the updates as stable. OK. give them a +1 karma and I'll push to stable. :-) -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From gvarisco at redhat.com Thu May 14 19:04:40 2009 From: gvarisco at redhat.com (Gianluca Varisco) Date: Thu, 14 May 2009 21:04:40 +0200 Subject: Thunderbird 3 Test Day TODAY In-Reply-To: <1242324424.6793.226.camel@flatline.devel.redhat.com> References: <1242324424.6793.226.camel@flatline.devel.redhat.com> Message-ID: <4A0C6B48.2010404@redhat.com> On 05/14/2009 08:07 PM, James Laska wrote: > Greetings folks, > > Apologies for the late notice, but word just came in that there is a > Thunderbird 3 test event today. Packages are provided for Fedora 9 > through Fedora 11. > > Any thunderbird users/testers interested in participating are welcome to > join the event over at > https://wiki.mozilla.org/Thunderbird:QA_TestDay:2009-05-14. > > Thanks, > James > Great - thanks for the reminder! I've just tested the F11 package provided and it fixes #492109 - https://bugzilla.mozilla.org/show_bug.cgi?id=492109 Awesome! ;-) Cheers, Gianluca From Jochen at herr-schmitt.de Thu May 14 19:31:11 2009 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 14 May 2009 21:31:11 +0200 Subject: transition a few packages to new owners In-Reply-To: <20090514184320.GC18564@auslistsprd01.us.dell.com> References: <20090513173051.GB12695@auslistsprd01.us.dell.com> <4A0B1014.1050403@herr-schmitt.de> <20090513183459.GB18564@auslistsprd01.us.dell.com> <0MKxQS-1M4c9a1SqB-0002S4@mrelayeu.kundenserver.de> <20090514184320.GC18564@auslistsprd01.us.dell.com> Message-ID: <4A0C717F.8060601@herr-schmitt.de> Matt Domsch schrieb: > > > OK. give them a +1 karma and I'll push to stable. :-) > > > OK, But IMHO it's not necessary to have a positiv karma to push a package into stable. Best Regards: Jochen Schmitt -------------- next part -------------- An HTML attachment was scrubbed... URL: From orion at cora.nwra.com Thu May 14 19:53:12 2009 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 14 May 2009 13:53:12 -0600 Subject: Determine time of last keystroke and mouse movement In-Reply-To: <20090514011629.GW16602@bilbo.ozlabs.org> References: <4A0B3262.2090702@cora.nwra.com> <20090514011629.GW16602@bilbo.ozlabs.org> Message-ID: <4A0C76A8.9060800@cora.nwra.com> Tony Breeds wrote: > On Wed, May 13, 2009 at 02:49:38PM -0600, Orion Poplawski wrote: >> Is there anyway for periodic (cron like) job running as root on Fedora >> 10 (and up) to determine time of the last keypress and mouse movement? >> Back in the day I could look at the access time of /dev/tty7, but this >> appears to be no longer the case (even when moving to /dev/tty1 to >> account for the vt1 X shift). Any ideas on how to determine this would >> be greatly appreciated. > > I'm sure you can write something to read (and log) /dev/input/* This daemon > could be started at system boot and /shouldn't/ interfere with system opperation. > > Yours Tony > Thanks, this is the approach I've taken. Yet Another Daemon. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -------------- next part -------------- A non-text attachment was scrubbed... Name: inputwatch.c Type: text/x-csrc Size: 3072 bytes Desc: not available URL: From abo at stacken.kth.se Thu May 14 20:05:10 2009 From: abo at stacken.kth.se (=?ISO-8859-1?Q?Alexander_Bostr=F6m?=) Date: Thu, 14 May 2009 22:05:10 +0200 Subject: Fedora Community Pre-Beta Testing In-Reply-To: <4A0B38B5.6040704@gmail.com> References: <4A0AEA7F.4060302@redhat.com> <200905132232.35752.opensource@till.name> <4A0B2FDE.1090906@redhat.com> <4A0B38B5.6040704@gmail.com> Message-ID: <4A0C7976.60009@stacken.kth.se> The way to solve problems like this is of course to use a single sign on infrastructure (CAS, Shibboleth, OpenID, Pubcookie, Kerberos/SPNEGO) so that there is only one single web page or dialog where the user has to enter the password, or to use X509 client certificates. Combinations of these do of course exist. I'm not overly worried about the Fedora infrastructure, just noting that there are partial solutions and people working on solving the rest. (FreeIPA is a good foundation, The Fedora infrastructure does hand out certificates, most web applications can be integrated with single sign on systems and so on.) /abo From rdieter at math.unl.edu Thu May 14 17:41:06 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 14 May 2009 12:41:06 -0500 Subject: kde-4.3 beta1 incoming to F-12 branch Message-ID: <4A0C57B2.5000408@math.unl.edu> The KDE SIG has begun importing and building kde-4.3beta1 in the F-12/ branch. Hopefully we'll finish up over the coming few days. Until finished, any other kde-related builds may go wonky. Let us know if you have any questions or problems. -- Rex _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From jonstanley at gmail.com Thu May 14 20:50:28 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Thu, 14 May 2009 16:50:28 -0400 Subject: Plans for tomorrow's (20090515) FESCo meeting Message-ID: The following topics will be discussed at the FESCo meeting tomorrow: 108 Would be good if there was an acl for "let all packagers edit this package" in pkgdb 142 Make x86_64 more visible or even the default choice 144 PPC as a secondary arch for Fedora 12 146 revoke rjones' sponsor and provenpackager status 147 Meeting agenda item: No broken dependencies should be a packaging guideline 148 FPC report - 2009-05-12 149 NetworkManager IPv6 - https://fedoraproject.org/wiki/Features/NetworkManagerIPv6 150 NetworkManager System connections - https://fedoraproject.org/wiki/Features/NetworkManagerSystemConnections 151 PolicyKitOne - https://fedoraproject.org/wiki/Features/PolicyKitOne For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor. From kevin.kofler at chello.at Thu May 14 20:51:11 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 14 May 2009 22:51:11 +0200 Subject: FESco meeting summary for 20090507 References: <20090514130158.GA7053@mokona.greysector.net> Message-ID: Dominik 'Rathann' Mierzejewski wrote: > As a packager and a member of the FPC, I think it is a very bad idea to > let packages in without proper review. I'd like to hear the very > convincing arguments which I expect were presented directly to some FESCo > members but were not included in the IRC meeting log for why this was > allowed and why the packages in question (which ones, exactly?) couldn't > go through the usual hoops like all new packages. > I don't see why the Java team (who, exactly?) or anyone else should > be allowed to import packages into Fedora CVS without proper review. Well, the FESCo decision says "This mini-review will be defined by FPC", so FPC could define the mini-review to be identical to a full review. :-) Kevin Kofler From a.badger at gmail.com Thu May 14 21:15:39 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 14 May 2009 14:15:39 -0700 Subject: Fedora Community Pre-Beta Testing In-Reply-To: <4A0C7976.60009@stacken.kth.se> References: <4A0AEA7F.4060302@redhat.com> <200905132232.35752.opensource@till.name> <4A0B2FDE.1090906@redhat.com> <4A0B38B5.6040704@gmail.com> <4A0C7976.60009@stacken.kth.se> Message-ID: <4A0C89FB.1010700@gmail.com> Alexander Bostr?m wrote: > The way to solve problems like this is of course to use a single sign on > infrastructure (CAS, Shibboleth, OpenID, Pubcookie, Kerberos/SPNEGO) so > that there is only one single web page or dialog where the user has to > enter the password, or to use X509 client certificates. Combinations of > these do of course exist. > > I'm not overly worried about the Fedora infrastructure, just noting that > there are partial solutions and people working on solving the rest. > (FreeIPA is a good foundation, The Fedora infrastructure does hand out > certificates, most web applications can be integrated with single sign > on systems and so on.) > We have a pubcookie like setup for Fedora Infrastructure. But that doesn't help here because the domain is different from the cookie issuer. Some of the other single sign on technologies would help but they involve a manpower cost to setup, deploy, and maintain that we don't have anyone who wants to pay yet. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From orion at cora.nwra.com Thu May 14 21:28:10 2009 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 14 May 2009 15:28:10 -0600 Subject: Thunderbird 3 Test Day TODAY In-Reply-To: <1242324424.6793.226.camel@flatline.devel.redhat.com> References: <1242324424.6793.226.camel@flatline.devel.redhat.com> Message-ID: <4A0C8CEA.3030303@cora.nwra.com> On 05/14/2009 12:07 PM, James Laska wrote: > Greetings folks, > > Apologies for the late notice, but word just came in that there is a > Thunderbird 3 test event today. Packages are provided for Fedora 9 > through Fedora 11. So, F-9 and F-10 will definitely move to Thunderbird 3.0 soon? If not, I don't think updates-testing is the right spot for these package. If so, better get the calendar working first. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From kevin.kofler at chello.at Thu May 14 21:33:38 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 14 May 2009 23:33:38 +0200 Subject: Breaking deps deliberately References: <20090513134744.GA19304@amd.home.annexia.org> <4A0AD15F.6040300@fedoraproject.org> <20090513135728.GA19428@amd.home.annexia.org> <20090513142048.GA19610@amd.home.annexia.org> <20090513142742.GB19610@amd.home.annexia.org> <20090513220839.GA22106@amd.home.annexia.org> <20090514114703.6ea61d2d@faldor.intranet> <20090514102623.GA25246@amd.home.annexia.org> Message-ID: Richard W.M. Jones wrote: > It now fails at runtime with an error message saying that vmchannel is > not supported by that version of qemu. ... which is what Michael meant by "malfunctioning". But I don't know how important that functionality is for libguestfs as a whole. Kevin Kofler From caillon at redhat.com Thu May 14 21:40:26 2009 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 14 May 2009 14:40:26 -0700 Subject: Thunderbird 3 Test Day TODAY In-Reply-To: <4A0C8CEA.3030303@cora.nwra.com> References: <1242324424.6793.226.camel@flatline.devel.redhat.com> <4A0C8CEA.3030303@cora.nwra.com> Message-ID: <4A0C8FCA.6060802@redhat.com> On 05/14/2009 02:28 PM, Orion Poplawski wrote: > On 05/14/2009 12:07 PM, James Laska wrote: >> Greetings folks, >> >> Apologies for the late notice, but word just came in that there is a >> Thunderbird 3 test event today. Packages are provided for Fedora 9 >> through Fedora 11. > > So, F-9 and F-10 will definitely move to Thunderbird 3.0 soon? If not, I > don't think updates-testing is the right spot for these package. If so, > better get the calendar working first. That is being entertained, yes. I do not expect it will happen before GA though. A lot of testing needs to happen still. From kevin.kofler at chello.at Thu May 14 21:34:53 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 14 May 2009 23:34:53 +0200 Subject: Breaking deps deliberately References: <20090513111343.4d79d48f@faldor.intranet> <20090513134744.GA19304@amd.home.annexia.org> <4A0AD15F.6040300@fedoraproject.org> <20090513135728.GA19428@amd.home.annexia.org> <20090513142048.GA19610@amd.home.annexia.org> <20090513142742.GB19610@amd.home.annexia.org> <20090513220839.GA22106@amd.home.annexia.org> <20090514114703.6ea61d2d@faldor.intranet> Message-ID: Michael Schwendt wrote: > Btw, the F-10 update would have had a higher %release than the F-11 > update (1.0.21-4.fc10 > 1.0.21-3.fc11). Sigh, why do people keep doing this instead of using proper 3.fc10.1 versioning? Deliberate breaking of upgrade paths also needs to be banned! Kevin Kofler From sundaram at fedoraproject.org Thu May 14 21:53:36 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 15 May 2009 03:23:36 +0530 Subject: Breaking deps deliberately In-Reply-To: References: <20090513111343.4d79d48f@faldor.intranet> <20090513134744.GA19304@amd.home.annexia.org> <4A0AD15F.6040300@fedoraproject.org> <20090513135728.GA19428@amd.home.annexia.org> <20090513142048.GA19610@amd.home.annexia.org> <20090513142742.GB19610@amd.home.annexia.org> <20090513220839.GA22106@amd.home.annexia.org> <20090514114703.6ea61d2d@faldor.intranet> Message-ID: <4A0C92E0.7070600@fedoraproject.org> On 05/15/2009 03:04 AM, Kevin Kofler wrote: > Michael Schwendt wrote: >> Btw, the F-10 update would have had a higher %release than the F-11 >> update (1.0.21-4.fc10 > 1.0.21-3.fc11). > > Sigh, why do people keep doing this instead of using proper 3.fc10.1 > versioning? Is that method documented anywhere? Rahul From oget.fedora at gmail.com Thu May 14 22:00:33 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Thu, 14 May 2009 18:00:33 -0400 Subject: Breaking deps deliberately In-Reply-To: <4A0C92E0.7070600@fedoraproject.org> References: <20090513111343.4d79d48f@faldor.intranet> <20090513135728.GA19428@amd.home.annexia.org> <20090513142048.GA19610@amd.home.annexia.org> <20090513142742.GB19610@amd.home.annexia.org> <20090513220839.GA22106@amd.home.annexia.org> <20090514114703.6ea61d2d@faldor.intranet> <4A0C92E0.7070600@fedoraproject.org> Message-ID: On Thu, May 14, 2009 at 5:53 PM, Rahul Sundaram wrote: > On 05/15/2009 03:04 AM, Kevin Kofler wrote: >> Michael Schwendt wrote: >>> Btw, the F-10 update would have had a higher %release than the F-11 >>> update (1.0.21-4.fc10 > 1.0.21-3.fc11). >> >> Sigh, why do people keep doing this instead of using proper 3.fc10.1 >> versioning? > > Is that method documented anywhere? > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Minor_release_bumps_for_old_branches ... although I find it a bit weird to have this rule in the Naming Guidelines. Orcan From wolfy at nobugconsulting.ro Thu May 14 22:02:19 2009 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Fri, 15 May 2009 01:02:19 +0300 Subject: Breaking deps deliberately In-Reply-To: <4A0C92E0.7070600@fedoraproject.org> References: <20090513111343.4d79d48f@faldor.intranet> <20090513134744.GA19304@amd.home.annexia.org> <4A0AD15F.6040300@fedoraproject.org> <20090513135728.GA19428@amd.home.annexia.org> <20090513142048.GA19610@amd.home.annexia.org> <20090513142742.GB19610@amd.home.annexia.org> <20090513220839.GA22106@amd.home.annexia.org> <20090514114703.6ea61d2d@faldor.intranet> <4A0C92E0.7070600@fedoraproject.org> Message-ID: <4A0C94EB.5000909@nobugconsulting.ro> On 05/15/2009 12:53 AM, Rahul Sundaram wrote: > On 05/15/2009 03:04 AM, Kevin Kofler wrote: > >> Michael Schwendt wrote: >> >>> Btw, the F-10 update would have had a higher %release than the F-11 >>> update (1.0.21-4.fc10 > 1.0.21-3.fc11). >>> >> Sigh, why do people keep doing this instead of using proper 3.fc10.1 >> versioning? >> > > Is that method documented anywhere? > > Rahul > > https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Minor_release_bumps_for_old_branches -- Manuel Wolfshant linux registered user #131416 IT manager NoBug Consulting SRL A: Yes. >Q: Are you sure? >>A: Because it reverses the logical flow of conversation. >>>Q: Why is top posting frowned upon? From sundaram at fedoraproject.org Thu May 14 22:14:35 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 15 May 2009 03:44:35 +0530 Subject: Breaking deps deliberately In-Reply-To: References: <20090513111343.4d79d48f@faldor.intranet> <20090513135728.GA19428@amd.home.annexia.org> <20090513142048.GA19610@amd.home.annexia.org> <20090513142742.GB19610@amd.home.annexia.org> <20090513220839.GA22106@amd.home.annexia.org> <20090514114703.6ea61d2d@faldor.intranet> <4A0C92E0.7070600@fedoraproject.org> Message-ID: <4A0C97CB.4090201@fedoraproject.org> On 05/15/2009 03:30 AM, Orcan Ogetbil wrote: > On Thu, May 14, 2009 at 5:53 PM, Rahul Sundaram wrote: >> On 05/15/2009 03:04 AM, Kevin Kofler wrote: >>> Michael Schwendt wrote: >>>> Btw, the F-10 update would have had a higher %release than the F-11 >>>> update (1.0.21-4.fc10 > 1.0.21-3.fc11). >>> Sigh, why do people keep doing this instead of using proper 3.fc10.1 >>> versioning? >> Is that method documented anywhere? >> > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Minor_release_bumps_for_old_branches > > ... although I find it a bit weird to have this rule in the Naming Guidelines. I wasn't expecting it to be under naming guidelines either. Would referring to it from http://fedoraproject.org/wiki/Package_update_HOWTO help? Rahul From wolfy at nobugconsulting.ro Thu May 14 22:14:05 2009 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Fri, 15 May 2009 01:14:05 +0300 Subject: Breaking deps deliberately In-Reply-To: <4A0C97CB.4090201@fedoraproject.org> References: <20090513111343.4d79d48f@faldor.intranet> <20090513135728.GA19428@amd.home.annexia.org> <20090513142048.GA19610@amd.home.annexia.org> <20090513142742.GB19610@amd.home.annexia.org> <20090513220839.GA22106@amd.home.annexia.org> <20090514114703.6ea61d2d@faldor.intranet> <4A0C92E0.7070600@fedoraproject.org> <4A0C97CB.4090201@fedoraproject.org> Message-ID: <4A0C97AD.1040801@nobugconsulting.ro> On 05/15/2009 01:14 AM, Rahul Sundaram wrote: > On 05/15/2009 03:30 AM, Orcan Ogetbil wrote: > >> On Thu, May 14, 2009 at 5:53 PM, Rahul Sundaram wrote: >> >>> On 05/15/2009 03:04 AM, Kevin Kofler wrote: >>> >>>> Michael Schwendt wrote: >>>> >>>>> Btw, the F-10 update would have had a higher %release than the F-11 >>>>> update (1.0.21-4.fc10 > 1.0.21-3.fc11). >>>>> >>>> Sigh, why do people keep doing this instead of using proper 3.fc10.1 >>>> versioning? >>>> >>> Is that method documented anywhere? >>> >>> >> http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Minor_release_bumps_for_old_branches >> >> ... although I find it a bit weird to have this rule in the Naming Guidelines. >> > > I wasn't expecting it to be under naming guidelines either. > > Would referring to it from > > http://fedoraproject.org/wiki/Package_update_HOWTO help? > http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo should mention it. BTW, http://fedoraproject.org/wiki/PackageMaintainers/UsingCvsFaq#How_do_I_make_changes_to_an_older_branch.3F mentions this trick, too. From sundaram at fedoraproject.org Thu May 14 22:25:47 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 15 May 2009 03:55:47 +0530 Subject: Breaking deps deliberately In-Reply-To: <4A0C97AD.1040801@nobugconsulting.ro> References: <20090513111343.4d79d48f@faldor.intranet> <20090513135728.GA19428@amd.home.annexia.org> <20090513142048.GA19610@amd.home.annexia.org> <20090513142742.GB19610@amd.home.annexia.org> <20090513220839.GA22106@amd.home.annexia.org> <20090514114703.6ea61d2d@faldor.intranet> <4A0C92E0.7070600@fedoraproject.org> <4A0C97CB.4090201@fedoraproject.org> <4A0C97AD.1040801@nobugconsulting.ro> Message-ID: <4A0C9A6B.4000307@fedoraproject.org> On 05/15/2009 03:44 AM, Manuel Wolfshant wrote: > On 05/15/2009 01:14 AM, Rahul Sundaram wrote: >> Would referring to it from >> >> http://fedoraproject.org/wiki/Package_update_HOWTO help? >> > http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo > should mention it. These are both the same links if you didn't notice. Rahul From fedora-devel-list at cygnusx-1.org Thu May 14 22:22:29 2009 From: fedora-devel-list at cygnusx-1.org (Nathan Grennan) Date: Thu, 14 May 2009 15:22:29 -0700 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A082E70.7030904@TheTroubleshooters.dk> References: <4A082E70.7030904@TheTroubleshooters.dk> Message-ID: <4A0C99A5.1040401@cygnusx-1.org> On 05/11/2009 06:56 AM, Michael Nielsen wrote: > Hi, > > I've been told this is the right place to place this debate starter. > > > Not to demean the fine work that has been done in maintaining fedora, > however the distribution is slowly killing itself, being destroyed by > contradicting philosophies. Many of the problems have been directly > copied from the Windows world. > > The main problems are. I don't agree with you on some of your points, but I do support your overall point. This is something that has been bugging me for years also, but does seem to be especially an issue lately. I have come up with a few different ways to look at it. It seems to me it isn't always even a server vs desktop, but a desktop vs laptop divide. The server generally sorts itself out in a fairly clean fashion, and that is especially true if you use something like CentOS for servers. By the time something makes it into CentOS from Fedora it has been polished enough to be in fairly usable shape. I still don't always like they direction things take, like say all the anaconda changes, but it is usable. The bigger issue is desktop vs laptop users. Which also can be viewed as older power users vs new users, and sysadmins vs programmers. These dichotomies cause a lot of grief in a number of ways. Examples: Desktop vs Laptop: NetworkManager vs /etc/sysconfig/network-scripts: NetworkManager is great for laptop users, because it deals with wireless, especially wireless with encryption in a fairly graceful way, when it works. It is not so great for desktop users who have no encryption needs, or mobility and find NetworkManager less reliable. Which is why desktop users complain when it becomes the new default. PulseAudio(esd, artsd, etc) vs ALSA(direct): PulseAudio, or something like it, is something needed for laptop users to do software mixing on their generic onboard sound cards. Yet for desktop users, especially power users, who still have SB Live!, Audigy, Turtle Beach, etc cards with hardware mixing, things like PulseAudio are just more trouble than they are worth. There are various goals in conflict. The programmers seem to have the laptop/new user mindset at heart. Part of this mindset, which I have seen in this thread, and you see all the time is "Why are you whining to me, you don't pay my paycheck". While out of the other side of their mouth they say, be a part of the community. But the you don't pay my paycheck aspect doesn't quite jive with the be part of the community aspect. Another aspect of be part of the community is, well if you don't like it, write your own patch. The problem is these are generally power users and/or sysadmins. While they are technical enough that they could program, they are too busy with work and keeping up with all the changes to the various programs. That they can't spend all their time submitting patches to every project that is going in a direction they don't like. On top of that, when they do submit patches, more than half the time they developer/maintainer will say they aren't interested in the patch. So why should they bother in the first place. Open source largely lets the programmers do whatever they want. On the other hand, for the users(power users) it becomes a dictatorship per program. Fedora leaders tell us to go to upstream. In the past we have gone to upstream, and have been ignored. The issue is also a grey area since many of the maintainers are also the upstream developers. What is it going to take to get the programmers to take power user input before they go off coding some new idea? What is it going to take to get them to not make everything a work in progress when it is critical desktop infrastructure like sound and networking? From walters at verbum.org Thu May 14 22:27:52 2009 From: walters at verbum.org (Colin Walters) Date: Thu, 14 May 2009 18:27:52 -0400 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A0C99A5.1040401@cygnusx-1.org> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A0C99A5.1040401@cygnusx-1.org> Message-ID: On Thu, May 14, 2009 at 6:22 PM, Nathan Grennan wrote: > > > ?It seems to me it isn't always even a server vs desktop, but a desktop vs > laptop divide. The desktop team has always focused on laptops because laptops are the harder case, and if you get the laptop right, then you generally get the desktop right along the way. From fedora-devel-list at cygnusx-1.org Thu May 14 22:37:30 2009 From: fedora-devel-list at cygnusx-1.org (Nathan Grennan) Date: Thu, 14 May 2009 15:37:30 -0700 Subject: Fedora (Linux) is Destroying it self In-Reply-To: References: <4A082E70.7030904@TheTroubleshooters.dk> <4A0C99A5.1040401@cygnusx-1.org> Message-ID: <4A0C9D2A.2070601@cygnusx-1.org> On 05/14/2009 03:27 PM, Colin Walters wrote: > The desktop team has always focused on laptops because laptops are the > harder case, and if you get the laptop right, then you generally get > the desktop right along the way. I agree laptops are harder from a logistics perspective, but I disagree that it results in it generally just working for the desktop users. I also think desktops are harder from a supporting all the different types of hardware perspective. Desktop hardware and laptop hardware tend to be so different. Laptops are generally a generation behind on motherboard chipsets and processors. They tend to have less variety of hardware when it comes to network, video, and sound cards. Keyboards on laptops are pretty much always done the same way since they are built-in. Mice on laptops are almost always trackpads, since they are built-in. Other cards come out different too, PCI/PCIe vs Cardbus/ExpressCard/USB. From orion at cora.nwra.com Thu May 14 23:05:09 2009 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 14 May 2009 17:05:09 -0600 Subject: Installing multiple versions of software In-Reply-To: <4A094AC8.9090602@TheTroubleshooters.dk> References: <4A082E70.7030904@TheTroubleshooters.dk> <200905111040.27935.konrad@tylerc.org> <4A094AC8.9090602@TheTroubleshooters.dk> Message-ID: <4A0CA3A5.4040209@cora.nwra.com> On 05/12/2009 04:09 AM, Michael Nielsen wrote: > However, due to some of the issues I've pointed out, I've started not > using the package > manager for the main components for the development work I do, because > of the problem of not > being able to use the package manager to maintain multiple versions of > an application > on a system - something that could be implemented almost trivially, by > restructuring > the way packages are installed. I've found this annoying at times. I think Debian does a better job of this, though it's been a while since I've used it. The flip argument is that with multiple versions things get more complicated and focus is taken away from working on the latest version which is definitely one of Fedora's main goals. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From chitlesh.goorah at gmail.com Thu May 14 23:26:39 2009 From: chitlesh.goorah at gmail.com (Chitlesh GOORAH) Date: Fri, 15 May 2009 01:26:39 +0200 Subject: emacs: verilog-mode versus dinotrace Message-ID: <50baabb30905141626r46d0489cqfa2beff33d43ce65@mail.gmail.com> Hello there, I want to hear your thoughts about removing verilog-mode from the emacs packages : emacs-el and emacs-common Files affected are /usr/share/emacs/22.3/lisp/progmodes/verilog-mode.el.gz /usr/share/emacs/22.3/lisp/progmodes/verilog-mode.elc I will instead package verilog-mode separately for fedora for the following reasons: - verilog-mode's release is not in sync with emac's releases - verilog-mode now has system-verilog support. I guess you still remember the emails about the lack of system-verilog support which lead to the exclusion of the opensource industry verification packages - OVM and VMM. - verilog-mode on emacs and dinotrace[1]: simple and quick digital waveforms debugging (by the user) with the user's verilog files - (done on the fly) - to ensure that verilog-mode shipped with F-XX is not older than that shipped with EL-5 . Emacs-21 does not include verilog-mode. Emacs-21 is shipped with EL-5. Emacs-22 includes verilog-mode. Emacs-22 is shipped by fedora. Since I'm packaging dinotrace for EL-5 as well and the later requires verilog-mode, a package review [2] is needed for emacs-verilog-mode. == What does it mean to the users ? == Those using verilog-mode are mostly FEL users. 1) As dinotrace (currently being reviewed) enters fedora repositories, those users will benefit with extra digital waveforms manipulation which gtkwave currently lacks. 2) The introduction of system-verilog support on both verilog-mode and perl-Verilog(latest release) [1]: https://bugzilla.redhat.com/show_bug.cgi?id=478749 [2]: https://bugzilla.redhat.com/show_bug.cgi?id=500931 Kind regards, Chitlesh From cmadams at hiwaay.net Fri May 15 00:14:32 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 14 May 2009 19:14:32 -0500 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A0C9D2A.2070601@cygnusx-1.org> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A0C99A5.1040401@cygnusx-1.org> <4A0C9D2A.2070601@cygnusx-1.org> Message-ID: <20090515001432.GB1148000@hiwaay.net> Once upon a time, Nathan Grennan said: > Desktop hardware and laptop hardware tend to be so different. Laptops > are generally a generation behind on motherboard chipsets and > processors. Not really in recent years, as Intel, AMD, and the other associated vendors have focused on power management across the board (with laptop chips leading the way). > They tend to have less variety of hardware when it comes to > network, video, and sound cards. Again, not necessarily, at least for network and video. They may be different from desktop, but there is a wide variety. A given line or even brand of laptop may be more uniform, but there are a lot of different makes and models. > Keyboards on laptops are pretty much > always done the same way since they are built-in. Laptops almost always have "special" keys that not all desktops have, and on laptops they can be more important (suspend, volume control, etc.). > Mice on laptops are > almost always trackpads, since they are built-in. Well, Thinkpads (and some others) have Trackpoint. Also, lots of people have a USB (or in my case Bluetooth) mouse. Most desktop users only have one pointing device. > Other cards come out > different too, PCI/PCIe vs Cardbus/ExpressCard/USB. Cardbus == PCI+hotswap ExpressCard == PCIe+hotswap (+another USB connector) USB is USB (not sure what you meant by listing it) I'd have to say my laptop has a lot more "interesting" hardware than my desktops. Hot-swap card slots, built-in memory card reader (PCI connected, not USB), hot swap drive bay, Bluetooth, wireless, multiple pointer devices, special keyboard keys like volume control, etc. Laptops also tend (at least as shipped) to have more limited resources (less RAM, smaller and slower hard drives, slower CPUs, limited video, etc.), so making a laptop run something with good response will almost always improve responsiveness on desktops as well. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From fedora-devel-list at cygnusx-1.org Fri May 15 00:46:47 2009 From: fedora-devel-list at cygnusx-1.org (Nathan Grennan) Date: Thu, 14 May 2009 17:46:47 -0700 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <20090515001432.GB1148000@hiwaay.net> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A0C99A5.1040401@cygnusx-1.org> <4A0C9D2A.2070601@cygnusx-1.org> <20090515001432.GB1148000@hiwaay.net> Message-ID: <4A0CBB77.60603@cygnusx-1.org> On 05/14/2009 05:14 PM, Chris Adams wrote: > Once upon a time, Nathan Grennan said: >> Desktop hardware and laptop hardware tend to be so different. Laptops >> are generally a generation behind on motherboard chipsets and >> processors. > > Not really in recent years, as Intel, AMD, and the other associated > vendors have focused on power management across the board (with laptop > chips leading the way). Yes, the are focused on power management across the board, but new processors and chipsets come out for desktops first. The i7 was for desktops first. > >> They tend to have less variety of hardware when it comes to >> network, video, and sound cards. > > Again, not necessarily, at least for network and video. They may be > different from desktop, but there is a wide variety. A given line or > even brand of laptop may be more uniform, but there are a lot of > different makes and models. It isn't that wide of a variety, and for wired cards they aren't swappable. In some cases wireless cards aren't swapped for artificial technical reasons. Video cards it is always a really stripped down form of ATI/Nvidia cards or Intel, and not swappable. This means way less combinations of hardware. > >> Keyboards on laptops are pretty much >> always done the same way since they are built-in. > > Laptops almost always have "special" keys that not all desktops have, > and on laptops they can be more important (suspend, volume control, > etc.). Desktops can have lots of special keys too. Though they aren't my personal taste. I mentioned them more on desktops are ps/2 or usb, where as laptop keyboards are handled by the manufacture. Unless you plug in an external, which most people don't. >> Mice on laptops are >> almost always trackpads, since they are built-in. > > Well, Thinkpads (and some others) have Trackpoint. Also, lots of people > have a USB (or in my case Bluetooth) mouse. Most desktop users only > have one pointing device. Thinkpads are the main exception. Yes, lots of people do use external mice on laptops, but even more just deal with the built-in trackpad, which is a whole different experience than a external mouse. >> Other cards come out >> different too, PCI/PCIe vs Cardbus/ExpressCard/USB. > > Cardbus == PCI+hotswap > ExpressCard == PCIe+hotswap (+another USB connector) > USB is USB (not sure what you meant by listing it) > Even if they are technically hotswap versions of the same thing, the actual equipment you purchase, and the drivers you use with them tend to be VERY different. Hence why I mentioned it. > I'd have to say my laptop has a lot more "interesting" hardware than my > desktops. Hot-swap card slots, built-in memory card reader (PCI > connected, not USB), hot swap drive bay, Bluetooth, wireless, multiple > pointer devices, special keyboard keys like volume control, etc. I can do a lot more interesting stuff with a desktop. It is just that you are given the option when ordering to get more built-in. Some things make more sense in a laptop, like wireless, and volume control(built-in speakers). > Laptops also tend (at least as shipped) to have more limited resources > (less RAM, smaller and slower hard drives, slower CPUs, limited video, > etc.), so making a laptop run something with good response will almost > always improve responsiveness on desktops as well. Yeah, that is why I am not a fan of laptops. They are so limited. I can do so much more with my desktop faster. Their use cases are also so different. A lot of laptop work revolves around running off a battery. Desktops don't have a real need for that. Another issue is things like cpu scaling. On a laptop this makes sense. In my experience on a desktop it noticeably reduces performance. I might be willing to make that trade off on a laptop, but not a desktop. From cmadams at hiwaay.net Fri May 15 01:47:52 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 14 May 2009 20:47:52 -0500 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A0CBB77.60603@cygnusx-1.org> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A0C99A5.1040401@cygnusx-1.org> <4A0C9D2A.2070601@cygnusx-1.org> <20090515001432.GB1148000@hiwaay.net> <4A0CBB77.60603@cygnusx-1.org> Message-ID: <20090515014752.GE1148000@hiwaay.net> Once upon a time, Nathan Grennan said: > Their use cases are also so different. A lot of laptop work revolves > around running off a battery. Desktops don't have a real need for that. > Another issue is things like cpu scaling. On a laptop this makes sense. > In my experience on a desktop it noticeably reduces performance. I might > be willing to make that trade off on a laptop, but not a desktop. Power management also makes lots of sense on a desktop. My desktop systems run a lot cooler because of it; my main system runs with the CPU fan stopped (cooler and quieter) most of the time due to CPU scaling. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From bruno at wolff.to Fri May 15 04:39:34 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Thu, 14 May 2009 23:39:34 -0500 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <1242280970.2923.918.camel@adam.local.net> References: <1242060668.28322.85.camel@localhost.localdomain> <1242240008.2316.2.camel@prague> <2d319b780905131147r14143d5ev97ed5be9cff50773@mail.gmail.com> <1242247260.2316.5.camel@prague> <4A0B3430.8080902@gmail.com> <1242250170.2316.9.camel@prague> <4A0BA256.2080606@redhat.com> <20090514054033.GB21431@wolff.to> <1242280970.2923.918.camel@adam.local.net> Message-ID: <20090515043934.GA13758@wolff.to> On Wed, May 13, 2009 at 23:02:50 -0700, Adam Williamson wrote: > > Er, it did? I'm still using ifconfig and route. They appear to work. :) > The joys of backwards compatibility! ip is more powerful. I believe it allows you to set up things on an interface easily that need at least using aliases for ifconfig and in some cases might not be doable. They aren't things you normally want to do though. From markmc at redhat.com Fri May 15 06:58:31 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 15 May 2009 07:58:31 +0100 Subject: Plans for tomorrow's (20090515) FESCo meeting In-Reply-To: References: Message-ID: <1242370711.3254.7.camel@blaa> Hi Jon, On Thu, 2009-05-14 at 16:50 -0400, Jon Stanley wrote: > The following topics will be discussed at the FESCo meeting tomorrow: Suggestion - could you add the meeting time to these mails? http://fedoraproject.org/wiki/Development/SteeringCommittee Currently meets every Friday at 16:00 UTC during the summer, 17:00 UTC in the winter on the Freenode IRC Network in #fedora-meeting. Thanks, Mark. From rjones at redhat.com Fri May 15 07:45:15 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 15 May 2009 08:45:15 +0100 Subject: Breaking deps deliberately In-Reply-To: References: <20090513134744.GA19304@amd.home.annexia.org> <4A0AD15F.6040300@fedoraproject.org> <20090513135728.GA19428@amd.home.annexia.org> <20090513142048.GA19610@amd.home.annexia.org> <20090513142742.GB19610@amd.home.annexia.org> <20090513220839.GA22106@amd.home.annexia.org> <20090514114703.6ea61d2d@faldor.intranet> Message-ID: <20090515074515.GA30109@amd.home.annexia.org> On Thu, May 14, 2009 at 11:34:53PM +0200, Kevin Kofler wrote: > Michael Schwendt wrote: > > Btw, the F-10 update would have had a higher %release than the F-11 > > update (1.0.21-4.fc10 > 1.0.21-3.fc11). > > Sigh, why do people keep doing this instead of using proper 3.fc10.1 > versioning? Deliberate breaking of upgrade paths also needs to be banned! Yes, that's wrong. I usually get this right ('X%{?_dist}.Y') but in this case I must have forgotten. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From nicolas.mailhot at laposte.net Fri May 15 08:30:43 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 15 May 2009 10:30:43 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: References: <4A082E70.7030904@TheTroubleshooters.dk> <4A0C99A5.1040401@cygnusx-1.org> Message-ID: <8c197f0ebf9551eba0d6448c78b38dc7.squirrel@arekh.dyndns.org> Le Ven 15 mai 2009 00:27, Colin Walters a ?crit : > > On Thu, May 14, 2009 at 6:22 PM, Nathan Grennan > wrote: >> >> >> ?It seems to me it isn't always even a server vs desktop, but a >> desktop vs >> laptop divide. > > The desktop team has always focused on laptops because laptops are the > harder case, and if you get the laptop right, then you generally get > the desktop right along the way. I think the "laptops are the harder case" is true for power management but false for pretty much everything else. Very few laptops drive complex devices because laptops are not that extensible and laptops manufacturers prefer limited cheap general purpose hardware over more complete expensive less general solutions. Also because laptops are shut down/disconnected regularly they are not used for long-running, background nor network-exposed computing). -- Nicolas Mailhot From laurent.rineau__fedora at normalesup.org Fri May 15 08:50:45 2009 From: laurent.rineau__fedora at normalesup.org (Laurent Rineau) Date: Fri, 15 May 2009 10:50:45 +0200 Subject: transition a few packages to new owners In-Reply-To: <200905131129.01576.konrad@tylerc.org> References: <20090513173051.GB12695@auslistsprd01.us.dell.com> <200905131129.01576.konrad@tylerc.org> Message-ID: <200905151050.45546@rineau.tsetse> On Wednesday 13 May 2009 20:29:01 Conrad Meyer wrote: > On Wednesday 13 May 2009 10:30:51 am Matt Domsch wrote: > > I'd like to transition a few packages to new owners. If you are > > interested, please apply in the pkgdb and I'll transfer them to you. > > > > aiccu -- SixXS Automatic IPv6 Connectivity Client Utility > > gpp -- GNOME Photo Printer > > oggvideotools -- Toolbox for manipulating Ogg video files > > perl-GnuPG-Interface -- Perl interface to GnuPG > > pgp-tools -- Collection of several utilities related to OpenPGP > > > > Thanks, > > Matt > > > > -- > > Matt Domsch > > Linux Technology Strategist, Dell Office of the CTO > > linux.dell.com & www.dell.com/linux > > I'll take aiccu. There should be a packacing effort so that aiccu can be configured as a NetworkManagerDispatcher service. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From bojan at rexursive.com Fri May 15 09:09:41 2009 From: bojan at rexursive.com (Bojan Smojver) Date: Fri, 15 May 2009 19:09:41 +1000 Subject: kernel-2.6.29.3-142.fc11 Message-ID: <1242378581.3179.10.camel@shrek.rexursive.com> I see some patches in the latest F-11 kernel have been applied post -140 kernel: - linux-2.6-iommu-fixes.patch: intel-iommu: fix PCI device detach from virtual machine 3199aa6bc8766e17b8f60820c4f78d59c25fce0e upstream. - linux-2.6-iommu-fixes.patch: intel-iommu: PAE memory corruption fix fd18de50b9e7965f93d231e7390436fb8900c0e6 upstream. Also, re-cherry-pick patchset and fix up merge conflicts against 2.6.29.3. Would these things have anything to do with kernel panicing when modesetting is turned on with Intel graphics hardware? -- Bojan From naheemzaffar at gmail.com Fri May 15 09:30:06 2009 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Fri, 15 May 2009 10:30:06 +0100 Subject: kernel-2.6.29.3-142.fc11 In-Reply-To: <1242378581.3179.10.camel@shrek.rexursive.com> References: <1242378581.3179.10.camel@shrek.rexursive.com> Message-ID: <3adc77210905150230h49b7450bl7ca30b6f22a18fd5@mail.gmail.com> 2009/5/15 Bojan Smojver > I see some patches in the latest F-11 kernel have been applied post -140 > kernel: > > - linux-2.6-iommu-fixes.patch: intel-iommu: fix PCI device detach from > virtual machine 3199aa6bc8766e17b8f60820c4f78d59c25fce0e upstream. > > - linux-2.6-iommu-fixes.patch: intel-iommu: PAE memory corruption fix > fd18de50b9e7965f93d231e7390436fb8900c0e6 upstream. Also, re-cherry-pick > patchset and fix up merge conflicts against 2.6.29.3. > > Would these things have anything to do with kernel panicing when > modesetting is turned on with Intel graphics hardware? > I can also confirm that kernels 140+ (updated to it a moment ago along [followed by -142 from koji] with MESA updates, so the problem may be elsewhere...) KMS no longer works on my Radeon X1950 pro card either. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bojan at rexursive.com Fri May 15 10:22:43 2009 From: bojan at rexursive.com (Bojan Smojver) Date: Fri, 15 May 2009 10:22:43 +0000 (UTC) Subject: kernel-2.6.29.3-142.fc11 References: <1242378581.3179.10.camel@shrek.rexursive.com> <3adc77210905150230h49b7450bl7ca30b6f22a18fd5@mail.gmail.com> Message-ID: Naheem Zaffar gmail.com> writes: > I can also confirm that kernels 140+ (updated to it a moment ago along [followed by -142 from koji] with MESA updates, so the problem may be elsewhere...) KMS no longer works on my Radeon X1950 pro card either. I get a flickering screen on VT1 where X is supposed to be, every time I move my mouse. Eventually, the kernel panics. -- Bojan From bojan at rexursive.com Fri May 15 11:02:37 2009 From: bojan at rexursive.com (Bojan Smojver) Date: Fri, 15 May 2009 11:02:37 +0000 (UTC) Subject: kernel-2.6.29.3-142.fc11 References: <1242378581.3179.10.camel@shrek.rexursive.com> <3adc77210905150230h49b7450bl7ca30b6f22a18fd5@mail.gmail.com> Message-ID: Bojan Smojver rexursive.com> writes: > I get a flickering screen on VT1 where X is supposed to be, every time I > move my mouse. Eventually, the kernel panics. Bug #500983. -- Bojan From jonathan.underwood at gmail.com Fri May 15 11:00:06 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 15 May 2009 12:00:06 +0100 Subject: emacs: verilog-mode versus dinotrace In-Reply-To: <50baabb30905141626r46d0489cqfa2beff33d43ce65@mail.gmail.com> References: <50baabb30905141626r46d0489cqfa2beff33d43ce65@mail.gmail.com> Message-ID: <645d17210905150400j418bcbd4k9f171a33102bcb1@mail.gmail.com> 2009/5/15 Chitlesh GOORAH : > Hello there, > > I want to hear your thoughts about removing verilog-mode from the > emacs packages : emacs-el and emacs-common > > Files affected are > /usr/share/emacs/22.3/lisp/progmodes/verilog-mode.el.gz > /usr/share/emacs/22.3/lisp/progmodes/verilog-mode.elc > > I will instead package verilog-mode separately for fedora for the > following reasons: [snip] I have concerns about this. There are many emacs lisp packages which are both bundled with Emacs and also developed in their own "further upstream" sandbox. Other examples include org-mode, reftex, gnus etc. If we start going down the path of ripping these out of the emacs distribution and replacing them with their more rapidly evolving upstreams we don't benefit from the integration and bug fixing work done in the emacs trunk. This amounts to more work for the Fedora emacs package maintainers when it comes to bugs etc. On the other hand I do see the appeal of newer packages (personally I end up having a local copy of org-mode which is loaded in preference to the emacs bundled one, for example). The origin of this is the emacs development model really, and the lack of a well integrated add-on module mechanism (although Tom Tromey's work on this is great). Personally, I'd rather see us develop a packaging strategy whereby we don't rip out verilog-mode from the core emacs packages, but we can also have an add-on package which contains the latest and greatest verilog-mode which, if installed, is loaded in preference to the one from the core emacs packages. The first response when a bug is reported against verilog-mode would then be " do a yum remove emacs-verilog-mode and see if the bug is still there". I haven't looked too closely at what would be required as far as what is required in terms of load-path munging, but it should be possible I think. Jonathan. From chitlesh.goorah at gmail.com Fri May 15 11:44:01 2009 From: chitlesh.goorah at gmail.com (Chitlesh GOORAH) Date: Fri, 15 May 2009 13:44:01 +0200 Subject: emacs: verilog-mode versus dinotrace In-Reply-To: <645d17210905150400j418bcbd4k9f171a33102bcb1@mail.gmail.com> References: <50baabb30905141626r46d0489cqfa2beff33d43ce65@mail.gmail.com> <645d17210905150400j418bcbd4k9f171a33102bcb1@mail.gmail.com> Message-ID: <50baabb30905150444y1948618eq67151811bb7e9599@mail.gmail.com> On Fri, May 15, 2009 at 1:00 PM, Jonathan Underwood wrote: > The origin of this is the emacs development model really, and the lack > of a well integrated add-on module mechanism (although Tom Tromey's > work on this is great). > > Personally, I'd rather see us develop a packaging strategy whereby we > don't rip out verilog-mode from the core emacs packages, but we can > also have an add-on package which contains the latest and greatest > verilog-mode which, if installed, is loaded in preference to the one > from the core emacs packages. The first response when a bug is > reported against verilog-mode would then be " do a yum remove > emacs-verilog-mode and see if the bug is still there". I haven't > looked too closely at what would be required as far as what is > required in terms of load-path munging, but it should be possible I > think. Hello Jonathan, I like the idea having the verilog-mode loaded by priority : -1) emacs-verilog-mode -2) if emacs-verilog-mode is not present then load verilog-mode coming with emacs-el Could you review the emacs-verilog-mode package ? The latest verilog-mode comes with system-verilog support and I'm trying to get as much system-verilog support for FEL in order to introduce OVM and VMM on fedora. Chitlesh PS :We should not forget that verilog-mode and dinotrace have the same upstream. From jonathan.underwood at gmail.com Fri May 15 12:11:04 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 15 May 2009 13:11:04 +0100 Subject: emacs: verilog-mode versus dinotrace In-Reply-To: <50baabb30905150444y1948618eq67151811bb7e9599@mail.gmail.com> References: <50baabb30905141626r46d0489cqfa2beff33d43ce65@mail.gmail.com> <645d17210905150400j418bcbd4k9f171a33102bcb1@mail.gmail.com> <50baabb30905150444y1948618eq67151811bb7e9599@mail.gmail.com> Message-ID: <645d17210905150511y68fb63d2q1167b34891544dcb@mail.gmail.com> 2009/5/15 Chitlesh GOORAH : > Hello ?Jonathan, > > I like the idea having the verilog-mode loaded by priority : > -1) ?emacs-verilog-mode > -2) if emacs-verilog-mode is not present then load verilog-mode coming > with emacs-el > > Could you review the emacs-verilog-mode package ? > Sure, do you have a BZ#? Will look at it over the w.e. > The latest verilog-mode comes with system-verilog support and I'm > trying to get as much system-verilog support for FEL in order to > introduce OVM and VMM on fedora. Excellent. From rawhide at fedoraproject.org Fri May 15 13:13:35 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Fri, 15 May 2009 13:13:35 +0000 (UTC) Subject: rawhide report: 20090515 changes Message-ID: <20090515131335.8694E1F8216@releng2.fedora.phx.redhat.com> Compose started at Fri May 15 06:15:04 UTC 2009 Updated Packages: cups-1.4-0.b2.17.fc11 --------------------- * Thu May 14 2009 Tim Waugh 1:1.4-0.b2.17 - Prevent cupsd crash when handling IPP_TAG_DELETEATTR requests (STR #3197, bug #500859). drupal-6.12-1.fc11 ------------------ * Thu May 14 2009 Jon Ciesla - 6.12-1 - Update to 6.11, SA-CORE-2009-006. mkinitrd-6.0.84-1.fc11 ---------------------- * Thu May 14 2009 Peter Jones - 6.0.84-1 - Don't use fixed device names in cryptsetup (#500830) plymouth-0.7.0-0.2009.05.14.2.fc11 ---------------------------------- * Thu May 14 2009 Ray Strode 0.7.0-0.2009.05.14.1 - Update to new snapshot that renames plugins to fix upgrades somewhat (bug 499940) * Thu May 14 2009 Ray Strode 0.7.0-0.2009.05.14.2 - Add plymouth-set-default-plugin compat script for upgrades - Force solar to bring in system-plugin to work around comps snafu (bug 499940) xorg-x11-drv-ati-6.12.2-14.fc11 ------------------------------- * Thu May 14 2009 Kyle McMartin 6.12.2-14 - radeon-modeset-still-more-fixes.patch: Bump the GEM interface version to 31 so we don't activate it... (#500801) Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 5 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From dan at danny.cz Fri May 15 13:21:10 2009 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Fri, 15 May 2009 15:21:10 +0200 Subject: s390x Status (Was Re: Secondary Architecture Status?) In-Reply-To: <1241911202.24436.81.camel@macbook.infradead.org> References: <1241911202.24436.81.camel@macbook.infradead.org> Message-ID: <1242393670.3703.337.camel@eagle.danny.cz> David Woodhouse p??e v Ne 10. 05. 2009 v 00:20 +0100: > On Sat, 2009-05-09 at 13:24 -0400, Jon Stanley wrote: > > FESCo conducted a brief discussion of moving PowerPC to a secondary > > architecture for Fedora 12. The general consensus is that since > > Fedora 12 development cycle has already begun, it is not appropriate > > for Fedora 12. However, for Fedora 13, FESCo is in favor of the idea. > > NB: THIS IS NOT AN OFFICIAL VOTE OR POSISTION, THAT WILL COME NEXT > > WEEK. > > It was originally decreed by the Board that we wouldn't drop PowerPC > from being a primary architecture until some other architecture has > actually shown that the infrastructure for secondary architectures is > working. > > We still don't have any secondary architectures gearing up to ship > Fedora 11 -- it would be really interesting to know why that is. > > What technical barriers are still there -- why don't we have a release > yet? > > I think that at this point it's acceptable to leave the fate of the port > to the people who most care about it -- but if there are infrastructure > or other problems which would block a release _regardless_ of how hard > the port maintainers work, that's less reasonable. > > So a report from our existing secondary architecture teams on why they > haven't managed to release yet would be useful input to next week's > meeting. Short info about s390x status - it was restarted earlier this year with the goal to have F-11 release - still building F-11 packages - 5620 successful builds (--latest), ~360 ExcludeArchs, ~750 failures with the Java stack being the main hurdle - we have some issues with capacity of the network connection to the koji hub and it also limits our progress - only a bunch of packages exist now on the koji hub, but we should start doing composes soon(TM) Dan From kyle at mcmartin.ca Fri May 15 14:03:44 2009 From: kyle at mcmartin.ca (Kyle McMartin) Date: Fri, 15 May 2009 10:03:44 -0400 Subject: kernel-2.6.29.3-142.fc11 In-Reply-To: References: <1242378581.3179.10.camel@shrek.rexursive.com> <3adc77210905150230h49b7450bl7ca30b6f22a18fd5@mail.gmail.com> Message-ID: <20090515140344.GC18732@bombadil.infradead.org> On Fri, May 15, 2009 at 11:02:37AM +0000, Bojan Smojver wrote: > Bojan Smojver rexursive.com> writes: > > > I get a flickering screen on VT1 where X is supposed to be, every time I > > move my mouse. Eventually, the kernel panics. > > Bug #500983. > Please try xorg-x11-drv-ati 6.12.2-14 and let me know if this doesn't help. regards, Kyle From loganjerry at gmail.com Fri May 15 14:49:23 2009 From: loganjerry at gmail.com (Jerry James) Date: Fri, 15 May 2009 08:49:23 -0600 Subject: emacs: verilog-mode versus dinotrace In-Reply-To: <645d17210905150511y68fb63d2q1167b34891544dcb@mail.gmail.com> References: <50baabb30905141626r46d0489cqfa2beff33d43ce65@mail.gmail.com> <645d17210905150400j418bcbd4k9f171a33102bcb1@mail.gmail.com> <50baabb30905150444y1948618eq67151811bb7e9599@mail.gmail.com> <645d17210905150511y68fb63d2q1167b34891544dcb@mail.gmail.com> Message-ID: <870180fe0905150749vde43b77sa1e8f40929048cbb@mail.gmail.com> On Fri, May 15, 2009 at 6:11 AM, Jonathan Underwood wrote: > 2009/5/15 Chitlesh GOORAH : >> Hello ?Jonathan, >> >> I like the idea having the verilog-mode loaded by priority : >> -1) ?emacs-verilog-mode >> -2) if emacs-verilog-mode is not present then load verilog-mode coming >> with emacs-el >> >> Could you review the emacs-verilog-mode package ? >> > > Sure, do you have a BZ#? Will look at it over the w.e. > >> The latest verilog-mode comes with system-verilog support and I'm >> trying to get as much system-verilog support for FEL in order to >> introduce OVM and VMM on fedora. > > Excellent. What about the XEmacs version of verilog-mode? It is in xemacs-packages-extra. -- Jerry James, whose status as an XEmacs developer is entirely coincidental http://www.jamezone.org/ From pertusus at free.fr Fri May 15 14:59:13 2009 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 15 May 2009 16:59:13 +0200 Subject: FESco meeting summary for 20090507 In-Reply-To: <4A0C52DB.6040004@freenet.de> References: <20090514130158.GA7053@mokona.greysector.net> <4A0C2035.5040304@freenet.de> <20090514141203.GB11456@free.fr> <4A0C3F09.8070400@freenet.de> <20090514160603.GH11456@free.fr> <4A0C52DB.6040004@freenet.de> Message-ID: <20090515145913.GB9953@free.fr> On Thu, May 14, 2009 at 07:20:27PM +0200, Ralf Corsepius wrote: > So far, we still have free speech? Not denying that. -- Pat From nikolay at vladimiroff.com Fri May 15 15:20:59 2009 From: nikolay at vladimiroff.com (Nikolay Vladimirov) Date: Fri, 15 May 2009 18:20:59 +0300 Subject: Games SIG wishlist update? Message-ID: Hi, I took some time to look trough the Wishlist of the Games SIG and here is what I found: https://fedoraproject.org/wiki/Talk:SIGs/Games/WishList I know that it's up to each maintainer to chose weather or not to package something but most of these project are not active. Is it a good idea for them to stay in the wishlist with eventual packaging and eventual bug reports that will never be fixed? -- NV From lemenkov at gmail.com Fri May 15 15:52:01 2009 From: lemenkov at gmail.com (Peter Lemenkov) Date: Fri, 15 May 2009 19:52:01 +0400 Subject: Games SIG wishlist update? In-Reply-To: References: Message-ID: Hello All! 2009/5/15 Nikolay Vladimirov : > Hi, I took some time to look trough the Wishlist of the Games SIG and > here is what I found: > https://fedoraproject.org/wiki/Talk:SIGs/Games/WishList Good work! > I know that it's up to each maintainer to chose weather or not to > package something but most of these project are not active. > Is it a good idea for them to stay in the wishlist with eventual > packaging and eventual bug reports that will never be fixed? These records in wiki doesn't consume any human/hardware/other resources, so I think it's safe to leave them here. Maybe sometimes someone will pick them up and package or even revive them. O/T you may find it interesting to join our xmpp-conference at fedora-devel at conference.jabber.ru :) ????? ?????????? :) -- With best regards! From chitlesh.goorah at gmail.com Fri May 15 16:19:50 2009 From: chitlesh.goorah at gmail.com (Chitlesh GOORAH) Date: Fri, 15 May 2009 18:19:50 +0200 Subject: emacs: verilog-mode versus dinotrace In-Reply-To: <870180fe0905150749vde43b77sa1e8f40929048cbb@mail.gmail.com> References: <50baabb30905141626r46d0489cqfa2beff33d43ce65@mail.gmail.com> <645d17210905150400j418bcbd4k9f171a33102bcb1@mail.gmail.com> <50baabb30905150444y1948618eq67151811bb7e9599@mail.gmail.com> <645d17210905150511y68fb63d2q1167b34891544dcb@mail.gmail.com> <870180fe0905150749vde43b77sa1e8f40929048cbb@mail.gmail.com> Message-ID: <50baabb30905150919t51d2f56fjf963e14e42d93d65@mail.gmail.com> > On Fri, May 15, 2009 at 6:11 AM, Jonathan Underwood >> Sure, do you have a BZ#? Will look at it over the w.e. https://bugzilla.redhat.com/show_bug.cgi?id=500931 On Fri, May 15, 2009 at 4:49 PM, Jerry James wrote: > What about the XEmacs version of verilog-mode? ?It is in xemacs-packages-extra. > -- > Jerry James, whose status as an XEmacs developer is entirely coincidental Excuse my lack of experience with emacs, does it mean we are already shipping 2 _old_ versions of verilog-mode ? Why ? Jerry, can you update the XEmacs upstream's verilog-mode ? Then the fedora packager of xemacs can pull it. However it is a bit confusing of shipping verilog-mode twice (now thrice with my emacs-verilog-mode package). Can't there be only one common verilog-mode or other .el files for both emacs and xemacs ? regards, Chitlesh From kwhiskerz at gmail.com Fri May 15 16:24:13 2009 From: kwhiskerz at gmail.com (Petrus de Calguarium) Date: Fri, 15 May 2009 10:24:13 -0600 Subject: kde-4.3 beta1 incoming to F-12 branch References: <4A0C57B2.5000408__45769.6945792579$1242332450$gmane$org@math.unl.edu> Message-ID: Rex Dieter wrote: > Let us know if you have any questions or problems. > How can I stay on rawhide instead of transitioning to F11? From bruno at wolff.to Fri May 15 16:38:49 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Fri, 15 May 2009 11:38:49 -0500 Subject: Games SIG wishlist update? In-Reply-To: References: Message-ID: <20090515163849.GA25964@wolff.to> On Fri, May 15, 2009 at 18:20:59 +0300, Nikolay Vladimirov wrote: > Hi, I took some time to look trough the Wishlist of the Games SIG and > here is what I found: > https://fedoraproject.org/wiki/Talk:SIGs/Games/WishList > > I know that it's up to each maintainer to chose weather or not to > package something but most of these project are not active. > Is it a good idea for them to stay in the wishlist with eventual > packaging and eventual bug reports that will never be fixed? I think it makes more sense to keep the list and make notes about ones that we don't want to package indicating why. That way we won't keep getting new requests for them. From loganjerry at gmail.com Fri May 15 16:40:45 2009 From: loganjerry at gmail.com (Jerry James) Date: Fri, 15 May 2009 10:40:45 -0600 Subject: emacs: verilog-mode versus dinotrace In-Reply-To: <50baabb30905150919t51d2f56fjf963e14e42d93d65@mail.gmail.com> References: <50baabb30905141626r46d0489cqfa2beff33d43ce65@mail.gmail.com> <645d17210905150400j418bcbd4k9f171a33102bcb1@mail.gmail.com> <50baabb30905150444y1948618eq67151811bb7e9599@mail.gmail.com> <645d17210905150511y68fb63d2q1167b34891544dcb@mail.gmail.com> <870180fe0905150749vde43b77sa1e8f40929048cbb@mail.gmail.com> <50baabb30905150919t51d2f56fjf963e14e42d93d65@mail.gmail.com> Message-ID: <870180fe0905150940t16ef5497oeb948f870e63239b@mail.gmail.com> On Fri, May 15, 2009 at 10:19 AM, Chitlesh GOORAH wrote: > Excuse my lack of experience with emacs, does it mean we are already > shipping 2 _old_ versions of verilog-mode ? Why ? > > Jerry, can you update the XEmacs upstream's verilog-mode ? Then the > fedora packager of xemacs can pull it. I'll take a look. It looks like Marcus Harnisch updated the XEmacs version to upstream revision 463 back in January. He would probably have a better chance than I would of not botching a move to revision 502. Plus, I'd have no idea how to test the result since I am entirely ignorant of Verilog. Ugh, it looks like we have some GPLv2 versus GPLv3 issues with that file. Let me talk to the other developers about what we can do. > However it is a bit confusing of shipping verilog-mode twice (now > thrice with my emacs-verilog-mode package). Can't there be only one > common verilog-mode or other .el files for both emacs and xemacs ? No. The .el files are the source code. Both editors byte compile that source code into a .elc file, but their byte codes diverged some years back. Some distributions have tried to share code between the two, with invariably disastrous results for one editor or the other. -- Jerry James http://www.jamezone.org/ From awilliam at redhat.com Fri May 15 17:46:42 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 15 May 2009 10:46:42 -0700 Subject: kernel-2.6.29.3-142.fc11 In-Reply-To: <1242378581.3179.10.camel@shrek.rexursive.com> References: <1242378581.3179.10.camel@shrek.rexursive.com> Message-ID: <1242409602.2923.958.camel@adam.local.net> On Fri, 2009-05-15 at 19:09 +1000, Bojan Smojver wrote: > I see some patches in the latest F-11 kernel have been applied post -140 > kernel: > > - linux-2.6-iommu-fixes.patch: intel-iommu: fix PCI device detach from > virtual machine 3199aa6bc8766e17b8f60820c4f78d59c25fce0e upstream. > > - linux-2.6-iommu-fixes.patch: intel-iommu: PAE memory corruption fix > fd18de50b9e7965f93d231e7390436fb8900c0e6 upstream. Also, re-cherry-pick > patchset and fix up merge conflicts against 2.6.29.3. > > Would these things have anything to do with kernel panicing when > modesetting is turned on with Intel graphics hardware? Have you filed a bug for this? It sounds like a release critical regression... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From nikolay at vladimiroff.com Fri May 15 18:01:18 2009 From: nikolay at vladimiroff.com (Nikolay Vladimirov) Date: Fri, 15 May 2009 21:01:18 +0300 (EET) Subject: Games SIG wishlist update? Message-ID: 2009/5/15 Bruno Wolff III: > On Fri, May 15, 2009 at 18:20:59 +0300, > ?Nikolay Vladimirov wrote: >> Hi, I took some time to look trough the Wishlist of the Games SIG and >> here is what I found: >> https://fedoraproject.org/wiki/Talk:SIGs/Games/WishList >> >> I know that it's up to each maintainer to chose weather or not to >> package something but most of these project are not active. >> Is it a good idea for them to stay in the wishlist with eventual >> packaging and eventual bug reports that will never be fixed? > > I think it makes more sense to keep the list and make notes about ones that > we don't want to package indicating why. That way we won't keep getting new > requests for them. > I updated https://fedoraproject.org/wiki/SIGs/Games/WishList as follows: * Added "Dead upstream" section and moved some entries there * Updated the micropolis URL * Removed all entries with dead links. -- NV -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 270 bytes Desc: OpenPGP digital signature URL: From kevin at scrye.com Fri May 15 18:50:06 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Fri, 15 May 2009 12:50:06 -0600 Subject: kde-4.3 beta1 incoming to F-12 branch In-Reply-To: References: <4A0C57B2.5000408__45769.6945792579$1242332450$gmane$org@math.unl.edu> Message-ID: <20090515125006.213a2379@ohm.scrye.com> On Fri, 15 May 2009 10:24:13 -0600 Petrus de Calguarium wrote: > Rex Dieter wrote: > > > Let us know if you have any questions or problems. > > > How can I stay on rawhide instead of transitioning to F11? Re-enable the rawhide repository and disable fedora/fedora-updates. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From jwboyer at gmail.com Fri May 15 19:20:43 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 15 May 2009 15:20:43 -0400 Subject: FESCo meeting summary for 20090515 Message-ID: <20090515192043.GA6310@yoda.jdub.homelinux.org> == Members Present == * Jon Stanley (jds2001) * Kevin Fenzi (nirik) * Dan Horak (sharkcz) * Josh Boyer (jwb) * Brian Pepple (bpepple) * Bill Nottingham (notting) * David Woodhouse (dwmw2) * Jarod Wilson (j-rod) == Members Absent == * Dennis Gilmore (dgilmore) == PPC as a secondary arch for Fedora 12 == FESCo approved a proposal to keep PPC a primary architecture for Fedora 12, but move it to a secondary architecture for Fedora 13. There was brief discussion on some of the value in keeping PPC primary, however Jesse Keating pointed out that the same value would be present if PPC proved to be a complete and successful secondary architecture. == revoke rjones' sponsor and provenpackager status == FESCo declined the proposal to revoke Richard Jones' sposon and provenpackage status based on the intentional introduction of a broken dependency. That has been corrected in the repos and Richard has stated that he will not do this intentionally again. There was some further discussion on what it takes to revoke these priviledges, and FESCo generally agreed that it would be evaluated on a case-by-case basis taking into account things like how egregious the issue was, repeat offenders, etc. == No broken dependencies should be a packaging guideline == After further discussion, FESCo asked that Toshio and Richard draft up a packaging guideline and submit it to the Fedora Packaging Committee == Make x86_64 more visible or even the default choice == FESCo asked M?ir?n Duffy for input on making x86_64 more visible on the Fedora download page. The initial feedback was that a banner for 64-bit could be possible, but that the page is designed for a very large audience which may or may not be technically inclined. FESCo deferred to M?ir?n and asked that further discussion be taken to the website list. == FPC report - 2009-05-12 == FESCo approved all the pending FPC guidelines. There was some discussion on the pre-review guideline and it was amended to require rel-eng/fesco approval before package groups can use the guideline. == NM IPv6 - https://fedoraproject.org/wiki/Features/NetworkManagerIPv6 == FESCo approved this feature for Fedora 12 == PolicyKitOne - https://fedoraproject.org/wiki/Features/PolicyKitOne == FESCo approved this feature for Fedora 12 == FESCo Elections == FESCo highlighted that the nomination period for the next FESCo election is now open. There are 5 seats open for election. FESCo encourages those that wish to participate in FESCo to add themselves to the nomination page: https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations IRC log: http://bpepple.fedorapeople.org/fesco/FESCo-2009-05-15.html From kwhiskerz at gmail.com Fri May 15 19:27:48 2009 From: kwhiskerz at gmail.com (Petrus de Calguarium) Date: Fri, 15 May 2009 13:27:48 -0600 Subject: kde-4.3 beta1 incoming to F-12 branch References: <4A0C57B2.5000408__45769.6945792579$1242332450$gmane$org@math.unl.edu> <20090515125006.213a2379@ohm.scrye.com> Message-ID: Kevin Fenzi wrote: > Re-enable the rawhide repository and disable fedora/fedora- updates. > Thanks. I have already done that, but I didn't dare run yum update yet, until there was some kind of fedora-release package (other than the recent 11-1, that I, of course, didn't install). Maybe there is no fedora-release package for rawhide, as it isn't a release? From caillon at redhat.com Fri May 15 19:32:50 2009 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 15 May 2009 12:32:50 -0700 Subject: Plans for tomorrow's (20090515) FESCo meeting In-Reply-To: <1242370711.3254.7.camel@blaa> References: <1242370711.3254.7.camel@blaa> Message-ID: <4A0DC362.4080905@redhat.com> On 05/14/2009 11:58 PM, Mark McLoughlin wrote: > Hi Jon, > > On Thu, 2009-05-14 at 16:50 -0400, Jon Stanley wrote: > >> The following topics will be discussed at the FESCo meeting tomorrow: > > Suggestion - could you add the meeting time to these mails? > > http://fedoraproject.org/wiki/Development/SteeringCommittee > > Currently meets every Friday at 16:00 UTC during the summer, 17:00 UTC > in the winter on the Freenode IRC Network in #fedora-meeting. So, is it summer or winter now? In South America, Africa, Australia, etc. it's winter.... In North America, Europe, Asia, summer... :-) From kevin at scrye.com Fri May 15 19:32:42 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Fri, 15 May 2009 13:32:42 -0600 Subject: kde-4.3 beta1 incoming to F-12 branch In-Reply-To: References: <4A0C57B2.5000408__45769.6945792579$1242332450$gmane$org@math.unl.edu> <20090515125006.213a2379@ohm.scrye.com> Message-ID: <20090515133242.78137b75@ohm.scrye.com> On Fri, 15 May 2009 13:27:48 -0600 Petrus de Calguarium wrote: > Kevin Fenzi wrote: > > > Re-enable the rawhide repository and disable fedora/fedora- > updates. > > > Thanks. I have already done that, but I didn't dare run yum > update yet, until there was some kind of fedora-release package > (other than the recent 11-1, that I, of course, didn't install). > Maybe there is no fedora-release package for rawhide, as it > isn't a release? There will be one once f11 is released. Look for it a day or two after release. Thats when rawhide will start composing against f12/devel branches as well. You should see a gigantic pile of updates then. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From jwboyer at gmail.com Fri May 15 19:43:42 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 15 May 2009 15:43:42 -0400 Subject: Plans for tomorrow's (20090515) FESCo meeting In-Reply-To: <4A0DC362.4080905@redhat.com> References: <1242370711.3254.7.camel@blaa> <4A0DC362.4080905@redhat.com> Message-ID: <20090515194342.GB6310@yoda.jdub.homelinux.org> On Fri, May 15, 2009 at 12:32:50PM -0700, Christopher Aillon wrote: > On 05/14/2009 11:58 PM, Mark McLoughlin wrote: >> Hi Jon, >> >> On Thu, 2009-05-14 at 16:50 -0400, Jon Stanley wrote: >> >>> The following topics will be discussed at the FESCo meeting tomorrow: >> >> Suggestion - could you add the meeting time to these mails? >> >> http://fedoraproject.org/wiki/Development/SteeringCommittee >> >> Currently meets every Friday at 16:00 UTC during the summer, 17:00 UTC >> in the winter on the Freenode IRC Network in #fedora-meeting. > > So, is it summer or winter now? In South America, Africa, Australia, > etc. it's winter.... In North America, Europe, Asia, summer... :-) Technically, I don't think it's summer anywhere at the moment. Summer doesn't start until June 20/21 in the northern hemisphere. josh From sundaram at fedoraproject.org Fri May 15 19:58:01 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 16 May 2009 01:28:01 +0530 Subject: Abrt - should this be a feature? Message-ID: <4A0DC949.7000601@fedoraproject.org> Hi http://fedoraproject.org/wiki/Features/ABRT It was broken when tested https://fedoraproject.org/wiki/QA/Test_Days/2009-02-26 Bug Buddy seems to the default still for GNOME. Why is it in the feature list? FESCo should reconsider this feature. Rahul From kevin at scrye.com Fri May 15 20:14:07 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Fri, 15 May 2009 14:14:07 -0600 Subject: Abrt - should this be a feature? In-Reply-To: <4A0DC949.7000601@fedoraproject.org> References: <4A0DC949.7000601@fedoraproject.org> Message-ID: <20090515141407.19b4bbd6@ohm.scrye.com> On Sat, 16 May 2009 01:28:01 +0530 Rahul Sundaram wrote: > Hi > > http://fedoraproject.org/wiki/Features/ABRT > > It was broken when tested > > https://fedoraproject.org/wiki/QA/Test_Days/2009-02-26 > > Bug Buddy seems to the default still for GNOME. Why is it in the > feature list? FESCo should reconsider this feature. Sadly, we were going on the "100%" there from the feature owner. ;( I think we should move this off to f12. I don't know if we can correct all the places it's mentioned in relation to f11, but we should try. > > Rahul > kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From emmanuel.seyman at club-internet.fr Fri May 15 23:30:25 2009 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Sat, 16 May 2009 01:30:25 +0200 Subject: transition a few packages to new owners In-Reply-To: <20090513173051.GB12695@auslistsprd01.us.dell.com> References: <20090513173051.GB12695@auslistsprd01.us.dell.com> Message-ID: <20090515233025.GA28735@orient.maison.lan> * Matt Domsch [13/05/2009 20:26] : > > pgp-tools -- Collection of several utilities related to OpenPGP I'll gladly take this one. I've added myself to the package in pkgdb. Emmanuel From bojan at rexursive.com Fri May 15 23:44:07 2009 From: bojan at rexursive.com (Bojan Smojver) Date: Sat, 16 May 2009 09:44:07 +1000 Subject: kernel-2.6.29.3-142.fc11 In-Reply-To: <20090515140344.GC18732@bombadil.infradead.org> References: <1242378581.3179.10.camel@shrek.rexursive.com> <3adc77210905150230h49b7450bl7ca30b6f22a18fd5@mail.gmail.com> <20090515140344.GC18732@bombadil.infradead.org> Message-ID: <1242431047.3179.11.camel@shrek.rexursive.com> On Fri, 2009-05-15 at 10:03 -0400, Kyle McMartin wrote: > Please try xorg-x11-drv-ati 6.12.2-14 and let me know if this doesn't > help. My machine has Intel graphics hardware. -- Bojan From bojan at rexursive.com Sat May 16 00:01:49 2009 From: bojan at rexursive.com (Bojan Smojver) Date: Sat, 16 May 2009 00:01:49 +0000 (UTC) Subject: kernel-2.6.29.3-142.fc11 References: <1242378581.3179.10.camel@shrek.rexursive.com> <1242409602.2923.958.camel@adam.local.net> Message-ID: Adam Williamson redhat.com> writes: > Have you filed a bug for this? It sounds like a release critical > regression... Yes. https://bugzilla.redhat.com/show_bug.cgi?id=500983 -- Bojan From Matt_Domsch at dell.com Sat May 16 01:06:09 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 15 May 2009 20:06:09 -0500 Subject: transition a few packages to new owners In-Reply-To: <20090515233025.GA28735@orient.maison.lan> References: <20090513173051.GB12695@auslistsprd01.us.dell.com> <20090515233025.GA28735@orient.maison.lan> Message-ID: <20090516010609.GA5241@auslistsprd01.us.dell.com> On Sat, May 16, 2009 at 01:30:25AM +0200, Emmanuel Seyman wrote: > * Matt Domsch [13/05/2009 20:26] : > > > > pgp-tools -- Collection of several utilities related to OpenPGP > > I'll gladly take this one. I've added myself to the package in pkgdb. Thank you. I've orphaned it now, please take ownership in pkgdb. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From rjones at redhat.com Sat May 16 07:31:15 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Sat, 16 May 2009 08:31:15 +0100 Subject: Plans for tomorrow's (20090515) FESCo meeting In-Reply-To: <4A0DC362.4080905@redhat.com> References: <1242370711.3254.7.camel@blaa> <4A0DC362.4080905@redhat.com> Message-ID: <20090516073115.GA2885@amd.home.annexia.org> On Fri, May 15, 2009 at 12:32:50PM -0700, Christopher Aillon wrote: > On 05/14/2009 11:58 PM, Mark McLoughlin wrote: >> Hi Jon, >> >> On Thu, 2009-05-14 at 16:50 -0400, Jon Stanley wrote: >> >>> The following topics will be discussed at the FESCo meeting tomorrow: >> >> Suggestion - could you add the meeting time to these mails? >> >> http://fedoraproject.org/wiki/Development/SteeringCommittee >> >> Currently meets every Friday at 16:00 UTC during the summer, 17:00 UTC >> in the winter on the Freenode IRC Network in #fedora-meeting. > > So, is it summer or winter now? In South America, Africa, Australia, > etc. it's winter.... In North America, Europe, Asia, summer... :-) The meeting wasn't when it said on the website. In fact it's at 17:00 UTC all year round, and the website has now been updated to say that. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw From veillard at redhat.com Sat May 16 07:56:14 2009 From: veillard at redhat.com (Daniel Veillard) Date: Sat, 16 May 2009 09:56:14 +0200 Subject: PolicyKit changes in F12 In-Reply-To: <1242262846.9432.9.camel@localhost.localdomain> References: <1242262846.9432.9.camel@localhost.localdomain> Message-ID: <20090516075614.GU1589@redhat.com> On Wed, May 13, 2009 at 09:00:46PM -0400, Matthias Clasen wrote: > Just a heads-up: > > We hope to land a new PolicyKit version (which will turn into 1.0, > eventually) in F12 soon. The new version simplifies the API and will > require PolicyKit-using application to be ported. For more information, > have a look at the feature page: > > http://fedoraproject.org/wiki/Features/PolicyKitOne > > It also has pointers to api docs and a (terse) porting guide. We already > have a collection of patches for quite a few PolicyKit-using apps, so > the transitions should be relatively painless. http://cgit.freedesktop.org/PolicyKit/tree/docs/PORTING-GUIDE doesn't uindicate how to discriminate at compile time which version we are compiling against. Please indictate in the porting doc how to detect the installed version in configure. That's the bare minimum when you're changing APIs in that way. We obviously need libvirt to handle older and newer versions ! Also what does ? No kit_* OOM handling in the new library means ? Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel at veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ From mschwendt at gmail.com Sat May 16 12:12:20 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sat, 16 May 2009 14:12:20 +0200 Subject: rpms/html-xml-utils/devel .cvsignore, 1.2, 1.3 html-xml-utils.spec, 1.6, 1.7 sources, 1.2, 1.3 In-Reply-To: <20090516105736.4313570128@cvs1.fedora.phx.redhat.com> References: <20090516105736.4313570128@cvs1.fedora.phx.redhat.com> Message-ID: <20090516141220.29151086@faldor.intranet> On Sat, 16 May 2009 10:57:36 +0000 (UTC), Milo? wrote: > Author: mjakubicek > > Update of /cvs/pkgs/rpms/html-xml-utils/devel > Log Message: > - Update to 5.3: many bugfixes, most binaries have now a "hx" prefix > - Removed Conflicts: surfraw, normalize > - Fixed license tag: W3C It's not a "fix", but the project simply switched to a different licence with their release of 4.2. > -html-xml-utils-3.7.tar.gz > +html-xml-utils-5.3.tar.gz > -License: GPL+ > +License: W3C From xjakub at fi.muni.cz Sat May 16 12:40:27 2009 From: xjakub at fi.muni.cz (Milos Jakubicek) Date: Sat, 16 May 2009 14:40:27 +0200 Subject: rpms/html-xml-utils/devel .cvsignore, 1.2, 1.3 html-xml-utils.spec, 1.6, 1.7 sources, 1.2, 1.3 In-Reply-To: <20090516141220.29151086@faldor.intranet> References: <20090516105736.4313570128@cvs1.fedora.phx.redhat.com> <20090516141220.29151086@faldor.intranet> Message-ID: <4A0EB43B.7030101@fi.muni.cz> Thanks for the info, I've read their changelog before, but there is nothing about this change unfortunately:( Regards, Milos On 16.5.2009 14:12, Michael Schwendt wrote: > On Sat, 16 May 2009 10:57:36 +0000 (UTC), Milo? wrote: > >> Author: mjakubicek >> >> Update of /cvs/pkgs/rpms/html-xml-utils/devel > >> Log Message: >> - Update to 5.3: many bugfixes, most binaries have now a "hx" prefix >> - Removed Conflicts: surfraw, normalize >> - Fixed license tag: W3C > > It's not a "fix", but the project simply switched to a different > licence with their release of 4.2. > >> -html-xml-utils-3.7.tar.gz >> +html-xml-utils-5.3.tar.gz > >> -License: GPL+ >> +License: W3C > From kanarip at kanarip.com Sat May 16 13:25:31 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sat, 16 May 2009 15:25:31 +0200 Subject: Database SIG? In-Reply-To: <1242082378.30883.73.camel@radiator.bos.redhat.com> References: <1242082378.30883.73.camel@radiator.bos.redhat.com> Message-ID: <4A0EBECB.2090603@kanarip.com> On 05/12/2009 12:52 AM, David Malcolm wrote: > Would anyone else be interested in a database special-interest-group > within Fedora? I don't see one at http://fedoraproject.org/wiki/SIGs > > I seem to spend much of my time working with SQL these days, and I'm > interested in both client-side tools for mucking about with SQL, and > with server-side implementations, test suites, plus the more esoteric > things like XML and object databases, SPARQL, Tutorial D, etc. > > So there'd be some overlap with the Server SIG, but there are plenty of > GUI tools as well (e.g. openoffice-base, schema visualizers, etc). > > High-level goal might be to make Fedora the best place to go for someone > trying to learn about SQL and relational databases [1], and other types > of db. > > A first step might be to gather a list of interesting open-source > database software, and then to package more of it for Fedora. I've > tried looking for such a list, but unfortunately the package database > tends to dominate my queries. > > Anyone else out there? > Interested, yes. Knowledgeable, not so much ;-) Kind regards, Jeroen van Meeuwen -kanarip From rawhide at fedoraproject.org Sat May 16 13:48:42 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Sat, 16 May 2009 13:48:42 +0000 (UTC) Subject: rawhide report: 20090516 changes Message-ID: <20090516134842.780981F821E@releng2.fedora.phx.redhat.com> Compose started at Sat May 16 06:15:04 UTC 2009 Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 0 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From schaiba at gmail.com Sat May 16 14:29:09 2009 From: schaiba at gmail.com (Aioanei Rares) Date: Sat, 16 May 2009 17:29:09 +0300 Subject: Database SIG? In-Reply-To: <1242082378.30883.73.camel@radiator.bos.redhat.com> References: <1242082378.30883.73.camel@radiator.bos.redhat.com> Message-ID: <4A0ECDB5.4020405@gmail.com> David Malcolm wrote: > Would anyone else be interested in a database special-interest-group > within Fedora? I don't see one at http://fedoraproject.org/wiki/SIGs > > I seem to spend much of my time working with SQL these days, and I'm > interested in both client-side tools for mucking about with SQL, and > with server-side implementations, test suites, plus the more esoteric > things like XML and object databases, SPARQL, Tutorial D, etc. > > So there'd be some overlap with the Server SIG, but there are plenty of > GUI tools as well (e.g. openoffice-base, schema visualizers, etc). > > High-level goal might be to make Fedora the best place to go for someone > trying to learn about SQL and relational databases [1], and other types > of db. > > A first step might be to gather a list of interesting open-source > database software, and then to package more of it for Fedora. I've > tried looking for such a list, but unfortunately the package database > tends to dominate my queries. > > Anyone else out there? > > Dave > > [1] and, indeed, the differences between the two, for any followers of > the "Third Manifesto" out there > > Way cool! From snecklifter at gmail.com Sat May 16 15:16:21 2009 From: snecklifter at gmail.com (Christopher Brown) Date: Sat, 16 May 2009 16:16:21 +0100 Subject: Database SIG? In-Reply-To: <1242082378.30883.73.camel@radiator.bos.redhat.com> References: <1242082378.30883.73.camel@radiator.bos.redhat.com> Message-ID: <364d303b0905160816p59365447wf4b82530a75d8490@mail.gmail.com> 2009/5/11 David Malcolm : > Would anyone else be interested in a database special-interest-group > within Fedora? ?I don't see one at http://fedoraproject.org/wiki/SIGs > > I seem to spend much of my time working with SQL these days, and I'm > interested in both client-side tools for mucking about with SQL, and > with server-side implementations, test suites, plus the more esoteric > things like XML and object databases, SPARQL, Tutorial D, etc. > > So there'd be some overlap with the Server SIG, but there are plenty of > GUI tools as well (e.g. openoffice-base, schema visualizers, etc). > > High-level goal might be to make Fedora the best place to go for someone > trying to learn about SQL and relational databases [1], and other types > of db. > > A first step might be to gather a list of interesting open-source > database software, and then to package more of it for Fedora. ?I've > tried looking for such a list, but unfortunately the package database > tends to dominate my queries. > > Anyone else out there? I think this is excellent timing. I'm no database guru but with my crystal ball I foresee MySQL requiring some form of attention in the near future. :) -- Christopher Brown From josef at toxicpanda.com Sat May 16 15:25:26 2009 From: josef at toxicpanda.com (Josef Bacik) Date: Sat, 16 May 2009 11:25:26 -0400 Subject: Warning for F11 BTRFS users Message-ID: <1b7401870905160825s19c6788et94b446fd5ae7f619@mail.gmail.com> Hello, Don't go to 2.6.29.3-140. Something's gone horribly wrong. I'm working on fixing it, I'll let you know when you are safe to upgrade your kernel again (all 2 other users :) ). Sorry about that, Josef From karsten at redhat.com Sat May 16 17:35:39 2009 From: karsten at redhat.com (karsten at redhat.com) Date: Sat, 16 May 2009 19:35:39 +0200 Subject: Ongoing mass rebuild on s390x Message-ID: <20090516173539.GD10645@redhat.de> Hi, Just in case you're wondering about the koji mails of your packages being rebuilt: I'm currently looping over all F-11 packages and rebuilding them on s390x, which is a secondary arch. If you have some free time and one of your packages failed to build, please check the logs and try to figure out what went wrong. If it's just a dependency problem, ignore it for now. If it is a real issue, I'd appreciate it if you could take a look at it as you as the package maintainer could most likely fix it faster than I can. Thanks ! Karsten -- Karsten Hopp GPG 1024D/70ABD02C Fingerprint D2D4 3B6B 2DE4 464C A432 210A DFF8 A140 70AB D02C Red Hat Deutschland, Hauptstaetter Str.58 70178 Stuttgart, Tel.+49-711-96437-0, Fax +49-711-96437-111 From dimi at lattica.com Sat May 16 17:37:10 2009 From: dimi at lattica.com (Dimi Paun) Date: Sat, 16 May 2009 13:37:10 -0400 Subject: Sound doesn't work, again! Message-ID: <1242495430.3022.40.camel@dimi.lattica.com> Folks, Yesterday I had to reboot -- this is highly stressful experience for me, as *every* time I do that something doesn't work, especially something to do with sound. Sure enough, I can no longer turn the sound loud enough, despite fscking around with alsamixer, and a myriad of other sliders all over the place. Guys, I am using _standard_ hardware, I am running a _standard_ F11 install. I am doing nothing special! And yet, I can not get more than 24h of reliable sound out of my system!!! Newsflash! It is 2009! Sound Just Doesn't Work (TM)! How is a regular user supposed to use this system? I have spent *tens* of hours trying to get it to work, It just doesn't! I filed bug reports, investigated, etc. Lennart is very helpful, I appreciate it. Yet, basic sound output is a _total_ nightmare: https://bugzilla.redhat.com/show_bug.cgi?id=501122 https://bugzilla.redhat.com/show_bug.cgi?id=500657 https://bugzilla.redhat.com/show_bug.cgi?id=497550 https://bugzilla.redhat.com/show_bug.cgi?id=493788 I have more Linux experience than 99.99% of all Linux users, and it managed to almost break me. Is a "normal" user to have a better experience? If so, I'd love to know how. I really do. Guys, please understand: I love all the tricks that I can do with PA. They are really neat. But they mean _zero_ if basic sound just doesn't work! Even controlling volume is a nightmare (bug 501122). Does anybody care that in AD 2009 we ship a system where getting basic sound of one's computer would make a grown man cry? -- Dimi Paun Lattica, Inc. From pbrobinson at gmail.com Sat May 16 18:23:12 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Sat, 16 May 2009 19:23:12 +0100 Subject: Ongoing mass rebuild on s390x In-Reply-To: <20090516173539.GD10645@redhat.de> References: <20090516173539.GD10645@redhat.de> Message-ID: <5256d0b0905161123m758b16c0l79fcee3662e5fd51@mail.gmail.com> > Just in case you're wondering about the koji mails of your packages being rebuilt: > > I'm currently looping over all F-11 packages and rebuilding them on s390x, which > is a secondary arch. If you have some free time and one of your packages failed > to build, please check the logs and try to figure out what went wrong. If it's > just a dependency problem, ignore it for now. If it is a real issue, I'd > appreciate it if you could take a look at it as you as the package maintainer > could most likely fix it faster than I can. Is there a way to test the builds of packages that have issues on s390x to see if in fact they are fixed? Peter From arequipeno at gmail.com Sat May 16 18:37:38 2009 From: arequipeno at gmail.com (Ian Pilcher) Date: Sat, 16 May 2009 13:37:38 -0500 Subject: Ongoing mass rebuild on s390x In-Reply-To: <5256d0b0905161123m758b16c0l79fcee3662e5fd51@mail.gmail.com> References: <20090516173539.GD10645@redhat.de> <5256d0b0905161123m758b16c0l79fcee3662e5fd51@mail.gmail.com> Message-ID: Peter Robinson wrote: > Is there a way to test the builds of packages that have issues on > s390x to see if in fact they are fixed? http://www.hercules-390.org/ -- ======================================================================== Ian Pilcher arequipeno at gmail.com ======================================================================== From karsten at redhat.com Sat May 16 18:43:27 2009 From: karsten at redhat.com (karsten at redhat.com) Date: Sat, 16 May 2009 20:43:27 +0200 Subject: Ongoing mass rebuild on s390x In-Reply-To: <20090516173539.GD10645@redhat.de> References: <20090516173539.GD10645@redhat.de> Message-ID: <20090516184326.GB31277@redhat.de> On Sat, May 16, 2009 at 07:35:39PM +0200, karsten at redhat.com wrote: > Hi, > > Just in case you're wondering about the koji mails of your packages being rebuilt: > > I'm currently looping over all F-11 packages and rebuilding them on s390x, which > is a secondary arch. If you have some free time and one of your packages failed > to build, please check the logs and try to figure out what went wrong. If it's > just a dependency problem, ignore it for now. If it is a real issue, I'd > appreciate it if you could take a look at it as you as the package maintainer > could most likely fix it faster than I can. > > Thanks ! > > Karsten > One thing I forgot to mention was how you can submit builds to s390x: koji -c ~/.koji/s390-config build dist-f11 CVS_URL or from the usual CVS checkout: SECONDARY_CONFIG=" -c ~/.koji/s390-config " make build Karsten -- Karsten Hopp GPG 1024D/70ABD02C Fingerprint D2D4 3B6B 2DE4 464C A432 210A DFF8 A140 70AB D02C Red Hat Deutschland, Hauptstaetter Str.58 70178 Stuttgart, Tel.+49-711-96437-0, Fax +49-711-96437-111 From mcepl at redhat.com Sat May 16 22:12:31 2009 From: mcepl at redhat.com (Matej Cepl) Date: Sun, 17 May 2009 00:12:31 +0200 Subject: Warning for F11 BTRFS users References: <1b7401870905160825s19c6788et94b446fd5ae7f619@mail.gmail.com> Message-ID: On 2009-05-16, 15:25 GMT, Josef Bacik wrote: > Don't go to 2.6.29.3-140. Something's gone horribly wrong. > I'm working on fixing it, I'll let you know when you are safe > to upgrade your kernel again (all 2 other users :) ). Sorry > about that, I wasn't the only one? Mat?j From dgboles at comcast.net Sat May 16 22:14:57 2009 From: dgboles at comcast.net (David) Date: Sat, 16 May 2009 18:14:57 -0400 Subject: Sound doesn't work, again! In-Reply-To: <1242495430.3022.40.camel@dimi.lattica.com> References: <1242495430.3022.40.camel@dimi.lattica.com> Message-ID: <4A0F3AE1.3090709@comcast.net> On 5/16/2009 1:37 PM, Dimi Paun wrote: > Folks, > > Yesterday I had to reboot -- this is highly stressful experience > for me, as *every* time I do that something doesn't work, especially > something to do with sound. > > Sure enough, I can no longer turn the sound loud enough, despite > fscking around with alsamixer, and a myriad of other sliders all > over the place. > > Guys, I am using _standard_ hardware, I am running a _standard_ > F11 install. I am doing nothing special! And yet, I can not get > more than 24h of reliable sound out of my system!!! > > Newsflash! It is 2009! Sound Just Doesn't Work (TM)! > > How is a regular user supposed to use this system? I have spent *tens* > of hours trying to get it to work, It just doesn't! I filed bug reports, > investigated, etc. Lennart is very helpful, I appreciate it. > Yet, basic sound output is a _total_ nightmare: > https://bugzilla.redhat.com/show_bug.cgi?id=501122 > https://bugzilla.redhat.com/show_bug.cgi?id=500657 > https://bugzilla.redhat.com/show_bug.cgi?id=497550 > https://bugzilla.redhat.com/show_bug.cgi?id=493788 > > > I have more Linux experience than 99.99% of all Linux users, and it > managed to almost break me. Is a "normal" user to have a better > experience? If so, I'd love to know how. I really do. > > Guys, please understand: I love all the tricks that I can do with PA. > They are really neat. But they mean _zero_ if basic sound just doesn't > work! Even controlling volume is a nightmare (bug 501122). > > Does anybody care that in AD 2009 we ship a system where getting basic > sound of one's computer would make a grown man cry? > "How is a regular user supposed to use this system?". Your system? Or my system. I prefer to use my system. My sound works just fine thank you. Now if you turn off the 'rant mode' and provide some more information, other than "Sound Just Doesn't Work (TM)!" I would think that several here might be more than willing to try to help you. -- David From dgboles at comcast.net Sat May 16 22:22:29 2009 From: dgboles at comcast.net (David) Date: Sat, 16 May 2009 18:22:29 -0400 Subject: Sound doesn't work, again! In-Reply-To: <4A0F3AE1.3090709@comcast.net> References: <1242495430.3022.40.camel@dimi.lattica.com> <4A0F3AE1.3090709@comcast.net> Message-ID: <4A0F3CA5.7030505@comcast.net> On 5/16/2009 6:14 PM, David wrote: > On 5/16/2009 1:37 PM, Dimi Paun wrote: >> Folks, >> >> Yesterday I had to reboot -- this is highly stressful experience >> for me, as *every* time I do that something doesn't work, especially >> something to do with sound. >> >> Sure enough, I can no longer turn the sound loud enough, despite >> fscking around with alsamixer, and a myriad of other sliders all >> over the place. >> >> Guys, I am using _standard_ hardware, I am running a _standard_ >> F11 install. I am doing nothing special! And yet, I can not get >> more than 24h of reliable sound out of my system!!! >> >> Newsflash! It is 2009! Sound Just Doesn't Work (TM)! >> >> How is a regular user supposed to use this system? I have spent *tens* >> of hours trying to get it to work, It just doesn't! I filed bug reports, >> investigated, etc. Lennart is very helpful, I appreciate it. >> Yet, basic sound output is a _total_ nightmare: >> https://bugzilla.redhat.com/show_bug.cgi?id=501122 >> https://bugzilla.redhat.com/show_bug.cgi?id=500657 >> https://bugzilla.redhat.com/show_bug.cgi?id=497550 >> https://bugzilla.redhat.com/show_bug.cgi?id=493788 >> >> >> I have more Linux experience than 99.99% of all Linux users, and it >> managed to almost break me. Is a "normal" user to have a better >> experience? If so, I'd love to know how. I really do. >> >> Guys, please understand: I love all the tricks that I can do with PA. >> They are really neat. But they mean _zero_ if basic sound just doesn't >> work! Even controlling volume is a nightmare (bug 501122). >> >> Does anybody care that in AD 2009 we ship a system where getting basic >> sound of one's computer would make a grown man cry? >> > > > "How is a regular user supposed to use this system?". Your system? Or my > system. I prefer to use my system. My sound works just fine thank you. > > Now if you turn off the 'rant mode' and provide some more information, > other than "Sound Just Doesn't Work (TM)!" I would think that several > here might be more than willing to try to help you. > Footnote to you - I should have mentioned that you should probably post this to the Fedora-Testers list fedora-test-list at redhat.com you have to enroll. -- David From dimi at lattica.com Sat May 16 23:44:27 2009 From: dimi at lattica.com (Dimi Paun) Date: Sat, 16 May 2009 19:44:27 -0400 Subject: Sound doesn't work, again! In-Reply-To: <4A0F3AE1.3090709@comcast.net> References: <1242495430.3022.40.camel@dimi.lattica.com> <4A0F3AE1.3090709@comcast.net> Message-ID: <1242517467.3022.57.camel@dimi.lattica.com> On Sat, 2009-05-16 at 18:14 -0400, David wrote: > Now if you turn off the 'rant mode' and provide some more information, > other than "Sound Just Doesn't Work (TM)!" I would think that several > here might be more than willing to try to help you. Hm, and I thought linking to 4 bugs report would provide enough of "information". But sure, let me be more clear. This morning I had to reboot. This is the result: https://bugzilla.redhat.com/show_bug.cgi?id=501122 I have reported for weeks that I can't get more than 24h of reliable sound: https://bugzilla.redhat.com/show_bug.cgi?id=500657 (I have a hard time imagining that I'm the only one experiencing this) Moreover, my comment about "How is a regular user supposed to use this system?" was reflecting the fact that we have a strange combination of volume controls and sliders that have the interesting property of allowing too little control than is required in real life, all the while being obscure and complicated with respect to what they control. (please see https://bugzilla.redhat.com/show_bug.cgi?id=501122 for info). However, this rant is about more than just bug reports. The current situation is not acceptable. I have been reporting for years that I do not have reliable sound, yet little has changed. The fact that some systems work is not indicative of reliability. It is more informative in such cases to look at systems that do _not_ work, like mine. There is a lot of emphasis placed on all sort of fancy features (like network support, etc) all the while basic sound in widely used apps like Flash and Skype having _serious_ problems. And when they are reported as such, you are told off that these are closed source apps. Rubbish. -- Dimi Paun Lattica, Inc. From kevin.kofler at chello.at Sun May 17 00:03:15 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 17 May 2009 02:03:15 +0200 Subject: Database SIG? References: <1242082378.30883.73.camel@radiator.bos.redhat.com> <364d303b0905160816p59365447wf4b82530a75d8490@mail.gmail.com> Message-ID: Christopher Brown wrote: > I think this is excellent timing. I'm no database guru but with my > crystal ball I foresee MySQL requiring some form of attention in the > near future. :) You mean with your oracle? ;-) Kevin Kofler From dgboles at comcast.net Sun May 17 00:51:52 2009 From: dgboles at comcast.net (David) Date: Sat, 16 May 2009 20:51:52 -0400 Subject: Sound doesn't work, again! In-Reply-To: <1242517467.3022.57.camel@dimi.lattica.com> References: <1242495430.3022.40.camel@dimi.lattica.com> <4A0F3AE1.3090709@comcast.net> <1242517467.3022.57.camel@dimi.lattica.com> Message-ID: <4A0F5FA8.9060302@comcast.net> On 5/16/2009 7:44 PM, Dimi Paun wrote: > On Sat, 2009-05-16 at 18:14 -0400, David wrote: >> Now if you turn off the 'rant mode' and provide some more information, >> other than "Sound Just Doesn't Work (TM)!" I would think that several >> here might be more than willing to try to help you. > > Hm, and I thought linking to 4 bugs report would provide enough > of "information". But sure, let me be more clear. > > This morning I had to reboot. This is the result: > https://bugzilla.redhat.com/show_bug.cgi?id=501122 > > I have reported for weeks that I can't get more than 24h of reliable > sound: > https://bugzilla.redhat.com/show_bug.cgi?id=500657 > (I have a hard time imagining that I'm the only one experiencing this) > > Moreover, my comment about "How is a regular user supposed to use this > system?" was reflecting the fact that we have a strange combination > of volume controls and sliders that have the interesting property of > allowing too little control than is required in real life, all the while > being obscure and complicated with respect to what they control. > (please see https://bugzilla.redhat.com/show_bug.cgi?id=501122 for > info). > > However, this rant is about more than just bug reports. The current > situation is not acceptable. I have been reporting for years that > I do not have reliable sound, yet little has changed. > > The fact that some systems work is not indicative of reliability. > It is more informative in such cases to look at systems that do _not_ > work, like mine. There is a lot of emphasis placed on all sort > of fancy features (like network support, etc) all the while basic > sound in widely used apps like Flash and Skype having _serious_ > problems. And when they are reported as such, you are told off that > these are closed source apps. Rubbish. 1) Your oldest bug is about three weeks old. The other three are three days old. The oldest bug did receive attention but I do not believe that you supplied the requested information from what I read. 2) In that oldest bug you said that you have a pre-release of Fedora 11, which would be the development branch known ad Rawhide, running on your production machine. That does not make good sense. Might I suggest that you install a release version of Fedora. I would suggest Fedora 10 as Fedora 9 will EOL in a little over a month? that way your production machine can still do it's job and you can have more time to research your problem. I say 'your problem' because it also appears that no one else has this problem. At least not that I can see. Good luck. -- David From ivazqueznet at gmail.com Sun May 17 02:14:38 2009 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sat, 16 May 2009 22:14:38 -0400 Subject: Ongoing mass rebuild on s390x In-Reply-To: References: <20090516173539.GD10645@redhat.de> <5256d0b0905161123m758b16c0l79fcee3662e5fd51@mail.gmail.com> Message-ID: <1242526478.9875.129.camel@ignacio.ignacio.lan> On Sat, 2009-05-16 at 13:37 -0500, Ian Pilcher wrote: > Peter Robinson wrote: > > Is there a way to test the builds of packages that have issues on > > s390x to see if in fact they are fixed? > > http://www.hercules-390.org/ I remember trying to wrap my head around Hercules a while back and not having any luck whatsoever simply because I'm not a mainframe guy. Is there any way to get a sane base config usable for Fedora testing, along with basic instructions? -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From oget.fedora at gmail.com Sun May 17 02:20:28 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Sat, 16 May 2009 22:20:28 -0400 Subject: FESco meeting summary for 20090507 In-Reply-To: <4A0608EA.6010700@fi.muni.cz> References: <4A05BF03.6070508@fi.muni.cz> <1241891561.9577.3.camel@localhost.localdomain> <4A05D17C.8030305@gmail.com> <4A0608EA.6010700@fi.muni.cz> Message-ID: On Sat, May 9, 2009 at 6:51 PM, Milos Jakubicek wrote: > I'd take over the following packages -- provided the current comaintainers > are not interested in becoming primary maintainers, of course! > ... > lzma ... >From what I understand, lzma is being replaced by xz by its upstream: http://tukaani.org/xz/ Do you have any intention to package xz? Orcan From dtimms at iinet.net.au Sun May 17 02:43:48 2009 From: dtimms at iinet.net.au (David Timms) Date: Sun, 17 May 2009 12:43:48 +1000 Subject: yum upgrade v anaconda upgrade differences Message-ID: <4A0F79E4.2040003@iinet.net.au> On the yum list a question was asked which intrigued me: Why can anaconda manage to upgrade a system, when yum upgrade can't. The postulation was that anaconda is cheating (ie running --nodeps installs). This would allow it to complete an upgrade where dependencies lead to unavailable packages that are not on the dvd, but are in the complete Fedora, and or non- fedora repositories, that are not available at upgrade time. Is that why it can work ? Or what are essential differences between an anaconda upgrade and yum upgrade ? DaveT. From abo at stacken.kth.se Sun May 17 05:22:31 2009 From: abo at stacken.kth.se (=?ISO-8859-1?Q?Alexander_Bostr=F6m?=) Date: Sun, 17 May 2009 07:22:31 +0200 Subject: Sound doesn't work, again! In-Reply-To: <4A0F5FA8.9060302@comcast.net> References: <1242495430.3022.40.camel@dimi.lattica.com> <4A0F3AE1.3090709@comcast.net> <1242517467.3022.57.camel@dimi.lattica.com> <4A0F5FA8.9060302@comcast.net> Message-ID: <4A0F9F17.1090209@stacken.kth.se> David skrev: > Might I suggest that you install a release version of Fedora. I would > suggest Fedora 10 as Fedora 9 will EOL in a little over a month? We (the community) want people to test pre-releases and rawhide and to file bugs. There's certainly no community benefit to anyone downgrading to a release. But yes, fedora-test is probably a better list to post to. /abo From dimi at lattica.com Sun May 17 06:35:14 2009 From: dimi at lattica.com (Dimi Paun) Date: Sun, 17 May 2009 02:35:14 -0400 Subject: Sound doesn't work, again! In-Reply-To: <4A0F5FA8.9060302@comcast.net> References: <1242495430.3022.40.camel@dimi.lattica.com> <4A0F3AE1.3090709@comcast.net> <1242517467.3022.57.camel@dimi.lattica.com> <4A0F5FA8.9060302@comcast.net> Message-ID: <1242542114.3022.78.camel@dimi.lattica.com> On Sat, 2009-05-16 at 20:51 -0400, David wrote: > 1) Your oldest bug is about three weeks old. The other three are three > days old. The oldest bug did receive attention but I do not believe > that you supplied the requested information from what I read. It's really not helpful to tell me when I filed the latest bugs. I've been using RedHat/Fedora Linux since about '96 exclusively on all my boxes, so you can imagine that there's a lot more to this than the last batch of bugs that I reported. > 2) In that oldest bug you said that you have a pre-release of Fedora > 11, which would be the development branch known ad Rawhide, running on > your production machine. That does not make good sense. Well, it does. I've said over and over on this list that ever since F3, I had horrible trouble with sound, to the point that I gave up on it for years -- it was just too frustrating to have to deal with it breaking every few days for no apparent reason. I used to run F8 until recently, with PA giving me no end of trouble. I could _not_ upgrade to either F9 or F10 due to a very serious bug in Anaconda/dmraid: https://bugzilla.redhat.com/show_bug.cgi?id=468649 (essentially you could not install on a RAID 1 partition). Out of insane frustration with the sound, I decided to try the F11 Beta, being the first Fedora since F8 (!) that would install on a BIOS RAID 1 disk (is that such a rare setup I wonder?) This was a bit better than F8 in terms of PA crashing like crazy after 1-3h of use, but right of the bat I had troubles: https://bugzilla.redhat.com/show_bug.cgi?id=493790 https://bugzilla.redhat.com/show_bug.cgi?id=493788 https://bugzilla.redhat.com/show_bug.cgi?id=498094 > Might I suggest that you install a release version of Fedora. I would > suggest Fedora 10 as Fedora 9 will EOL in a little over a month? that > way your production machine can still do it's job and you can have > more time to research your problem. This is sending me on a wild goose chase. I know that sound sucked _badly_ in F8, F9/10 is out of the question, and besides, the problems that I am having will not be fixed by me moving off of F11. Look, I know I'm frustrated. You would be too when you - run bog-standard hardware - run non-patched, as pristine as possible version of Fedora - you spend ~1h almost daily to get sound out of Flash, Skype, Rhythmbox, etc, sound that you just fixed, and it stopped working out of the blue. Almost daily! But the bottom line is that I am a old timer when it comes to Linux, and an experience hacker to boot. I'm easily in the top 1% of technical users. If this drove me insane, how would a non-technical user feel? The big problem is that instead of this giving the community pause (OK, the guy maybe grumpy and frustrated, but we might have a genuine problem on our hands), I am given condescending advice that would put me on a sterile goose chase. Guys, I'm one of the people that stuck around and helped. Do you honestly think Fedora would be any better if it drove me away? -- Dimi Paun Lattica, Inc. From bochecha at fedoraproject.org Sun May 17 07:06:39 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Sun, 17 May 2009 09:06:39 +0200 Subject: Sound doesn't work, again! In-Reply-To: <1242542114.3022.78.camel@dimi.lattica.com> References: <1242495430.3022.40.camel@dimi.lattica.com> <4A0F3AE1.3090709@comcast.net> <1242517467.3022.57.camel@dimi.lattica.com> <4A0F5FA8.9060302@comcast.net> <1242542114.3022.78.camel@dimi.lattica.com> Message-ID: <2d319b780905170006q53a29001wcc6348af93b561cc@mail.gmail.com> > ?- you spend ~1h almost daily to get sound out of Flash, Skype, > ? ?Rhythmbox, etc, sound that you just fixed, and it stopped > ? ?working out of the blue. Almost daily! Does it break after an update ? If so, it could be that you modified a config file that is not marked ? noreplace ? in the spec file, and so your modifications are overwritten. Either the place you made the modifications are not the good place, or the package should be fixed as this should indeed be a ? noreplace ? file, or maybe you should send your modifications to those files in a bug report so that they are integrated in the source... This is the case fot the file ? /lib/alsa/init/hda ? for example. I modified it based on some instructions from Lennart and Adam so that my sound wouldn't be too faint at startup. But at the first update, this file got replaced (which seems to be normal), but I had sent my modifications to the devs so that they could integrate them (and in fact, it wasn't necessary any more after an other bug was fixed :). Also, if it breaks only after a reboot (i.e. with no updates), then forget about what I said :) ---------- Mathieu Bridon (bochecha) From denis at poolshark.org Sun May 17 07:50:01 2009 From: denis at poolshark.org (Denis Leroy) Date: Sun, 17 May 2009 09:50:01 +0200 Subject: Sound doesn't work, again! In-Reply-To: <1242542114.3022.78.camel@dimi.lattica.com> References: <1242495430.3022.40.camel@dimi.lattica.com> <4A0F3AE1.3090709@comcast.net> <1242517467.3022.57.camel@dimi.lattica.com> <4A0F5FA8.9060302@comcast.net> <1242542114.3022.78.camel@dimi.lattica.com> Message-ID: <4A0FC1A9.2060805@poolshark.org> On 05/17/2009 08:35 AM, Dimi Paun wrote: > Well, it does. I've said over and over on this list that ever since F3, > I had horrible trouble with sound, to the point that I gave up on it for > years -- it was just too frustrating to have to deal with it breaking > every few days for no apparent reason. Sounds like some paranormal Curse of some sort. Seriously though, does sound work from the F-11 live CD ? From hughsient at gmail.com Sun May 17 08:14:03 2009 From: hughsient at gmail.com (Richard Hughes) Date: Sun, 17 May 2009 09:14:03 +0100 Subject: PolicyKit changes in F12 In-Reply-To: <20090516075614.GU1589@redhat.com> References: <1242262846.9432.9.camel@localhost.localdomain> <20090516075614.GU1589@redhat.com> Message-ID: <15e53e180905170114h2cfdb70q1727160a2cb75a9b@mail.gmail.com> On Sat, May 16, 2009 at 8:56 AM, Daniel Veillard wrote: > ?? No kit_* OOM handling in the new library > means ? The old kit_* functions used to handle OOM (out of memory conditions) and report back the correct error. The new library is more GLib like, and doesn't handle OOM very well at all. It's likely you didn't care about OOM before, so this change won't affect you. Richard. From dgboles at comcast.net Sun May 17 12:29:58 2009 From: dgboles at comcast.net (David) Date: Sun, 17 May 2009 08:29:58 -0400 Subject: Sound doesn't work, again! In-Reply-To: <4A0F9F17.1090209@stacken.kth.se> References: <1242495430.3022.40.camel@dimi.lattica.com> <4A0F3AE1.3090709@comcast.net> <1242517467.3022.57.camel@dimi.lattica.com> <4A0F5FA8.9060302@comcast.net> <4A0F9F17.1090209@stacken.kth.se> Message-ID: <4A100346.20400@comcast.net> On 5/17/2009 1:22 AM, Alexander Bostr?m wrote: > David skrev: > >> Might I suggest that you install a release version of Fedora. I would >> suggest Fedora 10 as Fedora 9 will EOL in a little over a month? > > We (the community) want people to test pre-releases and rawhide and to > file bugs. There's certainly no community benefit to anyone downgrading > to a release. > > But yes, fedora-test is probably a better list to post to. I agree with the testing 100%. However he said that this was a necessary, production, machine. http://fedoraproject.org/wiki/Releases/Rawhide " Who should use Rawhide? No-one should use Rawhide as their main day-to-day workstation. As Rawhide is a development branch, many changes are not heavily tested (or tested at all) before being released to Rawhide, and packages in Rawhide can and do break without warning. It is even possible that bugs in Rawhide could cause data loss. However, testing Rawhide is a very valuable activity which helps to direct Fedora development and ensure the quality of stable releases is high. It's also a fun way to try out the latest software almost as soon as it comes out. If you have a spare system, or are willing to install Rawhide to spare space on an existing system and dual boot, or use a virtual machine, testing Rawhide is a great way to contribute to Fedora development." But many still do. -- David From skvidal at fedoraproject.org Sun May 17 14:07:18 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Sun, 17 May 2009 10:07:18 -0400 (EDT) Subject: yum upgrade v anaconda upgrade differences In-Reply-To: <4A0F79E4.2040003@iinet.net.au> References: <4A0F79E4.2040003@iinet.net.au> Message-ID: On Sun, 17 May 2009, David Timms wrote: > On the yum list a question was asked which intrigued me: > Why can anaconda manage to upgrade a system, when yum upgrade can't. > > The postulation was that anaconda is cheating (ie running --nodeps installs). > This would allow it to complete an upgrade where dependencies lead to > unavailable packages that are not on the dvd, but are in the complete Fedora, > and or non- fedora repositories, that are not available at upgrade time. > > Is that why it can work ? > Or what are essential differences between an anaconda upgrade and yum upgrade > ? anaconda is also running outside of the system you're trying to update - it doesn't have to worry about making its own environment entirely unusable. So it can do things like --nodeps w/o a concern for not being able to complete the transaction. Finally anaconda uses a whiteout/blacklist info to be able to force certain things out of the transaction. preupgrade uses those, now, via a yum plugin. -sv From naheemzaffar at gmail.com Sun May 17 14:43:15 2009 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Sun, 17 May 2009 15:43:15 +0100 Subject: Sound doesn't work, again! In-Reply-To: <4A100346.20400@comcast.net> References: <1242495430.3022.40.camel@dimi.lattica.com> <4A0F3AE1.3090709@comcast.net> <1242517467.3022.57.camel@dimi.lattica.com> <4A0F5FA8.9060302@comcast.net> <4A0F9F17.1090209@stacken.kth.se> <4A100346.20400@comcast.net> Message-ID: <3adc77210905170743k3e640fabx2c0b6b3f957b2cf2@mail.gmail.com> 2009/5/17 David > I agree with the testing 100%. However he said that this was a > necessary, production, machine. > > > http://fedoraproject.org/wiki/Releases/Rawhide > > " Who should use Rawhide? > > No-one should use Rawhide as their main day-to-day workstation. As > Rawhide is a development branch, many changes are not heavily tested (or > tested at all) before being released to Rawhide, and packages in Rawhide > can and do break without warning. It is even possible that bugs in > Rawhide could cause data loss. However, testing Rawhide is a very > valuable activity which helps to direct Fedora development and ensure > the quality of stable releases is high. It's also a fun way to try out > the latest software almost as soon as it comes out. If you have a spare > system, or are willing to install Rawhide to spare space on an existing > system and dual boot, or use a virtual machine, testing Rawhide is a > great way to contribute to Fedora development." > > > But many still do. I would think that "frozen" rawhid just before a release is a different matter - if no serious bugs are reported in the software, that is the software that will make it into a final release. Rawhide a few months ago/a few months from now and today are IMO two different beasts. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rawhide at fedoraproject.org Sun May 17 14:59:02 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Sun, 17 May 2009 14:59:02 +0000 (UTC) Subject: rawhide report: 20090517 changes Message-ID: <20090517145903.162E51F8216@releng2.fedora.phx.redhat.com> Compose started at Sun May 17 06:15:07 UTC 2009 Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 0 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From dgboles at comcast.net Sun May 17 15:09:23 2009 From: dgboles at comcast.net (David) Date: Sun, 17 May 2009 11:09:23 -0400 Subject: Sound doesn't work, again! In-Reply-To: <3adc77210905170743k3e640fabx2c0b6b3f957b2cf2@mail.gmail.com> References: <1242495430.3022.40.camel@dimi.lattica.com> <4A0F3AE1.3090709@comcast.net> <1242517467.3022.57.camel@dimi.lattica.com> <4A0F5FA8.9060302@comcast.net> <4A0F9F17.1090209@stacken.kth.se> <4A100346.20400@comcast.net> <3adc77210905170743k3e640fabx2c0b6b3f957b2cf2@mail.gmail.com> Message-ID: <4A1028A3.6080202@comcast.net> On 5/17/2009 10:43 AM, Naheem Zaffar wrote: > > > 2009/5/17 David > > > I agree with the testing 100%. However he said that this was a > necessary, production, machine. > > > http://fedoraproject.org/wiki/Releases/Rawhide > > " Who should use Rawhide? > > No-one should use Rawhide as their main day-to-day workstation. As > Rawhide is a development branch, many changes are not heavily tested (or > tested at all) before being released to Rawhide, and packages in Rawhide > can and do break without warning. It is even possible that bugs in > Rawhide could cause data loss. However, testing Rawhide is a very > valuable activity which helps to direct Fedora development and ensure > the quality of stable releases is high. It's also a fun way to try out > the latest software almost as soon as it comes out. If you have a spare > system, or are willing to install Rawhide to spare space on an existing > system and dual boot, or use a virtual machine, testing Rawhide is a > great way to contribute to Fedora development." > > > But many still do. > > > I would think that "frozen" rawhid just before a release is a different > matter - if no serious bugs are reported in the software, that is the > software that will make it into a final release. > > Rawhide a few months ago/a few months from now and today are IMO two > different beasts. > Final Freeze Policy http://fedoraproject.org/wiki/ReleaseEngineering/FinalFreezePolicy This "frozen" rawhide" (future F-11) that you speak of is still getting daily updates. Or it was. The latest / last(?) ones where on Fri May 15. You are still updating aren't you? I use Rawhide on a day to day basis. However I also have the latest release installed, kept up to date, should Rawhide have a problem. Which it does from time to time but not too often. So no I still do not think it is wise to run Rawhide or a beta of it on a critical machine. User's choice. If it breaks the user gets to keep the pieces. -- David From davidz at redhat.com Sun May 17 15:24:29 2009 From: davidz at redhat.com (David Zeuthen) Date: Sun, 17 May 2009 11:24:29 -0400 Subject: PolicyKit changes in F12 In-Reply-To: <20090516075614.GU1589@redhat.com> References: <1242262846.9432.9.camel@localhost.localdomain> <20090516075614.GU1589@redhat.com> Message-ID: <1242573869.4508.10.camel@localhost.localdomain> On Sat, 2009-05-16 at 09:56 +0200, Daniel Veillard wrote: > On Wed, May 13, 2009 at 09:00:46PM -0400, Matthias Clasen wrote: > > Just a heads-up: > > > > We hope to land a new PolicyKit version (which will turn into 1.0, > > eventually) in F12 soon. The new version simplifies the API and will > > require PolicyKit-using application to be ported. For more information, > > have a look at the feature page: > > > > http://fedoraproject.org/wiki/Features/PolicyKitOne > > > > It also has pointers to api docs and a (terse) porting guide. We already > > have a collection of patches for quite a few PolicyKit-using apps, so > > the transitions should be relatively painless. > > http://cgit.freedesktop.org/PolicyKit/tree/docs/PORTING-GUIDE > > doesn't uindicate how to discriminate at compile time which version > we are compiling against. Please indictate in the porting doc how to > detect the installed version in configure. That's the bare minimum > when you're changing APIs in that way. We obviously need libvirt to > handle older and newer versions ! For testing availability, PolicyKit 0.9.x provides polkit.pc, the new version provides polkit-gobject-1.pc that you can use to test for. > Also what does > ? No kit_* OOM handling in the new library > means ? The client side library now uses GObject and the policy there is to abort() on OOM. If you don't like this, you can use either the D-Bus interface of the PolicyKit daemon or call out to a helper program (not yet written, but it's simple) to check the authorization. Note that the model in the new PolicyKit release is a lot simpler - you now only need PolicyKit support in the actual privileged mechanism that needs to check for authorization. E.g. the client (virt-manager in this case) does not really need to know anything about PolicyKit - the authentication dialogs are popped up automatically if the mechanism passes ALLOW_USER_INTERACTION when checking whether the client calling into your mechanism is authorized for some action. So, for the libvirt daemon, where I believe you do care about handling OOM, the easiest thing is probably to just use the helper program to check for authorizations. Just easier all around and less foreign code polluting your process. Anyway, I'll make sure there are sufficient docs to make this transition as simple as possible. David From mail at robertoragusa.it Sun May 17 15:37:17 2009 From: mail at robertoragusa.it (Roberto Ragusa) Date: Sun, 17 May 2009 17:37:17 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <20090515001432.GB1148000@hiwaay.net> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A0C99A5.1040401@cygnusx-1.org> <4A0C9D2A.2070601@cygnusx-1.org> <20090515001432.GB1148000@hiwaay.net> Message-ID: <4A102F2D.3070809@robertoragusa.it> Chris Adams wrote: > I'd have to say my laptop has a lot more "interesting" hardware than my > desktops. Hot-swap card slots, built-in memory card reader (PCI > connected, not USB), hot swap drive bay, Bluetooth, wireless, multiple > pointer devices, special keyboard keys like volume control, etc. On the other hand, laptops are typically single-everything, while desktop (and servers still more) are multi-everything. One CD/DVD unit. One hard disk. One screen. One keyboard. One ethernet. One wireless. One user. (!!!) The annoying issues in recent Fedora are mostly related to things beyond the laptop world: RAID, LVM, multinetwork setup and all the "but I'm not logged in the console" and "but I'm not the only user" problems (NetworkManager, pulseaudio, hal, dbus, permissions and policies,...). For example, the "I have two sound cards and a lineout goes in a linein, how can I control the volume" issue can not be anticipated if one automatically thinks always about laptops. Fedora is (incorrectly) blamed to be the "beta" of RHEL. Considering all the "laptop dragged from one Starbucks to another" (credits to the guy inventing this denomination) infrastructure there is now in Fedora, I'm really curious to see how the next RHEL will be shaped (KMS?! NetworkManager?!). -- Roberto Ragusa mail at robertoragusa.it From adel.safi at imag.fr Sun May 17 15:52:05 2009 From: adel.safi at imag.fr (Adel ESSAFI) Date: Sun, 17 May 2009 16:52:05 +0100 Subject: easycap video adapter In-Reply-To: References: Message-ID: Hi I have downloaded the stk driver and when trying to install the driver I get this error. Can you help please. Regards Adel [adel at localhost stk11xx-2.1.0]$ make -f Makefile.standalone cleandoc Removing documentation generated by Doxygen... [adel at localhost stk11xx-2.1.0]$ make -f Makefile.standalone make -C /lib/modules/2.6.27.21-170.2.56.fc10.i686/build SUBDIRS=/home/adel/Desktop/stk11xx-2.1.0 modules make[1]: Entering directory `/usr/src/kernels/2.6.27.21-170.2.56.fc10.i686' CC [M] /home/adel/Desktop/stk11xx-2.1.0/stk11xx-usb.o CC [M] /home/adel/Desktop/stk11xx-2.1.0/stk11xx-v4l.o /home/adel/Desktop/stk11xx-2.1.0/stk11xx-v4l.c: In function ?v4l_stk11xx_ioctl?: /home/adel/Desktop/stk11xx-2.1.0/stk11xx-v4l.c:1662: warning: passing argument 1 of ?video_usercopy? from incompatible pointer type /home/adel/Desktop/stk11xx-2.1.0/stk11xx-v4l.c:1662: warning: passing argument 2 of ?video_usercopy? makes pointer from integer without a cast /home/adel/Desktop/stk11xx-2.1.0/stk11xx-v4l.c:1662: warning: passing argument 4 of ?video_usercopy? makes integer from pointer without a cast /home/adel/Desktop/stk11xx-2.1.0/stk11xx-v4l.c:1662: error: too few arguments to function ?video_usercopy? /home/adel/Desktop/stk11xx-2.1.0/stk11xx-v4l.c: In function ?v4l_stk11xx_register_video_device?: /home/adel/Desktop/stk11xx-2.1.0/stk11xx-v4l.c:1686: warning: assignment from incompatible pointer type /home/adel/Desktop/stk11xx-2.1.0/stk11xx-v4l.c: At top level: 2009/5/5 Benjam?n Valero Espinosa > 2009/5/5 Adel ESSAFI > >> I have an easycap video adapter. When plugged on linux, the system >> detects it but I am still not able ti use it (with cheese or mogulus). >> when I di lsusb, I get this entry. >> >> [adel at localhost ~]$ lsusb >> Bus 002 Device 005: ID 05e1:0408 Syntek Semiconductor Co., Ltd >> >> Can you help please? >> > > Nowadays there is no easy way to make it work. There is a driver in > development for Syntek webcams [1], and a patch to do this driver work with > the EasyCap video adapter [2]. In [3] you can find instructions to make it > work (in Ubuntu and in Spanish, but it is better than nothing). > > For me it works, although I am still trying to capture video and audio at > once with mencoder (I get a strange floating point exception), because > gstreamer is a little slower in that task. Whatever I can help, you got my > email. > > Benja > > [1] http://syntekdriver.sourceforge.net/ > [2] > https://sourceforge.net/forum/forum.php?thread_id=2803299&forum_id=616182 > [3] http://crysol.org/es/node/1103 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://ilovefedora.blogspot.com/ -- PhD candidate in Computer Science Address BP 108, Bureau de poste Tunis republique 1001 Tunis Tunisia tel: +216 97 246 706 fax: +216 71 391 166 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adelessafi at gmail.com Sun May 17 15:56:46 2009 From: adelessafi at gmail.com (Adel ESSAFI) Date: Sun, 17 May 2009 16:56:46 +0100 Subject: easycap video adapter In-Reply-To: References: Message-ID: Hi I have downloaded the stk driver and when trying to install the driver I get this error. Can you help please. Regards Adel [adel at localhost stk11xx-2.1.0]$ make -f Makefile.standalone cleandoc Removing documentation generated by Doxygen... [adel at localhost stk11xx-2.1.0]$ make -f Makefile.standalone make -C /lib/modules/2.6.27.21-170.2.56.fc10.i686/build SUBDIRS=/home/adel/Desktop/stk11xx-2.1.0 modules make[1]: Entering directory `/usr/src/kernels/2.6.27.21-170.2.56.fc10.i686' CC [M] /home/adel/Desktop/stk11xx-2.1.0/stk11xx-usb.o CC [M] /home/adel/Desktop/stk11xx-2.1.0/stk11xx-v4l.o /home/adel/Desktop/stk11xx-2.1.0/stk11xx-v4l.c: In function ?v4l_stk11xx_ioctl?: /home/adel/Desktop/stk11xx-2.1.0/stk11xx-v4l.c:1662: warning: passing argument 1 of ?video_usercopy? from incompatible pointer type /home/adel/Desktop/stk11xx-2.1.0/stk11xx-v4l.c:1662: warning: passing argument 2 of ?video_usercopy? makes pointer from integer without a cast /home/adel/Desktop/stk11xx-2.1.0/stk11xx-v4l.c:1662: warning: passing argument 4 of ?video_usercopy? makes integer from pointer without a cast /home/adel/Desktop/stk11xx-2.1.0/stk11xx-v4l.c:1662: error: too few arguments to function ?video_usercopy? /home/adel/Desktop/stk11xx-2.1.0/stk11xx-v4l.c: In function ?v4l_stk11xx_register_video_device?: /home/adel/Desktop/stk11xx-2.1.0/stk11xx-v4l.c:1686: warning: assignment from incompatible pointer type /home/adel/Desktop/stk11xx-2.1.0/stk11xx-v4l.c: At top level: 2009/5/5 Benjam?n Valero Espinosa > 2009/5/5 Adel ESSAFI > >> I have an easycap video adapter. When plugged on linux, the system >> detects it but I am still not able ti use it (with cheese or mogulus). >> when I di lsusb, I get this entry. >> >> [adel at localhost ~]$ lsusb >> Bus 002 Device 005: ID 05e1:0408 Syntek Semiconductor Co., Ltd >> >> Can you help please? >> > > Nowadays there is no easy way to make it work. There is a driver in > development for Syntek webcams [1], and a patch to do this driver work with > the EasyCap video adapter [2]. In [3] you can find instructions to make it > work (in Ubuntu and in Spanish, but it is better than nothing). > > For me it works, although I am still trying to capture video and audio at > once with mencoder (I get a strange floating point exception), because > gstreamer is a little slower in that task. Whatever I can help, you got my > email. > > Benja > > [1] http://syntekdriver.sourceforge.net/ > [2] > https://sourceforge.net/forum/forum.php?thread_id=2803299&forum_id=616182 > [3] http://crysol.org/es/node/1103 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://ilovefedora.blogspot.com/ -- PhD candidate in Computer Science Address BP 108, Bureau de poste Tunis republique 1001 Tunis Tunisia tel: +216 97 246 706 fax: +216 71 391 166 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschmidt at redhat.com Sun May 17 16:36:16 2009 From: mschmidt at redhat.com (Michal Schmidt) Date: Sun, 17 May 2009 18:36:16 +0200 Subject: easycap video adapter In-Reply-To: References: Message-ID: <20090517183616.09671fbf@hammerfall> Dne Sun, 17 May 2009 16:52:05 +0100 Adel ESSAFI napsal(a): > Hi > I have downloaded the stk driver and when trying to install the > driver I get this error. > > Can you help please. > > Regards > > Adel > > [adel at localhost stk11xx-2.1.0]$ make -f Makefile.standalone cleandoc > Removing documentation generated by Doxygen... > [adel at localhost stk11xx-2.1.0]$ make -f Makefile.standalone > make -C /lib/modules/2.6.27.21-170.2.56.fc10.i686/build > SUBDIRS=/home/adel/Desktop/stk11xx-2.1.0 modules > make[1]: Entering directory > `/usr/src/kernels/2.6.27.21-170.2.56.fc10.i686' CC > [M] /home/adel/Desktop/stk11xx-2.1.0/stk11xx-usb.o CC > [M] /home/adel/Desktop/stk11xx-2.1.0/stk11xx-v4l.o /home/adel/Desktop/stk11xx-2.1.0/stk11xx-v4l.c: > In function ?v4l_stk11xx_ioctl?: > /home/adel/Desktop/stk11xx-2.1.0/stk11xx-v4l.c:1662: warning: passing > argument 1 of ?video_usercopy? from incompatible pointer type > /home/adel/Desktop/stk11xx-2.1.0/stk11xx-v4l.c:1662: warning: passing > argument 2 of ?video_usercopy? makes pointer from integer without a > cast /home/adel/Desktop/stk11xx-2.1.0/stk11xx-v4l.c:1662: warning: > passing argument 4 of ?video_usercopy? makes integer from pointer > without a cast /home/adel/Desktop/stk11xx-2.1.0/stk11xx-v4l.c:1662: > error: too few arguments to function ?video_usercopy? > /home/adel/Desktop/stk11xx-2.1.0/stk11xx-v4l.c: In function > ?v4l_stk11xx_register_video_device?: > /home/adel/Desktop/stk11xx-2.1.0/stk11xx-v4l.c:1686: warning: > assignment from incompatible pointer type > /home/adel/Desktop/stk11xx-2.1.0/stk11xx-v4l.c: At top level: The error indicates the driver you downloaded is for an older kernel version. There was an in-kernel API change and the driver needs to be updated. Solving this is off-topic for fedora-devel list. Michal From mschmidt at redhat.com Sun May 17 16:42:16 2009 From: mschmidt at redhat.com (Michal Schmidt) Date: Sun, 17 May 2009 18:42:16 +0200 Subject: easycap video adapter In-Reply-To: <20090517183616.09671fbf@hammerfall> References: <20090517183616.09671fbf@hammerfall> Message-ID: <20090517184216.6107f160@hammerfall> Dne Sun, 17 May 2009 18:36:16 +0200 Michal Schmidt napsal(a): > The error indicates the driver you downloaded is for an older kernel > version. There was an in-kernel API change and the driver needs to be > updated. Actually it's the other way around. The driver is for a _newer_ kernel. > Solving this is off-topic for fedora-devel list. This is still true. > Michal From dan at danny.cz Sun May 17 16:42:25 2009 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Sun, 17 May 2009 18:42:25 +0200 Subject: Ongoing mass rebuild on s390x In-Reply-To: <1242526478.9875.129.camel@ignacio.ignacio.lan> References: <20090516173539.GD10645@redhat.de> <5256d0b0905161123m758b16c0l79fcee3662e5fd51@mail.gmail.com> <1242526478.9875.129.camel@ignacio.ignacio.lan> Message-ID: <1242578545.3716.35.camel@eagle.danny.cz> Ignacio Vazquez-Abrams p??e v So 16. 05. 2009 v 22:14 -0400: > On Sat, 2009-05-16 at 13:37 -0500, Ian Pilcher wrote: > > Peter Robinson wrote: > > > Is there a way to test the builds of packages that have issues on > > > s390x to see if in fact they are fixed? > > > > http://www.hercules-390.org/ > > I remember trying to wrap my head around Hercules a while back and not > having any luck whatsoever simply because I'm not a mainframe guy. Is > there any way to get a sane base config usable for Fedora testing, along > with basic instructions? You can find my presentation about Hercules and config+kernel+initrd ready to start an installation at http://sharkcz.fedorapeople.org/hercules/ The system to be installed is CentOS 4, but the same config works for RHEL 5 and I expect that it will be useful also for Fedora. Dan From abo at stacken.kth.se Sun May 17 16:44:58 2009 From: abo at stacken.kth.se (=?ISO-8859-1?Q?Alexander_Bostr=F6m?=) Date: Sun, 17 May 2009 18:44:58 +0200 Subject: Sound doesn't work, again! In-Reply-To: <4A1028A3.6080202@comcast.net> References: <1242495430.3022.40.camel@dimi.lattica.com> <4A0F3AE1.3090709@comcast.net> <1242517467.3022.57.camel@dimi.lattica.com> <4A0F5FA8.9060302@comcast.net> <4A0F9F17.1090209@stacken.kth.se> <4A100346.20400@comcast.net> <3adc77210905170743k3e640fabx2c0b6b3f957b2cf2@mail.gmail.com> <4A1028A3.6080202@comcast.net> Message-ID: <4A103F0A.9080203@stacken.kth.se> David skrev: > User's choice. If it breaks the user gets to keep the pieces. Yes. And when it does break and when the user writes a thorough useful bug report(*), then we thank them for it and encourage them to continue doing so. Especially when it's only a couple of weeks until the next release. /abo *) I haven't actually looked at the linked bug reports, so I can't judge the quality of those. From dgboles at comcast.net Sun May 17 17:31:18 2009 From: dgboles at comcast.net (David) Date: Sun, 17 May 2009 13:31:18 -0400 Subject: Sound doesn't work, again! In-Reply-To: <4A103F0A.9080203@stacken.kth.se> References: <1242495430.3022.40.camel@dimi.lattica.com> <4A0F3AE1.3090709@comcast.net> <1242517467.3022.57.camel@dimi.lattica.com> <4A0F5FA8.9060302@comcast.net> <4A0F9F17.1090209@stacken.kth.se> <4A100346.20400@comcast.net> <3adc77210905170743k3e640fabx2c0b6b3f957b2cf2@mail.gmail.com> <4A1028A3.6080202@comcast.net> <4A103F0A.9080203@stacken.kth.se> Message-ID: <4A1049E6.40207@comcast.net> On 5/17/2009 12:44 PM, Alexander Bostr?m wrote: > David skrev: > >> User's choice. If it breaks the user gets to keep the pieces. > > Yes. > > And when it does break and when the user writes a thorough useful bug > report(*), then we thank them for it and encourage them to continue > doing so. Especially when it's only a couple of weeks until the next > release. > > /abo > > *) I haven't actually looked at the linked bug reports, so I can't judge > the quality of those. > Okay I'll try again. I am happy that the OP is using Fedora and has for a long time. I am happy that he is testing / trying the Rawhide that will be Fedora 11. I am sorry that he has this problem. Itis good that he reported it and posted it to bugzilla. Okay? But I wish, for his sake, that he was not having this problem on his production machine because *I still think Rawhide on a critical, must have machine is not a good idea.* Users should run Rawhide on non critical machines like the instructions / suggestions plainly say. Or have a duel boot such as I do. Have a great day. -- David From jkeating at redhat.com Sun May 17 17:37:36 2009 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 17 May 2009 10:37:36 -0700 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A102F2D.3070809@robertoragusa.it> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A0C99A5.1040401@cygnusx-1.org> <4A0C9D2A.2070601@cygnusx-1.org> <20090515001432.GB1148000@hiwaay.net> <4A102F2D.3070809@robertoragusa.it> Message-ID: <1242581856.3223.24.camel@localhost.localdomain> On Sun, 2009-05-17 at 17:37 +0200, Roberto Ragusa wrote: > On the other hand, laptops are typically single-everything, while > desktop > (and servers still more) are multi-everything. > > One CD/DVD unit. > One hard disk. > One screen. > One keyboard. > One ethernet. > One wireless. > One user. (!!!) This is all pretty far from the truth. Regularly laptops have USB peripherals plugged in, such as a second optical drive, one or more external harddrives, second or third screens, keyboards and mice, ethernet and wireless devices, as well as user switching between family members. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dimi at lattica.com Sun May 17 18:15:27 2009 From: dimi at lattica.com (Dimi Paun) Date: Sun, 17 May 2009 14:15:27 -0400 Subject: Sound doesn't work, again! In-Reply-To: <4A1049E6.40207@comcast.net> References: <1242495430.3022.40.camel@dimi.lattica.com> <4A0F3AE1.3090709@comcast.net> <1242517467.3022.57.camel@dimi.lattica.com> <4A0F5FA8.9060302@comcast.net> <4A0F9F17.1090209@stacken.kth.se> <4A100346.20400@comcast.net> <3adc77210905170743k3e640fabx2c0b6b3f957b2cf2@mail.gmail.com> <4A1028A3.6080202@comcast.net> <4A103F0A.9080203@stacken.kth.se> <4A1049E6.40207@comcast.net> Message-ID: <1242584127.3022.88.camel@dimi.lattica.com> On Sun, 2009-05-17 at 13:31 -0400, David wrote: > But I wish, for his sake, that he was not having this problem on his > production machine because *I still think Rawhide on a critical, must > have machine is not a good idea.* Guys, I appreciate the concern, but this is missing the point. I have explained already why I couldn't run F9/F10, and why I upgraded to F11. For me sound is a critical issue, and due to untold number of problems in F8, I decided to risk it and move over to F11 Beta. Please try to see that _if_ I waited until F11 Final, the sound problems that I reported would not have been fixed. The works-on-no-doesn't-work sound problems have been a constant in my experience with Fedora, ever since F3 (while running only release versions, never betas until now)! By focusing on the fact that this is F11 Beta and not Final we are ignoring the elephant in the room. We all know that this is very close to what will be released as final anyway, and in fact a lot of the problems I am seeing are not reasonably fixable until release day. I am just trying to raise awareness that there is a major problem with the way we approach sound in Fedora, and we need to reevaluate the situation. And by this I don't mean "dump PA". I think Lennart is a very capable developer, and I appreciate his efforts. However I think the development focus for PA can use some rethinking. -- Dimi Paun Lattica, Inc. From smooge at gmail.com Sun May 17 18:35:15 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Sun, 17 May 2009 12:35:15 -0600 Subject: Sound doesn't work, again! In-Reply-To: <1242584127.3022.88.camel@dimi.lattica.com> References: <1242495430.3022.40.camel@dimi.lattica.com> <1242517467.3022.57.camel@dimi.lattica.com> <4A0F5FA8.9060302@comcast.net> <4A0F9F17.1090209@stacken.kth.se> <4A100346.20400@comcast.net> <3adc77210905170743k3e640fabx2c0b6b3f957b2cf2@mail.gmail.com> <4A1028A3.6080202@comcast.net> <4A103F0A.9080203@stacken.kth.se> <4A1049E6.40207@comcast.net> <1242584127.3022.88.camel@dimi.lattica.com> Message-ID: <80d7e4090905171135y3c979fd6l5de5cc019f3d9e14@mail.gmail.com> On Sun, May 17, 2009 at 12:15 PM, Dimi Paun wrote: > On Sun, 2009-05-17 at 13:31 -0400, David wrote: >> But I wish, for his sake, that he was not having this problem on his >> production machine because *I still think Rawhide on a critical, must >> have machine is not a good idea.* > > Guys, I appreciate the concern, but this is missing the point. > I have explained already why I couldn't run F9/F10, and why I > upgraded to F11. > > For me sound is a critical issue, and due to untold number of > problems in F8, I decided to risk it and move over to F11 Beta. Ok look at it this way. You mention you have had problems with Sound since FC3. Has this been the same hardware? If it has been, then I would seriously look at the hardware. A lot of customer sound problems I have dealt with ended up being bad speakers, bad cables to speakers, bad power supplies to speakers, bad connectors on the back of sound card, etc. Others were sound card drivers, a couple of cards that needed new firmware, and a lot of "it says its an XYZ card" but it turns out it is a badly implemented XYZ card. You have also had problems before PulseAudio was involved... so laying it at PulseAudio's steps is a bit strong. Did you try setting it up without PulseAudio? Did it work fine then for the extended amount of time you say (eg 24+hours)? If then, yes its a problem. If no, then we need to look at what is really the problem. -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From dimi at lattica.com Sun May 17 18:52:09 2009 From: dimi at lattica.com (Dimi Paun) Date: Sun, 17 May 2009 14:52:09 -0400 Subject: Sound doesn't work, again! In-Reply-To: <80d7e4090905171135y3c979fd6l5de5cc019f3d9e14@mail.gmail.com> References: <1242495430.3022.40.camel@dimi.lattica.com> <1242517467.3022.57.camel@dimi.lattica.com> <4A0F5FA8.9060302@comcast.net> <4A0F9F17.1090209@stacken.kth.se> <4A100346.20400@comcast.net> <3adc77210905170743k3e640fabx2c0b6b3f957b2cf2@mail.gmail.com> <4A1028A3.6080202@comcast.net> <4A103F0A.9080203@stacken.kth.se> <4A1049E6.40207@comcast.net> <1242584127.3022.88.camel@dimi.lattica.com> <80d7e4090905171135y3c979fd6l5de5cc019f3d9e14@mail.gmail.com> Message-ID: <1242586329.3022.110.camel@dimi.lattica.com> On Sun, 2009-05-17 at 12:35 -0600, Stephen John Smoogen wrote: > Ok look at it this way. You mention you have had problems with Sound > since FC3. Has this been the same hardware? If it has been, then I > would seriously look at the hardware. A lot of customer sound problems > I have dealt with ended up being bad speakers, bad cables to speakers, > bad power supplies to speakers, bad connectors on the back of sound > card, etc. Yes, I have looked at that, and it is most definitely not the case. Besides, since F3 I think I changed at least one computer :) > Others were sound card drivers, a couple of cards that > needed new firmware, and a lot of "it says its an XYZ card" but it > turns out it is a badly implemented XYZ card. AFAIU, I have a fairly standard sound card: 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02) > You have also had problems before PulseAudio was involved... so laying > it at PulseAudio's steps is a bit strong. Sure, I am not saying the problems in F3 where PA's fault. > Did you try setting it up > without PulseAudio? Did it work fine then for the extended amount of > time you say (eg 24+hours)? If then, yes its a problem. If no, then we > need to look at what is really the problem. This is an experiment which I didn't do, but if you read the bug reports, it is very unlikely that they originate somewhere else. -- Dimi Paun Lattica, Inc. From bochecha at fedoraproject.org Sun May 17 19:19:16 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Sun, 17 May 2009 18:19:16 -0100 Subject: Sound doesn't work, again! In-Reply-To: <1242586329.3022.110.camel@dimi.lattica.com> References: <1242495430.3022.40.camel@dimi.lattica.com> <4A0F9F17.1090209@stacken.kth.se> <4A100346.20400@comcast.net> <3adc77210905170743k3e640fabx2c0b6b3f957b2cf2@mail.gmail.com> <4A1028A3.6080202@comcast.net> <4A103F0A.9080203@stacken.kth.se> <4A1049E6.40207@comcast.net> <1242584127.3022.88.camel@dimi.lattica.com> <80d7e4090905171135y3c979fd6l5de5cc019f3d9e14@mail.gmail.com> <1242586329.3022.110.camel@dimi.lattica.com> Message-ID: <2d319b780905171219y5b1f90efy56a33ac5605fb73d@mail.gmail.com> > AFAIU, I have a fairly standard sound card: > 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02) Same card here. It's been working fine from F9 (first release I used on this laptop) to F11. ---------- Mathieu Bridon (bochecha) From rondu.richard at gmail.com Sun May 17 19:36:06 2009 From: rondu.richard at gmail.com (Richard Rondu) Date: Sun, 17 May 2009 20:36:06 +0100 Subject: Sound doesn't work, again! In-Reply-To: <2d319b780905171219y5b1f90efy56a33ac5605fb73d@mail.gmail.com> References: <1242495430.3022.40.camel@dimi.lattica.com> <4A100346.20400@comcast.net> <3adc77210905170743k3e640fabx2c0b6b3f957b2cf2@mail.gmail.com> <4A1028A3.6080202@comcast.net> <4A103F0A.9080203@stacken.kth.se> <4A1049E6.40207@comcast.net> <1242584127.3022.88.camel@dimi.lattica.com> <80d7e4090905171135y3c979fd6l5de5cc019f3d9e14@mail.gmail.com> <1242586329.3022.110.camel@dimi.lattica.com> <2d319b780905171219y5b1f90efy56a33ac5605fb73d@mail.gmail.com> Message-ID: <35d32c5c0905171236j6f2c8b1ate697bf5d4b8131af@mail.gmail.com> On Sun, May 17, 2009 at 8:19 PM, Mathieu Bridon (bochecha) wrote: >> AFAIU, I have a fairly standard sound card: >> 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02) > > Same card here. It's been working fine from F9 (first release I used > on this laptop) to F11. > Same card, worked fine from F8 to F9. Quite randomly in F10, it broke several times after some updates (don't ask me which) and currently I had for the first time to use tsched=0 since around 2 weeks or I have a bad sound quality with glitch etc (not to mention pulseaudio crash quite frequently, worked fine before F10). From drago01 at gmail.com Sun May 17 20:57:57 2009 From: drago01 at gmail.com (drago01) Date: Sun, 17 May 2009 22:57:57 +0200 Subject: Sound doesn't work, again! In-Reply-To: <2d319b780905171219y5b1f90efy56a33ac5605fb73d@mail.gmail.com> References: <1242495430.3022.40.camel@dimi.lattica.com> <4A100346.20400@comcast.net> <3adc77210905170743k3e640fabx2c0b6b3f957b2cf2@mail.gmail.com> <4A1028A3.6080202@comcast.net> <4A103F0A.9080203@stacken.kth.se> <4A1049E6.40207@comcast.net> <1242584127.3022.88.camel@dimi.lattica.com> <80d7e4090905171135y3c979fd6l5de5cc019f3d9e14@mail.gmail.com> <1242586329.3022.110.camel@dimi.lattica.com> <2d319b780905171219y5b1f90efy56a33ac5605fb73d@mail.gmail.com> Message-ID: On Sun, May 17, 2009 at 9:19 PM, Mathieu Bridon (bochecha) wrote: >> AFAIU, I have a fairly standard sound card: >> 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02) ICH8 Audio device is too generic. What matters is what codec the card uses (dmesg should tell you). From jaroslav at aster.pl Sun May 17 21:15:52 2009 From: jaroslav at aster.pl (=?utf-8?q?Jaros=C5=82aw_G=C3=B3rny?=) Date: Sun, 17 May 2009 23:15:52 +0200 Subject: Sound doesn't work, again! In-Reply-To: <4A0F5FA8.9060302@comcast.net> References: <1242495430.3022.40.camel@dimi.lattica.com> <1242517467.3022.57.camel@dimi.lattica.com> <4A0F5FA8.9060302@comcast.net> Message-ID: <200905172315.53807.jaroslav@aster.pl> Hi, Sunday 17 May 2009 02:51:52 David napisa?(a): > I say 'your problem' because it also appears that no one else has this > problem. At least not that I can see. That's basically not true. Just look a previous week - at least 2 big threads about problems with PA. And Dimi's bugs are not the only ones regarding PA. I'm also one of the people who have problems with PA from time to time. If it works for you always - great, lucky you. regards, -- Jaros?aw G?rny RHCE From dwmw2 at infradead.org Sun May 17 21:58:29 2009 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 17 May 2009 22:58:29 +0100 Subject: Sound doesn't work, again! In-Reply-To: <1242542114.3022.78.camel@dimi.lattica.com> References: <1242495430.3022.40.camel@dimi.lattica.com> <4A0F3AE1.3090709@comcast.net> <1242517467.3022.57.camel@dimi.lattica.com> <4A0F5FA8.9060302@comcast.net> <1242542114.3022.78.camel@dimi.lattica.com> Message-ID: <1242597509.2964.2036.camel@macbook.infradead.org> On Sun, 2009-05-17 at 02:35 -0400, Dimi Paun wrote: > > Look, I know I'm frustrated. You would be too when you > - run bog-standard hardware > - run non-patched, as pristine as possible version of Fedora > - you spend ~1h almost daily to get sound out of Flash, Skype, > Rhythmbox, etc, sound that you just fixed, and it stopped > working out of the blue. Almost daily! Seriously, just remove PulseAudio. It was the only way I could get sound to work reliably in F-10, and after persevering for a while I think I'm going to have to give up and do that in F-11 too. I often just get no sound at all from xine, and when I do it's often skipping a huge amount. I _would_ probably continue to persevere, but I want to update my father's laptop to F-11, and there's no way I can give him a machine with PulseAudio on it right now. It's just not ready for production use, in my opinion. So I should make my machine match his -- and enjoy having reliably functioning audio again. Unfortunately, in F-11 it's slightly more complicated to remove PA than it was in F-10. Now you have to cope with the fact that 'yum remove pulseaudio' also wants to strip all Bluetooth support from the system. Apparently you are _expected_ to drink the Kool-Aid... -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation From awilliam at redhat.com Sun May 17 22:28:06 2009 From: awilliam at redhat.com (Adam Williamson) Date: Sun, 17 May 2009 15:28:06 -0700 Subject: Sound doesn't work, again! In-Reply-To: <35d32c5c0905171236j6f2c8b1ate697bf5d4b8131af@mail.gmail.com> References: <1242495430.3022.40.camel@dimi.lattica.com> <4A100346.20400@comcast.net> <3adc77210905170743k3e640fabx2c0b6b3f957b2cf2@mail.gmail.com> <4A1028A3.6080202@comcast.net> <4A103F0A.9080203@stacken.kth.se> <4A1049E6.40207@comcast.net> <1242584127.3022.88.camel@dimi.lattica.com> <80d7e4090905171135y3c979fd6l5de5cc019f3d9e14@mail.gmail.com> <1242586329.3022.110.camel@dimi.lattica.com> <2d319b780905171219y5b1f90efy56a33ac5605fb73d@mail.gmail.com> <35d32c5c0905171236j6f2c8b1ate697bf5d4b8131af@mail.gmail.com> Message-ID: <1242599286.2923.968.camel@adam.local.net> On Sun, 2009-05-17 at 20:36 +0100, Richard Rondu wrote: > On Sun, May 17, 2009 at 8:19 PM, Mathieu Bridon (bochecha) > wrote: > >> AFAIU, I have a fairly standard sound card: > >> 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02) > > > > Same card here. It's been working fine from F9 (first release I used > > on this laptop) to F11. > > > > Same card, worked fine from F8 to F9. Quite randomly in F10, it broke > several times after some updates (don't ask me which) and currently I > had for the first time to use tsched=0 since around 2 weeks or I have > a bad sound quality with glitch etc (not to mention pulseaudio crash > quite frequently, worked fine before F10). It's not the 'same card', in fact. Simple lspci info like this is not sufficient to identify precisely Intel 8x0 or HDA codec sound hardware. You have to provide the output of alsa-info.sh , which gives the subsystem IDs, which actually precisely identify the hardware. There are dozens of different 8x0 and HDA implementions which share the same main vendor and device IDs. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From dgboles at comcast.net Sun May 17 22:44:07 2009 From: dgboles at comcast.net (David) Date: Sun, 17 May 2009 18:44:07 -0400 Subject: Sound doesn't work, again! In-Reply-To: <200905172315.53807.jaroslav@aster.pl> References: <1242495430.3022.40.camel@dimi.lattica.com> <1242517467.3022.57.camel@dimi.lattica.com> <4A0F5FA8.9060302@comcast.net> <200905172315.53807.jaroslav@aster.pl> Message-ID: <4A109337.5070800@comcast.net> On 5/17/2009 5:15 PM, Jaros?aw G?rny wrote: > Hi, > > Sunday 17 May 2009 02:51:52 David napisa?(a): > >> I say 'your problem' because it also appears that no one else has this >> problem. At least not that I can see. > > That's basically not true. Just look a previous week - at least 2 big threads > about problems with PA. And Dimi's bugs are not the only ones regarding PA. > I'm also one of the people who have problems with PA from time to time. > If it works for you always - great, lucky you. > > regards, PulseAudio has a really, really *bad* name. PulseAudio should be named 'PulseMixer' or perhaps something else. It is a mixer. Only and does not do anything with sound except combine audio settings. As for me being lucky? That I can not say. But it does work for me In Fedora and several other Linux distrobutions. Always has. I am sorry that it does not work for you. And do you want to know what really, really hurts about this? It works in Microsoft Windows. Has for years. :-( The way to get things 'fixed' is to be vocal. But to be polite while being vocal. :-) -- David From rodd at clarkson.id.au Sun May 17 23:13:47 2009 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Mon, 18 May 2009 09:13:47 +1000 Subject: OpenOffice 3.1 In-Reply-To: References: <4A034FD0.40103@gnat.ca> <1241767234.2551.1304.camel@Vain> <1241869878.2551.1439.camel@Vain> <1241882902.2886.50.camel@localhost.localdomain> <97da516f0905090858y3d9f36c7v5e7f41cfc5e9d6af@mail.gmail.com> <1241998651.2760.9.camel@moose> <1242002755.2760.23.camel@moose> Message-ID: <1242602027.18662.0.camel@moose> On Mon, 2009-05-11 at 15:21 +0200, Kevin Kofler wrote: > Rodd Clarkson wrote: > > Should she have to have take the time to relearn applications because > > you haven't got the time to upgrade? More importantly, from her > > perspective she doesn't give a damn if there are changes to things like > > "new hash algorithm in RPM, ext4 by default etc" and doesn't even > > realize that she uses these things. She does however use OOo, Firefox, > > Evolution and other applications and she does notice when they chance > > and she doesn't like it changing all the time (and especially > > mid-release). > > Well, there are distributions (like the one starting with a 'U') with such a > policy. Nobody is forcing her to use Fedora (except maybe you ;-) ). See, this is the problem with this line of thinking (and I didn't start this, I'm just trying to point out there are other view points.) Someone_1 says that Fedora should 'Do_This_1' Someone_2 else says that Fedora should 'Do_The_Opposite' Someone_1 says that Someone_2 should use Not_Fedora. Someone_2 could say to Someone_1 right back at you. Except in this case, Someone_2 was just pointing out that there are more view points (than one) about how Fedora should work, that the Fedora Community is broad and has many view points and that sometimes being part of a community is just excepting that things don't always go your way (most of this was implied ;-]). Seriously, if Fedora ran my way, it would work perfectly on hardware I wanted to run, (sorry everyone not using my choice of hardware), it would run the software I wanted (without all the bloat that comes with having to satisfy anyone elses needs), and when I had to (inconceivably) file a bugzilla, it would be addressed immediately without any delay, without thousands of the brightest minds working without sleep until it was solved. Oh, and it would be called Mydora (not Yourdora) and I would be happy. Anyhow, enjoy Yourdora! ;-] R. From dgboles at comcast.net Sun May 17 23:40:14 2009 From: dgboles at comcast.net (David) Date: Sun, 17 May 2009 19:40:14 -0400 Subject: Sound doesn't work, again! In-Reply-To: <1242584127.3022.88.camel@dimi.lattica.com> References: <1242495430.3022.40.camel@dimi.lattica.com> <4A0F3AE1.3090709@comcast.net> <1242517467.3022.57.camel@dimi.lattica.com> <4A0F5FA8.9060302@comcast.net> <4A0F9F17.1090209@stacken.kth.se> <4A100346.20400@comcast.net> <3adc77210905170743k3e640fabx2c0b6b3f957b2cf2@mail.gmail.com> <4A1028A3.6080202@comcast.net> <4A103F0A.9080203@stacken.kth.se> <4A1049E6.40207@comcast.net> <1242584127.3022.88.camel@dimi.lattica.com> Message-ID: <4A10A05E.2030604@comcast.net> On 5/17/2009 2:15 PM, Dimi Paun wrote: > On Sun, 2009-05-17 at 13:31 -0400, David wrote: >> But I wish, for his sake, that he was not having this problem on his >> production machine because *I still think Rawhide on a critical, must >> have machine is not a good idea.* > > Guys, I appreciate the concern, but this is missing the point. > I have explained already why I couldn't run F9/F10, and why I > upgraded to F11. Ahhh... I remember you name know. It's been a while since you posted that. > For me sound is a critical issue, and due to untold number of > problems in F8, I decided to risk it and move over to F11 Beta. > > Please try to see that _if_ I waited until F11 Final, the > sound problems that I reported would not have been fixed. > > The works-on-no-doesn't-work sound problems have been a constant > in my experience with Fedora, ever since F3 (while running only > release versions, never betas until now)! > > By focusing on the fact that this is F11 Beta and not Final we > are ignoring the elephant in the room. We all know that this is > very close to what will be released as final anyway, and in fact > a lot of the problems I am seeing are not reasonably fixable until > release day. > > I am just trying to raise awareness that there is a major problem > with the way we approach sound in Fedora, and we need to reevaluate > the situation. And by this I don't mean "dump PA". I think Lennart > is a very capable developer, and I appreciate his efforts. However > I think the development focus for PA can use some rethinking. And I agree with you that you do have a problem. What it is I do not know. But it might have something to do with you update from Fedora 8. Much has changed since then. In Fedora and I would think your install. May I suggest that you keep up with your Bugzilla report. *However* you might not see anything until after the Fedora 11 release. Only a week to go I would imagine that everyone is very busy. BTW there is always, has been in the past, a flood of updates that did not make it into the ISOs. Perhaps then you will see something encouraging. Best of luck. -- David From katzj at redhat.com Sun May 17 23:47:17 2009 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 17 May 2009 19:47:17 -0400 Subject: yum upgrade v anaconda upgrade differences In-Reply-To: References: <4A0F79E4.2040003@iinet.net.au> Message-ID: <20090517234717.GA71398@redhat.com> On Sunday, May 17 2009, Seth Vidal said: > On Sun, 17 May 2009, David Timms wrote: >> On the yum list a question was asked which intrigued me: >> Why can anaconda manage to upgrade a system, when yum upgrade can't. >> >> The postulation was that anaconda is cheating (ie running --nodeps >> installs). This would allow it to complete an upgrade where >> dependencies lead to unavailable packages that are not on the dvd, but >> are in the complete Fedora, and or non- fedora repositories, that are >> not available at upgrade time. >> >> Is that why it can work ? >> Or what are essential differences between an anaconda upgrade and yum >> upgrade ? > > anaconda is also running outside of the system you're trying to update - > it doesn't have to worry about making its own environment entirely > unusable. So it can do things like --nodeps w/o a concern for not being > able to complete the transaction. It also means that we can do things like use a newer version of rpm or a new kernel with ext4 support to (eventually) allow for migrating from ext3->ext4 Jeremy From dtimms at iinet.net.au Mon May 18 00:10:11 2009 From: dtimms at iinet.net.au (David Timms) Date: Mon, 18 May 2009 10:10:11 +1000 Subject: yum upgrade v anaconda upgrade differences In-Reply-To: <20090517234717.GA71398@redhat.com> References: <4A0F79E4.2040003@iinet.net.au> <20090517234717.GA71398@redhat.com> Message-ID: <4A10A763.7050806@iinet.net.au> On 18/05/09 09:47, Jeremy Katz wrote: > On Sunday, May 17 2009, Seth Vidal said: >> anaconda is also running outside of the system you're trying to update - >> it doesn't have to worry about making its own environment entirely >> unusable. So it can do things like --nodeps w/o a concern for not being >> able to complete the transaction. > > It also means that we can do things like use a newer version of rpm or a > new kernel with ext4 support to (eventually) allow for migrating from > ext3->ext4 OK, thanks Seth and Jeremy for that insight. Cheers, DaveT. From dimi at lattica.com Mon May 18 01:41:15 2009 From: dimi at lattica.com (Dimi Paun) Date: Sun, 17 May 2009 21:41:15 -0400 Subject: Sound doesn't work, again! In-Reply-To: References: <1242495430.3022.40.camel@dimi.lattica.com> <4A100346.20400@comcast.net> <3adc77210905170743k3e640fabx2c0b6b3f957b2cf2@mail.gmail.com> <4A1028A3.6080202@comcast.net> <4A103F0A.9080203@stacken.kth.se> <4A1049E6.40207@comcast.net> <1242584127.3022.88.camel@dimi.lattica.com> <80d7e4090905171135y3c979fd6l5de5cc019f3d9e14@mail.gmail.com> <1242586329.3022.110.camel@dimi.lattica.com> <2d319b780905171219y5b1f90efy56a33ac5605fb73d@mail.gmail.com> Message-ID: <1242610875.3022.115.camel@dimi.lattica.com> On Sun, 2009-05-17 at 22:57 +0200, drago01 wrote: > > ICH8 Audio device is too generic. > What matters is what codec the card uses (dmesg should tell you). Fair enough (from alsa-info.sh): Module: snd_hda_intel Codec: Analog Devices AD1988B For full info please check: http://www.alsa-project.org/db/?f=fd2bf7c14ecce1c17122f9be815d854d88af5fdb -- Dimi Paun Lattica, Inc. From cmadams at hiwaay.net Mon May 18 02:35:04 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Sun, 17 May 2009 21:35:04 -0500 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A102F2D.3070809@robertoragusa.it> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A0C99A5.1040401@cygnusx-1.org> <4A0C9D2A.2070601@cygnusx-1.org> <20090515001432.GB1148000@hiwaay.net> <4A102F2D.3070809@robertoragusa.it> Message-ID: <20090518023504.GA631425@hiwaay.net> Once upon a time, Roberto Ragusa said: > One CD/DVD unit. > One hard disk. > One screen. > One keyboard. > One ethernet. > One wireless. > One user. (!!!) I've only had an external DVD burner hooked up to my laptop once. I've had external hard drives, an external KVM switch (second screen and keyboard), and _two_ additional ethernets (an ExpressCard and a USB) connected. Really though, wireless == ethernet+more config, so almost every laptop has multiple ethernets. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From bojan at rexursive.com Mon May 18 03:57:28 2009 From: bojan at rexursive.com (Bojan Smojver) Date: Mon, 18 May 2009 13:57:28 +1000 Subject: Rawhide upgrade Message-ID: <1242619048.2404.9.camel@shrek.rexursive.com> I just upgraded yet another machine to Rawhide, but this time mysteriously the old problem of RPM not understanding the packages checksums resurfaced (the system was running fully updated F-10 at the time of upgrade). The other 3 boxes went just fine, but not this one. The only thing that's different about this system is that it is running SELinux in enforcing mode (targeted policy). The other 3 have SELinux disabled. Just after selinux-policy-targeted finished painting its asterisks on the screen, things went wrong. Every single package after that did not get upgraded (this includes "unimportant" things such as rpm and yum), but the cleanup did run (ergo, very few packages were left on the system). Errors on the screen were indicating that package checksums were wrong. I managed to rescue the machine with a bit of by-hand hacking (rpm2cpio on another machine is your friend), but just wanted to warn that maybe things are not yet 100%. Not sure if people bumped into this recently... -- Bojan From drago01 at gmail.com Mon May 18 06:54:33 2009 From: drago01 at gmail.com (drago01) Date: Mon, 18 May 2009 08:54:33 +0200 Subject: Sound doesn't work, again! In-Reply-To: <1242610875.3022.115.camel@dimi.lattica.com> References: <1242495430.3022.40.camel@dimi.lattica.com> <4A1028A3.6080202@comcast.net> <4A103F0A.9080203@stacken.kth.se> <4A1049E6.40207@comcast.net> <1242584127.3022.88.camel@dimi.lattica.com> <80d7e4090905171135y3c979fd6l5de5cc019f3d9e14@mail.gmail.com> <1242586329.3022.110.camel@dimi.lattica.com> <2d319b780905171219y5b1f90efy56a33ac5605fb73d@mail.gmail.com> <1242610875.3022.115.camel@dimi.lattica.com> Message-ID: On Mon, May 18, 2009 at 3:41 AM, Dimi Paun wrote: > On Sun, 2009-05-17 at 22:57 +0200, drago01 wrote: >> >> ICH8 Audio device is too generic. >> What matters is what codec the card uses (dmesg should tell you). > > Fair enough (from alsa-info.sh): > ?Module: snd_hda_intel > ?Codec: Analog Devices AD1988B I have Codec: Analog Devices AD1989B which works without any issues (F10/F11) . As both cards are very similar I doubt that it is a hardware related issue in your case. From mail at robertoragusa.it Mon May 18 07:14:44 2009 From: mail at robertoragusa.it (Roberto Ragusa) Date: Mon, 18 May 2009 09:14:44 +0200 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <20090518023504.GA631425@hiwaay.net> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A0C99A5.1040401@cygnusx-1.org> <4A0C9D2A.2070601@cygnusx-1.org> <20090515001432.GB1148000@hiwaay.net> <4A102F2D.3070809@robertoragusa.it> <20090518023504.GA631425@hiwaay.net> Message-ID: <4A110AE4.6030500@robertoragusa.it> Chris Adams wrote: > Once upon a time, Roberto Ragusa said: >> One CD/DVD unit. >> One hard disk. >> One screen. >> One keyboard. >> One ethernet. >> One wireless. >> One user. (!!!) > > I've only had an external DVD burner hooked up to my laptop once. I've > had external hard drives, an external KVM switch (second screen and > keyboard), and _two_ additional ethernets (an ExpressCard and a USB) > connected. Really though, wireless == ethernet+more config, so almost > every laptop has multiple ethernets. I never said that you can't plug things into a laptop, the focus of my statement was the word "typically". You can have many ethernets in a laptop (I have), but how many laptops do firewalling, masquerading, traffic shaping, load balancing, multihoming, fail over, ....? As those are highly unusual on a laptop, they receive less attention than laptop stuff as, e.g., having bluetooth audio. Server-oriented usage appears to be the least important scenario for Fedora at the moment; and I admit this can be considered appropriate if "the users" have laptops, not servers. -- Roberto Ragusa mail at robertoragusa.it From frankly3d at gmail.com Mon May 18 08:42:59 2009 From: frankly3d at gmail.com (Frank Murphy (Frankly3d)) Date: Mon, 18 May 2009 09:42:59 +0100 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A0814ED.60205@redhat.com> References: <4A0814ED.60205@redhat.com> Message-ID: <4A111F93.5090901@gmail.com> Stephen Gallagher wrote: > > If nothing else, consider this an open request to the Firefox, > Thunderbird and Lightning maintainers to provide a compatibility package > that can downgrade and replace the unstable and non-extensible versions > currently in the distribution. > Didn't read all the thread, so if answered apologies. For TB I did "yum erase thunderbird" Yum localinstall thunderbird-2.0.0.17-1.fc10.i386.rpm (downloaded from F10 mirror) No dep problems when done. I am using Firefox 3.5b, so can't help there. Frank -- msn: frankly3d skype: frankly3d Mailing-List Reply to: Mailing-List Still Learning, Unicode where possible From berrange at redhat.com Mon May 18 09:57:47 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 18 May 2009 10:57:47 +0100 Subject: PolicyKit changes in F12 In-Reply-To: <15e53e180905170114h2cfdb70q1727160a2cb75a9b@mail.gmail.com> References: <1242262846.9432.9.camel@localhost.localdomain> <20090516075614.GU1589@redhat.com> <15e53e180905170114h2cfdb70q1727160a2cb75a9b@mail.gmail.com> Message-ID: <20090518095747.GE29795@redhat.com> On Sun, May 17, 2009 at 09:14:03AM +0100, Richard Hughes wrote: > On Sat, May 16, 2009 at 8:56 AM, Daniel Veillard wrote: > > ?? No kit_* OOM handling in the new library > > means ? > > The old kit_* functions used to handle OOM (out of memory conditions) > and report back the correct error. The new library is more GLib like, > and doesn't handle OOM very well at all. It's likely you didn't care > about OOM before, so this change won't affect you. Well there are two ends to this. The client app side (eg virt-manager) we don't care about OOM, since we're using GTK and that just aborts all the time. For the service end, eg libvirtd, we do care about OOM handling and we test for it, so this change is an unfortunate regression :-( Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From ankit at redhat.com Mon May 18 10:04:57 2009 From: ankit at redhat.com (Ankitkumar Rameshchandra Patel) Date: Mon, 18 May 2009 15:34:57 +0530 Subject: Keyboard mapping characters with both shift keys Message-ID: <4A1132C9.4040601@redhat.com> What's the expected results of Left_Shift + Right_Shift + Any Key? I have tried Left_Shift + Right_Shift + each individual key combination of QWERTY keyboard in text editor (e.g. gedit) and got the following results: ~!@#$%^&*()_+ QWERUIOP| ASDFGHJKL:" BN? If you notice, there are many English alphabets not being displayed. e.g. Left_Shift + Right_Shift + t = , same for y, z, x, c, v and m keys. Is this a correct behavior? -- Ankit Patel From dwmw2 at infradead.org Mon May 18 10:08:18 2009 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 18 May 2009 11:08:18 +0100 Subject: Sound doesn't work, again! In-Reply-To: <1242542114.3022.78.camel@dimi.lattica.com> References: <1242495430.3022.40.camel@dimi.lattica.com> <4A0F3AE1.3090709@comcast.net> <1242517467.3022.57.camel@dimi.lattica.com> <4A0F5FA8.9060302@comcast.net> <1242542114.3022.78.camel@dimi.lattica.com> Message-ID: <1242641298.30251.0.camel@macbook.infradead.org> On Sun, 2009-05-17 at 02:35 -0400, Dimi Paun wrote: > I used to run F8 until recently, with PA giving me no end of trouble. > I could _not_ upgrade to either F9 or F10 due to a very serious bug > in Anaconda/dmraid: https://bugzilla.redhat.com/show_bug.cgi?id=468649 > (essentially you could not install on a RAID 1 partition). You couldn't _install_ them but you could easily have updated with yum, right? -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation From davidz at redhat.com Mon May 18 12:57:07 2009 From: davidz at redhat.com (David Zeuthen) Date: Mon, 18 May 2009 08:57:07 -0400 Subject: PolicyKit changes in F12 In-Reply-To: <20090518095747.GE29795@redhat.com> References: <1242262846.9432.9.camel@localhost.localdomain> <20090516075614.GU1589@redhat.com> <15e53e180905170114h2cfdb70q1727160a2cb75a9b@mail.gmail.com> <20090518095747.GE29795@redhat.com> Message-ID: <1242651427.4508.37.camel@localhost.localdomain> On Mon, 2009-05-18 at 10:57 +0100, Daniel P. Berrange wrote: > On Sun, May 17, 2009 at 09:14:03AM +0100, Richard Hughes wrote: > > On Sat, May 16, 2009 at 8:56 AM, Daniel Veillard wrote: > > > ? No kit_* OOM handling in the new library > > > means ? > > > > The old kit_* functions used to handle OOM (out of memory conditions) > > and report back the correct error. The new library is more GLib like, > > and doesn't handle OOM very well at all. It's likely you didn't care > > about OOM before, so this change won't affect you. > > Well there are two ends to this. The client app side (eg virt-manager) > we don't care about OOM, since we're using GTK and that just aborts all > the time. For the service end, eg libvirtd, we do care about OOM handling > and we test for it, so this change is an unfortunate regression :-( No, there is no regression here. As I tried to explain in the reply to Veillard: 1. In libvirtd, simply check for authorization by speaking to the polkitd-1 using either the D-Bus API (via e.g. libdbus-1 which handles OOM) or a through helper. 2. virt-manager will not have to know _anything_ about PolicyKit And if either polkitd-1 or the helper aborts() due to OOM, then you will get a D-Bus error back (or if using a helper, WIFEXITED(status) != 0) and you can check the authorization again - this works because the bus daemon (which handles OOM) will then reactivate polkitd-1. David From fedora at matbooth.co.uk Mon May 18 13:26:29 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Mon, 18 May 2009 14:26:29 +0100 Subject: Keyboard mapping characters with both shift keys In-Reply-To: <4A1132C9.4040601@redhat.com> References: <4A1132C9.4040601@redhat.com> Message-ID: <9497e9990905180626w37f74f4qecb2a638b2caf361@mail.gmail.com> On Mon, May 18, 2009 at 11:04 AM, Ankitkumar Rameshchandra Patel wrote: > What's the expected results of Left_Shift + Right_Shift + Any Key? > > I have tried Left_Shift + Right_Shift + each individual key combination of > QWERTY keyboard in text editor (e.g. gedit) and got the following results: > > ~!@#$%^&*()_+ > QWERUIOP| > ASDFGHJKL:" > BN? > > If you notice, there are many English alphabets not being displayed. e.g. > Left_Shift + Right_Shift + t = , same for y, z, x, c, v and m > keys. > > Is this a correct behavior? > Curiously, you can observe the same behaviour in Windows. Is this a limitation of the keyboards themselves, perhaps? -- Mat Booth www.matbooth.co.uk From rawhide at fedoraproject.org Mon May 18 14:04:08 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Mon, 18 May 2009 14:04:08 +0000 (UTC) Subject: rawhide report: 20090518 changes Message-ID: <20090518140408.DEA051B8003@releng2.fedora.phx.redhat.com> Compose started at Mon May 18 06:15:03 UTC 2009 Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 0 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From j.w.r.degoede at hhs.nl Mon May 18 14:14:48 2009 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 18 May 2009 16:14:48 +0200 Subject: New soname changing ClanLib coming to F-12 repo / buildroot Message-ID: <4A116D58.8060403@hhs.nl> Hi all, koji is currently building the new upstream 1.0.0 release of ClanLib. This is really is a bugfix release in the 0.8.x series, but to make clear the 0.8.x series is stable it has been renamed to the 1.0.x series, including a change in the soname. This release is 100% API compatible with the 0.8 series, so all you need to do is a rebuild. Here is a list of the dependend packages: [hans at localhost devel]$ repoquery -q --whatrequires --alldeps ClanLib openalchemist-0:0.3-5.fc11.x86_64 ballbuster-0:1.0-7.fc11.x86_64 trophy-0:1.1.5-3.fc11.x86_64 methane-0:1.4.7-6.fc11.x86_64 3 of those are mine and I'll take care of rebuilding them, that only leaves openalchemist, whose maintainer is in the CC Regards, Hans From zprikryl at redhat.com Mon May 18 14:23:52 2009 From: zprikryl at redhat.com (Zdenek Prikryl) Date: Mon, 18 May 2009 16:23:52 +0200 Subject: Abrt - should this be a feature? In-Reply-To: <4A0DC949.7000601@fedoraproject.org> References: <4A0DC949.7000601@fedoraproject.org> Message-ID: <4A116F78.3020607@redhat.com> Rahul Sundaram wrote: > Hi > > http://fedoraproject.org/wiki/Features/ABRT > > It was broken when tested > > https://fedoraproject.org/wiki/QA/Test_Days/2009-02-26 Yes, the test day explored several bugs (for this purpose the test day was), but critical bugs are fixed, some of feature requests are implemented. So imho the current state of abrt is good :-) > Bug Buddy seems to the default still for GNOME. Why is it in the feature > list? FESCo should reconsider this feature. In F11 abrt doesn't replace bb, they can be enabled at the same time. Note that abrt can catch more crashes than bb can (like non-gnome programs, kernel crashes [kerneloops], ...). -- Zdenek Prikryl From jwboyer at gmail.com Mon May 18 14:52:14 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 18 May 2009 10:52:14 -0400 Subject: F12 Naming: Cambridge -> Leonidas -> ? Message-ID: <20090518145214.GA2964@yoda.jdub.homelinux.org> Hi All, It's that time of year again. Time to start the naming process for the next Fedora release. To recap on the rules: 1) must have some link to Leonidas More specifically, the link should be Leonidas is a and is a Where is the same for both 2) The link between and Leonidas cannot be the same as between Cambridge and Leonidas. That link was "was a ship in the Union navy". We're repeating the collection process we used for Fedora 11 this time. Contributors wishing to make a suggestion are asked to go to the F11 naming wiki page, and add an entry to the suggestion table found there: https://fedoraproject.org/wiki/Name_suggestions_for_Fedora_12 The naming submissions are open starting now until May 23. The rest of the schedule is outlined on the wiki page. So, put on your thinking caps and come up with some really good suggestions! Happy naming. josh _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From kevin at scrye.com Mon May 18 15:09:53 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Mon, 18 May 2009 09:09:53 -0600 Subject: Package Maintainers Flags policy Message-ID: <20090518090953.5698908a@ohm.scrye.com> In FESCo's 2009-03-28 meeting a policy on Flag usage for packages in Fedora was approved. Due to an oversight, this policy was not announced here. ;( Please see: https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy and direct any comments to FESCo in a ticket or via the devel list. Thanks, and sorry for the oversight. ;( kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From jkeating at j2solutions.net Mon May 18 15:37:13 2009 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 18 May 2009 08:37:13 -0700 Subject: Fedora (Linux) is Destroying it self In-Reply-To: <4A110AE4.6030500@robertoragusa.it> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A0C99A5.1040401@cygnusx-1.org> <4A0C9D2A.2070601@cygnusx-1.org> <20090515001432.GB1148000@hiwaay.net> <4A102F2D.3070809@robertoragusa.it> <20090518023504.GA631425@hiwaay.net> <4A110AE4.6030500@robertoragusa.it> Message-ID: <1242661033.3223.30.camel@localhost.localdomain> On Mon, 2009-05-18 at 09:14 +0200, Roberto Ragusa wrote: > I never said that you can't plug things into a laptop, the > focus of my statement was the word "typically". > > You can have many ethernets in a laptop (I have), but how many > laptops do firewalling, masquerading, traffic shaping, > load balancing, multihoming, fail over, ....? > As those are highly unusual on a laptop, they receive > less attention than laptop stuff as, e.g., having bluetooth audio. Many of those are highly unusual for a desktop too. I'm not sure what you're trying to accomplish here, but they are /possible/ with a laptop, just as they are possible with a desktop. > > Server-oriented usage appears to be the least important scenario > for Fedora at the moment; and I admit this can be considered > appropriate if "the users" have laptops, not servers. > Server usage is as important as the server focused people make it. The people working on Laptop stuff are pretty active and we see a lot of development and forward looking from them. The server people, not so much as things continue to "Just Work". -- Jesse Keating RHCE (http://jkeating.livejournal.com) Fedora Project (http://fedoraproject.org/wiki/JesseKeating) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) identi.ca (http://identi.ca/jkeating) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From rnicholsNOSPAM at comcast.net Mon May 18 15:41:02 2009 From: rnicholsNOSPAM at comcast.net (Robert Nichols) Date: Mon, 18 May 2009 10:41:02 -0500 Subject: Keyboard mapping characters with both shift keys In-Reply-To: <9497e9990905180626w37f74f4qecb2a638b2caf361@mail.gmail.com> References: <4A1132C9.4040601@redhat.com> <9497e9990905180626w37f74f4qecb2a638b2caf361@mail.gmail.com> Message-ID: Mat Booth wrote: > On Mon, May 18, 2009 at 11:04 AM, Ankitkumar Rameshchandra Patel > wrote: >> What's the expected results of Left_Shift + Right_Shift + Any Key? >> >> I have tried Left_Shift + Right_Shift + each individual key combination of >> QWERTY keyboard in text editor (e.g. gedit) and got the following results: >> >> ~!@#$%^&*()_+ >> QWERUIOP| >> ASDFGHJKL:" >> BN? >> >> If you notice, there are many English alphabets not being displayed. e.g. >> Left_Shift + Right_Shift + t = , same for y, z, x, c, v and m >> keys. >> >> Is this a correct behavior? >> > > Curiously, you can observe the same behaviour in Windows. Is this a > limitation of the keyboards themselves, perhaps? Indeed, "showkey -s" does not show any scan codes being emitted for some keys while both the left and right shift keys are held down. I see this behavior for qwerty7890-= keys with my keyboard. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it. From loganjerry at gmail.com Mon May 18 15:45:49 2009 From: loganjerry at gmail.com (Jerry James) Date: Mon, 18 May 2009 09:45:49 -0600 Subject: Package Maintainers Flags policy In-Reply-To: <20090518090953.5698908a@ohm.scrye.com> References: <20090518090953.5698908a@ohm.scrye.com> Message-ID: <870180fe0905180845j553c38d9k3865089ea9dc1505@mail.gmail.com> On Mon, May 18, 2009 at 9:09 AM, Kevin Fenzi wrote: > In FESCo's 2009-03-28 meeting a policy on Flag usage for packages in > Fedora was approved. > > Due to an oversight, this policy was not announced here. ;( > > Please see: > > https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy > > and direct any comments to FESCo in a ticket or via the devel list. > > Thanks, and sorry for the oversight. ;( > > kevin The title of this policy didn't convey the correct meaning to my software-oriented brain. I was wondering why the setting of boolean values needed a policy. :-) In fact, I've got two problems with this title: 1. The word "flags" has a well-established use in the software world; and 2. The "in Fedora" part is redundant since the policy document is hosted on a Fedora-specific wiki. Might I suggest changing the title to "Policy for Handling Geopolitical Flags"? Even that is a bit wordy. How about "Geopolitical Flag Policy"? I think you need "Geopolitical" in there somewhere to avoid confusing software geeks like me. -- Jerry James http://www.jamezone.org/ From jkeating at redhat.com Mon May 18 15:46:33 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 18 May 2009 08:46:33 -0700 Subject: Keyboard mapping characters with both shift keys In-Reply-To: <9497e9990905180626w37f74f4qecb2a638b2caf361@mail.gmail.com> References: <4A1132C9.4040601@redhat.com> <9497e9990905180626w37f74f4qecb2a638b2caf361@mail.gmail.com> Message-ID: <1242661593.3223.36.camel@localhost.localdomain> On Mon, 2009-05-18 at 14:26 +0100, Mat Booth wrote: > > Curiously, you can observe the same behaviour in Windows. Is this a > limitation of the keyboards themselves, perhaps? Some keyboards, really cheap ones, are incapable of handling three keys pressed. I've ran into a few of them and immediately replaced them. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From frankly3d at gmail.com Mon May 18 15:52:14 2009 From: frankly3d at gmail.com (Frank Murphy) Date: Mon, 18 May 2009 16:52:14 +0100 Subject: Package Maintainers Flags policy In-Reply-To: <870180fe0905180845j553c38d9k3865089ea9dc1505@mail.gmail.com> References: <20090518090953.5698908a@ohm.scrye.com> <870180fe0905180845j553c38d9k3865089ea9dc1505@mail.gmail.com> Message-ID: <4A11842E.5040805@gmail.com> Jerry James wrote: > On Mon, May 18, 2009 at 9:09 AM, Kevin Fenzi wrote: > > 1. The word "flags" has a well-established use in the software world; and > > 2. The "in Fedora" part is redundant since the policy document is > hosted on a Fedora-specific wiki. > > Might I suggest changing the title to "Policy for Handling > Geopolitical Flags"? Even that is a bit wordy. How about > "Geopolitical Flag Policy"? I think you need "Geopolitical" in there > somewhere to avoid confusing software geeks like me. > Country Flags\National Emblems ? Frank From tmz at pobox.com Mon May 18 15:52:29 2009 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 18 May 2009 11:52:29 -0400 Subject: comps comps-f11.xml.in, 1.234, 1.235 comps-f10.xml.in, 1.244, 1.245 comps-f9.xml.in, 1.450, 1.451 In-Reply-To: <20090518154138.369E270114@cvs1.fedora.phx.redhat.com> References: <20090518154138.369E270114@cvs1.fedora.phx.redhat.com> Message-ID: <20090518155229.GT4433@inocybe.localdomain> Rick L. Vinyard, Jr. wrote: > Index: comps-f11.xml.in > =================================================================== > RCS file: /cvs/pkgs/comps/comps-f11.xml.in,v > retrieving revision 1.234 > retrieving revision 1.235 > diff -u -p -r1.234 -r1.235 > --- comps-f11.xml.in 14 May 2009 18:54:46 -0000 1.234 > +++ comps-f11.xml.in 18 May 2009 15:41:06 -0000 1.235 > @@ -1,6132 +0,0 @@ > - > - > - [many deleted lines snipped...] I'm guessing that deleting all the content of comps-f11.xml.in was not intended. ;) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Experience is not what happens to a man. It is what a man does with what happens to him. -- Aldous Huxley -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From musuruan at gmail.com Mon May 18 15:53:36 2009 From: musuruan at gmail.com (Andrea Musuruane) Date: Mon, 18 May 2009 17:53:36 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <20090518090953.5698908a@ohm.scrye.com> References: <20090518090953.5698908a@ohm.scrye.com> Message-ID: <29fee02b0905180853p2e544b18le6647e80d0d445a9@mail.gmail.com> On Mon, May 18, 2009 at 5:09 PM, Kevin Fenzi wrote: > In FESCo's 2009-03-28 meeting a policy on Flag usage for packages in > Fedora was approved. > > Due to an oversight, this policy was not announced here. ;( > > Please see: > > https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy > > and direct any comments to FESCo in a ticket or via the devel list. May I kindly ask what is the reason behind this decision? Or, even better, can someone update the above wiki page explaining the reason? Thanks. Andrea. From Jochen at herr-schmitt.de Mon May 18 16:04:25 2009 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 18 May 2009 18:04:25 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <29fee02b0905180853p2e544b18le6647e80d0d445a9@mail.gmail.com> References: <20090518090953.5698908a@ohm.scrye.com> <29fee02b0905180853p2e544b18le6647e80d0d445a9@mail.gmail.com> Message-ID: <4A118709.9080204@herr-schmitt.de> Andrea Musuruane schrieb: > May I kindly ask what is the reason behind this decision? Or, even > better, can someone update the above wiki page explaining the reason? > > Yes, I find this guideline anouyance. So a explaination, why we need this policy may be helpful. Best Regards: Jochen Schmitt From rvinyard at cs.nmsu.edu Mon May 18 16:05:18 2009 From: rvinyard at cs.nmsu.edu (Rick L. Vinyard, Jr.) Date: Mon, 18 May 2009 10:05:18 -0600 (MDT) Subject: comps comps-f11.xml.in, 1.234, 1.235 comps-f10.xml.in, 1.244, 1.245 comps-f9.xml.in, 1.450, 1.451 In-Reply-To: <20090518155229.GT4433@inocybe.localdomain> References: <20090518154138.369E270114@cvs1.fedora.phx.redhat.com> <20090518155229.GT4433@inocybe.localdomain> Message-ID: <37499.155.148.81.31.1242662718.squirrel@intranet.cs.nmsu.edu> Thankfully there's cvs... I'm not sure how the f11 version got nuked... must have been when I was propagating the changes to f10 and f9. Fortunately I had made a diff from CVS... which I've already applied after Bill restored it. =================================================================== RCS file: /cvs/pkgs/comps/comps-f11.xml.in,v retrieving revision 1.234 diff -U 5 -r1.234 comps-f11.xml.in --- comps-f11.xml.in 14 May 2009 18:54:46 -0000 1.234 +++ comps-f11.xml.in 18 May 2009 15:39:54 -0000 @@ -830,10 +830,13 @@ boost-devel coolkey-devel cyrus-sasl-devel db4-devel dbus-devel + dbus-cxx-devel + dbus-cxx-doc + dbus-cxx-tools expat-devel gdbm-devel geoclue-devel gmp-devel gpm-devel @@ -931,10 +934,11 @@ bzr check clips clips-doc clips-xclips + clipsmm-devel clisp cmake cmucl codeblocks cogito @@ -1015,10 +1019,11 @@ monotone mr nasm nemiver nqc + nqc-doc ocaml oorexx patchy perl-perlmenu perltidy @@ -2420,10 +2425,11 @@ libsexy-devel libsexymm-devel libsigc++20-devel nemiver papyrus-devel + papyrus-doc papyrus-extras-devel papyrus-gtkmm-devel plotmm-devel scim-devel vala @@ -4255,17 +4261,19 @@ sunbird taskcoach taskjuggler tellico texmaker + tetex-IEEEtran tinyerp tinyerp-server vym wyrd xchm xdvik xfbib + xournal Zim online-docs Todd Zullinger wrote: > Rick L. Vinyard, Jr. wrote: >> Index: comps-f11.xml.in >> =================================================================== >> RCS file: /cvs/pkgs/comps/comps-f11.xml.in,v >> retrieving revision 1.234 >> retrieving revision 1.235 >> diff -u -p -r1.234 -r1.235 >> --- comps-f11.xml.in 14 May 2009 18:54:46 -0000 1.234 >> +++ comps-f11.xml.in 18 May 2009 15:41:06 -0000 1.235 >> @@ -1,6132 +0,0 @@ >> - >> -> "comps.dtd"> >> - > [many deleted lines snipped...] > > I'm guessing that deleting all the content of comps-f11.xml.in was not > intended. ;) > > -- > Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Experience is not what happens to a man. It is what a man does with > what happens to him. > -- Aldous Huxley > > From limb at jcomserv.net Mon May 18 16:08:35 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 18 May 2009 11:08:35 -0500 Subject: Package Maintainers Flags policy In-Reply-To: <4A118709.9080204@herr-schmitt.de> References: <20090518090953.5698908a@ohm.scrye.com> <29fee02b0905180853p2e544b18le6647e80d0d445a9@mail.gmail.com> <4A118709.9080204@herr-schmitt.de> Message-ID: <4A118803.9080801@jcomserv.net> Jochen Schmitt wrote: > Andrea Musuruane schrieb: >> May I kindly ask what is the reason behind this decision? Or, even >> better, can someone update the above wiki page explaining the reason? >> >> > Yes, I find this guideline anouyance. So a explaination, why we need this > policy may be helpful. > > Best Regards: > > Jochen Schmitt > I was wondering as well. If it's a disk space issue, like the new font guidelines, it makes sense, but otherwise at first blush it looks like a solution in search of a problem. Not flaming, just drawing a blank on the intended benefit. I agree that it should be on the wiki page. -- in your fear, speak only peace in your fear, seek only love -d. bowie From christoph.wickert at googlemail.com Mon May 18 16:12:13 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Mon, 18 May 2009 18:12:13 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <20090518090953.5698908a@ohm.scrye.com> References: <20090518090953.5698908a@ohm.scrye.com> Message-ID: <1242663133.8519.87.camel@localhost.localdomain> Am Montag, den 18.05.2009, 09:09 -0600 schrieb Kevin Fenzi: > In FESCo's 2009-03-28 meeting a policy on Flag usage for packages in > Fedora was approved. > > Due to an oversight, this policy was not announced here. ;( As such things have become more and more frequent I think we need to figure out why it was not announce, who was responsible for announcing it and how we can make sure it wont happen again. Why are so many meeting minutes missing recently? Looking through my mail for 2009 I see: * 2009-05-15 * 2009-05-07 was in fact 2008-05-08 but never mind * 2009-05-01 missing * 2009-04-24 missing * 2009-04-07 missing * 2009-04-10 * 2009-04-03 * 2009-03-27 missing * 2009-03-20 missing, this is the one with the flag proposal * 2009-03-13 missing * 2009-03-11 missing * 2009-03-06 * 2009-03-03 * 2009-02-27 * 2009-02-20 * 2009-02-13 * 2009-02-06 missing * 2009-02-05 * 2009-01-30 * 2009-01-16 * 2009-01-07 The wiki page at https://fedoraproject.org/wiki/Development/SteeringCommittee/Meetings is even more incomplete, only http://bpepple.fedorapeople.org/fesco/ is complete, but has no summaries. No on the topic itself: In addition to the questions Toshio already raised in trac (https://fedorahosted.org/fesco/ticket/110 ) and which were left unanswered, there are a more questions coming to my mind: 1. What is the rationale behind this policy? I understand there are political issues with flags but I think they are not addressed properly with this guideline. For example according to the policy the "Nazi flag" can be shipped in Fedora, as long is in a separate package . Not sure about the US, but here in Germany it's not allowed (only under certain circumstances). 2. As I don't understand the rationale I don't understand the benefit of the guideline. What is the advantage for Fedora as a project? I only see needless work for our volunteer maintainers. Also it is very likely that we need to fork with our patches and this is a contradiction to our upstream mantra. 3. What is "technically or substantively essential to the package"? E.g. I'm maintaining xfce4-xkb-plugin, which (by default) uses flags to indicate the keyboard layout. Is this essential and who decides? 4. Who defines the terms used in the policy, for e. g. what is an "ethnocultural concept" or what a "religion"? 5. Speaking of religions: Are other religions symbols or pieces of software like sword (bible study tool, used to be in Fedora) or glosung (daily watchwords) allowed? What is the difference between a christian cross and and a cross on a flag? 6. How do we make sure users are aware of the flags packages? 7. What to do with a package that wont work without flags? Regards, Christoph From sundaram at fedoraproject.org Mon May 18 16:18:20 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 18 May 2009 21:48:20 +0530 Subject: Abrt - should this be a feature? In-Reply-To: <4A116F78.3020607@redhat.com> References: <4A0DC949.7000601@fedoraproject.org> <4A116F78.3020607@redhat.com> Message-ID: <4A118A4C.3050909@fedoraproject.org> On 05/18/2009 07:53 PM, Zdenek Prikryl wrote: > > In F11 abrt doesn't replace bb, they can be enabled at the same time. Note that > abrt can catch more crashes than bb can (like non-gnome programs, kernel crashes > [kerneloops], ...). How can they be enabled at the same time? Where is that information documented? Rahul From Jochen at herr-schmitt.de Mon May 18 16:31:23 2009 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 18 May 2009 18:31:23 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <4A118803.9080801@jcomserv.net> References: <20090518090953.5698908a@ohm.scrye.com> <29fee02b0905180853p2e544b18le6647e80d0d445a9@mail.gmail.com> <4A118709.9080204@herr-schmitt.de> <4A118803.9080801@jcomserv.net> Message-ID: <4A118D5B.1050102@herr-schmitt.de> Jon Ciesla schrieb: > I was wondering as well. If it's a disk space issue, like the new > font guidelines, it makes sense, but otherwise at first blush it looks > like a solution in search of a problem. Not flaming, just drawing a > blank on the intended benefit. I agree that it should be on the wiki > page. > Either we have a good reason for this guideline or we should throw it away. We don't need a overregulation for creating packages. Best Regards: Jochen Schmitt From dimi at lattica.com Mon May 18 16:41:32 2009 From: dimi at lattica.com (Dimi Paun) Date: Mon, 18 May 2009 12:41:32 -0400 Subject: Sound doesn't work, again! In-Reply-To: <1242641298.30251.0.camel@macbook.infradead.org> References: <1242495430.3022.40.camel@dimi.lattica.com> <4A0F3AE1.3090709@comcast.net> <1242517467.3022.57.camel@dimi.lattica.com> <4A0F5FA8.9060302@comcast.net> <1242542114.3022.78.camel@dimi.lattica.com> <1242641298.30251.0.camel@macbook.infradead.org> Message-ID: <1242664892.3022.138.camel@dimi.lattica.com> On Mon, 2009-05-18 at 11:08 +0100, David Woodhouse wrote: > > I used to run F8 until recently, with PA giving me no end of > trouble. > > I could _not_ upgrade to either F9 or F10 due to a very serious bug > > in Anaconda/dmraid: > https://bugzilla.redhat.com/show_bug.cgi?id=468649 > > (essentially you could not install on a RAID 1 partition). > > You couldn't _install_ them but you could easily have updated with > yum, right? How would I know? This is my production box -- without it I'm dead. What if the dmraid bug was present even after install, and I could not boot? I didn't have the guts to try that on my production box. -- Dimi Paun Lattica, Inc. From lemenkov at gmail.com Mon May 18 16:41:56 2009 From: lemenkov at gmail.com (Peter Lemenkov) Date: Mon, 18 May 2009 20:41:56 +0400 Subject: Package Maintainers Flags policy In-Reply-To: <20090518090953.5698908a@ohm.scrye.com> References: <20090518090953.5698908a@ohm.scrye.com> Message-ID: Hello All! 2009/5/18 Kevin Fenzi : > In FESCo's 2009-03-28 meeting a policy on Flag usage for packages in > Fedora was approved. > > Due to an oversight, this policy was not announced here. ;( > > Please see: > > https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy > > and direct any comments to FESCo in a ticket or via the devel list. Useless policy. Maybe all other issues are already resolved and that's why FESCo members have too much free time to create such jokes? -- With best regards! From sundaram at fedoraproject.org Mon May 18 16:56:14 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 18 May 2009 22:26:14 +0530 Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> Message-ID: <4A11932E.8070000@fedoraproject.org> On 05/18/2009 10:11 PM, Peter Lemenkov wrote: > Hello All! > > 2009/5/18 Kevin Fenzi : >> In FESCo's 2009-03-28 meeting a policy on Flag usage for packages in >> Fedora was approved. >> >> Due to an oversight, this policy was not announced here. ;( >> >> Please see: >> >> https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy >> >> and direct any comments to FESCo in a ticket or via the devel list. > > Useless policy. Maybe all other issues are already resolved and that's > why FESCo members have too much free time to create such jokes? Hold on folks. There is no need to be rude. Let someone explain what is happening first. Rahul From rnicholsNOSPAM at comcast.net Mon May 18 16:51:57 2009 From: rnicholsNOSPAM at comcast.net (Robert Nichols) Date: Mon, 18 May 2009 11:51:57 -0500 Subject: Keyboard mapping characters with both shift keys In-Reply-To: <1242661593.3223.36.camel@localhost.localdomain> References: <4A1132C9.4040601@redhat.com> <9497e9990905180626w37f74f4qecb2a638b2caf361@mail.gmail.com> <1242661593.3223.36.camel@localhost.localdomain> Message-ID: Jesse Keating wrote: > On Mon, 2009-05-18 at 14:26 +0100, Mat Booth wrote: >> Curiously, you can observe the same behaviour in Windows. Is this a >> limitation of the keyboards themselves, perhaps? > > Some keyboards, really cheap ones, are incapable of handling three keys > pressed. I've ran into a few of them and immediately replaced them. Mine is a pretty decent HP keyboard that I really like. I'm not planning on replacing it any time soon. In fact, I've got another as a spare for when this one finally wears out. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it. From pingou at pingoured.fr Mon May 18 16:52:08 2009 From: pingou at pingoured.fr (Pierre-Yves) Date: Mon, 18 May 2009 18:52:08 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <4A11932E.8070000@fedoraproject.org> References: <20090518090953.5698908a@ohm.scrye.com> <4A11932E.8070000@fedoraproject.org> Message-ID: <1242665528.5855.20.camel@red.localdomain> On Mon, 2009-05-18 at 22:26 +0530, Rahul Sundaram wrote: > On 05/18/2009 10:11 PM, Peter Lemenkov wrote: > > Hello All! > > > > 2009/5/18 Kevin Fenzi : > >> In FESCo's 2009-03-28 meeting a policy on Flag usage for packages in > >> Fedora was approved. > >> > >> Due to an oversight, this policy was not announced here. ;( > >> > >> Please see: > >> > >> https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy > >> > >> and direct any comments to FESCo in a ticket or via the devel list. > > > > Useless policy. Maybe all other issues are already resolved and that's > > why FESCo members have too much free time to create such jokes? > > Hold on folks. There is no need to be rude. Let someone explain what is > happening first. Agreed, even if I'm not (yet) convince how useful is this policy being insulting is the last thing to be... Best regards, Pierre From stickster at gmail.com Mon May 18 16:56:22 2009 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 18 May 2009 12:56:22 -0400 Subject: F12 Naming: Cambridge -> Leonidas -> ? In-Reply-To: <20090518145214.GA2964@yoda.jdub.homelinux.org> References: <20090518145214.GA2964@yoda.jdub.homelinux.org> Message-ID: <20090518165622.GQ3634@localhost.localdomain> On Mon, May 18, 2009 at 10:52:14AM -0400, Josh Boyer wrote: > Hi All, > > It's that time of year again. Time to start the naming process > for the next Fedora release. > > To recap on the rules: > > 1) must have some link to Leonidas > > More specifically, the link should be > Leonidas is a and > is a > Where is the same for both > > 2) The link between and Leonidas cannot be the same as > between Cambridge and Leonidas. That link was "was a ship in the Union navy". > > We're repeating the collection process we used for Fedora 11 this > time. Contributors wishing to make a suggestion are asked to go to > the F11 naming wiki page, and add an entry to the suggestion table > found there: > > https://fedoraproject.org/wiki/Name_suggestions_for_Fedora_12 > > The naming submissions are open starting now until May 23. The > rest of the schedule is outlined on the wiki page. > > So, put on your thinking caps and come up with some really good > suggestions! > > Happy naming. Please remember as you add names to make sure there are at least a few ways to link *out* of the name. If you find an F12 name that has something in common with F11, but no other significance, it probably won't make a good name. For instance, I see a great name, "Hippocoon," on the list already, which has no other significance I can find beyond its connection with F11 (also a Spartan king). That means we can't easily link *from* Hippocoon to something else for F13, and this name will likely be cut from the list. The Board and I are going to have to go through these names manually, so we do ask that you give us a hand in advance by thinking through *each* of your name suggestions carefully, according to all the guidelines on the wiki page. Thanks very much for your help! -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From tgl at redhat.com Mon May 18 17:07:55 2009 From: tgl at redhat.com (Tom Lane) Date: Mon, 18 May 2009 13:07:55 -0400 Subject: Package Maintainers Flags policy In-Reply-To: <4A11932E.8070000@fedoraproject.org> References: <20090518090953.5698908a@ohm.scrye.com> <4A11932E.8070000@fedoraproject.org> Message-ID: <3233.1242666475@sss.pgh.pa.us> Rahul Sundaram writes: > On 05/18/2009 10:11 PM, Peter Lemenkov wrote: >> Useless policy. Maybe all other issues are already resolved and that's >> why FESCo members have too much free time to create such jokes? > Hold on folks. There is no need to be rude. Let someone explain what is > happening first. It would be a good idea if the policy page itself contained some justification. Otherwise, anyone looking at it is going to think pretty much the same things expressed in this thread. For most of us this is a no-op, but for anyone actually affected, complying with this policy is going to be a serious PITA. You'd better provide a convincing justification, or you will not get (voluntary) compliance. regards, tom lane From andreas at bawue.net Mon May 18 17:11:22 2009 From: andreas at bawue.net (Andreas Thienemann) Date: Mon, 18 May 2009 19:11:22 +0200 (CEST) Subject: Package Maintainers Flags policy In-Reply-To: <20090518090953.5698908a@ohm.scrye.com> References: <20090518090953.5698908a@ohm.scrye.com> Message-ID: On Mon, 18 May 2009, Kevin Fenzi wrote: > In FESCo's 2009-03-28 meeting a policy on Flag usage for packages in > Fedora was approved. > > Due to an oversight, this policy was not announced here. ;( https://fedorahosted.org/fesco/ticket/154 According to Jon Stanly this should come up on the meeting on friday, 1700 UTC. Instead of further discussing this on the mailinglist, I'd suggest showing up at the meeting and getting your point across there. regards, andreas From bnocera at redhat.com Mon May 18 17:18:07 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 18 May 2009 18:18:07 +0100 Subject: Package Maintainers Flags policy In-Reply-To: <20090518090953.5698908a@ohm.scrye.com> References: <20090518090953.5698908a@ohm.scrye.com> Message-ID: <1242667087.25634.1927.camel@cookie.hadess.net> On Mon, 2009-05-18 at 09:09 -0600, Kevin Fenzi wrote: > In FESCo's 2009-03-28 meeting a policy on Flag usage for packages in > Fedora was approved. > > Due to an oversight, this policy was not announced here. ;( > > Please see: > > https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy > > and direct any comments to FESCo in a ticket or via the devel list. > > Thanks, and sorry for the oversight. ;( This should explain the reason why country flags shouldn't show up in interfaces: http://community.livejournal.com/xkbconfig/982.html (I didn't even read the policy, but I guess it's the same one we had arguments over in GNOME 6 years ago, and a bit before that in RH itself). It could cause problems in Europe, in Asia, and in North America (and that's just on top of my head). Cheers From denis at poolshark.org Mon May 18 17:18:07 2009 From: denis at poolshark.org (Denis Leroy) Date: Mon, 18 May 2009 19:18:07 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <20090518090953.5698908a@ohm.scrye.com> References: <20090518090953.5698908a@ohm.scrye.com> Message-ID: <4A11984F.2060605@poolshark.org> On 05/18/2009 05:09 PM, Kevin Fenzi wrote: > In FESCo's 2009-03-28 meeting a policy on Flag usage for packages in > Fedora was approved. > > Due to an oversight, this policy was not announced here. ;( > > Please see: > > https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy Surely, this needs to go through FPC first. From tcallawa at redhat.com Mon May 18 17:17:23 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 18 May 2009 13:17:23 -0400 Subject: Package Maintainers Flags policy In-Reply-To: <29fee02b0905180853p2e544b18le6647e80d0d445a9@mail.gmail.com> References: <20090518090953.5698908a@ohm.scrye.com> <29fee02b0905180853p2e544b18le6647e80d0d445a9@mail.gmail.com> Message-ID: <4A119823.4090509@redhat.com> On 05/18/2009 11:53 AM, Andrea Musuruane wrote: > May I kindly ask what is the reason behind this decision? Or, even > better, can someone update the above wiki page explaining the reason? As the person who drafted the flags policy, let me try to explain the rationale: In January, Roozbeh Pournader posted to fedora-legal-list where he said the following: I recently found that Deluge is using country flags to indicate the location of bittorrent peers. Flags are cute and nice of course (and a mental exercise), but are geopolitical hot spots. Upstream didn't like the concern, calling some people (including me?) "crazy ideologists". But the Fedora maintainer (Peter Gordon) fixed the bug in Rawhide (but we're still shipping flags in F9 and F10): https://bugzilla.redhat.com/show_bug.cgi?id=479265 But this is not why I'm writing. I'm writing because during the report, I found that we really don't have any official policy on flags. All I found in the wiki was what I had written myself a while ago, here, which is just based on my own experience as an i18n guy: http://fedoraproject.org/wiki/Languages #I_wish_to_use_my_country.27s_flag_to_refer_to_my_language But we really need a policy. And I thought this list is the best forum to get it into shape. The history is like this: With RHL 8.0, Red Hat decided to remove the Taiwan/Republic of China flag from KDE because of sensitivities/legal requirements of mainland/People's Rebublic of China. That created some public unease, including people stopping to use RHL because of that. Red Hat went a bit further of course, and removed all national flags in a later version. He raised some specific concerns, it is worth reading his original email: http://www.mail-archive.com/fedora-legal-list at redhat.com/msg00206.html At the time, the only policy in place was the informal, unwritten, no flags policy that we inherited from Red Hat Linux. I consulted with Red Hat Legal to codify that into a more formal policy for Fedora to use. Red Hat Legal felt that there was minimal legal risk to including flags, although, by having them, it may prevent Fedora from being available/acceptable in some countries (China being a notable example). Based on his original request (and his repeated reminders), I drafted this policy and submitted it to FESCo for review. I did not tell FESCo that they had to pass this for legal reasons (those sorts of things I'm empowered to simply implement), nor did Red Hat require this. If FESCo decides that they are not concerned about the possible geopolitical controversy or possible international restrictions, there's no skin off my back. I just drafted it upon the request of Fedora Community members. Tom "spot" Callaway, Fedora Legal From Jochen at herr-schmitt.de Mon May 18 17:28:17 2009 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 18 May 2009 19:28:17 +0200 Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> Message-ID: <4A119AB1.3010405@herr-schmitt.de> Andreas Thienemann schrieb: > https://fedorahosted.org/fesco/ticket/154 > > According to Jon Stanly this should come up on the meeting on friday, > 1700 UTC. > > +1 Best Regards: Jochen Schmitt From kevin.kofler at chello.at Mon May 18 17:32:56 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 18 May 2009 19:32:56 +0200 Subject: Package Maintainers Flags policy References: <20090518090953.5698908a@ohm.scrye.com> <1242667087.25634.1927.camel@cookie.hadess.net> Message-ID: Bastien Nocera wrote: > (I didn't even read the policy, but I guess it's the same one we had > arguments over in GNOME 6 years ago, and a bit before that in RH > itself). On the other hand, KDE upstream explicitly decided NOT to ban flags, as they consider banning flags to be a political move and to go against KDE's principle of political neutrality. Some involved also considered it a free speech issue. (Sorry, this is from memory, I can't find the old ML link right now.) And FYI, the current policy doesn't ban flags entirely, but they have to be in a -flags package which is not installed by default (this is now implemented for kdebase-runtime, it has a kdebase-runtime-flags subpackage; before that, flags used to be removed from kdebase-runtime entirely, as per the old unwritten policy, the current one is a compromise). It shall be noted that many users complained about flags being removed (they expect the keyboard layout chooser to use them), and the current solution where -flags is optional and not installed by default isn't very helpful either (but better than not having them at all). Kevin Kofler From notting at redhat.com Mon May 18 17:36:51 2009 From: notting at redhat.com (Bill Nottingham) Date: Mon, 18 May 2009 13:36:51 -0400 Subject: Package Maintainers Flags policy In-Reply-To: <4A11984F.2060605@poolshark.org> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> Message-ID: <20090518173651.GA6318@nostromo.devel.redhat.com> Denis Leroy (denis at poolshark.org) said: >> Due to an oversight, this policy was not announced here. ;( >> >> Please see: >> >> https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy > > Surely, this needs to go through FPC first. Given that it's (essentially) a legal issue (affecting distribution/ availability of Fedora), I don't see that. In much the same way that patents aren't a FPC consideration. Bill From denis at poolshark.org Mon May 18 17:39:05 2009 From: denis at poolshark.org (Denis Leroy) Date: Mon, 18 May 2009 19:39:05 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <20090518173651.GA6318@nostromo.devel.redhat.com> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> Message-ID: <4A119D39.2040905@poolshark.org> On 05/18/2009 07:36 PM, Bill Nottingham wrote: > Given that it's (essentially) a legal issue (affecting distribution/ > availability of Fedora), I don't see that. In much the same way that > patents aren't a FPC consideration. Whether such a policy is necessary or not may be a legal issue, but the technical implementation of it is very much an FPC consideration. From tcallawa at redhat.com Mon May 18 17:40:30 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 18 May 2009 13:40:30 -0400 Subject: Package Maintainers Flags policy In-Reply-To: <4A119D39.2040905@poolshark.org> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A119D39.2040905@poolshark.org> Message-ID: <4A119D8E.7040502@redhat.com> On 05/18/2009 01:39 PM, Denis Leroy wrote: > On 05/18/2009 07:36 PM, Bill Nottingham wrote: >> Given that it's (essentially) a legal issue (affecting distribution/ >> availability of Fedora), I don't see that. In much the same way that >> patents aren't a FPC consideration. > > Whether such a policy is necessary or not may be a legal issue, but the > technical implementation of it is very much an FPC consideration. Well, in this case, Red Hat Legal specifically recommended the technical implementation. I admit it is a weird gray area, which is why I sent it to FESCo. ~spot From jkeating at redhat.com Mon May 18 17:44:50 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 18 May 2009 10:44:50 -0700 Subject: Package Maintainers Flags policy In-Reply-To: <4A119D39.2040905@poolshark.org> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A119D39.2040905@poolshark.org> Message-ID: <1242668690.3223.51.camel@localhost.localdomain> On Mon, 2009-05-18 at 19:39 +0200, Denis Leroy wrote: > Whether such a policy is necessary or not may be a legal issue, but the > technical implementation of it is very much an FPC consideration. Sure, if you really want to get into a jurisdiction pissing match, FESCo can determine that flags shouldn't be installed as part of the base package, and leave it up to the packaging committee to figure out how else they could be installed. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bnocera at redhat.com Mon May 18 17:45:45 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 18 May 2009 18:45:45 +0100 Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <1242667087.25634.1927.camel@cookie.hadess.net> Message-ID: <1242668745.25634.2042.camel@cookie.hadess.net> On Mon, 2009-05-18 at 19:32 +0200, Kevin Kofler wrote: > Bastien Nocera wrote: > > (I didn't even read the policy, but I guess it's the same one we had > > arguments over in GNOME 6 years ago, and a bit before that in RH > > itself). > > On the other hand, KDE upstream explicitly decided NOT to ban flags, as they > consider banning flags to be a political move and to go against KDE's > principle of political neutrality. And as soon as you make a choice, one way or the other, you end up not being neutral any more. Maybe the project is neutral, but the person that makes the decision and is part of the project isn't. From denis at poolshark.org Mon May 18 17:52:57 2009 From: denis at poolshark.org (Denis Leroy) Date: Mon, 18 May 2009 19:52:57 +0200 Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <1242667087.25634.1927.camel@cookie.hadess.net> Message-ID: <4A11A079.20603@poolshark.org> On 05/18/2009 07:32 PM, Kevin Kofler wrote: > Bastien Nocera wrote: >> And FYI, the current policy doesn't ban flags entirely, but they have to be > in a -flags package which is not installed by default That's about the same as banning them. What percentage of users do you think will install them, let alone be aware they exist ? I understand the reasoning behind this policy, but overall this seems like a gross overreaction. We have a vast international community here, why not let this community write up a black-list of sensitive flags to avoid, rather than ban'em all ? -denis From dominik at greysector.net Mon May 18 17:53:41 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 18 May 2009 19:53:41 +0200 Subject: FESco meeting summary for 20090507 In-Reply-To: <20090514130158.GA7053@mokona.greysector.net> References: <20090514130158.GA7053@mokona.greysector.net> Message-ID: <20090518175341.GB7321@mokona.greysector.net> On Thursday, 14 May 2009 at 15:01, Dominik 'Rathann' Mierzejewski wrote: > On Saturday, 09 May 2009 at 19:24, Jon Stanley wrote: [...] > > Rel-eng brought a proposal during the open floor to allow the > > inclusion of packages in a special tag (something like dist-f12-maven) > > in preparation for the maven upgrade that had yet to be through a > > formal package review. These packages are not yet in a state suitable > > for inclusion in Fedora, and the Java team would prefer to get them > > functional prior to cleaning up the packaging. FESCo approved this > > propsal, with the caveat that the packages have to go through a > > mini-review prior to inclusiion in this tag and therefore being used > > in buildroots. This mini-review will be defined by FPC, and will > > include things such as checking for lack of binaries, and legal > > concerns. > > As a packager and a member of the FPC, I think it is a very bad idea to let > packages in without proper review. I'd like to hear the very convincing > arguments which I expect were presented directly to some FESCo members > but were not included in the IRC meeting log for why this was allowed and > why the packages in question (which ones, exactly?) couldn't go through > the usual hoops like all new packages. > I don't see why the Java team (who, exactly?) or anyone else should > be allowed to import packages into Fedora CVS without proper review. Four days have passed and my questions above are still unanswered. Is FESCo trying to ignore the issues raised? Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From skvidal at fedoraproject.org Mon May 18 17:54:53 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 18 May 2009 13:54:53 -0400 (EDT) Subject: Package Maintainers Flags policy In-Reply-To: <4A11A079.20603@poolshark.org> References: <20090518090953.5698908a@ohm.scrye.com> <1242667087.25634.1927.camel@cookie.hadess.net> <4A11A079.20603@poolshark.org> Message-ID: On Mon, 18 May 2009, Denis Leroy wrote: > On 05/18/2009 07:32 PM, Kevin Kofler wrote: >> Bastien Nocera wrote: >>> And FYI, the current policy doesn't ban flags entirely, but they have to >>> be >> in a -flags package which is not installed by default > > That's about the same as banning them. What percentage of users do you think > will install them, let alone be aware they exist ? I understand the reasoning > behind this policy, but overall this seems like a gross overreaction. We have > a vast international community here, why not let this community write up a > black-list of sensitive flags to avoid, rather than ban'em all ? > B/c the members from Ihaterandomstan and the folks from randomstan will never come to consensus short of involving the UN or possibly Jimmy Carter. -sv From cmadams at hiwaay.net Mon May 18 17:56:39 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 18 May 2009 12:56:39 -0500 Subject: Package Maintainers Flags policy In-Reply-To: <4A11A079.20603@poolshark.org> References: <20090518090953.5698908a@ohm.scrye.com> <1242667087.25634.1927.camel@cookie.hadess.net> <4A11A079.20603@poolshark.org> Message-ID: <20090518175639.GC1520737@hiwaay.net> Once upon a time, Denis Leroy said: > We have a vast international community here, why not let > this community write up a black-list of sensitive flags to avoid, rather > than ban'em all ? So what do you do when country A wants country B's flag removed and country B wants country A's flag removed? Who gets to say which flag is in and which flag is out? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jarod at redhat.com Mon May 18 18:02:07 2009 From: jarod at redhat.com (Jarod Wilson) Date: Mon, 18 May 2009 14:02:07 -0400 Subject: FESco meeting summary for 20090507 In-Reply-To: <20090518175341.GB7321@mokona.greysector.net> References: <20090514130158.GA7053@mokona.greysector.net> <20090518175341.GB7321@mokona.greysector.net> Message-ID: <200905181402.07942.jarod@redhat.com> On Monday 18 May 2009 13:53:41 Dominik 'Rathann' Mierzejewski wrote: > On Thursday, 14 May 2009 at 15:01, Dominik 'Rathann' Mierzejewski wrote: > > On Saturday, 09 May 2009 at 19:24, Jon Stanley wrote: > [...] > > > Rel-eng brought a proposal during the open floor to allow the > > > inclusion of packages in a special tag (something like dist-f12-maven) > > > in preparation for the maven upgrade that had yet to be through a > > > formal package review. These packages are not yet in a state suitable > > > for inclusion in Fedora, and the Java team would prefer to get them > > > functional prior to cleaning up the packaging. FESCo approved this > > > propsal, with the caveat that the packages have to go through a > > > mini-review prior to inclusiion in this tag and therefore being used > > > in buildroots. This mini-review will be defined by FPC, and will > > > include things such as checking for lack of binaries, and legal > > > concerns. > > > > As a packager and a member of the FPC, I think it is a very bad idea to let > > packages in without proper review. I'd like to hear the very convincing > > arguments which I expect were presented directly to some FESCo members > > but were not included in the IRC meeting log for why this was allowed and > > why the packages in question (which ones, exactly?) couldn't go through > > the usual hoops like all new packages. > > I don't see why the Java team (who, exactly?) or anyone else should > > be allowed to import packages into Fedora CVS without proper review. > > Four days have passed and my questions above are still unanswered. > Is FESCo trying to ignore the issues raised? Not intentionally, so far as I know. I missed the meeting in question myself though, so I missed out on the convincing arguments too... Can we perhaps revisit the topic in this week's meeting? -- Jarod Wilson jarod at redhat.com From mjg at redhat.com Mon May 18 18:33:02 2009 From: mjg at redhat.com (Matthew Garrett) Date: Mon, 18 May 2009 19:33:02 +0100 Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <1242667087.25634.1927.camel@cookie.hadess.net> Message-ID: <20090518183302.GA15180@srcf.ucam.org> On Mon, May 18, 2009 at 07:32:56PM +0200, Kevin Kofler wrote: > It shall be noted that many users complained about flags being removed (they > expect the keyboard layout chooser to use them), and the current solution > where -flags is optional and not installed by default isn't very helpful > either (but better than not having them at all). They may expect the keyboard layout chooser to use them, but you end up with awkward situations where geopolitical flags don't usefully represent keyboard layouts that are used in multiple countries or countries which have multiple keyboard layouts. Even from a purely technical perspective, flags rarely accurately depict what you're trying to present to the user. -- Matthew Garrett | mjg59 at srcf.ucam.org From kevin.kofler at chello.at Mon May 18 18:41:05 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 18 May 2009 20:41:05 +0200 Subject: Package Maintainers Flags policy References: <20090518090953.5698908a@ohm.scrye.com> <1242667087.25634.1927.camel@cookie.hadess.net> <20090518183302.GA15180@srcf.ucam.org> Message-ID: Matthew Garrett wrote: > They may expect the keyboard layout chooser to use them, but you end up > with awkward situations where geopolitical flags don't usefully > represent keyboard layouts that are used in multiple countries or > countries which have multiple keyboard layouts. Even from a purely > technical perspective, flags rarely accurately depict what you're trying > to present to the user. Yet KDE upstream and basically all the distros shipping KDE use them. We are the odd ones out. Kevin Kofler From mjg at redhat.com Mon May 18 18:58:41 2009 From: mjg at redhat.com (Matthew Garrett) Date: Mon, 18 May 2009 19:58:41 +0100 Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <1242667087.25634.1927.camel@cookie.hadess.net> <20090518183302.GA15180@srcf.ucam.org> Message-ID: <20090518185841.GA15550@srcf.ucam.org> On Mon, May 18, 2009 at 08:41:05PM +0200, Kevin Kofler wrote: > Matthew Garrett wrote: > > They may expect the keyboard layout chooser to use them, but you end up > > with awkward situations where geopolitical flags don't usefully > > represent keyboard layouts that are used in multiple countries or > > countries which have multiple keyboard layouts. Even from a purely > > technical perspective, flags rarely accurately depict what you're trying > > to present to the user. > > Yet KDE upstream and basically all the distros shipping KDE use them. We are > the odd ones out. There's several cases where we fix bugs that upstream thinks of as features. -- Matthew Garrett | mjg59 at srcf.ucam.org From paul-fedora at saturnine.org.uk Mon May 18 19:11:37 2009 From: paul-fedora at saturnine.org.uk (Paul Black) Date: Mon, 18 May 2009 20:11:37 +0100 Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <1242667087.25634.1927.camel@cookie.hadess.net> Message-ID: 2009/5/18 Kevin Kofler > And FYI, the current policy doesn't ban flags entirely, but they have to be > in a -flags package which is not installed by default (this is now > implemented for kdebase-runtime, it has a kdebase-runtime-flags subpackage; > before that, flags used to be removed from kdebase-runtime entirely, as per > the old unwritten policy, the current one is a compromise). Out of curiosity, any reason this is done for kdebase-runtime but not ktorrent? -- Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdieter at gmail.com Mon May 18 19:43:38 2009 From: jdieter at gmail.com (Jonathan Dieter) Date: Mon, 18 May 2009 22:43:38 +0300 Subject: Package Maintainers Flags policy In-Reply-To: <1242667087.25634.1927.camel@cookie.hadess.net> References: <20090518090953.5698908a@ohm.scrye.com> <1242667087.25634.1927.camel@cookie.hadess.net> Message-ID: <1242675818.15983.49.camel@jdlaptop.lesbg.loc> On Mon, 2009-05-18 at 18:18 +0100, Bastien Nocera wrote: > This should explain the reason why country flags shouldn't show up in > interfaces: > http://community.livejournal.com/xkbconfig/982.html > > (I didn't even read the policy, but I guess it's the same one we had > arguments over in GNOME 6 years ago, and a bit before that in RH > itself). > > It could cause problems in Europe, in Asia, and in North America (and > that's just on top of my head). And the Middle East. The display of certain flags here is can be a bit...interesting. I understand the desire for pretty icons, but having the wrong icon show up in front of the wrong person in the school I teach at could have some very unpleasant effects. (And, yes, we are running Fedora on our workstations, so this isn't a completely theoretical problem) So, please, leave the flag icons out of the main packages. Thanks, Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From josef at toxicpanda.com Mon May 18 20:07:12 2009 From: josef at toxicpanda.com (Josef Bacik) Date: Mon, 18 May 2009 16:07:12 -0400 Subject: Warning for F11 BTRFS users In-Reply-To: References: <1b7401870905160825s19c6788et94b446fd5ae7f619@mail.gmail.com> Message-ID: <1b7401870905181307t37e4ca8fp76d737f13e9a8858@mail.gmail.com> On Sat, May 16, 2009 at 6:12 PM, Matej Cepl wrote: > On 2009-05-16, 15:25 GMT, Josef Bacik wrote: >> Don't go to 2.6.29.3-140. ?Something's gone horribly wrong. >> I'm working on fixing it, I'll let you know when you are safe >> to upgrade your kernel again (all 2 other users :) ). ?Sorry >> about that, > > I wasn't the only one? > hehe, Eric Paris is also an unfortunate tester. BTW this is fixed in cvs now, so there should be a build at some point, I've been running with it on my desktop for a few hours now and everything is ok. Sorry for the interruption, we now return you to your regularly scheduled program. Josef From rc040203 at freenet.de Mon May 18 19:18:03 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 18 May 2009 21:18:03 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <20090518173651.GA6318@nostromo.devel.redhat.com> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> Message-ID: <4A11B46B.3010102@freenet.de> Bill Nottingham wrote: > Denis Leroy (denis at poolshark.org) said: >>> Due to an oversight, this policy was not announced here. ;( >>> >>> Please see: >>> >>> https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy >> Surely, this needs to go through FPC first. > > Given that it's (essentially) a legal issue (affecting distribution/ > availability of Fedora), I don't see that this is a legal issue, but a political one. It would only be a legal issue to Fedora, if using "flags" was a subject to US laws. > I don't see that. In much the same way that > patents aren't a FPC consideration. ACK. Not FPC's business. Ralf From bjorn at xn--rombobjrn-67a.se Mon May 18 20:38:45 2009 From: bjorn at xn--rombobjrn-67a.se (=?iso-8859-1?q?Bj=F6rn_Persson?=) Date: Mon, 18 May 2009 22:38:45 +0200 Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <1242667087.25634.1927.camel@cookie.hadess.net> Message-ID: <200905182239.04065.bjorn@xn--rombobjrn-67a.se> Kevin Kofler wrote: > It shall be noted that many users complained about flags being removed > (they expect the keyboard layout chooser to use them), and the current > solution where -flags is optional and not installed by default isn't very > helpful either (but better than not having them at all). To me it would seem more reasonable to install the flags by default. Then the anti-whatever extremists could just remove them, and the more relaxed among us would see the user interface the way the authors intended without jumping through additional hoops. To make it easy to remove all flags there could be a ban-flags package that would conflict with all the -flags subpackages. Bj?rn Persson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From bjorn at xn--rombobjrn-67a.se Mon May 18 20:39:09 2009 From: bjorn at xn--rombobjrn-67a.se (=?iso-8859-1?q?Bj=F6rn_Persson?=) Date: Mon, 18 May 2009 22:39:09 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <4A11A079.20603@poolshark.org> References: <20090518090953.5698908a@ohm.scrye.com> <4A11A079.20603@poolshark.org> Message-ID: <200905182239.09244.bjorn@xn--rombobjrn-67a.se> Denis Leroy wrote: > On 05/18/2009 07:32 PM, Kevin Kofler wrote: > > And FYI, the current policy doesn't ban flags entirely, but they have to > > be in a -flags package which is not installed by default > > That's about the same as banning them. What percentage of users do you > think will install them, let alone be aware they exist ? It wouldn't be so bad if a package could suggest another package without requiring it, so that Yum or PackageKit could tell the user "There is also a kdebase-runtime-flags package that you can install if you like". Bj?rn Persson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From tomek at pipebreaker.pl Mon May 18 20:59:31 2009 From: tomek at pipebreaker.pl (Tomasz Torcz) Date: Mon, 18 May 2009 22:59:31 +0200 Subject: Warning for F11 BTRFS users In-Reply-To: <1b7401870905181307t37e4ca8fp76d737f13e9a8858@mail.gmail.com> References: <1b7401870905160825s19c6788et94b446fd5ae7f619@mail.gmail.com> <1b7401870905181307t37e4ca8fp76d737f13e9a8858@mail.gmail.com> Message-ID: <20090518205931.GA1990@mother.fordon.pl.eu.org> On Mon, May 18, 2009 at 04:07:12PM -0400, Josef Bacik wrote: > On Sat, May 16, 2009 at 6:12 PM, Matej Cepl wrote: > > On 2009-05-16, 15:25 GMT, Josef Bacik wrote: > >> Don't go to 2.6.29.3-140. ?Something's gone horribly wrong. > >> I'm working on fixing it, I'll let you know when you are safe > >> to upgrade your kernel again (all 2 other users :) ). ?Sorry > >> about that, > > > > I wasn't the only one? > > > > hehe, Eric Paris is also an unfortunate tester. BTW this is fixed in > cvs now, so there should be a build at some point, I've been running > with it on my desktop for a few hours now and everything is ok. Sorry > for the interruption, we now return you to your regularly scheduled > program. Could you share some information just how fatal -140 is? I don't know if I could reboot safely :) -- Tomasz Torcz "Funeral in the morning, IDE hacking xmpp: zdzichubg at chrome.pl in the afternoon and evening." - Alan Cox From martin.sourada at gmail.com Mon May 18 21:21:05 2009 From: martin.sourada at gmail.com (Martin Sourada) Date: Mon, 18 May 2009 23:21:05 +0200 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A0814ED.60205@redhat.com> References: <4A0814ED.60205@redhat.com> Message-ID: <1242681665.8893.13.camel@pc-notebook.kolej.mff.cuni.cz> On Mon, 2009-05-11 at 08:07 -0400, Stephen Gallagher wrote: > OK, first off, why in $DEITY's name are we including Firefox 3.5b4 and > Thunderbird 3.0b2 in Fedora 11? These are unstable branches of the > browser and email client, and as such are supported by almost none of > the myriad of extensions available for the 3.0 and 2.0 versions, > respectively. > > I was more than a little disappointed when I upgraded my laptop to the > F11 Preview to discover that only two out of seven of my Thunderbird > extensions and three of my thirteen Firefox extensions remained functional. > > I understand that Fedora is a development OS, and I think it's a great > idea to have a firefox35 package and a thunderbird30 package, but these > SHOULD NOT be the defaults. > > Taking away the full functionality of a developer's web browser and > email client is an incredible step backwards for Fedora 11. The default > install of Fedora 11 should include the latest STABLE versions of > Firefox and Thunderbird, and then provide an OPTION to replace them with > the unstable development branch. > > I would understand if Firefox and Thunderbird were in their release > candidate phase, and we could reasonably expect that within three months > that they would hit final release. Firefox has no definitive (or even > approximate) release date scheduled, and Thunderbird is only in its > second beta. There is little-to-no guarantee that either of these > products will be deemed stable before Fedora 12, and I think it is a > severe mistake to make them the default before then. > > If nothing else, consider this an open request to the Firefox, > Thunderbird and Lightning maintainers to provide a compatibility package > that can downgrade and replace the unstable and non-extensible versions > currently in the distribution. Hrm, from a viewport of a xulrunner user (via epiphany), lately much more webkitgtk user (via midori), and an evolution user, I'd say the new gecko works worse in some areas (and better in others) than the one in F10, yet it seems feasible that firefox 3.5 stable floods the tubes within the F11-being-latest-stable timeframe. Considering how wonky the firefox release process is and how our users have strong desire to have the newest technology, I certainly don't envy whoever makes the final decision whether we'll go with it or revert. This time I am geared towards including FF3.5 in F11. As for thunderbird, seeing how it's only a second beta, I'd say we're a little early here, but considering it is not our default mail client, and is not even installed by default, I don't see it as much bigger issue either. Just my 2 cents, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From josef at toxicpanda.com Mon May 18 21:22:45 2009 From: josef at toxicpanda.com (Josef Bacik) Date: Mon, 18 May 2009 17:22:45 -0400 Subject: Warning for F11 BTRFS users In-Reply-To: <20090518205931.GA1990@mother.fordon.pl.eu.org> References: <1b7401870905160825s19c6788et94b446fd5ae7f619@mail.gmail.com> <1b7401870905181307t37e4ca8fp76d737f13e9a8858@mail.gmail.com> <20090518205931.GA1990@mother.fordon.pl.eu.org> Message-ID: <1b7401870905181422t618122d1h6509e4ddca0c7a44@mail.gmail.com> 2009/5/18 Tomasz Torcz : > On Mon, May 18, 2009 at 04:07:12PM -0400, Josef Bacik wrote: >> On Sat, May 16, 2009 at 6:12 PM, Matej Cepl wrote: >> > On 2009-05-16, 15:25 GMT, Josef Bacik wrote: >> >> Don't go to 2.6.29.3-140. ?Something's gone horribly wrong. >> >> I'm working on fixing it, I'll let you know when you are safe >> >> to upgrade your kernel again (all 2 other users :) ). ?Sorry >> >> about that, >> > >> > I wasn't the only one? >> > >> >> hehe, Eric Paris is also an unfortunate tester. ?BTW this is fixed in >> cvs now, so there should be a build at some point, I've been running >> with it on my desktop for a few hours now and everything is ok. ?Sorry >> for the interruption, we now return you to your regularly scheduled >> program. > > ?Could you share some information just how fatal -140 is? I don't know > if I could reboot safely :) > Yeah you can reboot safely, just anything that uses mmap isn't going to work. Yum wont work :) Josef From xavier at bachelot.org Mon May 18 20:46:43 2009 From: xavier at bachelot.org (Xavier Bachelot) Date: Mon, 18 May 2009 22:46:43 +0200 Subject: New soname changing ClanLib coming to F-12 repo / buildroot In-Reply-To: <4A116D58.8060403@hhs.nl> References: <4A116D58.8060403@hhs.nl> Message-ID: <4A11C933.50900@bachelot.org> Hans de Goede wrote: > Hi all, > > koji is currently building the new upstream 1.0.0 release > of ClanLib. This is really is a bugfix release in the 0.8.x > series, but to make clear the 0.8.x series is stable it > has been renamed to the 1.0.x series, including a change > in the soname. > > This release is 100% API compatible with the 0.8 series, > so all you need to do is a rebuild. Here is a list of > the dependend packages: > > [hans at localhost devel]$ repoquery -q --whatrequires --alldeps ClanLib > openalchemist-0:0.3-5.fc11.x86_64 > ballbuster-0:1.0-7.fc11.x86_64 > trophy-0:1.1.5-3.fc11.x86_64 > methane-0:1.4.7-6.fc11.x86_64 > > 3 of those are mine and I'll take care of rebuilding them, > that only leaves openalchemist, whose maintainer is in the CC > > Regards, > > Hans Hi Hans, Thanks for the heads up, openalchemist has been rebuilt. Regards, Xavier From opensource at till.name Mon May 18 21:50:35 2009 From: opensource at till.name (Till Maas) Date: Mon, 18 May 2009 23:50:35 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <20090518090953.5698908a@ohm.scrye.com> References: <20090518090953.5698908a@ohm.scrye.com> Message-ID: <200905182350.41222.opensource@till.name> On Mo Mai 18 2009, Kevin Fenzi wrote: > In FESCo's 2009-03-28 meeting a policy on Flag usage for packages in > Fedora was approved. > > Due to an oversight, this policy was not announced here. ;( Why is this a policy and not some packaging guideline. It clearly contains packaging instructions: | flag images must be placed in an -flags subpackage. The -flags subpackage | cannot be Required by the main package. Also this is something that should probably be checked at review time, which also makes it better suited in the review guidelines. Additionally the visibility of this page is pretty low, it is not linked from any other page. There is only a redirection from probably Tom Callaways proposal page: https://fedoraproject.org/wiki/Special:WhatLinksHere/Package_Maintainers_Flags_Policy And I agree that the title of the page is badly chosen, because it is not about flags regarding package maintainers. I also assumed some boolean flag, e.g. like the CVS request flag in bugzilla. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From gmaxwell at gmail.com Mon May 18 22:07:03 2009 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Mon, 18 May 2009 18:07:03 -0400 Subject: Downgrading Firefox 3.5 and Thunderbird 3.0 In-Reply-To: <4A0835B6.3000102@redhat.com> References: <4A0814ED.60205@redhat.com> <4A0821D1.8050803@comcast.net> <4A0824B7.90106@silfreed.net> <4A083314.9020802@comcast.net> <4A0835B6.3000102@redhat.com> Message-ID: On Mon, May 11, 2009 at 10:27 AM, Stephen Gallagher wrote: > Ok, just so I make sure I understand your argument completely. "It's > fine to include a pre-release copy of Thunderbird and Firefox because > you can bludgeon unsupported extensions into being supported by > following an undocumented and potentially dangerous hack." > > Seriously, people. This is exactly the sort of elitist bullshit that > puts people off of using Fedora. Furthermore, it's damned hypocritical. [snip] This isn't a pre-release / release issue. Extensions will lag the formal release by months. This is a long-standing problem for our upstream there. Mozilla has been doing some aggressive work trying to get extensions updated ahead of the release which is why any work now at all. The ones who have not yet updated for 3.5 will very likely still not be upgraded by the time of the formal release. And, yes? The RC is pending: http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/9b34f6991d125306/56495ed84714afd9?lnk=raot#56495ed84714afd9 From kevin.kofler at chello.at Tue May 19 00:28:55 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 19 May 2009 02:28:55 +0200 Subject: Package Maintainers Flags policy References: <20090518090953.5698908a@ohm.scrye.com> <1242667087.25634.1927.camel@cookie.hadess.net> <1242675818.15983.49.camel@jdlaptop.lesbg.loc> Message-ID: Jonathan Dieter wrote: > On Mon, 2009-05-18 at 18:18 +0100, Bastien Nocera wrote: >> It could cause problems in Europe, in Asia, and in North America (and >> that's just on top of my head). > > And the Middle East. Last I checked the Middle East was in Asia. ;-) Kevin Kofler From dmalcolm at redhat.com Tue May 19 00:55:30 2009 From: dmalcolm at redhat.com (David Malcolm) Date: Mon, 18 May 2009 20:55:30 -0400 Subject: Database SIG? In-Reply-To: <364d303b0905160816p59365447wf4b82530a75d8490@mail.gmail.com> References: <1242082378.30883.73.camel@radiator.bos.redhat.com> <364d303b0905160816p59365447wf4b82530a75d8490@mail.gmail.com> Message-ID: <1242694530.5103.131.camel@brick> On Sat, 2009-05-16 at 16:16 +0100, Christopher Brown wrote: > 2009/5/11 David Malcolm : > > Would anyone else be interested in a database special-interest-group > > within Fedora? I don't see one at http://fedoraproject.org/wiki/SIGs > > > > I seem to spend much of my time working with SQL these days, and I'm > > interested in both client-side tools for mucking about with SQL, and > > with server-side implementations, test suites, plus the more esoteric > > things like XML and object databases, SPARQL, Tutorial D, etc. > > > > So there'd be some overlap with the Server SIG, but there are plenty of > > GUI tools as well (e.g. openoffice-base, schema visualizers, etc). > > > > High-level goal might be to make Fedora the best place to go for someone > > trying to learn about SQL and relational databases [1], and other types > > of db. > > > > A first step might be to gather a list of interesting open-source > > database software, and then to package more of it for Fedora. I've > > tried looking for such a list, but unfortunately the package database > > tends to dominate my queries. > > > > Anyone else out there? > > I think this is excellent timing. I'm no database guru but with my > crystal ball I foresee MySQL requiring some form of attention in the > near future. :) > This may be, though I'm not an expert on the MySQL project/diaspora. FWIW I've added links to MariaDB and to Drizzle to https://fedoraproject.org/wiki/User:Dmalcolm/DatabaseSoftware#RDBMS ; but I'm not planning to package them personally. Should these be packaged yet? My (personal) opinion here is to defer to Tom Lane's judgment on these things (MySQL maintainer for Fedora; CCed); it may be fun to package them, but maybe it's too early? I guess they'd have to be separate, parallel installs, I wouldn't want them to destabilize the main MySQL packages. Dave From tgl at redhat.com Tue May 19 02:01:32 2009 From: tgl at redhat.com (Tom Lane) Date: Mon, 18 May 2009 22:01:32 -0400 Subject: Database SIG? In-Reply-To: <1242694530.5103.131.camel@brick> References: <1242082378.30883.73.camel@radiator.bos.redhat.com> <364d303b0905160816p59365447wf4b82530a75d8490@mail.gmail.com> <1242694530.5103.131.camel@brick> Message-ID: <4194.1242698492@sss.pgh.pa.us> David Malcolm writes: > On Sat, 2009-05-16 at 16:16 +0100, Christopher Brown wrote: >> I think this is excellent timing. I'm no database guru but with my >> crystal ball I foresee MySQL requiring some form of attention in the >> near future. :) >> > This may be, though I'm not an expert on the MySQL project/diaspora. > FWIW I've added links to MariaDB and to Drizzle to > https://fedoraproject.org/wiki/User:Dmalcolm/DatabaseSoftware#RDBMS ; > but I'm not planning to package them personally. > Should these be packaged yet? My (personal) opinion here is to defer to > Tom Lane's judgment on these things (MySQL maintainer for Fedora; CCed); > it may be fun to package them, but maybe it's too early? I guess they'd > have to be separate, parallel installs, I wouldn't want them to > destabilize the main MySQL packages. First off, +1 for a database SIG --- I didn't respond earlier because I didn't wish to muddy your sample, but I'm in. As for the mysql situation, for the moment I want to keep packaging "official" mysql, defined as "whatever mysql.com is shipping". If Oracle screws things up sufficiently (which I consider well within the realm of possibility) then that will have to be revisited, but for the moment I just want to wait and see. I don't personally have the bandwidth or interest to package a bunch of mysql forks, but if anyone else wants to pick up maintainership of some of them, I have no objection. We'd have to consider however whether a package of a fork could coexist with the "standard" mysql packages. I suppose a few Conflicts: directives would solve the problem if not, but it'd sure be more convenient if they could coexist, or at the very least share the same client-side packages. regards, tom lane From mhlavink at redhat.com Tue May 19 06:20:47 2009 From: mhlavink at redhat.com (Michal Hlavinka) Date: Tue, 19 May 2009 08:20:47 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <200905182239.04065.bjorn@xn--rombobjrn-67a.se> References: <20090518090953.5698908a@ohm.scrye.com> <200905182239.04065.bjorn@xn--rombobjrn-67a.se> Message-ID: <200905190820.47245.mhlavink@redhat.com> On Monday 18 May 2009 22:38:45 Bj?rn Persson wrote: > Kevin Kofler wrote: > > It shall be noted that many users complained about flags being removed > > (they expect the keyboard layout chooser to use them), and the current > > solution where -flags is optional and not installed by default isn't very > > helpful either (but better than not having them at all). > > To me it would seem more reasonable to install the flags by default. Then > the anti-whatever extremists could just remove them, and the more relaxed > among us would see the user interface the way the authors intended without > jumping through additional hoops. > > To make it easy to remove all flags there could be a ban-flags package that > would conflict with all the -flags subpackages. > > Bj?rn Persson +1, IMO flags should be installed by default. removing flags by default is definitely overreaction Fedora should be FREE If someone "really" needs to remove flags, we should provide easy way to remove/don't install flags, which are installed by default for people living in free world. They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety. ---- Benjamin Franklin (I was looking for log of fesco meeting, who is a freedom fighter here and who'll get my vote next time.... no one, that's sad...) From bochecha at fedoraproject.org Tue May 19 08:31:31 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Tue, 19 May 2009 10:31:31 +0200 Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <1242667087.25634.1927.camel@cookie.hadess.net> <1242675818.15983.49.camel@jdlaptop.lesbg.loc> Message-ID: <2d319b780905190131m383607c2v13e22aee27bcd4c1@mail.gmail.com> On Tue, May 19, 2009 at 02:28, Kevin Kofler wrote: > Jonathan Dieter wrote: > >> On Mon, 2009-05-18 at 18:18 +0100, Bastien Nocera wrote: >>> It could cause problems in Europe, in Asia, and in North America (and >>> that's just on top of my head). >> >> And the Middle East. I really can't see how this can be a problem at all... :-/ Doesn't the UN maintain a list of officially recognized countries ? If so, we can just use those, and if someone complains, it's not a Fedora issue but a UN issue. Any trouble with countries recognized in Fedora will have to be raised to the UN. This way, we rely on an official organization, we can use pretty flags, and everyone is happy (or has to be, I mean, are there some countries who don't recognize the authority of UN ?) ---------- Mathieu Bridon (bochecha) From denis at poolshark.org Tue May 19 09:26:54 2009 From: denis at poolshark.org (Denis Leroy) Date: Tue, 19 May 2009 11:26:54 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <20090518173651.GA6318@nostromo.devel.redhat.com> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> Message-ID: <4A127B5E.2080600@poolshark.org> On 05/18/2009 07:36 PM, Bill Nottingham wrote: > Denis Leroy (denis at poolshark.org) said: >>> Due to an oversight, this policy was not announced here. ;( >>> >>> Please see: >>> >>> https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy >> Surely, this needs to go through FPC first. > > Given that it's (essentially) a legal issue (affecting distribution/ > availability of Fedora), I don't see that. It is not really a legal issue, as Tom mentioned. You cannot get sued for putting "Free Tibet" on your web page. But back to the topic, putting all flags blindly into the same "controversial" category is simply silly, and an overreaction. As was mentioned in another post, let's stick with UN-recognized countries, and let packagers deal with other cases based on specific user complaints or feedback. I am not saying we should not deal with packages containing intentionally provocative political contents (I don't know, some sort of easter egg feature displaying political propaganda, has that ever happened ?), but the torrent package is a far cry from that scenario. At worst, isolate the deemed-offensive flags in a separate RPM (so that people who want to create a PRC-friendly Fedora spin can do so easily), but please don't put ALL flags in the same category. The drafted policy is overreaching. From jonathan.underwood at gmail.com Tue May 19 10:22:41 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 19 May 2009 11:22:41 +0100 Subject: Ongoing mass rebuild on s390x In-Reply-To: <20090516184326.GB31277@redhat.de> References: <20090516173539.GD10645@redhat.de> <20090516184326.GB31277@redhat.de> Message-ID: <645d17210905190322v5c56eb9eo35bd71f0e4873bfb@mail.gmail.com> 2009/5/16 : > On Sat, May 16, 2009 at 07:35:39PM +0200, karsten at redhat.com wrote: >> Hi, >> >> Just in case you're wondering about the koji mails of your packages being rebuilt: >> >> I'm currently looping over all F-11 packages and rebuilding them on s390x, which >> is a secondary arch. If you have some free time and one of your packages failed >> to build, please check the logs and try to figure out what went wrong. If it's >> just a dependency problem, ignore it for now. If it is a real issue, I'd >> appreciate it if you could take a look at it as you as the package maintainer >> could most likely fix it faster than I can. >> >> ? Thanks ! >> >> ? ? ? ? ? ?Karsten >> > > One thing I forgot to mention was how you can submit builds to s390x: > > koji -c ~/.koji/s390-config build dist-f11 CVS_URL > > or from the usual CVS checkout: > SECONDARY_CONFIG=" -c ~/.koji/s390-config " make build Is there any way to set things up so that package builds include s390 from this point onwards for a package - I'd rather keep packages on all archs "in step" ? Thanks, Jonathan. From jonathan.underwood at gmail.com Tue May 19 10:38:23 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 19 May 2009 11:38:23 +0100 Subject: Ongoing mass rebuild on s390x In-Reply-To: <20090516173539.GD10645@redhat.de> References: <20090516173539.GD10645@redhat.de> Message-ID: <645d17210905190338r49803d36k112eaa1c0d6a9f75@mail.gmail.com> 2009/5/16 : > Hi, > > Just in case you're wondering about the koji mails of your packages being rebuilt: > > I'm currently looping over all F-11 packages and rebuilding them on s390x, which > is a secondary arch. If you have some free time and one of your packages failed > to build, please check the logs and try to figure out what went wrong. If it's > just a dependency problem, ignore it for now. If it is a real issue, I'd > appreciate it if you could take a look at it as you as the package maintainer > could most likely fix it faster than I can. emacs-vm and emacs-bbdb failed to build due to a chicken-and-egg bootstrap requirement. To fix it: 1) Build emacs-vm without bbdb support 2) Build emacs-bbdb 3) Rebuild emacs-vm with bbdb support So, question: How to request retagging of packages for a secondary arch? In the above I need to have the build from 1 in the buildroot for 2, and the build from 2 in the build root for 3 J. From dwmw2 at infradead.org Tue May 19 10:39:39 2009 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 19 May 2009 11:39:39 +0100 Subject: Package Maintainers Flags policy In-Reply-To: <4A127B5E.2080600@poolshark.org> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> Message-ID: <1242729579.30251.156.camel@macbook.infradead.org> On Tue, 2009-05-19 at 11:26 +0200, Denis Leroy wrote: > On 05/18/2009 07:36 PM, Bill Nottingham wrote: > > Denis Leroy (denis at poolshark.org) said: > >>> Due to an oversight, this policy was not announced here. ;( > >>> > >>> Please see: > >>> > >>> https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy > >> Surely, this needs to go through FPC first. > > > > Given that it's (essentially) a legal issue (affecting distribution/ > > availability of Fedora), I don't see that. > > It is not really a legal issue, as Tom mentioned. You cannot get sued > for putting "Free Tibet" on your web page. You want to go live in China and try that, then? You're probably right -- you wouldn't get _sued_ ... There _are_ real problems with distributing certain flags, in certain jurisdictions -- and that means problems distributing _Fedora_ if it contains those flags. And we _really_ don't want to start removing _only_ the affected flags, which makes it look like we're taking sides in the issue. I don't much like the reasons that we have to do it -- but I do agree that it's best just to stay out of the political debate by not shipping _any_ flags. That's why I voted for the policy. I see a very strong parallel between this issue and the issue of "profanity". The first book of the Bible makes it clear that to be ashamed of nakedness and natural bodily function is a sign of sin -- so I believe that anyone who is offended by the word "fuck" is going to burn in hell, and anyone striving to be sinless should ensure that they are _not_ irrationally affected by such simple and natural things. But since some people _are_ offended, it's best for us to avoid the issue; to bowdlerise our fortune files and screensavers etc. Some trivial things offend some strange people, beyond all reason and proportion. It's just best for us to avoid shipping those things, unless the lack of them is a _real_ technical problem. Which it _isn't_, in the case of flags. -- dwmw2 From martin.marques at gmail.com Tue May 19 10:46:46 2009 From: martin.marques at gmail.com (=?UTF-8?B?TWFydMOtbiBNYXJxdcOpcw==?=) Date: Tue, 19 May 2009 07:46:46 -0300 Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <1242667087.25634.1927.camel@cookie.hadess.net> Message-ID: 2009/5/18 Paul Black : > 2009/5/18 Kevin Kofler >> >> And FYI, the current policy doesn't ban flags entirely, but they have to >> be >> in a -flags package which is not installed by default (this is now >> implemented for kdebase-runtime, it has a kdebase-runtime-flags >> subpackage; >> before that, flags used to be removed from kdebase-runtime entirely, as >> per >> the old unwritten policy, the current one is a compromise). > > Out of curiosity, any reason this is done for kdebase-runtime but not > ktorrent? Ugh? Ktorrent has geo-political flags in the connection peers window. -- Mart?n Marqu?s select 'martin.marques' || '@' || 'gmail.com' DBA, Programador, Administrador From jmoskovc at redhat.com Tue May 19 10:57:49 2009 From: jmoskovc at redhat.com (Jiri Moskovcak) Date: Tue, 19 May 2009 12:57:49 +0200 Subject: Abrt - should this be a feature? In-Reply-To: <4A118A4C.3050909@fedoraproject.org> References: <4A0DC949.7000601@fedoraproject.org> <4A116F78.3020607@redhat.com> <4A118A4C.3050909@fedoraproject.org> Message-ID: <4A1290AD.90205@redhat.com> Rahul Sundaram wrote: > On 05/18/2009 07:53 PM, Zdenek Prikryl wrote: >> In F11 abrt doesn't replace bb, they can be enabled at the same time. Note that >> abrt can catch more crashes than bb can (like non-gnome programs, kernel crashes >> [kerneloops], ...). > > How can they be enabled at the same time? Where is that information > documented? > > Rahul > Because if the crash is handled by bb abrt won't detect it at all. It's the same for applications which have their own crash handlers (like pidgin). Jirka -------------- next part -------------- A non-text attachment was scrubbed... Name: jmoskovc.vcf Type: text/x-vcard Size: 134 bytes Desc: not available URL: From ewan at macmahon.me.uk Tue May 19 11:10:17 2009 From: ewan at macmahon.me.uk (Ewan Mac Mahon) Date: Tue, 19 May 2009 12:10:17 +0100 Subject: Package Maintainers Flags policy In-Reply-To: <1242729579.30251.156.camel@macbook.infradead.org> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> Message-ID: <20090519111017.GA32139@macmahon.me.uk> On Tue, May 19, 2009 at 11:39:39AM +0100, David Woodhouse wrote: > > Some trivial things offend some strange people, beyond all reason and > proportion. It's just best for us to avoid shipping those things, unless > the lack of them is a _real_ technical problem. Which it _isn't_, in the > case of flags. > It is for some packages. I can't see any sane way to package FreeCiv, for example, without using flags. At that point, do we just accept the package (Tibettan nation and flag and all) or drop perfectly good Free software from the distribution? Ewan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pbrobinson at gmail.com Tue May 19 11:32:25 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 19 May 2009 12:32:25 +0100 Subject: Package Maintainers Flags policy In-Reply-To: <20090519111017.GA32139@macmahon.me.uk> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <20090519111017.GA32139@macmahon.me.uk> Message-ID: <5256d0b0905190432u3dcd6b05w44b6caec7527e215@mail.gmail.com> >> Some trivial things offend some strange people, beyond all reason and >> proportion. It's just best for us to avoid shipping those things, unless >> the lack of them is a _real_ technical problem. Which it _isn't_, in the >> case of flags. >> > > It is for some packages. I can't see any sane way to package FreeCiv, > for example, without using flags. At that point, do we just accept the > package (Tibettan nation and flag and all) or drop perfectly good Free > software from the distribution? As per the original posting you'd raise the issue with FESCO for their review. Peter From karsten at redhat.com Tue May 19 12:09:35 2009 From: karsten at redhat.com (Karsten Hopp) Date: Tue, 19 May 2009 14:09:35 +0200 Subject: Ongoing mass rebuild on s390x In-Reply-To: <645d17210905190338r49803d36k112eaa1c0d6a9f75@mail.gmail.com> References: <20090516173539.GD10645@redhat.de> <645d17210905190338r49803d36k112eaa1c0d6a9f75@mail.gmail.com> Message-ID: <4A12A17F.9000205@redhat.com> Am 19.05.2009 12:38, schrieb Jonathan Underwood: > 2009/5/16: > >> Hi, >> >> Just in case you're wondering about the koji mails of your packages being rebuilt: >> >> I'm currently looping over all F-11 packages and rebuilding them on s390x, which >> is a secondary arch. If you have some free time and one of your packages failed >> to build, please check the logs and try to figure out what went wrong. If it's >> just a dependency problem, ignore it for now. If it is a real issue, I'd >> appreciate it if you could take a look at it as you as the package maintainer >> could most likely fix it faster than I can. >> > > emacs-vm and emacs-bbdb failed to build due to a chicken-and-egg > bootstrap requirement. > > To fix it: > 1) Build emacs-vm without bbdb support > 2) Build emacs-bbdb > 3) Rebuild emacs-vm with bbdb support > > So, question: How to request retagging of packages for a secondary > arch? In the above I need to have the build from 1 in the buildroot > for 2, and the build from 2 in the build root for 3 > > J. > > That was exactly the kind of hints I was looking for. I could have tried building emacs-bbdb without emacs-vm or the other way around. There was no re-tagging required, just build emacs-vm without bbdb support with a lower release number, then build emacs-bbdb, then the F-11 emacs-vm. Karsten -------------- next part -------------- An HTML attachment was scrubbed... URL: From musuruan at gmail.com Tue May 19 12:26:29 2009 From: musuruan at gmail.com (Andrea Musuruane) Date: Tue, 19 May 2009 14:26:29 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <1242729579.30251.156.camel@macbook.infradead.org> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> Message-ID: <29fee02b0905190526i593c1c97x840ba64d38455902@mail.gmail.com> On Tue, May 19, 2009 at 12:39 PM, David Woodhouse wrote: > There _are_ real problems with distributing certain flags, in certain > jurisdictions -- and that means problems distributing _Fedora_ if it > contains those flags. And we _really_ don't want to start removing > _only_ the affected flags, which makes it look like we're taking sides > in the issue. > > I don't much like the reasons that we have to do it -- but I do agree > that it's best just to stay out of the political debate by not shipping > _any_ flags. That's why I voted for the policy. I wonder what will happen in the long run if we continue to remove everything that anyone on the planet can consider "inappropriate". If we follow your argument we will do it to be an appealing distribution for everybody. But this is a contradiction because we will have less applications and less features than other distributions thus we will be very less appealing. Just my 2c. Bye, Andrea. From denis at poolshark.org Tue May 19 12:38:03 2009 From: denis at poolshark.org (Denis Leroy) Date: Tue, 19 May 2009 14:38:03 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <1242729579.30251.156.camel@macbook.infradead.org> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> Message-ID: <4A12A82B.1080502@poolshark.org> On 05/19/2009 12:39 PM, David Woodhouse wrote: > I don't much like the reasons that we have to do it -- but I do agree > that it's best just to stay out of the political debate by not shipping > _any_ flags. Will you also stay out of the profanity debate and blacklist all packages contains any textual occurrence of a profane word ? Or ship them in a separate "-adult" subpackage ? This is completely ridiculous, and the fact you are a member of FeSCO is plain scary. This can only be excused by lack of time and/or interest to think about a better solution. Worst of all, this "policy" is forced on us, without any sort of valid legal reason for it, or even chance for discussion on the mailing list. This is just plain terrible, and an embarassement for Fedora as a whole. Frankly this gives me doubt about even being involved with this... What is Paul Frields take on this ? -denis From dwmw2 at infradead.org Tue May 19 12:52:09 2009 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 19 May 2009 13:52:09 +0100 Subject: Package Maintainers Flags policy In-Reply-To: <29fee02b0905190526i593c1c97x840ba64d38455902@mail.gmail.com> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <29fee02b0905190526i593c1c97x840ba64d38455902@mail.gmail.com> Message-ID: <1242737529.30251.182.camel@macbook.infradead.org> On Tue, 2009-05-19 at 14:26 +0200, Andrea Musuruane wrote: > > I don't much like the reasons that we have to do it -- but I do agree > > that it's best just to stay out of the political debate by not shipping > > _any_ flags. That's why I voted for the policy. > > I wonder what will happen in the long run if we continue to remove > everything that anyone on the planet can consider "inappropriate".] I agree -- I'm dismayed by the tide of political correctness which blights our society. But even _I_ am not quixotic enough to want to stand up to it _all_ the time. Especially when I'm making decision as a representative of the Fedora project, rather than purely for myself. I think it's mildly hypocritical of anyone to demand that we restore flags without also restoring the missing bits of fortune files and the 'random image' screensavers. The principle is the same -- some stupid people choose to be offended, and we're pandering to them because we want an easy life. -- dwmw2 From walters at verbum.org Tue May 19 12:53:46 2009 From: walters at verbum.org (Colin Walters) Date: Tue, 19 May 2009 08:53:46 -0400 Subject: Abrt - should this be a feature? In-Reply-To: <4A1290AD.90205@redhat.com> References: <4A0DC949.7000601@fedoraproject.org> <4A116F78.3020607@redhat.com> <4A118A4C.3050909@fedoraproject.org> <4A1290AD.90205@redhat.com> Message-ID: On Tue, May 19, 2009 at 6:57 AM, Jiri Moskovcak wrote: > > Because if the crash is handled by bb abrt won't detect it at all. It's the > same for applications which have their own crash handlers (like pidgin). We can disable bug-buddy very easily (trivially) if ABRT is ready (is it?). An important concern is having a story to tell the GNOME project for how we're going to be providing them with bug data. If ABRT's server side component had say a filtered list of crashes in GNOME projects, or some automated way for developers to get at that data that'd be useful. From dwmw2 at infradead.org Tue May 19 12:59:06 2009 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 19 May 2009 13:59:06 +0100 Subject: Package Maintainers Flags policy In-Reply-To: <4A12A82B.1080502@poolshark.org> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> Message-ID: <1242737946.30251.189.camel@macbook.infradead.org> On Tue, 2009-05-19 at 14:38 +0200, Denis Leroy wrote: > On 05/19/2009 12:39 PM, David Woodhouse wrote: > > I don't much like the reasons that we have to do it -- but I do agree > > that it's best just to stay out of the political debate by not shipping > > _any_ flags. > > Will you also stay out of the profanity debate and blacklist all > packages contains any textual occurrence of a profane word ? Or ship > them in a separate "-adult" subpackage ? This is completely ridiculous, > and the fact you are a member of FeSCO is plain scary. This can only be > excused by lack of time and/or interest to think about a better solution. I believe we do remove profanity where it's visible to the user, such as in fortune files. We also removed the 'random image' screensaver, didn't we? I don't really _approve_ of those changes, just as I don't really approve of removing flags. But it's not that I disagree with the Fedora decision -- it's more that I disagree with the screwed-up society which makes it necessary. I do reluctantly concede that it's the most appropriate decision for Fedora. As did an overwhelming majority of my colleagues on FESCo, iirc. > Worst of all, this "policy" is forced on us, without any sort of valid > legal reason for it, or even chance for discussion on the mailing list. I'm sorry if that impression was given. I thought we actually postponed the discussion and vote on it for a week so that it could get more visibility -- do I misremember that? And my understanding is that there _is_ a valid legal reason for it. Distributing Fedora in some countries is _illegal_ if it contains certain flags, and can lead to extremely uncomfortable repercussions. -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation From alcapcom at gmail.com Tue May 19 13:00:40 2009 From: alcapcom at gmail.com (alcapcom) Date: Tue, 19 May 2009 15:00:40 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <200905182239.04065.bjorn@xn--rombobjrn-67a.se> References: <20090518090953.5698908a@ohm.scrye.com> <1242667087.25634.1927.camel@cookie.hadess.net> <200905182239.04065.bjorn@xn--rombobjrn-67a.se> Message-ID: <4ccd9dcb0905190600t30325bf1j56b7f53c5744900c@mail.gmail.com> 2009/5/18 Bj?rn Persson : > To me it would seem more reasonable to install the flags by default. Then the > anti-whatever extremists could just remove them, and the more relaxed among > us would see the user interface the way the authors intended without jumping > through additional hoops. +1 But I will try to say it in another way. Unfortunate peoples that live in countries where a _simple_ flag can give troubles for whatever cause/reason, can remove them all to be able to use Fedora. But please, don't cut our freedom just to be more friendly with authoritarian regimes. Alphonse From joost at cnoc.nl Tue May 19 13:13:55 2009 From: joost at cnoc.nl (Joost van der Sluis) Date: Tue, 19 May 2009 15:13:55 +0200 Subject: Problem with build-id and cycling the free pascal compiler In-Reply-To: <20090426204156.7431DFC3B6@magilla.sf.frob.com> References: <1240667628.31161.14.camel@wsjoost> <20090426204156.7431DFC3B6@magilla.sf.frob.com> Message-ID: <1242738835.30840.7.camel@wsjoost> Sorry for the late response, I've missed your mail. Op zondag 26-04-2009 om 13:41 uur [tijdzone -0700], schreef Roland McGrath: > We should figure out why they are different. (Off hand I don't think this > issue should have changed in the build tools since F10.) > > Can you give me two binaries they you think ought to be identical, but > which had different build IDs generated? Offcourse. I've placed a .tgz file here: http://menora.cnoc.nl/extern/DifferentBuildIDsExample.tgz It contains the source of a hello-world application. (hello.pp) And two binaries (hello and hello1) which differ but were build from the same source. There's also a link-script (link.res) and a shell-script (ppas.sh) which you can use to link the executables yourself. The necessary object files are also there. > I want to get to the bottom of the problem before you change anything. > > But I'll note that if you were to use --build-id=none then you'd have your > rpm build break in the find-debuginfo.sh stage because of missing a build ID. I know. > However, --build-id=0x00000000000000000000 (or any 20 hex digits you choose) > will hard-code that bogus build-ID during your link stages. That will make > your comparisons fine if your binaries are really identical. Then, the > find-debuginfo.sh stage will regenerate the build IDs after it edits the > source file names in the DWARF information. That's a nice trick. I could use that as a last resort. > But let's find the real source of the problem and fix it rather than > working around it. Thanks for the help, Joost. From rawhide at fedoraproject.org Tue May 19 13:14:29 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Tue, 19 May 2009 13:14:29 +0000 (UTC) Subject: rawhide report: 20090519 changes Message-ID: <20090519131429.CC8A11B8003@releng2.fedora.phx.redhat.com> Compose started at Tue May 19 06:15:03 UTC 2009 Updated Packages: anaconda-11.5.0.53-1.fc11 ------------------------- * Mon May 18 2009 David Cantrell - 11.5.0.53-1 - LVMVolumeGroupDevice stores pesize in MB, kickstart expects it in KB. (dlehman) - Don't schedule a format resize if reformat scheduled. (#500991) (dlehman) - Deactivate md arrays regardless of state if the device is present. (#496441) (dlehman) - Lame hack to make sure --size= is never 0 (#500905). (clumens) - Don't filter out partitions that haven't been allocated (#500932). (clumens) - Write out PE size as an integer, since that's what anaconda wants (#501049). (clumens) - Set clearPartType to None on preupgrade too (#499321). (clumens) - Fix indentation of line to remove cancelled actions from the list. (#500932) (dlehman) - Consider active-idle state of md device as accepatable status of device (#497407) (rvykydal) - Fix detection of cciss disks (#499408) (dchapman) - Get existing fs size for xfs. (dcantrell) - Get existing fs size for ntfs. (dcantrell) - Get existing fs size for jfs. (dcantrell) - Get existing fs size for ext2, ext3, and ext4. (dcantrell) - Compute existing filesystem size using fs info utility. (dcantrell) - Do not allow users to migrate ext4 to ext4. (dcantrell) - Correct handling of formats on encrypted preexisting LVs. (#499828) (dlehman) - Ignore unrecognized device-mapper devices we find. (#499967) (dlehman) - loader: Mount /tmp as tmpfs not ramfs so we can swap it out (ajax) - format.mountpoint -> lvd.mountpoint (#500913). (clumens) - Treat the loop labels as devices without a label.(#493219) (jgranado) - Add the partition table partition after initializing (#498602). (clumens) arj-3.10.22-8.fc11 ------------------ * Sat Apr 18 2009 Robert Scheck 3.10.22-8 - Added patch to disable the custom printf to avoid conflicting strnlen definition with glibc headers (thanks to Lubomir Rintel) cups-1.4-0.b2.18.fc11 --------------------- * Fri May 15 2009 Tim Waugh 1:1.4-0.b2.18 - More complete fix for STR #3197 (bug #500859). e2fsprogs-1.41.4-9.fc11 ----------------------- * Thu May 14 2009 Eric Sandeen 1.41.4-9 - Fix corrupted filesystems with mis-set i_file_acl_hi (#500935) gvfs-1.2.3-2.fc11 ----------------- * Mon May 18 2009 Tomas Bzatek - 1.2.3-1 - Update to 1.2.3 - Prevent deadlocks in dnssd resolver (#497631) * Mon May 18 2009 Tomas Bzatek - 1.2.3-2 - CDDA: allow query well-formed filenames only (#499266) * Wed May 13 2009 Matthias Clasen - 1.2.2-8 - Try to fix issues with webdav authentication inkscape-0.47-0.8.20090508svn.fc11 ---------------------------------- * Mon May 18 2009 Lubomir Rintel - 0.47-0.8.20090508svn - Fix ODG export * Fri May 08 2009 Lubomir Rintel - 0.47-0.7.20090508svn - Update to a post-alpha snapshot - Upstream applied our GCC 4.4 patch libnet-1.1.3-1.fc11 ------------------- * Sat May 16 2009 Robert Scheck 1.1.3-1 - Upgrade to 1.1.3 * Sun Apr 19 2009 Robert Scheck 1.1.2.1-14 - Enabled a shared library and made lots of spec file cleanups libsmbios-2.2.16-2.1.fc11 ------------------------- nsd-3.2.2-2.fc11 ---------------- * Mon May 18 2009 Paul Wouters - 3.2.2-1 - Upgraded to 3.2.2 security release http://www.nlnetlabs.nl/publications/NSD_vulnerability_announcement.html - Removed obsoleted options --enable-plugins --enable-mmap * Mon May 18 2009 Paul Wouters - 3.2.2-2 - Bump version phpMyAdmin-3.1.5-1.fc11 ----------------------- * Fri May 15 2009 Robert Scheck 3.1.5-1 - Upstream released 3.1.5 plymouth-0.7.0-0.2009.05.15.1.fc11 ---------------------------------- * Fri May 15 2009 Ray Strode 0.7.0-0.2009.05.15.1 - Fix spinfinity theme to point to the right image directory (bug 500994) pykickstart-1.54-1.fc11 ----------------------- * Mon May 18 2009 Chris Lumens - 1.54-1 - Make sure the F11 handler gets used for "partition" and "part" (#501020). spin-kickstarts-0.11.3-1.fc11 ----------------------------- * Sat May 16 2009 Jeroen van Meeuwen 0.11.3-1 - New release - Removed developer spin from the mix tigervnc-0.0.90-0.9.fc11 ------------------------ * Mon May 18 2009 Adam Tkac 0.0.90-9 - fix vncpasswd crash on long passwords (#499401) - start session dbus daemon correctly (#497592) * Mon May 11 2009 Adam Tkac 0.0.90-0.8.1 - remove merged tigervnc-manminor.patch * Tue May 05 2009 Adam Tkac 0.0.90-0.8 - update to 0.0.90 unicap-0.9.5-1.fc11 ------------------- * Sun May 03 2009 Robert Scheck 0.9.5-1 - Upgrade to 0.9.5 xorg-x11-drv-nouveau-0.0.12-36.20090514git9656762.fc11 ------------------------------------------------------ * Thu May 14 2009 Ben Skeggs 0.0.12-36.20090514git9656762 - nv50: fix hang with multiple displays when encoders swap crtcs * Fri May 08 2009 Ben Skeggs 0.0.12-35.20090507git1072103 - nv50: ensure crtcs get reprogrammed as needed across resize xorg-x11-server-1.6.1.901-1.fc11 -------------------------------- * Mon May 18 2009 Adam Jackson 1.6.1.901-1 - Rebase to 1.6.2 pre-release - xserver-1.6.1-hush-warning.patch: Silence the prerelease warning spew. - xserver-1.6.0-xinerama-crashes.patch: merged - xserver-1.6.1-activate-device.patch: merged - xserver-1.6.1-proc-cmdline.patch: Print /proc/cmdline in the log - xserver-1.6.0-primary.patch: Don't include prehistoric PCI devices in the candidate list for primary video. (#500057) - Drop the %pre scriptlet from the Xorg subpackage, it's been there since FC5, if you haven't upgraded by now you're quite doomed. * Mon May 11 2009 Peter Hutterer 1.6.1-14 - xserver-1.6.1-synaptics.patch: Don't synthesize a mouse section if unreferenced synaptics devices are found in the xorg.conf (#499792) * Fri May 08 2009 Adam Jackson 1.6.1-13 - xserver-1.6.1-vt-switch.patch: Synthesize key releases on vt switch away, not just on return. Fixes CPU usage bug while switched away. (#484393) * Thu May 07 2009 Adam Jackson 1.6.1-12 - xserver-1.6.1-nouveau.patch: AIGLX setup failure is not an error for nouveau. Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 17 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From denis at poolshark.org Tue May 19 13:16:32 2009 From: denis at poolshark.org (Denis Leroy) Date: Tue, 19 May 2009 15:16:32 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <1242737529.30251.182.camel@macbook.infradead.org> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <29fee02b0905190526i593c1c97x840ba64d38455902@mail.gmail.com> <1242737529.30251.182.camel@macbook.infradead.org> Message-ID: <4A12B130.5040107@poolshark.org> On 05/19/2009 02:52 PM, David Woodhouse wrote: > I think it's mildly hypocritical of anyone to demand that we restore > flags without also restoring the missing bits of fortune files and the > 'random image' screensavers. The principle is the same -- some stupid > people choose to be offended, and we're pandering to them because we > want an easy life. I use the educational suite GCompris with my 2-year old daughter, which I really enjoy doing. The configuration menu uses flag countries to let you select the language of the various games. A French flag for French, a Portugal flag for portuguese, even a Catalan flag for people from Barcelona. Now the burden is on the packager to figure out how to patch the application to work without the images (tough sell to get upstream help on this). If you agree to the absurdity of the broad effects caused by the policy you voted for, you need to resign from FeSCo immediately. -denis From karsten at redhat.com Tue May 19 13:21:59 2009 From: karsten at redhat.com (Karsten Hopp) Date: Tue, 19 May 2009 15:21:59 +0200 Subject: Ongoing mass rebuild on s390x In-Reply-To: <645d17210905190322v5c56eb9eo35bd71f0e4873bfb@mail.gmail.com> References: <20090516173539.GD10645@redhat.de> <20090516184326.GB31277@redhat.de> <645d17210905190322v5c56eb9eo35bd71f0e4873bfb@mail.gmail.com> Message-ID: <4A12B277.7060806@redhat.com> Am 19.05.2009 12:22, schrieb Jonathan Underwood: > > Is there any way to set things up so that package builds include s390 > from this point onwards for a package - I'd rather keep packages on > all archs "in step" ? > > Thanks, > Jonathan. > AFAIK there's a cron script which needs to run on the koji hub to run those builds on the secondary archs. This isn't enabled yet as there are still quite a few packages missing and we'd get too many failures caused by unresolved dependencies. But the plan is to enable this as soon as possible. Karsten From skvidal at fedoraproject.org Tue May 19 13:25:21 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 19 May 2009 09:25:21 -0400 (EDT) Subject: Package Maintainers Flags policy In-Reply-To: <4A12B130.5040107@poolshark.org> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <29fee02b0905190526i593c1c97x840ba64d38455902@mail.gmail.com> <1242737529.30251.182.camel@macbook.infradead.org> <4A12B130.5040107@poolshark.org> Message-ID: On Tue, 19 May 2009, Denis Leroy wrote: > On 05/19/2009 02:52 PM, David Woodhouse wrote: >> I think it's mildly hypocritical of anyone to demand that we restore >> flags without also restoring the missing bits of fortune files and the >> 'random image' screensavers. The principle is the same -- some stupid >> people choose to be offended, and we're pandering to them because we >> want an easy life. > > I use the educational suite GCompris with my 2-year old daughter, which I > really enjoy doing. The configuration menu uses flag countries to let you > select the language of the various games. A French flag for French, a > Portugal flag for portuguese, even a Catalan flag for people from Barcelona. > Now the burden is on the packager to figure out how to patch the application > to work without the images (tough sell to get upstream help on this). > > If you agree to the absurdity of the broad effects caused by the policy you > voted for, you need to resign from FeSCo immediately. I don't think that particular leap is logical. What do the flags specify for a country like the US? Or China? or Switzerland? If a program means to say "choose your language" then they should say "choose your language". Not "choose a flag from a linguistically homogenous country". -sv From stickster at gmail.com Tue May 19 13:27:56 2009 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 19 May 2009 09:27:56 -0400 Subject: Package Maintainers Flags policy In-Reply-To: <1242737946.30251.189.camel@macbook.infradead.org> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <1242737946.30251.189.camel@macbook.infradead.org> Message-ID: <20090519132756.GJ5760@localhost.localdomain> On Tue, May 19, 2009 at 01:59:06PM +0100, David Woodhouse wrote: > On Tue, 2009-05-19 at 14:38 +0200, Denis Leroy wrote: > > On 05/19/2009 12:39 PM, David Woodhouse wrote: > > > I don't much like the reasons that we have to do it -- but I do agree > > > that it's best just to stay out of the political debate by not shipping > > > _any_ flags. > > > > Will you also stay out of the profanity debate and blacklist all > > packages contains any textual occurrence of a profane word ? Or ship > > them in a separate "-adult" subpackage ? This is completely ridiculous, > > and the fact you are a member of FeSCO is plain scary. This can only be > > excused by lack of time and/or interest to think about a better solution. > > I believe we do remove profanity where it's visible to the user, such as > in fortune files. We also removed the 'random image' screensaver, didn't > we? > > I don't really _approve_ of those changes, just as I don't really > approve of removing flags. But it's not that I disagree with the Fedora > decision -- it's more that I disagree with the screwed-up society which > makes it necessary. I do reluctantly concede that it's the most > appropriate decision for Fedora. As did an overwhelming majority of my > colleagues on FESCo, iirc. > > > Worst of all, this "policy" is forced on us, without any sort of valid > > legal reason for it, or even chance for discussion on the mailing list. > > I'm sorry if that impression was given. I thought we actually postponed > the discussion and vote on it for a week so that it could get more > visibility -- do I misremember that? > > And my understanding is that there _is_ a valid legal reason for it. > Distributing Fedora in some countries is _illegal_ if it contains > certain flags, and can lead to extremely uncomfortable repercussions. And since I was asked for my opinion, I think David stated it pretty clearly. But frankly I don't think my opinion is needed or, indeed, that relevant. I do feel strongly that FESCo, as a community elected body, needs to be empowered to make these kinds of decisions without worrying about the FPL second-guessing them constantly. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From mjg at redhat.com Tue May 19 13:28:59 2009 From: mjg at redhat.com (Matthew Garrett) Date: Tue, 19 May 2009 14:28:59 +0100 Subject: Package Maintainers Flags policy In-Reply-To: <4A12B130.5040107@poolshark.org> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <29fee02b0905190526i593c1c97x840ba64d38455902@mail.gmail.com> <1242737529.30251.182.camel@macbook.infradead.org> <4A12B130.5040107@poolshark.org> Message-ID: <20090519132859.GA13698@srcf.ucam.org> On Tue, May 19, 2009 at 03:16:32PM +0200, Denis Leroy wrote: > I use the educational suite GCompris with my 2-year old daughter, which > I really enjoy doing. The configuration menu uses flag countries to let > you select the language of the various games. A French flag for French, > a Portugal flag for portuguese, even a Catalan flag for people from > Barcelona. Now the burden is on the packager to figure out how to patch > the application to work without the images (tough sell to get upstream > help on this). There isn't a 1:1 mapping between flags and languages, and arguably an educational suite should be avoiding encouraging that confusion in children. > If you agree to the absurdity of the broad effects caused by the policy > you voted for, you need to resign from FeSCo immediately. Please keep the conversation civil. -- Matthew Garrett | mjg59 at srcf.ucam.org From skvidal at fedoraproject.org Tue May 19 13:30:02 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 19 May 2009 09:30:02 -0400 (EDT) Subject: Package Maintainers Flags policy In-Reply-To: <4A12A82B.1080502@poolshark.org> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> Message-ID: On Tue, 19 May 2009, Denis Leroy wrote: > Will you also stay out of the profanity debate and blacklist all packages > contains any textual occurrence of a profane word ? Or ship them in a > separate "-adult" subpackage ? This is completely ridiculous, and the fact > you are a member of FeSCO is plain scary. This can only be excused by lack of > time and/or interest to think about a better solution. > > Worst of all, this "policy" is forced on us, without any sort of valid legal > reason for it, or even chance for discussion on the mailing list. The simple reality is China. The Chinese gov't was not happy about taiwanese flags being marked on Taiwan - or the Tibetan flag on Tibet. Now, your next question is "why is that our problem?" And the answer is - if we are banned from distribution in china then we have lost a bunch of potential contributors. And then your next question is "does the Chinese gov't really care about a linux distro having a Taiwanese or Tibetan flag in some programs it ships?" and the answer to that question is yes, very much. So, of course does this mean we are siding with china? No, we're not siding with anyone, that's the whole point. Flags mean a lot to a lot of people. They carry a lot of patriotic crap w/them. -sv From musuruan at gmail.com Tue May 19 13:33:30 2009 From: musuruan at gmail.com (Andrea Musuruane) Date: Tue, 19 May 2009 15:33:30 +0200 Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <29fee02b0905190526i593c1c97x840ba64d38455902@mail.gmail.com> <1242737529.30251.182.camel@macbook.infradead.org> <4A12B130.5040107@poolshark.org> Message-ID: <29fee02b0905190633y17d15955k2b676778058d2d4b@mail.gmail.com> On Tue, May 19, 2009 at 3:25 PM, Seth Vidal wrote: > If a program means to say "choose your language" then they should say > "choose your language". Not "choose a flag from a linguistically homogenous > country". I don't agree. Usually if you have to choose a language is mainly because you cannot understand what is written on the screen. Therefore an ideographic form to represent a language is needed. Flags is an obvious choice. If we cannot use them, what else? Bye, Andrea. From billcrawford1970 at gmail.com Tue May 19 13:48:46 2009 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Tue, 19 May 2009 14:48:46 +0100 Subject: Package Maintainers Flags policy In-Reply-To: <29fee02b0905190633y17d15955k2b676778058d2d4b@mail.gmail.com> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <29fee02b0905190526i593c1c97x840ba64d38455902@mail.gmail.com> <1242737529.30251.182.camel@macbook.infradead.org> <4A12B130.5040107@poolshark.org> <29fee02b0905190633y17d15955k2b676778058d2d4b@mail.gmail.com> Message-ID: <4A12B8BE.90403@googlemail.com> Andrea Musuruane wrote: > On Tue, May 19, 2009 at 3:25 PM, Seth Vidal wrote: >> If a program means to say "choose your language" then they should say >> "choose your language". Not "choose a flag from a linguistically homogenous >> country". > > I don't agree. Usually if you have to choose a language is mainly > because you cannot understand what is written on the screen. Therefore > an ideographic form to represent a language is needed. Flags is an > obvious choice. If we cannot use them, what else? Firefox language packs have no flags ;o) From bochecha at fedoraproject.org Tue May 19 13:50:21 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Tue, 19 May 2009 15:50:21 +0200 Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> Message-ID: <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> > And then your next question is "does the Chinese gov't really care about a > linux distro having a Taiwanese or Tibetan flag in some programs it ships?" > and the answer to that question is yes, very much. > > So, of course does this mean we are siding with china? No, we're not siding > with anyone, that's the whole point. > > Flags mean a lot to a lot of people. They carry a lot of patriotic crap > w/them. But what is the official internationally recognized status of Taiwan ? If that's a part of china, then it's not an actual country, then we can remove its flag. If that's an independent country, then it has a flag, and we can use it. I really wonder why we are trying to solve those geopolitical international issues. Those are for the governments and the UN to solve. They agree on a list of officially recognized countries, and we use it. I really can't understand where the problem comes from :-/ Are there countries not agreeing with each others regarding the official status of other countries (not like country A says country B is inside country A, but rather country A and country B disagree on the status of country C) ? Are there countries that disagree with the UN regarding the official status of a "geographic area" ? ---------- Mathieu Bridon (bochecha) From tcallawa at redhat.com Tue May 19 13:50:56 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 19 May 2009 09:50:56 -0400 Subject: Package Maintainers Flags policy In-Reply-To: <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> Message-ID: <4A12B940.4050605@redhat.com> On 05/19/2009 09:50 AM, Mathieu Bridon (bochecha) wrote: > Are there countries not agreeing with each others regarding the > official status of other countries (not like country A says country B > is inside country A, but rather country A and country B disagree on > the status of country C) ? Are there countries that disagree with the > UN regarding the official status of a "geographic area" ? To answer your questions, yes, and yes. ~spot From denis at poolshark.org Tue May 19 13:52:47 2009 From: denis at poolshark.org (Denis Leroy) Date: Tue, 19 May 2009 15:52:47 +0200 Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> Message-ID: <4A12B9AF.4010009@poolshark.org> On 05/19/2009 03:30 PM, Seth Vidal wrote: > Flags mean a lot to a lot of people. They carry a lot of patriotic crap > w/them. Seth, I think we all agree to that. There is a list of pairs that causes problems :-). To be more accurate, there is a well-known very short list of pairs that Fedora cannot ship with legally. The point is: the policy is way overreaching. This would be better dealt with on a case-by-case basis, only when we know for a *fact* we cannot ship Fedora with a specific flag. A flag that has no legal issues but may offend someone is not a good enough reason, it becomes an upstream project issue rather than a Fedora issue. -denis From ewan at macmahon.me.uk Tue May 19 13:56:40 2009 From: ewan at macmahon.me.uk (Ewan Mac Mahon) Date: Tue, 19 May 2009 14:56:40 +0100 Subject: Package Maintainers Flags policy In-Reply-To: <5256d0b0905190432u3dcd6b05w44b6caec7527e215@mail.gmail.com> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <20090519111017.GA32139@macmahon.me.uk> <5256d0b0905190432u3dcd6b05w44b6caec7527e215@mail.gmail.com> Message-ID: <20090519135640.GB32139@macmahon.me.uk> On Tue, May 19, 2009 at 12:32:25PM +0100, Peter Robinson wrote: > >> Some trivial things offend some strange people, beyond all reason and > >> proportion. It's just best for us to avoid shipping those things, unless > >> the lack of them is a _real_ technical problem. Which it _isn't_, in the > >> case of flags. > >> > > > > It is for some packages. I can't see any sane way to package FreeCiv, > > for example, without using flags. At that point, do we just accept the > > package (Tibettan nation and flag and all) or drop perfectly good Free > > software from the distribution? > > As per the original posting you'd raise the issue with FESCO for their review. > Which is a fine procedural answer, but doesn't really help unless we have some idea of what their decision would be. I can only see a few feasable outcomes: - The package stays in, flags, and textual mentions of Tibettan nationhood intact. In which case Fedora is still not 'China safe'. - The controversial flags are removed, others stay in, and FESCO have to make the call as to who's flags count as controversial. - The flags are split out as per the policy, and the default install of FreeCiv is crippled for anyone that doesn't realise the -flags package exists. - The whole package is dropped from Fedora. There does seem to be an assumption in the acceptance of this policy that flags are easily removed, and that's not always the case. It's easy to say 'refer the hard cases to FESCO', but if the end result is that the difficult cases just have their flags left in, then there seems little point in going to the trouble of removing them from the easier cases. Alternatively, if the end result is that hard cases just get dropped from Fedora, then I think that's reasonable cause to object to the policy. Ewan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at fedoraproject.org Tue May 19 13:55:15 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 19 May 2009 09:55:15 -0400 (EDT) Subject: Package Maintainers Flags policy In-Reply-To: <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> Message-ID: On Tue, 19 May 2009, Mathieu Bridon (bochecha) wrote: > > Are there countries not agreeing with each others regarding the > official status of other countries (not like country A says country B > is inside country A, but rather country A and country B disagree on > the status of country C) ? Are there countries that disagree with the > UN regarding the official status of a "geographic area" ? Yes. http://en.wikipedia.org/wiki/Disputed_territories#Disputes_involving_parties_that_each_have_some_territory_under_control_but_do_not_recognize_each_other the list goes on and on and on. -sv From loganjerry at gmail.com Tue May 19 13:58:45 2009 From: loganjerry at gmail.com (Jerry James) Date: Tue, 19 May 2009 07:58:45 -0600 Subject: Ongoing mass rebuild on s390x In-Reply-To: <4A12B277.7060806@redhat.com> References: <20090516173539.GD10645@redhat.de> <20090516184326.GB31277@redhat.de> <645d17210905190322v5c56eb9eo35bd71f0e4873bfb@mail.gmail.com> <4A12B277.7060806@redhat.com> Message-ID: <870180fe0905190658n1dc8d573gb962031ac24825ca@mail.gmail.com> On Tue, May 19, 2009 at 7:21 AM, Karsten Hopp wrote: > AFAIK there's a cron script which needs to run on the koji hub to run those > builds on the > secondary archs. This isn't enabled yet as there are still quite a few > packages missing and > we'd get too many failures caused by unresolved dependencies. > But the plan is to enable this as soon as possible. How about debugging facilities? The C part of GCL is compiling successfully, but then it crashes while trying to process the Lisp part. Is there a box I can log into remotely so I can use gdb on the thing to see what's going on? -- Jerry James http://www.jamezone.org/ From bjorn at xn--rombobjrn-67a.se Tue May 19 13:59:25 2009 From: bjorn at xn--rombobjrn-67a.se (=?utf-8?q?Bj=C3=B6rn_Persson?=) Date: Tue, 19 May 2009 15:59:25 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <29fee02b0905190633y17d15955k2b676778058d2d4b@mail.gmail.com> References: <20090518090953.5698908a@ohm.scrye.com> <29fee02b0905190633y17d15955k2b676778058d2d4b@mail.gmail.com> Message-ID: <200905191559.25564.bjorn@xn--rombobjrn-67a.se> Andrea Musuruane wrote: > On Tue, May 19, 2009 at 3:25 PM, Seth Vidal wrote: > > If a program means to say "choose your language" then they should say > > "choose your language". Not "choose a flag from a linguistically > > homogenous country". > > I don't agree. Usually if you have to choose a language is mainly > because you cannot understand what is written on the screen. Therefore > an ideographic form to represent a language is needed. Flags is an > obvious choice. If we cannot use them, what else? Here's a list of languages that have articles on a certain topic in Wikipedia. Do you have any problem finding your choice? ??????? Bosanski Brezhoneg ????????? Catal? ?esky Dansk Deutsch Eesti ???????? English Espa?ol Esperanto Euskara ????? Fran?ais Galego ??? ?????? Hornjoserbsce Hrvatski Bahasa Indonesia ?slenska Italiano ????? Latvie?u L?tzebuergesch Lietuvi? Lumbaart Magyar Bahasa Melayu Nederlands ??? ?Norsk (bokm?l)? ?Norsk (nynorsk)? Piemont?is Polski Portugu?s Rom?n? ??????? Shqip Sicilianu Simple English Sloven?ina Sloven??ina ?????? / Srpski Basa Sunda Suomi Svenska Tagalog ??? T?rk?e ?????????? ???? Ti?ng Vi?t ?????? ?? ?? Bj?rn Persson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From skvidal at fedoraproject.org Tue May 19 13:59:07 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 19 May 2009 09:59:07 -0400 (EDT) Subject: Package Maintainers Flags policy In-Reply-To: <4ccd9dcb0905190600t30325bf1j56b7f53c5744900c@mail.gmail.com> References: <20090518090953.5698908a@ohm.scrye.com> <1242667087.25634.1927.camel@cookie.hadess.net> <200905182239.04065.bjorn@xn--rombobjrn-67a.se> <4ccd9dcb0905190600t30325bf1j56b7f53c5744900c@mail.gmail.com> Message-ID: On Tue, 19 May 2009, alcapcom wrote: > 2009/5/18 Bj?rn Persson : >> To me it would seem more reasonable to install the flags by default. Then the >> anti-whatever extremists could just remove them, and the more relaxed among >> us would see the user interface the way the authors intended without jumping >> through additional hoops. > > +1 > > But I will try to say it in another way. > > Unfortunate peoples that live in countries where a _simple_ flag can > give troubles for whatever cause/reason, can remove them all to be > able to use Fedora. But please, don't cut our freedom just to be more > friendly with authoritarian regimes. What if a non-authoritarian regime didn't want us to distribute a flag that was offensive to their democratically-empowered populace? Would that be okay then? the whole reason for nuking the set of flags entirely is so we are NOT choosing sides. -sv From bochecha at fedoraproject.org Tue May 19 14:05:17 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Tue, 19 May 2009 16:05:17 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <4A12B940.4050605@redhat.com> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> Message-ID: <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> On Tue, May 19, 2009 at 15:50, Tom "spot" Callaway wrote: > On 05/19/2009 09:50 AM, Mathieu Bridon (bochecha) wrote: >> Are there countries not agreeing with each others regarding the >> official status of other countries (not like country A says country B >> is inside country A, but rather country A and country B disagree on >> the status of country C) ? Are there countries that disagree with the >> UN regarding the official status of a "geographic area" ? > > To answer your questions, yes, and yes. Then we're totally doomed :) I mean, how could we hope to solve this kind of issue on our level if even those of the world can't ? Anyway, sticking to the official internation standard list of countries maintained by UN (if such a list exists) seems much more neutral to me. We don't decide anything on countries, we use the decision of an official organization empowered to make such a decision. By abandoning flags alltogether, we actually make a decision: we choose to side with those who don't agree with the UN. ---------- Mathieu Bridon (bochecha) From karsten at redhat.com Tue May 19 14:07:48 2009 From: karsten at redhat.com (Karsten Hopp) Date: Tue, 19 May 2009 16:07:48 +0200 Subject: Ongoing mass rebuild on s390x In-Reply-To: <870180fe0905190658n1dc8d573gb962031ac24825ca@mail.gmail.com> References: <20090516173539.GD10645@redhat.de> <20090516184326.GB31277@redhat.de> <645d17210905190322v5c56eb9eo35bd71f0e4873bfb@mail.gmail.com> <4A12B277.7060806@redhat.com> <870180fe0905190658n1dc8d573gb962031ac24825ca@mail.gmail.com> Message-ID: <4A12BD34.6020208@redhat.com> Am 19.05.2009 15:58, schrieb Jerry James: > On Tue, May 19, 2009 at 7:21 AM, Karsten Hopp wrote: > >> AFAIK there's a cron script which needs to run on the koji hub to run those >> builds on the >> secondary archs. This isn't enabled yet as there are still quite a few >> packages missing and >> we'd get too many failures caused by unresolved dependencies. >> But the plan is to enable this as soon as possible. >> > > How about debugging facilities? The C part of GCL is compiling > successfully, but then it crashes while trying to process the Lisp > part. Is there a box I can log into remotely so I can use gdb on the > thing to see what's going on? > Unfortunately not, but that's similar to the other archs. If you don' t have p.e. a ppc machine at home you'll have difficulties fixing a ppc related crash. Atm you'll have to do some nasty tricks to get the information you need such as running gdb from the spec file ;-( Well, there's a S390 emulator in F-11 called hercules, but as we don't have bootable images yet, this won't work. Karsten -------------- next part -------------- An HTML attachment was scrubbed... URL: From msuchy at redhat.com Tue May 19 14:09:28 2009 From: msuchy at redhat.com (Miroslav Suchy) Date: Tue, 19 May 2009 10:09:28 -0400 (EDT) Subject: Package Maintainers Flags policy In-Reply-To: <426407226.2287811242742061961.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <2010113601.2287931242742168497.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> ----- "David Woodhouse" wrote: > I believe we do remove profanity where it's visible to the user, such > as > in fortune files. We also removed the 'random image' screensaver, > didn't > we? Please remove ktorrent and all *torrent* packages. IFPI and MPAA claims that it is mostly used for illegal downloading... > And my understanding is that there _is_ a valid legal reason for it. > Distributing Fedora in some countries is _illegal_ if it contains > certain flags, and can lead to extremely uncomfortable repercussions. Fedora Custom Spins? With affected packages removed? Or rebuilded? Miroslav Suchy From cmadams at hiwaay.net Tue May 19 14:10:56 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 19 May 2009 09:10:56 -0500 Subject: Package Maintainers Flags policy In-Reply-To: <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> Message-ID: <20090519141056.GA734423@hiwaay.net> Once upon a time, Mathieu Bridon (bochecha) said: > But what is the official internationally recognized status of Taiwan ? There is no such thing. Who makes it "official" (hint: lots of people disagree with the answer "the UN")? Some countries recognize Taiwan as an independent country, some don't, and some kind-of do (but not "officially"). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From skvidal at fedoraproject.org Tue May 19 14:11:29 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 19 May 2009 10:11:29 -0400 (EDT) Subject: Package Maintainers Flags policy In-Reply-To: <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> Message-ID: On Tue, 19 May 2009, Mathieu Bridon (bochecha) wrote: > On Tue, May 19, 2009 at 15:50, Tom "spot" Callaway wrote: >> On 05/19/2009 09:50 AM, Mathieu Bridon (bochecha) wrote: >>> Are there countries not agreeing with each others regarding the >>> official status of other countries (not like country A says country B >>> is inside country A, but rather country A and country B disagree on >>> the status of country C) ? Are there countries that disagree with the >>> UN regarding the official status of a "geographic area" ? >> >> To answer your questions, yes, and yes. > > Then we're totally doomed :) Why yes, yes we are. > > I mean, how could we hope to solve this kind of issue on our level if > even those of the world can't ? We muddle through. > > Anyway, sticking to the official internation standard list of > countries maintained by UN (if such a list exists) seems much more > neutral to me. We don't decide anything on countries, we use the > decision of an official organization empowered to make such a > decision. Afaict there is no such list. I'd be happy to be wrong about this, though. > By abandoning flags alltogether, we actually make a decision: we > choose to side with those who don't agree with the UN. No, we don't. and afaict, the UN just muddles through, too. It flags lots of different flags but gives in to various powers when asked to. Fun, huh? Here's a short list of some of the flags which will cause problems in the world: http://commons.wikimedia.org/wiki/Flags_of_active_autonomist_and_secessionist_movements -sv From jwboyer at gmail.com Tue May 19 14:17:11 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 19 May 2009 10:17:11 -0400 Subject: Ongoing mass rebuild on s390x In-Reply-To: <4A12BD34.6020208@redhat.com> References: <20090516173539.GD10645@redhat.de> <20090516184326.GB31277@redhat.de> <645d17210905190322v5c56eb9eo35bd71f0e4873bfb@mail.gmail.com> <4A12B277.7060806@redhat.com> <870180fe0905190658n1dc8d573gb962031ac24825ca@mail.gmail.com> <4A12BD34.6020208@redhat.com> Message-ID: <20090519141711.GA24152@hansolo.jdub.homelinux.org> On Tue, May 19, 2009 at 04:07:48PM +0200, Karsten Hopp wrote: > Am 19.05.2009 15:58, schrieb Jerry James: >> On Tue, May 19, 2009 at 7:21 AM, Karsten Hopp wrote: >> >>> AFAIK there's a cron script which needs to run on the koji hub to run those >>> builds on the >>> secondary archs. This isn't enabled yet as there are still quite a few >>> packages missing and >>> we'd get too many failures caused by unresolved dependencies. >>> But the plan is to enable this as soon as possible. >>> >> >> How about debugging facilities? The C part of GCL is compiling >> successfully, but then it crashes while trying to process the Lisp >> part. Is there a box I can log into remotely so I can use gdb on the >> thing to see what's going on? >> > > > Unfortunately not, but that's similar to the other archs. > If you don' t have p.e. a ppc machine at home you'll have difficulties > fixing a ppc related crash. Atm you'll have to do some nasty tricks There are at least three of us that happily offer ssh access to ppc/ppc64 machines. While that isn't the same as having one sitting in front of you, it does work for a large number of problems. So it's not exactly the same :). josh From aph at redhat.com Tue May 19 14:21:23 2009 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 May 2009 15:21:23 +0100 Subject: Package Maintainers Flags policy In-Reply-To: <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> Message-ID: <4A12C063.2080907@redhat.com> Mathieu Bridon (bochecha) wrote: >> And then your next question is "does the Chinese gov't really care about a >> linux distro having a Taiwanese or Tibetan flag in some programs it ships?" >> and the answer to that question is yes, very much. >> >> So, of course does this mean we are siding with china? No, we're not siding >> with anyone, that's the whole point. >> >> Flags mean a lot to a lot of people. They carry a lot of patriotic crap >> w/them. > > But what is the official internationally recognized status of Taiwan ? There is no World Governement that decides whether independent countries exist. However, Taiwan does not claim to be a country independent of China: the Taiwanese KMT, expelled from Beijing in by Mao, still claims to be the legitimate ruler of *all* China. > If that's a part of china, then it's not an actual country, then we > can remove its flag. > > If that's an independent country, then it has a flag, and we can use it. > > I really wonder why we are trying to solve those geopolitical > international issues. Those are for the governments and the UN to > solve. They agree on a list of officially recognized countries, and we > use it. The UN does not decide what is an "officially recognized country". All it can do is decide whether to admit a country as a member. This is not the same as being a sovereign state, which in practice depends on being recognized by other nations. Andrew. From rc040203 at freenet.de Tue May 19 14:23:21 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 19 May 2009 16:23:21 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <20090519132756.GJ5760@localhost.localdomain> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <1242737946.30251.189.camel@macbook.infradead.org> <20090519132756.GJ5760@localhost.localdomain> Message-ID: <4A12C0D9.1080706@freenet.de> Paul W. Frields wrote: > On Tue, May 19, 2009 at 01:59:06PM +0100, David Woodhouse wrote: >> On Tue, 2009-05-19 at 14:38 +0200, Denis Leroy wrote: >>> On 05/19/2009 12:39 PM, David Woodhouse wrote: >> And my understanding is that there _is_ a valid legal reason for it. >> Distributing Fedora in some countries is _illegal_ if it contains >> certain flags, and can lead to extremely uncomfortable repercussions. Shipping Fedora is always at risk to contain componets which may be considered illegal somewhere due to the nature of "nationalism", "cultural backgrounds", "national laws" and the dynamic nature of such kind of problems. This problem isn't restricted to national symbols (such as flags) but is subject to many topics (E.g. "uncertified games" in Europe, mp3 in the US). > And since I was asked for my opinion, I think David stated it pretty > clearly. But frankly I don't think my opinion is needed or, indeed, > that relevant. Didn't you state to be intending to "lead by example"? If so, you're probably better of to have an opinion. > I do feel strongly that FESCo, as a community elected > body, 1/2 community elected. Ralf From walters at verbum.org Tue May 19 14:25:23 2009 From: walters at verbum.org (Colin Walters) Date: Tue, 19 May 2009 10:25:23 -0400 Subject: Package Maintainers Flags policy In-Reply-To: <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> Message-ID: On Tue, May 19, 2009 at 10:05 AM, Mathieu Bridon (bochecha) wrote: > > Anyway, sticking to the official internation standard list of > countries maintained by UN (if such a list exists) seems much more > neutral to me. A list of current countries doesn't solve the problem. Let's take for example Freeciv, which was cited earlier as having flags as a core part of the experience (I'd disagree, but anyways). Do we allow historical flags or not? I can think of more than one past historical leader and flag that are likely to be controversial, and definitely one which is banned in a perfectly democractic country (this is what Seth was hinting at earlier). > By abandoning flags alltogether, we actually make a decision: we > choose to side with those who don't agree with the UN. Every decision has tradeoffs and ramifications. The point is, are flags/symbols a core part of the value Fedora is delivering in most of these cases? No. Note that we aren't taking away anyone's freedom here - anyone is free to create a localized spin which includes some flags or other changes as they desire. From loganjerry at gmail.com Tue May 19 14:28:15 2009 From: loganjerry at gmail.com (Jerry James) Date: Tue, 19 May 2009 08:28:15 -0600 Subject: Ongoing mass rebuild on s390x In-Reply-To: <20090519141711.GA24152@hansolo.jdub.homelinux.org> References: <20090516173539.GD10645@redhat.de> <20090516184326.GB31277@redhat.de> <645d17210905190322v5c56eb9eo35bd71f0e4873bfb@mail.gmail.com> <4A12B277.7060806@redhat.com> <870180fe0905190658n1dc8d573gb962031ac24825ca@mail.gmail.com> <4A12BD34.6020208@redhat.com> <20090519141711.GA24152@hansolo.jdub.homelinux.org> Message-ID: <870180fe0905190728s1a951ad9qaac017240ab8afa5@mail.gmail.com> On Tue, May 19, 2009 at 8:17 AM, Josh Boyer wrote: > There are at least three of us that happily offer ssh access to ppc/ppc64 > machines. ?While that isn't the same as having one sitting in front of you, > it does work for a large number of problems. ?So it's not exactly the same :). Yes, and I took advantage of that to get GCL working on ppc [1]. Thank you all very much. It's unfortunate that the same cannot be done for s390x. I could never have done the necessary ppc debugging by perusing build logs, at least not in a reasonable amount of time, so I am not inclined to even try for s390x. This means that GCL will probably just stay broken on that arch. Footnotes: [1] However, it doesn't work on ppc64 now, and likely never will. The way GCL builds images is fundamentally at odds with the way the ppc64 BFD library works. If we have any ppc64 linker experts amongst us, perhaps you could join me on the GCL mailing list so we can talk the issues over. -- Jerry James http://www.jamezone.org/ From ewan at macmahon.me.uk Tue May 19 14:47:22 2009 From: ewan at macmahon.me.uk (Ewan Mac Mahon) Date: Tue, 19 May 2009 15:47:22 +0100 Subject: Package Maintainers Flags policy In-Reply-To: References: <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> Message-ID: <20090519144722.GC32139@macmahon.me.uk> On Tue, May 19, 2009 at 10:25:23AM -0400, Colin Walters wrote: > > A list of current countries doesn't solve the problem. Let's take for > example Freeciv, which was cited earlier as having flags as a core > part of the experience (I'd disagree, but anyways). > The problem with FreeCiv is that the only distinction between a city or unit of one nation and one of another is the flag[1], so there doesn't seem to be any simple way to remove them. They could be replaced with different flags graphics, but they'd all have to be distinct; you couldn't just use (e.g.) the Fedora logo for every nation. There's also the fact that FreeCiv in particular contains Tibet as a playable nation; even if the flag were removed, I don't think refering to the Tibetan nation would pass muster in China. That being the case we're either going to need to go a lot further than removing just flags, or accept that generic Fedora won't be 'China safe', in which case we might as well leave the flags alone. Ewan [1] e.g: From musuruan at gmail.com Tue May 19 14:51:25 2009 From: musuruan at gmail.com (Andrea Musuruane) Date: Tue, 19 May 2009 16:51:25 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <200905191559.25564.bjorn@xn--rombobjrn-67a.se> References: <20090518090953.5698908a@ohm.scrye.com> <29fee02b0905190633y17d15955k2b676778058d2d4b@mail.gmail.com> <200905191559.25564.bjorn@xn--rombobjrn-67a.se> Message-ID: <29fee02b0905190751v65fafc97qd5928c93b2389529@mail.gmail.com> 2009/5/19 Bj?rn Persson : > Here's a list of languages that have articles on a certain topic in Wikipedia. > Do you have any problem finding your choice? No, I don't but it is time consuming. After all, icons are made to access information faster. If I have to overemphasize your argument, I would ask you why should we use a graphical environment at all, after all we can all read inside a terminal. I think this is a really practical matter. There may not be the space for a text. Flags are icons if the guidelines tell us to remove them, we have to substitute them with some other icon set. What is this other icon set? Bye, Andrea. From stickster at gmail.com Tue May 19 14:56:48 2009 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 19 May 2009 10:56:48 -0400 Subject: Package Maintainers Flags policy In-Reply-To: <4A12C0D9.1080706@freenet.de> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <1242737946.30251.189.camel@macbook.infradead.org> <20090519132756.GJ5760@localhost.localdomain> <4A12C0D9.1080706@freenet.de> Message-ID: <20090519145648.GC2271@localhost.localdomain> On Tue, May 19, 2009 at 04:23:21PM +0200, Ralf Corsepius wrote: > Paul W. Frields wrote: >> On Tue, May 19, 2009 at 01:59:06PM +0100, David Woodhouse wrote: >>> On Tue, 2009-05-19 at 14:38 +0200, Denis Leroy wrote: >>>> On 05/19/2009 12:39 PM, David Woodhouse wrote: > >>> And my understanding is that there _is_ a valid legal reason for it. >>> Distributing Fedora in some countries is _illegal_ if it contains >>> certain flags, and can lead to extremely uncomfortable repercussions. > Shipping Fedora is always at risk to contain componets which may be > considered illegal somewhere due to the nature of "nationalism", > "cultural backgrounds", "national laws" and the dynamic nature of such > kind of problems. > > This problem isn't restricted to national symbols (such as flags) but is > subject to many topics (E.g. "uncertified games" in Europe, mp3 in the > US). > >> And since I was asked for my opinion, I think David stated it pretty >> clearly. But frankly I don't think my opinion is needed or, indeed, >> that relevant. > Didn't you state to be intending to "lead by example"? > > If so, you're probably better of to have an opinion. I think you've inferred something incorrectly from my comments. I didn't say that I had no opinion. David already posted an identical opinion and I had nothing to add. >> I do feel strongly that FESCo, as a community elected >> body, > 1/2 community elected. It's a fully elected body. Half the seats are up for election after this release of Fedora, the other half after the next one. This is similar to the succession method for many other elected bodies. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From walters at verbum.org Tue May 19 14:59:07 2009 From: walters at verbum.org (Colin Walters) Date: Tue, 19 May 2009 10:59:07 -0400 Subject: Package Maintainers Flags policy In-Reply-To: <20090519144722.GC32139@macmahon.me.uk> References: <4A11984F.2060605@poolshark.org> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> Message-ID: On Tue, May 19, 2009 at 10:47 AM, Ewan Mac Mahon wrote: > > The problem with FreeCiv is that the only distinction between a city or > unit of one nation and one of another is the flag[1], so there doesn't > seem to be any simple way to remove them. Hmm, right I forgot they're on the units too, I was just thinking of the civilization selection screen. Well, the fix for Freeciv might have to be that civilizations get randomly assigned block colors. > There's also the fact that FreeCiv in particular contains Tibet as a > playable nation; even if the flag were removed, I don't think refering > to the Tibetan nation would pass muster in China. That being the case > we're either going to need to go a lot further than removing just flags, > or accept that generic Fedora won't be 'China safe', in which case we > might as well leave the flags alone. Here's the problem though, there are some obvious gaps in the Freeciv civilization list as I mentioned before. Some of which would be offensive to a large swath of the Western world, some which would be extremely controversial in smaller areas of the world, etc. What happens if one of those items gets added to the civilization list upstream? (Do they have a policy?) Actually let's be practical here and admit Freeciv is a pretty special case. The main thing we want to squash is things like flags in input method selection which is very prominent in the UI, and flags in bittorrent clients whose removal doesn't at all substantially affect the operation of the software. Maybe we need a flag in the RPM .spec to say "this package contains geopolitical symbols" and mark all of Freeciv as that. From fedora at leemhuis.info Tue May 19 15:07:02 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 19 May 2009 17:07:02 +0200 Subject: What questions would you like to ask the Fedora Board or FESCo Candidates? Message-ID: <4A12CB16.4050104@leemhuis.info> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Several seats of the Fedora Board and FESCo are up for election soon(?). Right now we are in the nomination period, which will be followed by a "Candidate Questionnaire." That means we give candidates a list of questions to answer by mail before the Town Hall meetings on IRC happen. Candidates may choose to answer (or not) those questions as they see fit. Voters can use the answers to get an impression of what the candidate think or plan to do while serving for the Board or FESCo. That should help to get a interesting discussion running during the IRC Town Hall meetings. Furthermore, those people that can't or don't want to participate in the IRC meetings can use the answers to make a more informed vote. Hence we need to prepare a few good questions that we can send to the candidates once the nomination period ends. And that's where I need *your help*: If you have one or more questions you'd like to send to the candidates simply go and add them to: https://fedoraproject.org/wiki/Elections/Questionnaire It just takes a minute or two, so best to do it right now -- otherwise you might get distracted and forget about it. ;-) I'll take care of the remaining work to review, sort, and clean up the questions(?), and send them to the candidates after the nomination period ends. Hence, I need them by around the 27th of May. I'll later collect the answers from the candidates and put them up for pubic consumption to give people enough time to read them before the town hall meetings start. So go to the wiki and add at least one hard question! The answer will help Fedora contributors to chose whom to vote for! Thanks in advance. CU knurd (?) If you haven't read about it yet see https://fedoraproject.org/wiki/Elections for details. (?) If you want to get involved or review the question before I send them please drop me a line and I'll get that arranged -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkoSyxYACgkQUjQh93TopkE14QCfd8S+T8a1k8NUy+gkBbnMOqMx nosAoKl4jgum9/8NV4MkZ6L7wBX89k6b =0Qr6 -----END PGP SIGNATURE----- From skvidal at fedoraproject.org Tue May 19 15:09:18 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 19 May 2009 11:09:18 -0400 (EDT) Subject: Package Maintainers Flags policy In-Reply-To: References: <4A11984F.2060605@poolshark.org> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> Message-ID: On Tue, 19 May 2009, Colin Walters wrote: > > Actually let's be practical here and admit Freeciv is a pretty special > case. The main thing we want to squash is things like flags in input > method selection which is very prominent in the UI, and flags in > bittorrent clients whose removal doesn't at all substantially affect > the operation of the software. > It's also completely possible that freeciv may not be a package we can ship. If someone packaged a "free taiwan" game where you protested the PRC and wheeled and dealed to get various world gov'ts to officially recognize taiwan (an amusing game premise, actually) I think we'd probably have to not ship it. Just as if someone packaged a game adaptation of "springtime for hitler and germany." (from the producers musical/movie for anyone who doesn't get the reference) we'd probably not ship it. -sv From a.badger at gmail.com Tue May 19 15:10:31 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 19 May 2009 08:10:31 -0700 Subject: Package Maintainers Flags policy In-Reply-To: <4A12C0D9.1080706@freenet.de> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <1242737946.30251.189.camel@macbook.infradead.org> <20090519132756.GJ5760@localhost.localdomain> <4A12C0D9.1080706@freenet.de> Message-ID: <4A12CBE7.406@gmail.com> On 05/19/2009 07:23 AM, Ralf Corsepius wrote: > Paul W. Frields wrote: >> I do feel strongly that FESCo, as a community elected >> body, > 1/2 community elected. > The Board is half elected, half appointed. FESCo is wholly elected. -Toshio From notting at redhat.com Tue May 19 15:23:36 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 19 May 2009 11:23:36 -0400 Subject: Package Maintainers Flags policy In-Reply-To: <4ccd9dcb0905190600t30325bf1j56b7f53c5744900c@mail.gmail.com> References: <20090518090953.5698908a@ohm.scrye.com> <1242667087.25634.1927.camel@cookie.hadess.net> <200905182239.04065.bjorn@xn--rombobjrn-67a.se> <4ccd9dcb0905190600t30325bf1j56b7f53c5744900c@mail.gmail.com> Message-ID: <20090519152336.GC32715@nostromo.devel.redhat.com> alcapcom (alcapcom at gmail.com) said: > Unfortunate peoples that live in countries where a _simple_ flag can > give troubles for whatever cause/reason, can remove them all to be > able to use Fedora. But please, don't cut our freedom just to be more > friendly with authoritarian regimes. The simplest way to make it so that anyone can easily and persistently remove them is to not ship them by default. Makes it a lot harder to break that way. Bill From walters at verbum.org Tue May 19 15:27:13 2009 From: walters at verbum.org (Colin Walters) Date: Tue, 19 May 2009 11:27:13 -0400 Subject: Package Maintainers Flags policy In-Reply-To: References: <4A11984F.2060605@poolshark.org> <4A12A82B.1080502@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> Message-ID: On Tue, May 19, 2009 at 11:09 AM, Seth Vidal wrote: > > It's also completely possible that freeciv may not be a package we can ship. Not have at all in RPM form on the mirrors and in the repo list you mean? That's a pretty harsh solution. There's degrees here. I could imagine for example that for some consumers of Fedora, being able to automatically strip out the controversial packages when redistributing, and have yum be able to skip listing -flags/controversial packages would be enough for them. That seems to be some of the logic behind the current flags policy, though please correct me if I'm wrong. > If someone packaged a "free taiwan" game where you protested the PRC and > wheeled and dealed to get various world gov'ts to officially recognize > taiwan (an amusing game premise, actually) I think we'd probably have to not > ship it. Just as if someone packaged a game adaptation of "springtime for > hitler and germany." (from the producers musical/movie for anyone who > doesn't get the reference) we'd probably not ship it. Well, luckily for us the vast majority of these kinds of things are Flash games on the web now, so they're not our problem. From bnocera at redhat.com Tue May 19 15:30:37 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Tue, 19 May 2009 16:30:37 +0100 Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <1242667087.25634.1927.camel@cookie.hadess.net> <200905182239.04065.bjorn@xn--rombobjrn-67a.se> <4ccd9dcb0905190600t30325bf1j56b7f53c5744900c@mail.gmail.com> Message-ID: <1242747037.25634.7307.camel@cookie.hadess.net> On Tue, 2009-05-19 at 09:59 -0400, Seth Vidal wrote: > > On Tue, 19 May 2009, alcapcom wrote: > > > 2009/5/18 Bj?rn Persson : > >> To me it would seem more reasonable to install the flags by default. Then the > >> anti-whatever extremists could just remove them, and the more relaxed among > >> us would see the user interface the way the authors intended without jumping > >> through additional hoops. > > > > +1 > > > > But I will try to say it in another way. > > > > Unfortunate peoples that live in countries where a _simple_ flag can > > give troubles for whatever cause/reason, can remove them all to be > > able to use Fedora. But please, don't cut our freedom just to be more > > friendly with authoritarian regimes. > > What if a non-authoritarian regime didn't want us to distribute a flag > that was offensive to their democratically-empowered populace? Would that > be okay then? Say, using pretzels and sausages on flags instead of Swastikas... http://www.spiegel.de/international/zeitgeist/0,1518,617987,00.html > the whole reason for nuking the set of flags entirely is so we are NOT > choosing sides. Which was my early answer to Kevin on the subject, and comforts me in my thinking :) From skvidal at fedoraproject.org Tue May 19 15:34:36 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 19 May 2009 11:34:36 -0400 (EDT) Subject: Package Maintainers Flags policy In-Reply-To: References: <4A11984F.2060605@poolshark.org> <4A12A82B.1080502@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> Message-ID: On Tue, 19 May 2009, Colin Walters wrote: > On Tue, May 19, 2009 at 11:09 AM, Seth Vidal wrote: >> >> It's also completely possible that freeciv may not be a package we can ship. > > Not have at all in RPM form on the mirrors and in the repo list you > mean? That's a pretty harsh solution. There's degrees here. I could > imagine for example that for some consumers of Fedora, being able to > automatically strip out the controversial packages when > redistributing, and have yum be able to skip listing > -flags/controversial packages would be enough for them. That seems to > be some of the logic behind the current flags policy, though please > correct me if I'm wrong. We'd need: 1. some kind of plugin to handle it 2. some sort of provides tag in the rpm that's a lot of crap to do in lieu of just not shipping the pkg. >> If someone packaged a "free taiwan" game where you protested the PRC and >> wheeled and dealed to get various world gov'ts to officially recognize >> taiwan (an amusing game premise, actually) I think we'd probably have to not >> ship it. Just as if someone packaged a game adaptation of "springtime for >> hitler and germany." (from the producers musical/movie for anyone who >> doesn't get the reference) we'd probably not ship it. > > Well, luckily for us the vast majority of these kinds of things are > Flash games on the web now, so they're not our problem. yet. -sv From dwmw2 at infradead.org Tue May 19 15:41:31 2009 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 19 May 2009 16:41:31 +0100 Subject: Package Maintainers Flags policy In-Reply-To: <20090519132859.GA13698@srcf.ucam.org> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <29fee02b0905190526i593c1c97x840ba64d38455902@mail.gmail.com> <1242737529.30251.182.camel@macbook.infradead.org> <4A12B130.5040107@poolshark.org> <20090519132859.GA13698@srcf.ucam.org> Message-ID: <1242747691.2919.25.camel@macbook.infradead.org> On Tue, 2009-05-19 at 14:28 +0100, Matthew Garrett wrote: > On Tue, May 19, 2009 at 03:16:32PM +0200, Denis Leroy wrote: > > If you agree to the absurdity of the broad effects caused by the policy > > you voted for, you need to resign from FeSCo immediately. The policy said 'come to FESCo if you want an exception', but sets the standard that we should avoid shipping flags where it's not necessary. I think that's a perfectly acceptable and pragmatic solution. > Please keep the conversation civil. That was civil enough. He disagrees strongly with the decision which FESCo took, and presumably wants _all_ of us who voted for this policy to resign, rather than just myself. He stated that desire quite politely, and I think he's perfectly entitled to do so. As it happens, my seat and the seats of a few others who voted for this policy are coming up for re-election soon anyway. So Denis gets his wish :) -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation From craftjml at gmail.com Tue May 19 15:42:11 2009 From: craftjml at gmail.com (Jud Craft) Date: Tue, 19 May 2009 10:42:11 -0500 Subject: Keyboard mapping characters with both shift keys In-Reply-To: References: <4A1132C9.4040601@redhat.com> <9497e9990905180626w37f74f4qecb2a638b2caf361@mail.gmail.com> <1242661593.3223.36.camel@localhost.localdomain> Message-ID: <20d6441a0905190842i33027fb9mbbb548c38169039e@mail.gmail.com> Logitech wave multimedia keyboard here, L+R shift + t doesn't work. L+Rs + r does work. Maybe it has something to do with the wiring of the keyboard (even on nice keyboards), that only certain groups of keys can send so many signals at a certain time. From dwmw2 at infradead.org Tue May 19 15:45:58 2009 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 19 May 2009 16:45:58 +0100 Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <1242667087.25634.1927.camel@cookie.hadess.net> Message-ID: <1242747958.2919.31.camel@macbook.infradead.org> On Mon, 2009-05-18 at 19:32 +0200, Kevin Kofler wrote: > On the other hand, KDE upstream explicitly decided NOT to ban flags, > as they consider banning flags to be a political move and to go > against KDE's principle of political neutrality. Consider the following statement: On the other hand, $PROJECT upstream explicitly decided NOT to ban profanity, as they consider banning profanity to be a political move and to go against $PROJECT's principle of political neutrality. Would people be arguing to ship that project, unmodified, in Fedora? Try the same statement with s/profanity/sexually explicit images/. Or anything that offends some people irrationally. Besides, the KDE position doesn't make any sense -- you either ship (for example) a Taiwanese flag, or you don't. Either way, you've thrown your opinion into the ring. Only by _avoiding_ flags altogether do you get to avoid participating in the political debate, and remain neutral. -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation From ewan at macmahon.me.uk Tue May 19 15:55:47 2009 From: ewan at macmahon.me.uk (Ewan Mac Mahon) Date: Tue, 19 May 2009 16:55:47 +0100 Subject: Package Maintainers Flags policy In-Reply-To: References: <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> Message-ID: <20090519155546.GD32139@macmahon.me.uk> On Tue, May 19, 2009 at 10:59:07AM -0400, Colin Walters wrote: > On Tue, May 19, 2009 at 10:47 AM, Ewan Mac Mahon wrote: > > > > The problem with FreeCiv is that the only distinction between a city or > > unit of one nation and one of another is the flag[1], so there doesn't > > seem to be any simple way to remove them. > > Hmm, right I forgot they're on the units too, I was just thinking of > the civilization selection screen. > > Actually let's be practical here and admit Freeciv is a pretty special > case. > That's true, but if the no flags policy is intended to cover the whole distribution then it needs to take account of the hard cases as well as the easy ones. > The main thing we want to squash is things like flags in input > method selection which is very prominent in the UI, and flags in > bittorrent clients whose removal doesn't at all substantially affect > the operation of the software. > That's a reasonable postion, but it's not quite the same as the current policy. We really do need to decide whether the response to a package that can't feasably have it's flags removed is to drop the package, or live with the flags. If we go for the latter then we're not actually solved the problem of distributing Fedora in places like China, and I'm not sure that the former is an attractive trade-off for what seems a fairly marginal benefit. Ewan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From walters at verbum.org Tue May 19 16:01:56 2009 From: walters at verbum.org (Colin Walters) Date: Tue, 19 May 2009 12:01:56 -0400 Subject: Package Maintainers Flags policy In-Reply-To: References: <4A11984F.2060605@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> Message-ID: On Tue, May 19, 2009 at 11:34 AM, Seth Vidal wrote: > We'd need: > 1. some kind of plugin to handle it > 2. some sort of provides tag in the rpm > > that's a lot of crap to do in lieu of just not shipping the pkg. OK, yeah I understand it's not simple to tweak the infrastructure. On the other hand I do think Freeciv is a good example of a free software game of the kind we'd like Fedora to have available, and the flags are not trivial to remove. I guess this one comes down to the case-by-case for FESCo. Again though it would be useful though if someone involved in the policy could explain how the -flags subpackages are planned to be consumed. I'm just guessing that the goal is for derived distributions to be able to automatically strip them out, and as I said in that case it seems like it would be fine for them if they could also strip out Freeciv given some tag in the package (along with cases like the educational games with flags), while keeping it available (i.e. on the mirrors) in Fedora "upstream". From dwmw2 at infradead.org Tue May 19 16:10:03 2009 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 19 May 2009 17:10:03 +0100 Subject: Package Maintainers Flags policy In-Reply-To: <20090519155546.GD32139@macmahon.me.uk> References: <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <20090519155546.GD32139@macmahon.me.uk> Message-ID: <1242749403.2919.36.camel@macbook.infradead.org> On Tue, 2009-05-19 at 16:55 +0100, Ewan Mac Mahon wrote: > We really do need to decide whether the response to a package that can't > feasably have it's flags removed is to drop the package, or live with > the flags. If we go for the latter then we're not actually solved the > problem of distributing Fedora in places like China, and I'm not sure > that the former is an attractive trade-off for what seems a fairly > marginal benefit. We really do need to decide whether the response to a package that can't feasibly have its patented algorithms removed is to drop the package, or live with the patents. If we go for the latter then we've not actually solved the problem of distributing Fedora in places like the US. The former _is_ a simple enough trade-off. We have a "Fedora Free World" repository already... Seriously, folks -- we're only doing for flags the _same_ thing we've done for a bunch of other things that would make it problematic to ship Fedora in certain places. Just because it isn't an issue where _you_ live, that doesn't mean we shouldn't care about it. I wish people would stop being so parochial. -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation From jkeating at redhat.com Tue May 19 16:13:24 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 19 May 2009 09:13:24 -0700 Subject: Package Maintainers Flags policy In-Reply-To: <2d319b780905190131m383607c2v13e22aee27bcd4c1@mail.gmail.com> References: <20090518090953.5698908a@ohm.scrye.com> <1242667087.25634.1927.camel@cookie.hadess.net> <1242675818.15983.49.camel@jdlaptop.lesbg.loc> <2d319b780905190131m383607c2v13e22aee27bcd4c1@mail.gmail.com> Message-ID: <1242749604.3223.76.camel@localhost.localdomain> On Tue, 2009-05-19 at 10:31 +0200, Mathieu Bridon (bochecha) wrote: > (or has to be, I mean, are there some > countries who don't recognize the authority of UN ?) Plenty. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Tue May 19 16:14:32 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 19 May 2009 09:14:32 -0700 Subject: Package Maintainers Flags policy In-Reply-To: <20090519144722.GC32139@macmahon.me.uk> References: <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> Message-ID: <4A12DAE8.8040903@gmail.com> On 05/19/2009 07:47 AM, Ewan Mac Mahon wrote: > On Tue, May 19, 2009 at 10:25:23AM -0400, Colin Walters wrote: >> A list of current countries doesn't solve the problem. Let's take for >> example Freeciv, which was cited earlier as having flags as a core >> part of the experience (I'd disagree, but anyways). >> > The problem with FreeCiv is that the only distinction between a city or > unit of one nation and one of another is the flag[1], so there doesn't > seem to be any simple way to remove them. They could be replaced with > different flags graphics, but they'd all have to be distinct; you > couldn't just use (e.g.) the Fedora logo for every nation. > > There's also the fact that FreeCiv in particular contains Tibet as a > playable nation; even if the flag were removed, I don't think refering > to the Tibetan nation would pass muster in China. That being the case > we're either going to need to go a lot further than removing just flags, > or accept that generic Fedora won't be 'China safe', in which case we > might as well leave the flags alone. > So here's a possibility of how a compromise could be structured. This is assuming that FESCo doesn't just decide that flags can be kept because spot's explanation in this thread clarified the legal situation: Currently, the FESCo Policy mandates that: 1) If use of flags "is not technically or substantively essential" to a package, they must be in subpackages or not included. 2) Programs which require the flags must have a fallback mechanism because they are prohibited from Requiring the flags subpackage. 3) Exceptions are granted for programs which feel they need to violate this. New Proposal: [current definition of flags remains] * Packages that include flags must show that they do this by having a virtual Provides: Politics(flags). * If a package is on the main spin (or required by something on the main spin in the case of updates that pull in different packages), it cannot Provides: Politics(flags). * If a program is needed for the main spin but Provides: Politics(flags), someone must do the work to move the flags into a subpackage that Provides the flags and patch the program to make existence of the flags optional. As noted above, that subpackage cannot be Required from the package that is on the main spin. Several notes: * I divided this up a bit from the current policy. So there's a political decision, no flags on the main spin, and an implementation decision: Use a virtual Provides to mark the packages. I don't know if FESCo wants to decide the whole thing or if they want to hand off the second half to FPC for a solution by a certain deadline. * Packages not on the main spin have minimal burden under this proposal * Packages on the main spin (or packages that understand the issues and decide they want to be distributable in countries where some flags are banned) will still need to do the work, possibly carry patches, etc. * This ties the policy to the existence of a "main spin". I don't believe there's serious plans to get rid of that but if we do, this policy will need to be revised. * There's no exception process like the current Policy. The anticipated answer to a problematic package is: "Don't put that program on the main spin". * Distributing Fedora in countries that ban certain flags is somewhat harder: - Before, a mirror could exclude subpackages that ended in -flags. Now the mirror would need to exclude packages that Provides: Politics(flags) and, to be nice to their consumers, the packages that depend on them. The mirror might have gotten away with not regenerating the repodata with the current policy because installing an optional -flags package wouldn't be that common but they would definitely need to regenerate the repodata if the exclusion of Politics(flags): packages was leading to programs users might want not ending in the repository. - Note that you *can* still distribute the main Fedora spin without difficulty. -Toshio From jkeating at redhat.com Tue May 19 16:21:04 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 19 May 2009 09:21:04 -0700 Subject: Package Maintainers Flags policy In-Reply-To: <4A12B9AF.4010009@poolshark.org> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <4A12B9AF.4010009@poolshark.org> Message-ID: <1242750064.3223.78.camel@localhost.localdomain> On Tue, 2009-05-19 at 15:52 +0200, Denis Leroy wrote: > Seth, I think we all agree to that. There is a list of > pairs that causes problems :-). To be more accurate, there is a > well-known very short list of pairs that Fedora cannot > ship with legally. The point is: the policy is way overreaching. This > would be better dealt with on a case-by-case basis, only when we know > for a *fact* we cannot ship Fedora with a specific flag. A flag that has > no legal issues but may offend someone is not a good enough reason, it > becomes an upstream project issue rather than a Fedora issue. When you single out the flags to remove, you are in fact siding with the people that take offense to those flags, eg China. I certainly don't want the Fedora project to appear to be taking sides with China in their Tibet issues. The only way to be fair, is if we're going to remove one flag, we remove them all. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Tue May 19 16:23:40 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 19 May 2009 09:23:40 -0700 Subject: Package Maintainers Flags policy In-Reply-To: <20090519144722.GC32139@macmahon.me.uk> References: <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> Message-ID: <1242750220.3223.79.camel@localhost.localdomain> On Tue, 2009-05-19 at 15:47 +0100, Ewan Mac Mahon wrote: > On Tue, May 19, 2009 at 10:25:23AM -0400, Colin Walters wrote: > > > > A list of current countries doesn't solve the problem. Let's take for > > example Freeciv, which was cited earlier as having flags as a core > > part of the experience (I'd disagree, but anyways). > > > The problem with FreeCiv is that the only distinction between a city or > unit of one nation and one of another is the flag[1], so there doesn't > seem to be any simple way to remove them. They could be replaced with > different flags graphics, but they'd all have to be distinct; you > couldn't just use (e.g.) the Fedora logo for every nation. > > There's also the fact that FreeCiv in particular contains Tibet as a > playable nation; even if the flag were removed, I don't think refering > to the Tibetan nation would pass muster in China. That being the case > we're either going to need to go a lot further than removing just flags, > or accept that generic Fedora won't be 'China safe', in which case we > might as well leave the flags alone. > > Ewan > > [1] e.g: From skvidal at fedoraproject.org Tue May 19 16:25:02 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 19 May 2009 12:25:02 -0400 (EDT) Subject: Package Maintainers Flags policy In-Reply-To: <1242750220.3223.79.camel@localhost.localdomain> References: <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <1242750220.3223.79.camel@localhost.localdomain> Message-ID: On Tue, 19 May 2009, Jesse Keating wrote: > On Tue, 2009-05-19 at 15:47 +0100, Ewan Mac Mahon wrote: >> On Tue, May 19, 2009 at 10:25:23AM -0400, Colin Walters wrote: >>> >>> A list of current countries doesn't solve the problem. Let's take for >>> example Freeciv, which was cited earlier as having flags as a core >>> part of the experience (I'd disagree, but anyways). >>> >> The problem with FreeCiv is that the only distinction between a city or >> unit of one nation and one of another is the flag[1], so there doesn't >> seem to be any simple way to remove them. They could be replaced with >> different flags graphics, but they'd all have to be distinct; you >> couldn't just use (e.g.) the Fedora logo for every nation. >> >> There's also the fact that FreeCiv in particular contains Tibet as a >> playable nation; even if the flag were removed, I don't think refering >> to the Tibetan nation would pass muster in China. That being the case >> we're either going to need to go a lot further than removing just flags, >> or accept that generic Fedora won't be 'China safe', in which case we >> might as well leave the flags alone. >> >> Ewan >> >> [1] e.g: > That's a pretty big reason why games such as FreeCiv should stick to > fictional countries and fictional flags. It avoids all of these issues. Then the fictional residents of Ihaterandomstan and randomstan will be outraged! -sv From skvidal at fedoraproject.org Tue May 19 16:28:08 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 19 May 2009 12:28:08 -0400 (EDT) Subject: Package Maintainers Flags policy In-Reply-To: <4A12DAE8.8040903@gmail.com> References: <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <4A12DAE8.8040903@gmail.com> Message-ID: On Tue, 19 May 2009, Toshio Kuratomi wrote: > * If a program is needed for the main spin but Provides: Politics(flags), > someone must do the work to move the flags into a subpackage that Provides > the flags and patch the program to make existence of the flags optional. As > noted above, that subpackage cannot be Required from the package that is on > the main spin. If we end up needing yum plugin of some kind to handle this can I call it the free-randomstan plugin? -sv From notting at redhat.com Tue May 19 16:32:32 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 19 May 2009 12:32:32 -0400 Subject: Package Maintainers Flags policy In-Reply-To: References: <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <4A12DAE8.8040903@gmail.com> Message-ID: <20090519163232.GA3247@nostromo.devel.redhat.com> Seth Vidal (skvidal at fedoraproject.org) said: >> * If a program is needed for the main spin but Provides: >> Politics(flags), someone must do the work to move the flags into a >> subpackage that Provides the flags and patch the program to make >> existence of the flags optional. As noted above, that subpackage >> cannot be Required from the package that is on the main spin. > > If we end up needing yum plugin of some kind to handle this can I call > it the free-randomstan plugin? We don't have a yum-patents plugin, or Provides(patents). Why are we going to such lengths here? Bill From xjakub at fi.muni.cz Tue May 19 16:39:29 2009 From: xjakub at fi.muni.cz (Milos Jakubicek) Date: Tue, 19 May 2009 18:39:29 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <200905182350.41222.opensource@till.name> References: <20090518090953.5698908a@ohm.scrye.com> <200905182350.41222.opensource@till.name> Message-ID: <4A12E0C1.2000409@fi.muni.cz> On 18.5.2009 23:50, Till Maas wrote: > On Mo Mai 18 2009, Kevin Fenzi wrote: >> In FESCo's 2009-03-28 meeting a policy on Flag usage for packages in >> Fedora was approved. >> >> Due to an oversight, this policy was not announced here. ;( > > Why is this a policy and not some packaging guideline. It clearly contains > packaging instructions: > > | flag images must be placed in an -flags subpackage. The -flags subpackage > | cannot be Required by the main package. > > Also this is something that should probably be checked at review time, which > also makes it better suited in the review guidelines. > > Additionally the visibility of this page is pretty low, it is not linked from > any other page. There is only a redirection from probably Tom Callaways > proposal page: > https://fedoraproject.org/wiki/Special:WhatLinksHere/Package_Maintainers_Flags_Policy Yes, this was the reason why I brought this up on #fedora-devel (and I'm sorry that it led to such a flame) to spot as I was not even sure whether it is still a proposal or already approved policy. Please turn this discussion back to two questions: 1) What should be the page name? 2) Where should it be moved to and from what pages linked so that people do not miss it? Thanks, Milos From denis at poolshark.org Tue May 19 16:41:03 2009 From: denis at poolshark.org (Denis Leroy) Date: Tue, 19 May 2009 18:41:03 +0200 Subject: Package Maintainers Flags policy In-Reply-To: References: <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <4A12DAE8.8040903@gmail.com> Message-ID: <4A12E11F.8040303@poolshark.org> On 05/19/2009 06:28 PM, Seth Vidal wrote: > If we end up needing yum plugin of some kind to handle this can I call > it the free-randomstan plugin? I am sure people from countries with a "stan" suffix find your example classy and in good taste. Congratulations. From skvidal at fedoraproject.org Tue May 19 16:44:46 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 19 May 2009 12:44:46 -0400 (EDT) Subject: Package Maintainers Flags policy In-Reply-To: <4A12E11F.8040303@poolshark.org> References: <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <4A12DAE8.8040903@gmail.com> <4A12E11F.8040303@poolshark.org> Message-ID: On Tue, 19 May 2009, Denis Leroy wrote: > On 05/19/2009 06:28 PM, Seth Vidal wrote: >> If we end up needing yum plugin of some kind to handle this can I call >> it the free-randomstan plugin? > > I am sure people from countries with a "stan" suffix find your example classy > and in good taste. Congratulations. I'm happy with randomstan, randomville, randomburg, randomton, etc, etc The suffix -st?n (spelled ????? in the Perso-Arabic script) is Persian for "place of", derived from the Indo-Aryan equivalent, -sth?na ... en.wikipedia.org/wiki/-stan I didn't mean it to point out any region of the world, only to denote 'place of'. -sv From a.badger at gmail.com Tue May 19 16:46:48 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 19 May 2009 09:46:48 -0700 Subject: Package Maintainers Flags policy In-Reply-To: <1242750220.3223.79.camel@localhost.localdomain> References: <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <1242750220.3223.79.camel@localhost.localdomain> Message-ID: <4A12E278.9000901@gmail.com> On 05/19/2009 09:23 AM, Jesse Keating wrote: > On Tue, 2009-05-19 at 15:47 +0100, Ewan Mac Mahon wrote: >> On Tue, May 19, 2009 at 10:25:23AM -0400, Colin Walters wrote: >>> A list of current countries doesn't solve the problem. Let's take for >>> example Freeciv, which was cited earlier as having flags as a core >>> part of the experience (I'd disagree, but anyways). >>> >> The problem with FreeCiv is that the only distinction between a city or >> unit of one nation and one of another is the flag[1], so there doesn't >> seem to be any simple way to remove them. They could be replaced with >> different flags graphics, but they'd all have to be distinct; you >> couldn't just use (e.g.) the Fedora logo for every nation. >> >> There's also the fact that FreeCiv in particular contains Tibet as a >> playable nation; even if the flag were removed, I don't think refering >> to the Tibetan nation would pass muster in China. That being the case >> we're either going to need to go a lot further than removing just flags, >> or accept that generic Fedora won't be 'China safe', in which case we >> might as well leave the flags alone. >> >> Ewan >> >> [1] e.g: > That's a pretty big reason why games such as FreeCiv should stick to > fictional countries and fictional flags. It avoids all of these issues. > Using real countries does add value to freeciv (I'm not the only one that clicks a country and reads about all the great leaders from there, right? Right? Anyone? Bueller? ;-) It's also unavoidable in other games that are meant to be simulations as opposed to equally weighted wargames. -Toshio From a.badger at gmail.com Tue May 19 16:50:00 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 19 May 2009 09:50:00 -0700 Subject: Package Maintainers Flags policy In-Reply-To: <20090519163232.GA3247@nostromo.devel.redhat.com> References: <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <4A12DAE8.8040903@gmail.com> <20090519163232.GA3247@nostromo.devel.redhat.com> Message-ID: <4A12E338.4060308@gmail.com> On 05/19/2009 09:32 AM, Bill Nottingham wrote: > Seth Vidal (skvidal at fedoraproject.org) said: >>> * If a program is needed for the main spin but Provides: >>> Politics(flags), someone must do the work to move the flags into a >>> subpackage that Provides the flags and patch the program to make >>> existence of the flags optional. As noted above, that subpackage >>> cannot be Required from the package that is on the main spin. >> If we end up needing yum plugin of some kind to handle this can I call >> it the free-randomstan plugin? > > We don't have a yum-patents plugin, or Provides(patents). Why are we > going to such lengths here? > Wouldn't a policy on Provides: Policy(patents) have to originate with rpmfusion? -Toshio From alcapcom at gmail.com Tue May 19 16:51:38 2009 From: alcapcom at gmail.com (alcapcom) Date: Tue, 19 May 2009 18:51:38 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <20090519152336.GC32715@nostromo.devel.redhat.com> References: <20090518090953.5698908a@ohm.scrye.com> <1242667087.25634.1927.camel@cookie.hadess.net> <200905182239.04065.bjorn@xn--rombobjrn-67a.se> <4ccd9dcb0905190600t30325bf1j56b7f53c5744900c@mail.gmail.com> <20090519152336.GC32715@nostromo.devel.redhat.com> Message-ID: <4ccd9dcb0905190951g5748d3f5qddb57b3ac941aee7@mail.gmail.com> 2009/5/19 Bill Nottingham : > alcapcom (alcapcom at gmail.com) said: >> Unfortunate peoples that live in countries where a _simple_ flag can >> give troubles for whatever cause/reason, can remove them all to be >> able to use Fedora. But please, don't cut our freedom just to be more >> friendly with authoritarian regimes. > > The simplest way to make it so that anyone can easily and persistently > remove them is to not ship them by default. Makes it a lot harder to > break that way. > It's the simple way, but do we always choice the simple way? ...No we like freedom and challenges :-) We just need to continue what we always have do and like I had expected someone would come with something better that just remove all flags. Thanks Toshio. Alphonse From skvidal at fedoraproject.org Tue May 19 17:01:59 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 19 May 2009 13:01:59 -0400 (EDT) Subject: Package Maintainers Flags policy In-Reply-To: <20090519163232.GA3247@nostromo.devel.redhat.com> References: <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <4A12DAE8.8040903@gmail.com> <20090519163232.GA3247@nostromo.devel.redhat.com> Message-ID: On Tue, 19 May 2009, Bill Nottingham wrote: > Seth Vidal (skvidal at fedoraproject.org) said: >>> * If a program is needed for the main spin but Provides: >>> Politics(flags), someone must do the work to move the flags into a >>> subpackage that Provides the flags and patch the program to make >>> existence of the flags optional. As noted above, that subpackage >>> cannot be Required from the package that is on the main spin. >> >> If we end up needing yum plugin of some kind to handle this can I call >> it the free-randomstan plugin? > > We don't have a yum-patents plugin, or Provides(patents). Why are we > going to such lengths here? How would we have a Provides(patents) on pkgs in fedora? If the pkgs had patent issues we couldn't ship them at all, could we? -sv From alcapcom at gmail.com Tue May 19 17:12:00 2009 From: alcapcom at gmail.com (alcapcom) Date: Tue, 19 May 2009 19:12:00 +0200 Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <1242667087.25634.1927.camel@cookie.hadess.net> <200905182239.04065.bjorn@xn--rombobjrn-67a.se> <4ccd9dcb0905190600t30325bf1j56b7f53c5744900c@mail.gmail.com> Message-ID: <4ccd9dcb0905191012p5a3281ecx618ec7453c4df0cd@mail.gmail.com> 2009/5/19 Seth Vidal : > What if a non-authoritarian regime didn't want us to distribute a flag that > was offensive to their democratically-empowered populace? Would that be okay > then? IMHO it's an upstream problem not a Fedora one. Maybe sometimes upstream are to close to a given conflict to take a appropriate decision. In such cases, FESCO can use the current policy but only in this kind of cases. Make that sens? > the whole reason for nuking the set of flags entirely is so we are NOT > choosing sides. It's a way of doing, maybe not the only one. Alphonse From skvidal at fedoraproject.org Tue May 19 17:16:10 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 19 May 2009 13:16:10 -0400 (EDT) Subject: Package Maintainers Flags policy In-Reply-To: <4A12E278.9000901@gmail.com> References: <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <1242750220.3223.79.camel@localhost.localdomain> <4A12E278.9000901@gmail.com> Message-ID: On Tue, 19 May 2009, Toshio Kuratomi wrote: > Using real countries does add value to freeciv (I'm not the only one that > clicks a country and reads about all the great leaders from there, right? > Right? Anyone? Bueller? ;-) And this is why we aren't making a blanket black/white policy but letting fesco adjudicate the items where it is blurrier. > It's also unavoidable in other games that are meant to be simulations as > opposed to equally weighted wargames. and in some cases those games may have to be dropped. Sometimes things suck. I'd like to see a show of hands of people who are surprised. oh, look, no one has their hands up. -sv From bochecha at fedoraproject.org Tue May 19 17:27:06 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Tue, 19 May 2009 19:27:06 +0200 Subject: Package Maintainers Flags policy In-Reply-To: References: <4A11984F.2060605@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <1242750220.3223.79.camel@localhost.localdomain> <4A12E278.9000901@gmail.com> Message-ID: <2d319b780905191027v2ef80a22t4b8023eceae84664@mail.gmail.com> > I'd like to see a show of hands of people who are surprised. Actually, I am totally amazed that such a thing as a flag in a software can cause so many troubles. Call me naive, maybe I live in a parallel world populated only with Care Bears, but I really would never have imagined that people could boycott a product because it includes a reference to a place in the world that they do not recognized. So, here is me raising my hand. Anyway, I don't want to add anything more to the flames, I really do not care about this issue and I'll be happy to apply the policy (actually, I'm not sure I already saw a flag in Fedora :) Regards, ---------- Mathieu Bridon (bochecha) From dwinship at redhat.com Tue May 19 17:34:46 2009 From: dwinship at redhat.com (Dan Winship) Date: Tue, 19 May 2009 13:34:46 -0400 Subject: Package Maintainers Flags policy In-Reply-To: <4A12E0C1.2000409@fi.muni.cz> References: <20090518090953.5698908a@ohm.scrye.com> <200905182350.41222.opensource@till.name> <4A12E0C1.2000409@fi.muni.cz> Message-ID: <4A12EDB6.4070600@redhat.com> Milos Jakubicek wrote: > Please turn this discussion back to two questions: > > 1) What should be the page name? So just in case this can of worms isn't big enough already, it might be worth changing it to be a more generic "political arguments we don't want to get involved in" policy. Specifically, geolocation seems to be the free software buzzword for 2009, and there are a bunch of Summer of Code projects in GNOME and elsewhere involving location and mapping. Maps pose a similar set of problems to flags; eg, if you ship a map claiming that Northern Cyprus is a separate territory from Cyprus then Greece gets pissed off, and if you ship a map saying that it isn't, then Turkey gets pissed off. (As I understand it, the Cypriots themselves mostly just wish that Greece and Turkey would piss off.) And even if you only use maps that don't indicate political boundaries, there are still disputes over the names of certain international geographical features (such as whether the body of water separating Iran from Saudi Arabia is "the Persian Gulf" or "the Arabian Gulf"). All the free-software map stuff I've seen uses openstreetmap.org, meaning (a) we probably wouldn't actually be *shipping* maps, just providing the ability to cause them to be downloaded (which may or may not matter to us), and (b) we might be able to say "OpenStreetMap is aware of these issues and is trying to work through them in a reasonable manner (http://wiki.openstreetmap.org/wiki/Disputes) so we defer to them" (though we still might feel the need to warn users that the software might, under some circumstances, download maps that offend them). -- Dan From notting at redhat.com Tue May 19 17:42:32 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 19 May 2009 13:42:32 -0400 Subject: Package Maintainers Flags policy In-Reply-To: References: <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <4A12DAE8.8040903@gmail.com> <20090519163232.GA3247@nostromo.devel.redhat.com> Message-ID: <20090519174232.GA3984@nostromo.devel.redhat.com> Seth Vidal (skvidal at fedoraproject.org) said: >>> If we end up needing yum plugin of some kind to handle this can I call >>> it the free-randomstan plugin? >> >> We don't have a yum-patents plugin, or Provides(patents). Why are we >> going to such lengths here? > > How would we have a Provides(patents) on pkgs in fedora? If the pkgs had > patent issues we couldn't ship them at all, could we? What I'm saying is that in the amount of tossing around of ideas in this thread, and the amount of work that would be required to sanely implement this (and explain it in a way that makes sense to the users) we could have fixed 99.9% of the packages to not ship flags about 5 times over. Bill From skvidal at fedoraproject.org Tue May 19 17:44:37 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 19 May 2009 13:44:37 -0400 (EDT) Subject: Package Maintainers Flags policy In-Reply-To: <2d319b780905191027v2ef80a22t4b8023eceae84664@mail.gmail.com> References: <4A11984F.2060605@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <1242750220.3223.79.camel@localhost.localdomain> <4A12E278.9000901@gmail.com> <2d319b780905191027v2ef80a22t4b8023eceae84664@mail.gmail.com> Message-ID: On Tue, 19 May 2009, Mathieu Bridon (bochecha) wrote: >> I'd like to see a show of hands of people who are surprised. > > Actually, I am totally amazed that such a thing as a flag in a > software can cause so many troubles. > > Call me naive, maybe I live in a parallel world populated only with > Care Bears, but I really would never have imagined that people could > boycott a product because it includes a reference to a place in the > world that they do not recognized. > > So, here is me raising my hand. > > Anyway, I don't want to add anything more to the flames, I really do > not care about this issue and I'll be happy to apply the policy > (actually, I'm not sure I already saw a flag in Fedora :) >From what I can gather from google you live in France. Here is a list of the current French territorial disputes: Madagascar claims the French territories of Bassas da India, Europa Island, Glorioso Islands, and Juan de Nova Island; Comoros claims Mayotte; Mauritius claims Tromelin Island; territorial dispute between Suriname and the French overseas department of French Guiana; France asserts a territorial claim in Antarctica (Adelie Land); France and Vanuatu claim Matthew and Hunter Islands, east of New Caledonia hope that helps. -sv From skvidal at fedoraproject.org Tue May 19 17:46:01 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 19 May 2009 13:46:01 -0400 (EDT) Subject: Package Maintainers Flags policy In-Reply-To: <20090519174232.GA3984@nostromo.devel.redhat.com> References: <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <4A12DAE8.8040903@gmail.com> <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> Message-ID: On Tue, 19 May 2009, Bill Nottingham wrote: > Seth Vidal (skvidal at fedoraproject.org) said: >>>> If we end up needing yum plugin of some kind to handle this can I call >>>> it the free-randomstan plugin? >>> >>> We don't have a yum-patents plugin, or Provides(patents). Why are we >>> going to such lengths here? >> >> How would we have a Provides(patents) on pkgs in fedora? If the pkgs had >> patent issues we couldn't ship them at all, could we? > > What I'm saying is that in the amount of tossing around of ideas in this > thread, and the amount of work that would be required to sanely implement > this (and explain it in a way that makes sense to the users) we could > have fixed 99.9% of the packages to not ship flags about 5 times over. > I thought this thread was about explaining it in a way that our developers understand it. I'm sorry you feel your time has been wasted. -sv From notting at redhat.com Tue May 19 18:14:55 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 19 May 2009 14:14:55 -0400 Subject: Package Maintainers Flags policy In-Reply-To: References: <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <4A12DAE8.8040903@gmail.com> <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> Message-ID: <20090519181454.GA4397@nostromo.devel.redhat.com> Seth Vidal (skvidal at fedoraproject.org) said: >>>>> If we end up needing yum plugin of some kind to handle this can I call >>>>> it the free-randomstan plugin? >>>> >>>> We don't have a yum-patents plugin, or Provides(patents). Why are we >>>> going to such lengths here? >>> >>> How would we have a Provides(patents) on pkgs in fedora? If the pkgs had >>> patent issues we couldn't ship them at all, could we? >> >> What I'm saying is that in the amount of tossing around of ideas in this >> thread, and the amount of work that would be required to sanely implement >> this (and explain it in a way that makes sense to the users) we could >> have fixed 99.9% of the packages to not ship flags about 5 times over. >> > > I thought this thread was about explaining it in a way that our > developers understand it. Which 'it' here are you referring to? > I'm sorry you feel your time has been wasted. I just feel that once you've gotten to the point where we have to define packaging policies around magic provides, rel-eng checks to make sure that packages with magic provides don't end up in specific places, and then we may need special plugins to handle them... we've gone beyond reasonable solutions to the problem, and solutions that probably outweigh in effort and complexity the amount of work required to package things to just not use flags. Bill From roland at redhat.com Tue May 19 18:31:55 2009 From: roland at redhat.com (Roland McGrath) Date: Tue, 19 May 2009 11:31:55 -0700 (PDT) Subject: Problem with build-id and cycling the free pascal compiler In-Reply-To: Joost van der Sluis's message of Tuesday, 19 May 2009 15:13:55 +0200 <1242738835.30840.7.camel@wsjoost> References: <1240667628.31161.14.camel@wsjoost> <20090426204156.7431DFC3B6@magilla.sf.frob.com> <1242738835.30840.7.camel@wsjoost> Message-ID: <20090519183155.7137EFC3E5@magilla.sf.frob.com> > Offcourse. I've placed a .tgz file here: > http://menora.cnoc.nl/extern/DifferentBuildIDsExample.tgz > > It contains the source of a hello-world application. (hello.pp) And two > binaries (hello and hello1) which differ but were build from the same > source. > > There's also a link-script (link.res) and a shell-script (ppas.sh) which > you can use to link the executables yourself. The necessary object files > are also there. The 'hello' and 'hello1' binaries there are stripped. Your 'link.res' script passes -s to ld, which explains why they are stripped. But this defeats many purposes and hides the information I need to diagnose your problem. Surely your actual package builds don't link with -s, I hope. (If they do, your debuginfo rpms wind up useless.) Thanks, Roland From denis at poolshark.org Tue May 19 18:49:09 2009 From: denis at poolshark.org (Denis Leroy) Date: Tue, 19 May 2009 20:49:09 +0200 Subject: Package Maintainers Flags policy In-Reply-To: References: <4A11984F.2060605@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <1242750220.3223.79.camel@localhost.localdomain> <4A12E278.9000901@gmail.com> <2d319b780905191027v2ef80a22t4b8023eceae84664@mail.gmail.com> Message-ID: <4A12FF25.6070103@poolshark.org> On 05/19/2009 07:44 PM, Seth Vidal wrote: > Here is a list of the current French territorial disputes: > > Madagascar claims the French territories of Bassas da India, Europa > Island, Glorioso Islands, and Juan de Nova Island; Comoros claims > Mayotte; Mauritius claims Tromelin Island; territorial dispute between > Suriname and the French overseas department of French Guiana; France > asserts a territorial claim in Antarctica (Adelie Land); France and > Vanuatu claim Matthew and Hunter Islands, east of New Caledonia This is getting completely off topic. This has nothing to do about the legality of the Fedora distribution containing country flags pictures. From denis at poolshark.org Tue May 19 18:52:11 2009 From: denis at poolshark.org (Denis Leroy) Date: Tue, 19 May 2009 20:52:11 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <1242747691.2919.25.camel@macbook.infradead.org> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <29fee02b0905190526i593c1c97x840ba64d38455902@mail.gmail.com> <1242737529.30251.182.camel@macbook.infradead.org> <4A12B130.5040107@poolshark.org> <20090519132859.GA13698@srcf.ucam.org> <1242747691.2919.25.camel@macbook.infradead.org> Message-ID: <4A12FFDB.805@poolshark.org> On 05/19/2009 05:41 PM, David Woodhouse wrote: >> Please keep the conversation civil. > > That was civil enough. He disagrees strongly with the decision which > FESCo took, and presumably wants _all_ of us who voted for this policy > to resign, rather than just myself. He stated that desire quite > politely, and I think he's perfectly entitled to do so. > > As it happens, my seat and the seats of a few others who voted for this > policy are coming up for re-election soon anyway. So Denis gets his > wish :) Indeed :-) I'm left with the choice of either leaving Fedora or running for Fesco :-) Well we shall see, but it'll wait after F-11 release. From pertusus at free.fr Tue May 19 18:56:06 2009 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 19 May 2009 20:56:06 +0200 Subject: Package Maintainers Flags policy In-Reply-To: References: <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <1242750220.3223.79.camel@localhost.localdomain> <4A12E278.9000901@gmail.com> <2d319b780905191027v2ef80a22t4b8023eceae84664@mail.gmail.com> Message-ID: <20090519185606.GA4558@free.fr> On Tue, May 19, 2009 at 01:44:37PM -0400, Seth Vidal wrote: > > Here is a list of the current French territorial disputes: > > Madagascar claims the French territories of Bassas da India, Europa > Island, Glorioso Islands, and Juan de Nova Island; Comoros claims > Mayotte; Mauritius claims Tromelin Island; territorial dispute between > Suriname and the French overseas department of French Guiana; France > asserts a territorial claim in Antarctica (Adelie Land); This has been suspended, I believe. > France and > Vanuatu claim Matthew and Hunter Islands, east of New Caledonia That doesn't make the flags of those countries illegal in France (though there are other things that are censored in France, for example it could be possible for a medical software to be illegal in France). Maybe some crypto software in fedora is still illegal in France, at least it was clearly the case for openssh in redhat 5-6 years ago. Coping with every country laws, including countries where there is no free speech looks wrong to me (and most restrictions in the US looks already wrong to me, including patents and other stuff, like crypto regulations and certainly other I don't know about). I think that Fedora should only abide to US laws and the burden to make derivative works that are consistent with other country law should be on the shoulder of those who want to have a distro acceptable for their law. As an added benefit, that would also leave the possibility for those who want to resist those laws to do it easily. -- Pat From joost at cnoc.nl Tue May 19 18:59:49 2009 From: joost at cnoc.nl (Joost van der Sluis) Date: Tue, 19 May 2009 20:59:49 +0200 Subject: Problem with build-id and cycling the free pascal compiler In-Reply-To: <20090519183155.7137EFC3E5@magilla.sf.frob.com> References: <1240667628.31161.14.camel@wsjoost> <20090426204156.7431DFC3B6@magilla.sf.frob.com> <1242738835.30840.7.camel@wsjoost> <20090519183155.7137EFC3E5@magilla.sf.frob.com> Message-ID: <1242759589.10190.2.camel@wsjoost> Op dinsdag 19-05-2009 om 11:31 uur [tijdzone -0700], schreef Roland McGrath: > > Offcourse. I've placed a .tgz file here: > > http://menora.cnoc.nl/extern/DifferentBuildIDsExample.tgz > > > > It contains the source of a hello-world application. (hello.pp) And two > > binaries (hello and hello1) which differ but were build from the same > > source. > > > > There's also a link-script (link.res) and a shell-script (ppas.sh) which > > you can use to link the executables yourself. The necessary object files > > are also there. > > The 'hello' and 'hello1' binaries there are stripped. > Your 'link.res' script passes -s to ld, which explains why they are stripped. > But this defeats many purposes and hides the information I need to diagnose > your problem. Surely your actual package builds don't link with -s, I hope. > (If they do, your debuginfo rpms wind up useless.) I've placed a new file with the same name with unstripped-binaries. I just tried to make a simple example, but didn't realize that the compiled would add '-s' to the link-script when no debug-information is specified. (The script is generated by the compiler) Can you have another look? Joost. From skvidal at fedoraproject.org Tue May 19 19:01:59 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 19 May 2009 15:01:59 -0400 (EDT) Subject: Package Maintainers Flags policy In-Reply-To: <4A12FF25.6070103@poolshark.org> References: <4A11984F.2060605@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <1242750220.3223.79.camel@localhost.localdomain> <4A12E278.9000901@gmail.com> <2d319b780905191027v2ef80a22t4b8023eceae84664@mail.gmail.com> <4A12FF25.6070103@poolshark.org> Message-ID: On Tue, 19 May 2009, Denis Leroy wrote: > On 05/19/2009 07:44 PM, Seth Vidal wrote: >> Here is a list of the current French territorial disputes: >> >> Madagascar claims the French territories of Bassas da India, Europa >> Island, Glorioso Islands, and Juan de Nova Island; Comoros claims >> Mayotte; Mauritius claims Tromelin Island; territorial dispute between >> Suriname and the French overseas department of French Guiana; France >> asserts a territorial claim in Antarctica (Adelie Land); France and >> Vanuatu claim Matthew and Hunter Islands, east of New Caledonia > > This is getting completely off topic. This has nothing to do about the > legality of the Fedora distribution containing country flags pictures. > you're right - I intended to send that message off-list and I forgot to clip the list entry. mea culpa -sv From walters at verbum.org Tue May 19 19:07:31 2009 From: walters at verbum.org (Colin Walters) Date: Tue, 19 May 2009 15:07:31 -0400 Subject: Package Maintainers Flags policy In-Reply-To: <20090519181454.GA4397@nostromo.devel.redhat.com> References: <4A12B940.4050605@redhat.com> <20090519144722.GC32139@macmahon.me.uk> <4A12DAE8.8040903@gmail.com> <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> <20090519181454.GA4397@nostromo.devel.redhat.com> Message-ID: On Tue, May 19, 2009 at 2:14 PM, Bill Nottingham wrote: > > I just feel that once you've gotten to the point where we have to define > packaging policies around magic provides, rel-eng checks to make sure that > packages with magic provides don't end up in specific places, and then > we may need special plugins to handle them... we've gone beyond reasonable > solutions to the problem, and solutions that probably outweigh in effort > and complexity the amount of work required to package things to just not > use flags. Do we have any kind of (even approximate) list of affected packages? From nicolas.mailhot at laposte.net Tue May 19 19:24:37 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 19 May 2009 21:24:37 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <20090519185606.GA4558@free.fr> References: <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <1242750220.3223.79.camel@localhost.localdomain> <4A12E278.9000901@gmail.com> <2d319b780905191027v2ef80a22t4b8023eceae84664@mail.gmail.com> <20090519185606.GA4558@free.fr> Message-ID: <1242761077.4168.1.camel@arekh.okg> Le mardi 19 mai 2009 ? 20:56 +0200, Patrice Dumas a ?crit : > I think > that Fedora should only abide to US laws and the burden to make derivative > works that are consistent with other country law should be on the > shoulder of those who want to have a distro acceptable for their law. Why do you think the US is any more neutral in this matter than other countries ? -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From a.badger at gmail.com Tue May 19 19:27:35 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 19 May 2009 12:27:35 -0700 Subject: Package Maintainers Flags policy In-Reply-To: <20090519181454.GA4397@nostromo.devel.redhat.com> References: <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <4A12DAE8.8040903@gmail.com> <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> <20090519181454.GA4397@nostromo.devel.redhat.com> Message-ID: <4A130827.6040103@gmail.com> On 05/19/2009 11:14 AM, Bill Nottingham wrote: > Seth Vidal (skvidal at fedoraproject.org) said: >>>>>> If we end up needing yum plugin of some kind to handle this can I call >>>>>> it the free-randomstan plugin? >>>>> We don't have a yum-patents plugin, or Provides(patents). Why are we >>>>> going to such lengths here? >>>> How would we have a Provides(patents) on pkgs in fedora? If the pkgs had >>>> patent issues we couldn't ship them at all, could we? >>> What I'm saying is that in the amount of tossing around of ideas in this >>> thread, and the amount of work that would be required to sanely implement >>> this (and explain it in a way that makes sense to the users) we could >>> have fixed 99.9% of the packages to not ship flags about 5 times over. >>> >> I thought this thread was about explaining it in a way that our >> developers understand it. > > Which 'it' here are you referring to? > >> I'm sorry you feel your time has been wasted. > > I just feel that once you've gotten to the point where we have to define > packaging policies around magic provides, rel-eng checks to make sure that > packages with magic provides don't end up in specific places, and then > we may need special plugins to handle them... we've gone beyond reasonable > solutions to the problem, and solutions that probably outweigh in effort > and complexity the amount of work required to package things to just not > use flags. > As far as I can see, these are the differences from the current policy: 1) magic provides vs magic package names 2) rel-eng checks that the magic provides aren't on the spin vs rel-eng checks that -flags subpackages aren't required by anything else unless it's in a whitelist of exceptions granted by FESCo (and rel-eng has to check comps to make sure there are no -flags packages listed explicitly) 3) Adding a provides to packages that have flags vs porting packages to make flags optional. 4) Porting packages in the main spin to make flags an optional subpackage -- same for each. 5) possibly a yum plugin to handle the provides vs nobody-thought-far-enough-ahead-to-see-that-we'd-need-a-yum-plugin-to-cover-that-case-with-naming-as-a-solution-as-well. End result of both policies: Fedora Everything is not distributable in flag banning countries. Specific Fedora spins may be. Without a yum plugin, Fedora users have access to banned flag content if they want it. With a yum plugin, this can be prevented... unless the user disables the plugin. With provides, releng's script has to be more complex in #2. With the current policy, #3 is more work for every packager that has a package containing flags (including maintainance to forward port our patches). With the current policy we end up with lots of exceptions. For instance, freeciv should fall under: "technically or substantively essential to the package". The policy doesn't require marking these packages as containing flags so it needs to be updated in some manner if we want releng to be able to detect flag containing packages. -Toshio From pertusus at free.fr Tue May 19 19:28:07 2009 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 19 May 2009 21:28:07 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <1242761077.4168.1.camel@arekh.okg> References: <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <1242750220.3223.79.camel@localhost.localdomain> <4A12E278.9000901@gmail.com> <2d319b780905191027v2ef80a22t4b8023eceae84664@mail.gmail.com> <20090519185606.GA4558@free.fr> <1242761077.4168.1.camel@arekh.okg> Message-ID: <20090519192807.GB4558@free.fr> On Tue, May 19, 2009 at 09:24:37PM +0200, Nicolas Mailhot wrote: > Le mardi 19 mai 2009 ? 20:56 +0200, Patrice Dumas a ?crit : > > I think > > that Fedora should only abide to US laws and the burden to make derivative > > works that are consistent with other country law should be on the > > shoulder of those who want to have a distro acceptable for their law. > > Why do you think the US is any more neutral in this matter than other > countries ? I don't think so, and I said above that there are things I dislike in US laws, but Redhat and fedora are US entities, so it somehow determines the minimal set of laws fedora shouldn't break. -- Pat From awilliam at redhat.com Tue May 19 19:29:48 2009 From: awilliam at redhat.com (Adam Williamson) Date: Tue, 19 May 2009 12:29:48 -0700 Subject: Keyboard mapping characters with both shift keys In-Reply-To: <20d6441a0905190842i33027fb9mbbb548c38169039e@mail.gmail.com> References: <4A1132C9.4040601@redhat.com> <9497e9990905180626w37f74f4qecb2a638b2caf361@mail.gmail.com> <1242661593.3223.36.camel@localhost.localdomain> <20d6441a0905190842i33027fb9mbbb548c38169039e@mail.gmail.com> Message-ID: <1242761388.2923.994.camel@adam.local.net> On Tue, 2009-05-19 at 10:42 -0500, Jud Craft wrote: > Logitech wave multimedia keyboard here, L+R shift + t doesn't work. > L+Rs + r does work. > > Maybe it has something to do with the wiring of the keyboard (even on > nice keyboards), that only certain groups of keys can send so many > signals at a certain time. This is essentially it. Here's some references... http://www.dribin.org/dave/keyboard/html/index.html http://www.extremetech.com/article2/0,2845,2301151,00.asp this is usually a case of 'keyboard blocking', where certain combinations of three keys pressed together are prevented from doing anything in order to prevent 'keyboard ghosting' from happening. Some high-end keyboards use the diode solution suggested by the first article to prevent keyboard ghosting from being a problem, and hence don't implement keyboard blocking, so all combinations of three keys should work on these. Some keyboards also use a buffering system - Steelseries keyboards claim to allow you to press every key on the keyboard simultaneously... http://www.amazon.com/SteelSeries-64022-7G-Keyboard-Black/dp/B000W6IY6O -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From a.badger at gmail.com Tue May 19 19:34:03 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 19 May 2009 12:34:03 -0700 Subject: Package Maintainers Flags policy In-Reply-To: <1242761077.4168.1.camel@arekh.okg> References: <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <1242750220.3223.79.camel@localhost.localdomain> <4A12E278.9000901@gmail.com> <2d319b780905191027v2ef80a22t4b8023eceae84664@mail.gmail.com> <20090519185606.GA4558@free.fr> <1242761077.4168.1.camel@arekh.okg> Message-ID: <4A1309AB.4000608@gmail.com> On 05/19/2009 12:24 PM, Nicolas Mailhot wrote: > Le mardi 19 mai 2009 ? 20:56 +0200, Patrice Dumas a ?crit : >> I think >> that Fedora should only abide to US laws and the burden to make derivative >> works that are consistent with other country law should be on the >> shoulder of those who want to have a distro acceptable for their law. > > Why do you think the US is any more neutral in this matter than other > countries ? > > Because of spot's response on https://fedorahosted.org/fesco/ticket/110 :: jstanley: 1) What is the legal issue (if there is one)? [...] spot: So, to your questions: 1. There is no specific legal issue at this time. -Toshio From belegdol at gmail.com Tue May 19 19:44:55 2009 From: belegdol at gmail.com (Julian Sikorski) Date: Tue, 19 May 2009 21:44:55 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <20090519192807.GB4558@free.fr> References: <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <1242750220.3223.79.camel@localhost.localdomain> <4A12E278.9000901@gmail.com> <2d319b780905191027v2ef80a22t4b8023eceae84664@mail.gmail.com> <20090519185606.GA4558@free.fr> <1242761077.4168.1.camel@arekh.okg> <20090519192807.GB4558@free.fr> Message-ID: Patrice Dumas pisze: > On Tue, May 19, 2009 at 09:24:37PM +0200, Nicolas Mailhot wrote: >> Le mardi 19 mai 2009 ? 20:56 +0200, Patrice Dumas a ?crit : >>> I think >>> that Fedora should only abide to US laws and the burden to make derivative >>> works that are consistent with other country law should be on the >>> shoulder of those who want to have a distro acceptable for their law. >> Why do you think the US is any more neutral in this matter than other >> countries ? > > I don't think so, and I said above that there are things I dislike in > US laws, but Redhat and fedora are US entities, so it somehow > determines the minimal set of laws fedora shouldn't break. > > -- > Pat > That's the most sane argument I've seen in this discussion. Fedora is a US-based distribution, so let's stick to what's legal to distribute in the States. If we try to remove every bit which is illegal in one place or another, sooner or later we will end up with a product to crippled to be useful (as if lack of mp3/dvd playback ability wasn't enough). Julian P.S. I tried to stay out of this flamewar, but the overwhelming political correctness needs to be stopped. There's a saying ?don't be more saint than the pope? where I come from. From jkeating at redhat.com Tue May 19 19:55:36 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 19 May 2009 12:55:36 -0700 Subject: Package Maintainers Flags policy In-Reply-To: <4A130827.6040103@gmail.com> References: <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <4A12DAE8.8040903@gmail.com> <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> <20090519181454.GA4397@nostromo.devel.redhat.com> <4A130827.6040103@gmail.com> Message-ID: <1242762936.3029.6.camel@localhost.localdomain> On Tue, 2009-05-19 at 12:27 -0700, Toshio Kuratomi wrote: > As far as I can see, these are the differences from the current > policy: There is an easier option 3, which is no flags in Fedora period, regardless of what spin. Far easier to implement. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Tue May 19 19:57:06 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 19 May 2009 15:57:06 -0400 (EDT) Subject: Package Maintainers Flags policy In-Reply-To: <1242762936.3029.6.camel@localhost.localdomain> References: <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <4A12DAE8.8040903@gmail.com> <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> <20090519181454.GA4397@nostromo.devel.redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> Message-ID: On Tue, 19 May 2009, Jesse Keating wrote: > On Tue, 2009-05-19 at 12:27 -0700, Toshio Kuratomi wrote: >> As far as I can see, these are the differences from the current >> policy: > > There is an easier option 3, which is no flags in Fedora period, > regardless of what spin. Far easier to implement. > I like this one. -sv From pertusus at free.fr Tue May 19 19:58:38 2009 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 19 May 2009 21:58:38 +0200 Subject: In which country should Fedora be legal? Message-ID: <20090519195838.GC4558@free.fr> Hello, I think that the flag policy is the wrong way to look at a real issue. First, it tries to solve 2 issues 1. being legal in some countries 2. avoid pissing people I think that the second issue should be brought upstream and not solved at the Fedora level. As for the first, I think that it should be looked more broadly than on the flags issue. I think that instead of focussing on one issue that can be deemed illegal in some countries, the focus should be on countries that fedora should be legal in. Then there should be a legal counselling (like whath legal does for the US) such that all the relevant laws are taken care of. I think that coming with a list of countries we want to have fedora be legal in, and find people knowing enough the country law to setup the guidelines should be a mission for the board. As a side note, it is not neutral at all to remove all the flags from fedora, it favors countries where flags can be illegal. No problem not being neutral, but what country laws Fedor should abide to should, in my opinion be explicit. I think that the US is mandatory, because RedHat and Fedora are US entities, but the remaining is open. The flags issue seems to implicitly put China in the set, but I think that it would be better to have a Board decision here. -- Pat From belegdol at gmail.com Tue May 19 20:11:35 2009 From: belegdol at gmail.com (Julian Sikorski) Date: Tue, 19 May 2009 22:11:35 +0200 Subject: Package Maintainers Flags policy In-Reply-To: References: <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <4A12DAE8.8040903@gmail.com> <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> <20090519181454.GA4397@nostromo.devel.redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> Message-ID: Seth Vidal pisze: > > > On Tue, 19 May 2009, Jesse Keating wrote: > >> On Tue, 2009-05-19 at 12:27 -0700, Toshio Kuratomi wrote: >>> As far as I can see, these are the differences from the current >>> policy: >> >> There is an easier option 3, which is no flags in Fedora period, >> regardless of what spin. Far easier to implement. >> > > I like this one. > > -sv > This means that political correctness madness wins :( Julian From ewan at macmahon.me.uk Tue May 19 20:22:29 2009 From: ewan at macmahon.me.uk (Ewan Mac Mahon) Date: Tue, 19 May 2009 21:22:29 +0100 Subject: Package Maintainers Flags policy In-Reply-To: <1242762936.3029.6.camel@localhost.localdomain> References: <20090519144722.GC32139@macmahon.me.uk> <4A12DAE8.8040903@gmail.com> <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> <20090519181454.GA4397@nostromo.devel.redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> Message-ID: <20090519202228.GE32139@macmahon.me.uk> On Tue, May 19, 2009 at 12:55:36PM -0700, Jesse Keating wrote: > On Tue, 2009-05-19 at 12:27 -0700, Toshio Kuratomi wrote: > > As far as I can see, these are the differences from the current > > policy: > > There is an easier option 3, which is no flags in Fedora period, > regardless of what spin. Far easier to implement. > Or there's option 4, which is to not have a 'no flags' policy in Fedora. It's even easier to implement, requires no package changes, and no carrying of Fedora specific patches for ever more, and no loss of perfectly good software from the distribution. This sort of decision is always going to be a balance; on the one hand there are clearly real costs to Fedora in having a blanket ban on flags, and on the other we have (according to spot[1]) "no specific legal issue at this time". It seems to me that that balance comes down squarely on the side of leaving the flags alone. Ewan [1] https://fedorahosted.org/fesco/ticket/110 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Arnaud.Gomes at ircam.fr Tue May 19 20:23:50 2009 From: Arnaud.Gomes at ircam.fr (Arnaud Gomes-do-Vale) Date: Tue, 19 May 2009 22:23:50 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <1242762936.3029.6.camel@localhost.localdomain> (Jesse Keating's message of "Tue\, 19 May 2009 12\:55\:36 -0700") References: <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <4A12DAE8.8040903@gmail.com> <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> <20090519181454.GA4397@nostromo.devel.redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> Message-ID: Jesse Keating writes: > There is an easier option 3, which is no flags in Fedora period, > regardless of what spin. Far easier to implement. Am I the only one to think yellow is a particularly offensive color? Please remove it from Fedora! -- Arnaud From opensource at till.name Tue May 19 20:26:16 2009 From: opensource at till.name (Till Maas) Date: Tue, 19 May 2009 22:26:16 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <1242762936.3029.6.camel@localhost.localdomain> References: <4A12B940.4050605@redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> Message-ID: <200905192226.21739.opensource@till.name> On Di Mai 19 2009, Jesse Keating wrote: > On Tue, 2009-05-19 at 12:27 -0700, Toshio Kuratomi wrote: > > As far as I can see, these are the differences from the current > > policy: > > There is an easier option 3, which is no flags in Fedora period, > regardless of what spin. Far easier to implement. This is not easier for package maintainers who want to maintain a package in Fedora that contains flags, because additional work has to be done by the package maintainer. Adding some flag to the spec that indicates that the package contains political flags is a log easier. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mike at cchtml.com Tue May 19 20:26:34 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Tue, 19 May 2009 15:26:34 -0500 Subject: In which country should Fedora be legal? In-Reply-To: <20090519195838.GC4558@free.fr> References: <20090519195838.GC4558@free.fr> Message-ID: <4A1315FA.80408@cchtml.com> -------- Original Message -------- Subject: In which country should Fedora be legal? From: Patrice Dumas To: Development discussions related to Fedora Date: 05/19/2009 02:58 PM > Hello, > > I think that the flag policy is the wrong way to look at a real issue. > First, it tries to solve 2 issues > 1. being legal in some countries > 2. avoid pissing people > > I think that the second issue should be brought upstream and not solved > at the Fedora level. > I find every package in Fedora offensive, especially bc. 1 + 1 = 3 for crying out loud. Does it take a FESCo action to get this racist answer changed? My country of Whogivesadamn will be suing Red Hat and the FESCo board members if no action is taken. From awilliam at redhat.com Tue May 19 20:29:05 2009 From: awilliam at redhat.com (Adam Williamson) Date: Tue, 19 May 2009 13:29:05 -0700 Subject: Package Maintainers Flags policy In-Reply-To: <20090518090953.5698908a@ohm.scrye.com> References: <20090518090953.5698908a@ohm.scrye.com> Message-ID: <1242764945.4055.2.camel@adam.local.net> On Mon, 2009-05-18 at 09:09 -0600, Kevin Fenzi wrote: > In FESCo's 2009-03-28 meeting a policy on Flag usage for packages in > Fedora was approved. > > Due to an oversight, this policy was not announced here. ;( > > Please see: > > https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy > > and direct any comments to FESCo in a ticket or via the devel list. I can see both sides of the argument that has proceeded from this policy, but as a data point: if my personal inclinations are any indication, I would say this policy will likely have a freezing effect on contributions to Fedora if fully adopted. I do intend to get involved in packaging a few things for Fedora in future, but I certainly don't intend to go to the trouble of carrying patches to remove flags for eternity, so I would just not consider packaging any software which included proscribed images (and would immediately orphan any package I maintained if any proscribed images were added to it, or if someone pointed out that it had some that I'd missed). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From notting at redhat.com Tue May 19 20:33:06 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 19 May 2009 16:33:06 -0400 Subject: In which country should Fedora be legal? In-Reply-To: <20090519195838.GC4558@free.fr> References: <20090519195838.GC4558@free.fr> Message-ID: <20090519203305.GA7385@nostromo.devel.redhat.com> Patrice Dumas (pertusus at free.fr) said: > I think that the flag policy is the wrong way to look at a real issue. > First, it tries to solve 2 issues > 1. being legal in some countries > 2. avoid pissing people > > I think that the second issue should be brought upstream and not solved > at the Fedora level. Too late. We already remove content from various packages where necessary, as stated earlier in the thread. > As for the first, I think that it should be looked more broadly than > on the flags issue. I think that instead of focussing on one issue that > can be deemed illegal in some countries, the focus should be on countries > that fedora should be legal in. Then there should be a legal counselling > (like whath legal does for the US) such that all the relevant laws are > taken care of. If you're seriously suggesting we set up legal counsel in all countries before taking any action, that's not going to happen. Honestly, that sounds like intentionally setting the bar ridiculously high just for the purpopse of making sure no one could possibly do anything you might disagree with. > As a side note, it is not neutral at all to remove all the flags from > fedora, it favors countries where flags can be illegal. Given that I'm fairly sure there are zero countries on the planet where flags *cannot* be made illegal by some act of the populace or government, that's a specious argument. Bill From roland at redhat.com Tue May 19 20:34:27 2009 From: roland at redhat.com (Roland McGrath) Date: Tue, 19 May 2009 13:34:27 -0700 (PDT) Subject: Problem with build-id and cycling the free pascal compiler In-Reply-To: Joost van der Sluis's message of Tuesday, 19 May 2009 20:59:49 +0200 <1242759589.10190.2.camel@wsjoost> References: <1240667628.31161.14.camel@wsjoost> <20090426204156.7431DFC3B6@magilla.sf.frob.com> <1242738835.30840.7.camel@wsjoost> <20090519183155.7137EFC3E5@magilla.sf.frob.com> <1242759589.10190.2.camel@wsjoost> Message-ID: <20090519203427.2A90EFC38D@magilla.sf.frob.com> > I've placed a new file with the same name with unstripped-binaries. I > just tried to make a simple example, but didn't realize that the > compiled would add '-s' to the link-script when no debug-information is > specified. (The script is generated by the compiler) Btw, note that "--build-id=md5" is not what you want to be using. What gcc passes is just "--build-id", which defaults to "--build-id=sha1". fpc should use plain "--build-id" too. The fact that the input files don't contain any debug info rules out the kinds of problems I was expecting it would be. This just looks like a new ld bug (a regression since F10). https://bugzilla.redhat.com/show_bug.cgi?id=501582 Thanks, Roland From opensource at till.name Tue May 19 20:35:41 2009 From: opensource at till.name (Till Maas) Date: Tue, 19 May 2009 22:35:41 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <4A12DAE8.8040903@gmail.com> References: <4A11984F.2060605@poolshark.org> <20090519144722.GC32139@macmahon.me.uk> <4A12DAE8.8040903@gmail.com> Message-ID: <200905192235.42895.opensource@till.name> On Di Mai 19 2009, Toshio Kuratomi wrote: > New Proposal: > [current definition of flags remains] > > * Packages that include flags must show that they do this by having a > virtual Provides: Politics(flags). With Conflicts:, this seems to be a lot easier to implement. Just add a pseudo package named "no-flags" to the distribution and add a "Conflicts: no-flags" to any package that contains flags. Then install no-flags by default and every flag-hater is happy and others can just remove the package. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From notting at redhat.com Tue May 19 20:37:22 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 19 May 2009 16:37:22 -0400 Subject: Package Maintainers Flags policy In-Reply-To: <20090519202228.GE32139@macmahon.me.uk> References: <4A12DAE8.8040903@gmail.com> <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> <20090519181454.GA4397@nostromo.devel.redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <20090519202228.GE32139@macmahon.me.uk> Message-ID: <20090519203722.GB7385@nostromo.devel.redhat.com> Ewan Mac Mahon (ewan at macmahon.me.uk) said: > This sort of decision is always going to be a balance; on the one hand > there are clearly real costs to Fedora in having a blanket ban on flags, > and on the other we have (according to spot[1]) "no specific legal issue > at this time". They specifically stated that it may/will prevent Fedora from being available or acceptable in some countries. That's not insignificant. Bill From bochecha at fedoraproject.org Tue May 19 20:37:58 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Tue, 19 May 2009 22:37:58 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <200905192226.21739.opensource@till.name> References: <4A12B940.4050605@redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <200905192226.21739.opensource@till.name> Message-ID: <2d319b780905191337v7a05a2c8q77c9d007108b545b@mail.gmail.com> >> There is an easier option 3, which is no flags in Fedora period, >> regardless of what spin. ?Far easier to implement. > > This is not easier for package maintainers who want to maintain a package in > Fedora that contains flags, because additional work has to be done by the > package maintainer. Adding some flag to the spec that indicates that the > package contains political flags is a log easier. Or a lot of packages will move from Fedora to RPMFusion-Free ? Patents encombered packages are forbidden in Fedora, even if the software is free, so we put them in RPMFusion. Why not with flags ? ---------- Mathieu Bridon (bochecha) From opensource at till.name Tue May 19 20:42:07 2009 From: opensource at till.name (Till Maas) Date: Tue, 19 May 2009 22:42:07 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <4A12E0C1.2000409@fi.muni.cz> References: <20090518090953.5698908a@ohm.scrye.com> <200905182350.41222.opensource@till.name> <4A12E0C1.2000409@fi.muni.cz> Message-ID: <200905192242.08843.opensource@till.name> On Di Mai 19 2009, Milos Jakubicek wrote: > 1) What should be the page name? Political Flags Guideline maybe. > 2) Where should it be moved to and from what pages linked so that people > do not miss it? It should be included in the Review Guidelines (a SHOULD check item) and linked in the Packaging Guidelines. Btw. also some flag removal SIG would be nice, consisting of people who will create and maintain necessary patches, if there are any needed. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From opensource at till.name Tue May 19 20:51:11 2009 From: opensource at till.name (Till Maas) Date: Tue, 19 May 2009 22:51:11 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <20090519203722.GB7385@nostromo.devel.redhat.com> References: <4A12DAE8.8040903@gmail.com> <20090519202228.GE32139@macmahon.me.uk> <20090519203722.GB7385@nostromo.devel.redhat.com> Message-ID: <200905192251.12387.opensource@till.name> On Di Mai 19 2009, Bill Nottingham wrote: > Ewan Mac Mahon (ewan at macmahon.me.uk) said: > > This sort of decision is always going to be a balance; on the one hand > > there are clearly real costs to Fedora in having a blanket ban on flags, > > and on the other we have (according to spot[1]) "no specific legal issue > > at this time". > > They specifically stated that it may/will prevent Fedora from being > available or acceptable in some countries. That's not insignificant. If there really are that much of people who will contribute to Fedora if they can remove flags they dislike from Fedora, why don't they do the work required for this, i.e. writing patches, adding support for this to rpm and yum, ...? But I also doubt that people who would not use Fedora because some included software uses a flag they hate are people one can work in a FOSS-oriented or cooperative way with. So maybe this is also the reason for this. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From martin.marques at gmail.com Tue May 19 20:56:01 2009 From: martin.marques at gmail.com (=?UTF-8?B?TWFydMOtbiBNYXJxdcOpcw==?=) Date: Tue, 19 May 2009 17:56:01 -0300 Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> Message-ID: 2009/5/19 Seth Vidal : > > On Tue, 19 May 2009, Mathieu Bridon (bochecha) wrote: > >> >> Anyway, sticking to the official internation standard list of >> countries maintained by UN (if such a list exists) seems much more >> neutral to me. We don't decide anything on countries, we use the >> decision of an official organization empowered to make such a >> decision. > > Afaict there is no such list. I'd be happy to be wrong about this, though. Does this one suit you: http://www.un.org/en/members/index.shtml -- Mart?n Marqu?s select 'martin.marques' || '@' || 'gmail.com' DBA, Programador, Administrador From belegdol at gmail.com Tue May 19 20:57:09 2009 From: belegdol at gmail.com (Julian Sikorski) Date: Tue, 19 May 2009 22:57:09 +0200 Subject: Package Maintainers Flags policy In-Reply-To: References: <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <4A12DAE8.8040903@gmail.com> <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> <20090519181454.GA4397@nostromo.devel.redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> Message-ID: Arnaud Gomes-do-Vale pisze: > Jesse Keating writes: > >> There is an easier option 3, which is no flags in Fedora period, >> regardless of what spin. Far easier to implement. > > Am I the only one to think yellow is a particularly offensive color? > Please remove it from Fedora! > Or number 4. I heard it symbolises death in some Asian cultures. Julian From joost at cnoc.nl Tue May 19 20:57:26 2009 From: joost at cnoc.nl (Joost van der Sluis) Date: Tue, 19 May 2009 22:57:26 +0200 Subject: Problem with build-id and cycling the free pascal compiler In-Reply-To: <20090519203427.2A90EFC38D@magilla.sf.frob.com> References: <1240667628.31161.14.camel@wsjoost> <20090426204156.7431DFC3B6@magilla.sf.frob.com> <1242738835.30840.7.camel@wsjoost> <20090519183155.7137EFC3E5@magilla.sf.frob.com> <1242759589.10190.2.camel@wsjoost> <20090519203427.2A90EFC38D@magilla.sf.frob.com> Message-ID: <1242766646.10190.6.camel@wsjoost> Op dinsdag 19-05-2009 om 13:34 uur [tijdzone -0700], schreef Roland McGrath: > > I've placed a new file with the same name with unstripped-binaries. I > > just tried to make a simple example, but didn't realize that the > > compiled would add '-s' to the link-script when no debug-information is > > specified. (The script is generated by the compiler) > > Btw, note that "--build-id=md5" is not what you want to be using. > What gcc passes is just "--build-id", which defaults to "--build-id=sha1". > fpc should use plain "--build-id" too. It does. I was just testing different types. > The fact that the input files don't contain any debug info rules out the > kinds of problems I was expecting it would be. This just looks like a new > ld bug (a regression since F10). > > https://bugzilla.redhat.com/show_bug.cgi?id=501582 Thanks for the help. I hope that someone can fix this. Joost From skvidal at fedoraproject.org Tue May 19 20:56:47 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 19 May 2009 16:56:47 -0400 (EDT) Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> Message-ID: On Tue, 19 May 2009, Mart?n Marqu?s wrote: > 2009/5/19 Seth Vidal : >> >> On Tue, 19 May 2009, Mathieu Bridon (bochecha) wrote: >> >>> >>> Anyway, sticking to the official internation standard list of >>> countries maintained by UN (if such a list exists) seems much more >>> neutral to me. We don't decide anything on countries, we use the >>> decision of an official organization empowered to make such a >>> decision. >> >> Afaict there is no such list. I'd be happy to be wrong about this, though. > > Does this one suit you: > > http://www.un.org/en/members/index.shtml > It might suit me - but it does not suit folks from Tibet or Taiwan. -sv From oget.fedora at gmail.com Tue May 19 20:59:11 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Tue, 19 May 2009 16:59:11 -0400 Subject: Package Maintainers Flags policy In-Reply-To: <20090518090953.5698908a@ohm.scrye.com> References: <20090518090953.5698908a@ohm.scrye.com> Message-ID: On Mon, May 18, 2009 at 11:09 AM, Kevin Fenzi wrote: > In FESCo's 2009-03-28 meeting a policy on Flag usage for packages in > Fedora was approved. > > Due to an oversight, this policy was not announced here. ;( > > Please see: > > https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy > > and direct any comments to FESCo in a ticket or via the devel list. > > Thanks, and sorry for the oversight. ;( > I have a question: Suppose there is an application that I want to package that contains the Brazilian flag only and no other flags. Afaik, the Brazilian flag is not illegal in any country in the world. Do I still have to make a subpackage for this one flag? Orcan From a.badger at gmail.com Tue May 19 20:59:50 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 19 May 2009 13:59:50 -0700 Subject: Package Maintainers Flags policy In-Reply-To: <1242762936.3029.6.camel@localhost.localdomain> References: <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <4A12DAE8.8040903@gmail.com> <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> <20090519181454.GA4397@nostromo.devel.redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> Message-ID: <4A131DC6.8000605@gmail.com> On 05/19/2009 12:55 PM, Jesse Keating wrote: > On Tue, 2009-05-19 at 12:27 -0700, Toshio Kuratomi wrote: >> As far as I can see, these are the differences from the current >> policy: > > There is an easier option 3, which is no flags in Fedora period, > regardless of what spin. Far easier to implement. > > That's easier for releng but just as hard for the packager. If you want something that's truly easier, then I propose, "flags are just another piece of data provided by upstream unless US law makes us care." -Toshio From a.badger at gmail.com Tue May 19 21:03:37 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 19 May 2009 14:03:37 -0700 Subject: Package Maintainers Flags policy In-Reply-To: <20090519203722.GB7385@nostromo.devel.redhat.com> References: <4A12DAE8.8040903@gmail.com> <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> <20090519181454.GA4397@nostromo.devel.redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <20090519202228.GE32139@macmahon.me.uk> <20090519203722.GB7385@nostromo.devel.redhat.com> Message-ID: <4A131EA9.2070001@gmail.com> On 05/19/2009 01:37 PM, Bill Nottingham wrote: > Ewan Mac Mahon (ewan at macmahon.me.uk) said: >> This sort of decision is always going to be a balance; on the one hand >> there are clearly real costs to Fedora in having a blanket ban on flags, >> and on the other we have (according to spot[1]) "no specific legal issue >> at this time". > > They specifically stated that it may/will prevent Fedora from being > available or acceptable in some countries. That's not insignificant. > The current proposal doesn't fix this. Flags are not banned by the current policy. Fedora can carry them: 1) in a separate flags subpackage as long as the main package does not require it. 2) if the flag is "technically or substantively essential to the package". -Toshio From jkeating at redhat.com Tue May 19 21:08:12 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 19 May 2009 14:08:12 -0700 Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> Message-ID: <1242767292.3029.8.camel@localhost.localdomain> On Tue, 2009-05-19 at 16:59 -0400, Orcan Ogetbil wrote: > > I have a question: > > Suppose there is an application that I want to package that contains > the Brazilian flag only and no other flags. Afaik, the Brazilian flag > is not illegal in any country in the world. Do I still have to make a > subpackage for this one flag? Yes you would. The only way to be "neutral" is to treat all flags the same. Any different treatment would amount to preferential treatment which is exactly what we're trying to avoid. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Tue May 19 21:08:47 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 19 May 2009 17:08:47 -0400 Subject: Package Maintainers Flags policy In-Reply-To: <200905192226.21739.opensource@till.name> References: <4A12B940.4050605@redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <200905192226.21739.opensource@till.name> Message-ID: <20090519210847.GC7385@nostromo.devel.redhat.com> Till Maas (opensource at till.name) said: > > There is an easier option 3, which is no flags in Fedora period, > > regardless of what spin. Far easier to implement. > > This is not easier for package maintainers who want to maintain a package in > Fedora that contains flags, because additional work has to be done by the > package maintainer. Adding some flag to the spec that indicates that the > package contains political flags is a log easier. We carry patches all the time, and if people can't manage to apply patches to their packages when necessary, then co-maintainers may be in order. And I'll be willing to pitch into help fix things that need fixing. (drifiting afield from this specific issue now, but it's related) And really... it's not about being 'easier for package maintainers'. I'm really tired of hearing that trope applied any time any sort of policy is applied or suggested, whether it be: - not having flags in packages - having actual update notes in bodhi (or even using bodhi at all) - not pushing new libraries to every release immediately - not cursing out your fellow developers The entire point of joining a community like Fedora is to work together towards some common goals. To suggest as prima facie evidence that anything that makes things not as easy for packagers is bad implies a view where the package maintainer feels that his needs, his preferred workflow, or his convenience somehow supercedes the needs of the project itself, or the needs of its users. Frankly, such an attitude is just wrong. It smacks of elitism and an overinflated sense of ego. In the context of the project, none of us is more important than the project itself. Sometimes you have to do *actual work* that can't be reduced to a three line perl script; it's part of pitching in towards something greater than yourself. And in the grand scheme of things, I'd suggest that a billion potential users and contributors far outweighs the convenience of a few packagers (really, this will affect only a small number of packagers, anyway.) If maintainers can't handle that, well, then maybe they need to find a comaintainer, or maybe Fedora isn't for them. Bill From a.badger at gmail.com Tue May 19 21:10:28 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 19 May 2009 14:10:28 -0700 Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> Message-ID: <4A132044.6080402@gmail.com> On 05/19/2009 01:59 PM, Orcan Ogetbil wrote: > > > I have a question: > > Suppose there is an application that I want to package that contains > the Brazilian flag only and no other flags. Afaik, the Brazilian flag > is not illegal in any country in the world. Do I still have to make a > subpackage for this one flag? > According to policy, yes. If this wasn't the case then the argument that this policy is neutral goes out the window as it is only applying to flags that are in dispute by some countries. -Toshio From martin.marques at gmail.com Tue May 19 21:10:53 2009 From: martin.marques at gmail.com (=?UTF-8?B?TWFydMOtbiBNYXJxdcOpcw==?=) Date: Tue, 19 May 2009 18:10:53 -0300 Subject: Package Maintainers Flags policy In-Reply-To: <4A12C063.2080907@redhat.com> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12C063.2080907@redhat.com> Message-ID: 2009/5/19 Andrew Haley : > > The UN does not decide what is an "officially recognized country". ?All > it can do is decide whether to admit a country as a member. ?This is > not the same as being a sovereign state, which in practice depends on > being recognized by other nations. Isn't that what "United Nations" is? A bunch of countries that try to work diplomatically problems. -- Mart?n Marqu?s select 'martin.marques' || '@' || 'gmail.com' DBA, Programador, Administrador From jkeating at redhat.com Tue May 19 21:17:49 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 19 May 2009 14:17:49 -0700 Subject: Package Maintainers Flags policy In-Reply-To: <4A131DC6.8000605@gmail.com> References: <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <4A12DAE8.8040903@gmail.com> <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> <20090519181454.GA4397@nostromo.devel.redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <4A131DC6.8000605@gmail.com> Message-ID: <1242767869.3029.13.camel@localhost.localdomain> On Tue, 2009-05-19 at 13:59 -0700, Toshio Kuratomi wrote: > That's easier for releng but just as hard for the packager. Yes, it is unfortunate that our package set got to the point where flags existed in some of the packages, and that the unwritten rule from RHL and Fedora Core didn't make it forward into Fedora, the no flags rule. We'd have to do some clean up, and potentially lose some software in the process. We have to decide if we want to trade some software (and likely some packagers) for the ability for our software to be distributed to rather large targets, such as China, and potentially gain contributors, not just packagers. > If you want something that's truly easier, then I propose, "flags are > just another piece of data provided by upstream unless US law makes us > care." There is another concern here. Red Hat Enterprise Linux (RHEL) will likely continue the "no flags" policy, which means that any software within Fedora that RHEL would like to ship, the packaging will have to fork, and patches will have to be created. This isn't Fedora's problem, but something for RHT to note when it is deciding what software to take and how much work will be necessary to make it RHEL worthy. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Tue May 19 21:23:33 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 19 May 2009 14:23:33 -0700 Subject: Package Maintainers Flags policy In-Reply-To: <20090519210847.GC7385@nostromo.devel.redhat.com> References: <4A12B940.4050605@redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <200905192226.21739.opensource@till.name> <20090519210847.GC7385@nostromo.devel.redhat.com> Message-ID: <4A132355.3070903@gmail.com> On 05/19/2009 02:08 PM, Bill Nottingham wrote: > Till Maas (opensource at till.name) said: >>> There is an easier option 3, which is no flags in Fedora period, >>> regardless of what spin. Far easier to implement. >> This is not easier for package maintainers who want to maintain a package in >> Fedora that contains flags, because additional work has to be done by the >> package maintainer. Adding some flag to the spec that indicates that the >> package contains political flags is a log easier. > > We carry patches all the time, and if people can't manage to apply patches > to their packages when necessary, then co-maintainers may be in order. > And I'll be willing to pitch into help fix things that need fixing. > > (drifiting afield from this specific issue now, but it's related) > > And really... it's not about being 'easier for package maintainers'. I'm > really tired of hearing that trope applied any time any sort of policy > is applied or suggested, whether it be: > > - not having flags in packages > - having actual update notes in bodhi (or even using bodhi at all) > - not pushing new libraries to every release immediately > - not cursing out your fellow developers > > The entire point of joining a community like Fedora is to work together > towards some common goals. > > To suggest as prima facie evidence that anything that makes things not > as easy for packagers is bad implies a view where the package maintainer > feels that his needs, his preferred workflow, or his convenience somehow > supercedes the needs of the project itself, or the needs of its users. > > Frankly, such an attitude is just wrong. It smacks of elitism and an > overinflated sense of ego. In the context of the project, none of us is more > important than the project itself. Sometimes you have to do *actual work* > that can't be reduced to a three line perl script; it's part of pitching in > towards something greater than yourself. And in the grand scheme of things, > I'd suggest that a billion potential users and contributors far outweighs > the convenience of a few packagers (really, this will affect only a > small number of packagers, anyway.) > I agree with this sentiment 100%. We're here to make better packages, not whine about how making better packages is hard. However, I'd point out that in this specifc case Jesse raised the "easier" argument and Till was just replying to that. -Toshio From ewan at macmahon.me.uk Tue May 19 21:29:09 2009 From: ewan at macmahon.me.uk (Ewan Mac Mahon) Date: Tue, 19 May 2009 22:29:09 +0100 Subject: Package Maintainers Flags policy In-Reply-To: <20090519203722.GB7385@nostromo.devel.redhat.com> References: <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> <20090519181454.GA4397@nostromo.devel.redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <20090519202228.GE32139@macmahon.me.uk> <20090519203722.GB7385@nostromo.devel.redhat.com> Message-ID: <20090519212909.GF32139@macmahon.me.uk> On Tue, May 19, 2009 at 04:37:22PM -0400, Bill Nottingham wrote: > Ewan Mac Mahon (ewan at macmahon.me.uk) said: > > This sort of decision is always going to be a balance; on the one hand > > there are clearly real costs to Fedora in having a blanket ban on flags, > > and on the other we have (according to spot[1]) "no specific legal issue > > at this time". > > They specifically stated that it may/will prevent Fedora from being > available or acceptable in some countries. That's not insignificant. > I'm not sure I see that in the fesco trac ticket, but even so, I don't think it necessarily follows from that that we should be stripping flags. There are two basic questions (I think): - Will stripping the flags make Fedora acceptable everywhere? We know that various governments doesn't get on with certain flags, but how do they feel about tor, gnupg, sword, or FreeCiv's text-based references to Tibet? While the flags may be unacceptable, it's not clear that they're the only thing that's unacceptable, and there's no advantage in stripping the flags if Fedora remains off-limits in these countries for other reasons. - Even if a no flags policy would suffice to make Fedora acceptable in certain countries, then is that benefit worth the costs in increases package maintanance overhead, and removal of software from Fedora, particularly given the relative ease of creating localised spins or derivatives. My guess is that simply removing flags isn't enough to make Fedora acceptable the world over, and my opinion is that the benefits it does bring are outweighed by the costs. Ewan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue May 19 21:29:23 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 19 May 2009 14:29:23 -0700 Subject: One week slip of Fedora 11 Release Message-ID: <1242768563.3029.17.camel@localhost.localdomain> In a meeting today between Release Engineering, QA, and various team leads, we decided to enact a 7 day slip of the Fedora 11 release date. The primary reason behind this slip is the state of our blocker bug: https://bugzilla.redhat.com/showdependencytree.cgi?id=F11Blocker&hide_resolved=1 We cannot begin Release Candidate phase until the blocker bugs are closed or at least in MODIFIED state. We are not there today, which would be our last day to enter RC phase and still have enough time to release on the 26th. We hope to enter RC phase in the next couple days, and hit our new target, June 2nd. Freeze breaks for critical bugs will still be accepted, however trivial bug fixes should be pushed as updates via bodhi. Thanks! -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From jkeating at redhat.com Tue May 19 21:36:05 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 19 May 2009 14:36:05 -0700 Subject: Package Maintainers Flags policy In-Reply-To: <4A132355.3070903@gmail.com> References: <4A12B940.4050605@redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <200905192226.21739.opensource@till.name> <20090519210847.GC7385@nostromo.devel.redhat.com> <4A132355.3070903@gmail.com> Message-ID: <1242768965.3029.20.camel@localhost.localdomain> On Tue, 2009-05-19 at 14:23 -0700, Toshio Kuratomi wrote: > I agree with this sentiment 100%. We're here to make better packages, > not whine about how making better packages is hard. However, I'd point > out that in this specifc case Jesse raised the "easier" argument and > Till was just replying to that. I think that my point was that it is an easier to understand policy. It may be more difficult to enact, but it is a far sight easier than trying to figure out what other packages might require your flags, and if any of those packages are on something called a "default spin", which can change it's contents at any time. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kevin.kofler at chello.at Tue May 19 21:43:00 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 19 May 2009 23:43:00 +0200 Subject: Package Maintainers Flags policy References: <20090518090953.5698908a@ohm.scrye.com> <1242667087.25634.1927.camel@cookie.hadess.net> Message-ID: Paul Black wrote: > Out of curiosity, any reason this is done for kdebase-runtime but not > ktorrent? Because there's no enforcement of the policy and the ktorrent maintainer(s) just didn't do the change yet. It also needs to be verified that KTorrent will work properly if you remove the flags (i.e. don't install the subpackage). Kevin Kofler From denis at poolshark.org Tue May 19 21:44:01 2009 From: denis at poolshark.org (Denis Leroy) Date: Tue, 19 May 2009 23:44:01 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <20090519203722.GB7385@nostromo.devel.redhat.com> References: <4A12DAE8.8040903@gmail.com> <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> <20090519181454.GA4397@nostromo.devel.redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <20090519202228.GE32139@macmahon.me.uk> <20090519203722.GB7385@nostromo.devel.redhat.com> Message-ID: <4A132821.1030504@poolshark.org> On 05/19/2009 10:37 PM, Bill Nottingham wrote: > Ewan Mac Mahon (ewan at macmahon.me.uk) said: >> This sort of decision is always going to be a balance; on the one hand >> there are clearly real costs to Fedora in having a blanket ban on flags, >> and on the other we have (according to spot[1]) "no specific legal issue >> at this time". > > They specifically stated that it may/will prevent Fedora from being > available or acceptable in some countries. That's not insignificant. That's a pretty vague sentence. Do we have something more specific to work with, to justify this whole fiasco ? Have people complained ? Were threats made ? Bugzilla tickets filed ? Did the PRC threaten to add fedoraproject.org to the big firewall if we don't stop shipping FreeCIV immediately (a CeasePackage-and-desist letter :-) ) ? From gmaxwell at gmail.com Tue May 19 21:45:02 2009 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Tue, 19 May 2009 17:45:02 -0400 Subject: In which country should Fedora be legal? In-Reply-To: <20090519203305.GA7385@nostromo.devel.redhat.com> References: <20090519195838.GC4558@free.fr> <20090519203305.GA7385@nostromo.devel.redhat.com> Message-ID: On Tue, May 19, 2009 at 4:33 PM, Bill Nottingham wrote: >> As a side note, it is not neutral at all to remove all the flags from >> fedora, it favors countries where flags can be illegal. > > Given that I'm fairly sure there are zero countries on the planet > where flags *cannot* be made illegal by some act of the populace > or government, that's a specious argument. There is a lot of wrong headed flag usage out there in any case. For example, flags should never be used to identify languages. At best any effort to do so is going to be inaccurate. At worst the result is offensive to some people and illegal in some places. ? yet there is a lot of free software that conflates flags and languages. From a.badger at gmail.com Tue May 19 21:48:04 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 19 May 2009 14:48:04 -0700 Subject: Package Maintainers Flags policy In-Reply-To: <1242767869.3029.13.camel@localhost.localdomain> References: <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <4A12DAE8.8040903@gmail.com> <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> <20090519181454.GA4397@nostromo.devel.redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <4A131DC6.8000605@gmail.com> <1242767869.3029.13.camel@localhost.localdomain> Message-ID: <4A132914.9040305@gmail.com> On 05/19/2009 02:17 PM, Jesse Keating wrote: > On Tue, 2009-05-19 at 13:59 -0700, Toshio Kuratomi wrote: >> If you want something that's truly easier, then I propose, "flags are >> just another piece of data provided by upstream unless US law makes us >> care." > > There is another concern here. Red Hat Enterprise Linux (RHEL) will > likely continue the "no flags" policy, which means that any software > within Fedora that RHEL would like to ship, the packaging will have to > fork, and patches will have to be created. This isn't Fedora's problem, > but something for RHT to note when it is deciding what software to take > and how much work will be necessary to make it RHEL worthy. > RHEL has to do that even with this policy. The policy doesn't ban flags. It doesn't even banish them to subpackages in all cases. -Toshio From kevin.kofler at chello.at Tue May 19 21:53:02 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 19 May 2009 23:53:02 +0200 Subject: Package Maintainers Flags policy References: <20090518090953.5698908a@ohm.scrye.com> <1242667087.25634.1927.camel@cookie.hadess.net> <1242747958.2919.31.camel@macbook.infradead.org> Message-ID: David Woodhouse wrote: > Consider the following statement: > On the other hand, $PROJECT upstream explicitly decided NOT to > ban profanity, as they consider banning profanity to be a > political move and to go against $PROJECT's principle of > political neutrality. > > Would people be arguing to ship that project, unmodified, in Fedora? Hell fucking yeah! > Try the same statement with s/profanity/sexually explicit images/. Same here, if e.g. KDE started shipping sexual wallpapers, I don't see why we wouldn't ship them in kdebase-workspace-wallpapers or kdeartwork-wallpapers. (Now those are not installed by default, but that's a size issue and unrelated to the content. There are no sexual wallpapers in them at this time, at least none that I know of.) I also consider the censorship of screensavers which is now done in xscreensaver (renaming of tangrams with vulgar or sexual titles, webcollage not actually being a *web* collage by default to avoid fetching sexual content) stupid, if it was just me I'd have closed all those complaints as NOTABUG. > Besides, the KDE position doesn't make any sense -- you either ship (for > example) a Taiwanese flag, or you don't. FWIW, KDE ships it. Kevin Kofler From tcallawa at redhat.com Tue May 19 21:51:21 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 19 May 2009 17:51:21 -0400 Subject: Package Maintainers Flags policy In-Reply-To: <4A132821.1030504@poolshark.org> References: <4A12DAE8.8040903@gmail.com> <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> <20090519181454.GA4397@nostromo.devel.redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <20090519202228.GE32139@macmahon.me.uk> <20090519203722.GB7385@nostromo.devel.redhat.com> <4A132821.1030504@poolshark.org> Message-ID: <4A1329D9.1070007@redhat.com> On 05/19/2009 05:44 PM, Denis Leroy wrote: > That's a pretty vague sentence. Do we have something more specific to > work with, to justify this whole fiasco ? Have people complained ? Were > threats made ? Bugzilla tickets filed ? Did the PRC threaten to add > fedoraproject.org to the big firewall if we don't stop shipping FreeCIV > immediately (a CeasePackage-and-desist letter :-) ) ? People complained. I was asked to write a policy draft to handle flags. Well, to be specific, I was asked to document the unwritten "no flags" policy that we'd had from the Red Hat Linux days, but after giving it thought and consulting with Red Hat Legal, I came up with the current policy which: * permits flags in optional subpackages * permits flags when their use is not technically or substantively essential to the package * gives an explicit exception to flags when they are generic (fictional countries count as generic) * has an exception clause where a packager can plead their case to FESCo This is substantially divergent from "No Flags". ~spot From rms at 1407.org Tue May 19 21:55:36 2009 From: rms at 1407.org (Rui Miguel Silva Seabra) Date: Tue, 19 May 2009 22:55:36 +0100 Subject: In which country should Fedora be legal? In-Reply-To: <20090519195838.GC4558@free.fr> References: <20090519195838.GC4558@free.fr> Message-ID: <20090519215536.GB4623@roque.1407.org> On Tue, May 19, 2009 at 09:58:38PM +0200, Patrice Dumas wrote: > Hello, > > I think that the flag policy is the wrong way to look at a real issue. > First, it tries to solve 2 issues > 1. being legal in some countries It'll very likely become downright illegal in many countries in Europe depending on Cibercrime implementations. Rui -- Wibble. Today is Prickle-Prickle, the 66th day of Discord in the YOLD 3175 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? From a.badger at gmail.com Tue May 19 21:56:47 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 19 May 2009 14:56:47 -0700 Subject: Package Maintainers Flags policy In-Reply-To: <1242768965.3029.20.camel@localhost.localdomain> References: <4A12B940.4050605@redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <200905192226.21739.opensource@till.name> <20090519210847.GC7385@nostromo.devel.redhat.com> <4A132355.3070903@gmail.com> <1242768965.3029.20.camel@localhost.localdomain> Message-ID: <4A132B1F.4090803@gmail.com> On 05/19/2009 02:36 PM, Jesse Keating wrote: > On Tue, 2009-05-19 at 14:23 -0700, Toshio Kuratomi wrote: >> I agree with this sentiment 100%. We're here to make better packages, >> not whine about how making better packages is hard. However, I'd point >> out that in this specifc case Jesse raised the "easier" argument and >> Till was just replying to that. > > I think that my point was that it is an easier to understand policy. It came across as implementable, not as understandability: """" There is an easier option 3, which is no flags in Fedora period, regardless of what spin. Far easier to implement. """ > It > may be more difficult to enact, but it is a far sight easier than trying > to figure out what other packages might require your flags, and if any > of those packages are on something called a "default spin", which can > change it's contents at any time. And here you're again arguing about implementation, not about understandability. Where we deal with implementation, we deal with Bill's note about "easy". It's easier to trust that your packagers haven't packaged anything that has flags than to write a script that looks for the Provides (or filename) in the package set but it's not necessarily right for Fedora. -Toshio From kevin.kofler at chello.at Tue May 19 22:00:15 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 20 May 2009 00:00:15 +0200 Subject: Package Maintainers Flags policy References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <29fee02b0905190526i593c1c97x840ba64d38455902@mail.gmail.com> <1242737529.30251.182.camel@macbook.infradead.org> Message-ID: David Woodhouse wrote: > I think it's mildly hypocritical of anyone to demand that we restore > flags without also restoring the missing bits of fortune files and the > 'random image' screensavers. The principle is the same -- some stupid > people choose to be offended, and we're pandering to them because we > want an easy life. Indeed, that stuff should also be readded. Kevin Kofler From kevin.kofler at chello.at Tue May 19 22:01:46 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 20 May 2009 00:01:46 +0200 Subject: Package Maintainers Flags policy References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <29fee02b0905190526i593c1c97x840ba64d38455902@mail.gmail.com> Message-ID: Andrea Musuruane wrote: > I wonder what will happen in the long run if we continue to remove > everything that anyone on the planet can consider "inappropriate". We'll end up with not shipping anything at all. I'm sure even the kernel can offend someone somewhere. (Maybe: "Hey, 'kernel' is the same word as 'testicle' in my language, it's sexual!") Censorship is stupid. Kevin Kofler From jkeating at j2solutions.net Tue May 19 22:09:43 2009 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 19 May 2009 15:09:43 -0700 Subject: Package Maintainers Flags policy In-Reply-To: <4A132B1F.4090803@gmail.com> References: <4A12B940.4050605@redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <200905192226.21739.opensource@till.name> <20090519210847.GC7385@nostromo.devel.redhat.com> <4A132355.3070903@gmail.com> <1242768965.3029.20.camel@localhost.localdomain> <4A132B1F.4090803@gmail.com> Message-ID: <1242770983.3029.21.camel@localhost.localdomain> On Tue, 2009-05-19 at 14:56 -0700, Toshio Kuratomi wrote: > > It came across as implementable, not as understandability: > """" > There is an easier option 3, which is no flags in Fedora period, > regardless of what spin. Far easier to implement. > """ Sorry, I obviously typed without thinking (: > > It > > may be more difficult to enact, but it is a far sight easier than trying > > to figure out what other packages might require your flags, and if any > > of those packages are on something called a "default spin", which can > > change it's contents at any time. > > And here you're again arguing about implementation, not about > understandability. > > Where we deal with implementation, we deal with Bill's note about > "easy". It's easier to trust that your packagers haven't packaged > anything that has flags than to write a script that looks for the > Provides (or filename) in the package set but it's not necessarily right > for Fedora. -- Jesse Keating RHCE (http://jkeating.livejournal.com) Fedora Project (http://fedoraproject.org/wiki/JesseKeating) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) identi.ca (http://identi.ca/jkeating) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Tue May 19 22:10:52 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 19 May 2009 15:10:52 -0700 Subject: Package Maintainers Flags policy In-Reply-To: <4A132914.9040305@gmail.com> References: <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <4A12DAE8.8040903@gmail.com> <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> <20090519181454.GA4397@nostromo.devel.redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <4A131DC6.8000605@gmail.com> <1242767869.3029.13.camel@localhost.localdomain> <4A132914.9040305@gmail.com> Message-ID: <1242771052.3029.22.camel@localhost.localdomain> On Tue, 2009-05-19 at 14:48 -0700, Toshio Kuratomi wrote: > RHEL has to do that even with this policy. The policy doesn't ban > flags. It doesn't even banish them to subpackages in all cases. Right. In case it wasn't obvious, I don't like the proposed policy. I'd much rather we went all the way and just disallowed flags, much like gnome. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kevin.kofler at chello.at Tue May 19 22:04:11 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 20 May 2009 00:04:11 +0200 Subject: Package Maintainers Flags policy References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <29fee02b0905190526i593c1c97x840ba64d38455902@mail.gmail.com> <1242737529.30251.182.camel@macbook.infradead.org> <4A12B130.5040107@poolshark.org> Message-ID: Seth Vidal wrote: > If a program means to say "choose your language" then they should say > "choose your language". Not "choose a flag from a linguistically > homogenous country". and Matthew Garrett wrote: > There isn't a 1:1 mapping between flags and languages, and arguably an > educational suite should be avoiding encouraging that confusion in > children. And how do you expect a child below reading age to read what you're writing on the screen? Because that's the target userbase of GCompris. Kevin Kofler From denis at poolshark.org Tue May 19 22:13:48 2009 From: denis at poolshark.org (Denis Leroy) Date: Wed, 20 May 2009 00:13:48 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <4A1329D9.1070007@redhat.com> References: <4A12DAE8.8040903@gmail.com> <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> <20090519181454.GA4397@nostromo.devel.redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <20090519202228.GE32139@macmahon.me.uk> <20090519203722.GB7385@nostromo.devel.redhat.com> <4A132821.1030504@poolshark.org> <4A1329D9.1070007@redhat.com> Message-ID: <4A132F1C.408@poolshark.org> On 05/19/2009 11:51 PM, Tom "spot" Callaway wrote: > On 05/19/2009 05:44 PM, Denis Leroy wrote: >> That's a pretty vague sentence. Do we have something more specific to >> work with, to justify this whole fiasco ? Have people complained ? Were >> threats made ? Bugzilla tickets filed ? Did the PRC threaten to add >> fedoraproject.org to the big firewall if we don't stop shipping FreeCIV >> immediately (a CeasePackage-and-desist letter :-) ) ? > > People complained. How many ? Or is it just that one user from https://bugzilla.redhat.com/show_bug.cgi?id=479265 versus the "a lot of users were asking for flags. a lot." From kevin.kofler at chello.at Tue May 19 22:10:57 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 20 May 2009 00:10:57 +0200 Subject: Package Maintainers Flags policy References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <1242737946.30251.189.camel@macbook.infradead.org> Message-ID: David Woodhouse wrote: > And my understanding is that there _is_ a valid legal reason for it. > Distributing Fedora in some countries is _illegal_ if it contains > certain flags, and can lead to extremely uncomfortable repercussions. And distributing games or some kind of games is illegal in some countries (e.g. I've read that card and dice games are considered betting in some Muslim countries, and the status of non-child-safe games or even not certified child-safe games is dubious in other, even Western, countries), some countries ban Internet use, so web browsers, e-mail clients and even updating software might be a problem etc. We're left with nothing to ship if we remove everything banned in some country. Kevin Kofler From mw_triad at users.sourceforge.net Tue May 19 22:18:47 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Tue, 19 May 2009 17:18:47 -0500 Subject: Package Maintainers Flags policy In-Reply-To: <4A12E0C1.2000409@fi.muni.cz> References: <20090518090953.5698908a@ohm.scrye.com> <200905182350.41222.opensource@till.name> <4A12E0C1.2000409@fi.muni.cz> Message-ID: Milos Jakubicek wrote: > Please turn this discussion back to two questions: > > 1) What should be the page name? Fedora Political Correctness Policies. Let's be honest about what this is. Everyone already knows to loathe "PC", right? ;-) I'm inclined to agree with Julian Sikorski. Let's stick to requiring adherence to U.S. law (because we have to, not because it's in any sense "better"), and for the rest, Patches Thoughtfully Considered. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Here endeth the rant... which I realize is not likely to Win Friends or Influence People, especially the person to whom it was directed. -- Charles Wilson (generalized) From mike at cchtml.com Tue May 19 22:21:13 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Tue, 19 May 2009 17:21:13 -0500 Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <29fee02b0905190526i593c1c97x840ba64d38455902@mail.gmail.com> Message-ID: <4A1330D9.3070407@cchtml.com> -------- Original Message -------- Subject: Re: Package Maintainers Flags policy From: Kevin Kofler To: fedora-devel-list at redhat.com Date: 05/19/2009 05:01 PM > Censorship is stupid. > Until I saw your comments in this thread, I thought I was the only one who thought this. Fedora ~= Freedom Last I recall... Heck, it was even a Fedora 10 feature! Already forgotten... http://fedoraproject.org/wiki/Features/FedoraFreedom Sure, pull the "oh but that's software not political" card, but it is the same argument. Politics are best left for the pigs, and pigs make good bacon. MMMmmm bacon. From oget.fedora at gmail.com Tue May 19 22:21:40 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Tue, 19 May 2009 18:21:40 -0400 Subject: Package Maintainers Flags policy In-Reply-To: <1242767292.3029.8.camel@localhost.localdomain> References: <20090518090953.5698908a@ohm.scrye.com> <1242767292.3029.8.camel@localhost.localdomain> Message-ID: On Tue, May 19, 2009 at 5:08 PM, Jesse Keating wrote: > On Tue, 2009-05-19 at 16:59 -0400, Orcan Ogetbil wrote: >> >> I have a question: >> >> Suppose there is an application that I want to package that contains >> the Brazilian flag only and no other flags. Afaik, the Brazilian flag >> is not illegal in any country in the world. Do I still have to make a >> subpackage for this one flag? > > Yes you would. ?The only way to be "neutral" is to treat all flags the > same. ?Any different treatment would amount to preferential treatment > which is exactly what we're trying to avoid. > Wouldn't it be better if we apply this policy only to those packages that contain "unsafe" flags? I mean, if the tarball contains an "unsafe" flag, make a flags subpackage with all the flags. On the other hand, if all the flags in the tarball are "safe" as in my above example, I don't see the rationale for spending the time and the effort of creating a subpackage. Orcan From kevin.kofler at chello.at Tue May 19 22:21:19 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 20 May 2009 00:21:19 +0200 Subject: Package Maintainers Flags policy References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> Message-ID: Mathieu Bridon (bochecha) wrote: > Anyway, sticking to the official internation standard list of > countries maintained by UN (if such a list exists) seems much more > neutral to me. Not really. You'd remove at least one of the flags KDE ships and take a political stand by doing that. Kevin Kofler From kevin.kofler at chello.at Tue May 19 22:28:30 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 20 May 2009 00:28:30 +0200 Subject: Package Maintainers Flags policy References: <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <20090519155546.GD32139@macmahon.me.uk> <1242749403.2919.36.camel@macbook.infradead.org> Message-ID: David Woodhouse wrote: > Seriously, folks -- we're only doing for flags the _same_ thing we've > done for a bunch of other things that would make it problematic to ship > Fedora in certain places. The thing is, the US is where Fedora is located, so it has no other choice than to respect its laws (even where this sucks ? crippleware due to software patents is annoying!), China is not. If we tried to be legal in all countries, we'd have to remove a lot more stuff than just flags. Kevin Kofler From skvidal at fedoraproject.org Tue May 19 22:29:03 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 19 May 2009 18:29:03 -0400 (EDT) Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <29fee02b0905190526i593c1c97x840ba64d38455902@mail.gmail.com> <1242737529.30251.182.camel@macbook.infradead.org> <4A12B130.5040107@poolshark.org> Message-ID: On Wed, 20 May 2009, Kevin Kofler wrote: > Seth Vidal wrote: >> If a program means to say "choose your language" then they should say >> "choose your language". Not "choose a flag from a linguistically >> homogenous country". > > and Matthew Garrett wrote: >> There isn't a 1:1 mapping between flags and languages, and arguably an >> educational suite should be avoiding encouraging that confusion in >> children. > > And how do you expect a child below reading age to read what you're writing > on the screen? Because that's the target userbase of GCompris. > But you expect the child to recognize the flag of their country? sigh, cmon.. A child who can't read needs to be taught by an adult, who, in theory, can. -sv From fedora at matbooth.co.uk Tue May 19 22:30:03 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Tue, 19 May 2009 23:30:03 +0100 Subject: Ongoing mass rebuild on s390x In-Reply-To: <4A12B277.7060806@redhat.com> References: <20090516173539.GD10645@redhat.de> <20090516184326.GB31277@redhat.de> <645d17210905190322v5c56eb9eo35bd71f0e4873bfb@mail.gmail.com> <4A12B277.7060806@redhat.com> Message-ID: <9497e9990905191530l5b73c707gb2041ec41025b5ca@mail.gmail.com> On Tue, May 19, 2009 at 2:21 PM, Karsten Hopp wrote: > Am 19.05.2009 12:22, schrieb Jonathan Underwood: >> >> Is there any way to set things up so that package builds include s390 >> from this point onwards for a package - I'd rather keep packages on >> all archs "in step" ? >> >> Thanks, >> Jonathan. >> > > AFAIK there's a cron script which needs to run on the koji hub to run those > builds on the > secondary archs. This isn't enabled yet as there are still quite a few > packages missing and > we'd get too many failures caused by unresolved dependencies. > But the plan is to enable this as soon as possible. > > ? ? ? ? Karsten > Will the secondary arches eventually be integrated into the main koji instance? I don't really understand the technical need for separate instances... -- Mat Booth www.matbooth.co.uk From jkeating at redhat.com Tue May 19 22:31:36 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 19 May 2009 15:31:36 -0700 Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <1242767292.3029.8.camel@localhost.localdomain> Message-ID: <1242772296.3029.25.camel@localhost.localdomain> On Tue, 2009-05-19 at 18:21 -0400, Orcan Ogetbil wrote: > Wouldn't it be better if we apply this policy only to those packages > that contain "unsafe" flags? I mean, if the tarball contains an > "unsafe" flag, make a flags subpackage with all the flags. On the > other hand, if all the flags in the tarball are "safe" as in my above > example, I don't see the rationale for spending the time and the > effort of creating a subpackage. That's not a terrible stance to take, until you have a package that contains all the flags except for say Tibet. Plus you then have to try and keep a running list of "unsafe" flags, and make sure the package set is kept up to date with those unsafe removals. In my experience, such efforts fail. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kevin.kofler at chello.at Tue May 19 22:36:21 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 20 May 2009 00:36:21 +0200 Subject: Package Maintainers Flags policy References: <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <4A12DAE8.8040903@gmail.com> Message-ID: Toshio Kuratomi wrote: > * If a package is on the main spin (or required by something on the main > spin in the case of updates that pull in different packages) Which one? There are 3 primary spins. > * This ties the policy to the existence of a "main spin". I don't > believe there's serious plans to get rid of that but if we do, this > policy will need to be revised. There is already no one main spin, there's the "Desktop" (GNOME) Live CD and there's the installer DVD, both of which are "the main" to some people, and there's the KDE Live CD. Now I wouldn't object to only banning flags from the GNOME Live image because that means we could ship them in KDE packages. ;-) But I'd disagree in at least 2 ways with the rationale for that decision (censoring flags in the first place and considering only GNOME a first-class citizen). Kevin Kofler From kevin.kofler at chello.at Tue May 19 22:45:56 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 20 May 2009 00:45:56 +0200 Subject: Package Maintainers Flags policy References: <4A12B940.4050605@redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <200905192226.21739.opensource@till.name> <20090519210847.GC7385@nostromo.devel.redhat.com> Message-ID: Bill Nottingham wrote: > (really, this will affect only a small number of packagers, anyway.) I think you (and others) are significantly underestimating the number of affected packages. The previous unwritten policy (from RHL times) not to ship any flags wasn't enforced for community-maintained packages, several packages include flags and some (e.g. freeciv) need them for proper operation. Kevin Kofler From pbrobinson at gmail.com Tue May 19 22:47:23 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 19 May 2009 23:47:23 +0100 Subject: Fedora and the moblin2 fork Message-ID: <5256d0b0905191547w1d5725c3i2cd4338723cecc64@mail.gmail.com> Hi All, I know it was discussed a while ago. Specifically the difference between Fedora and moblin and why not upstream. It seems this blog post [1] explains some of the cross pollination :) So who wants to contribute to Fedora Mini [2] to get this in for Fedora 12? Peter [1] http://www.gnome.org/~michael/blog/2009-05-19.html [2] https://fedoraproject.org/wiki/SIGs/FedoraMini From kevin.kofler at chello.at Tue May 19 22:46:37 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 20 May 2009 00:46:37 +0200 Subject: Package Maintainers Flags policy References: <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <4A12DAE8.8040903@gmail.com> <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> <20090519181454.GA4397@nostromo.devel.redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <4A131DC6.8000605@gmail.com> Message-ID: Toshio Kuratomi wrote: > If you want something that's truly easier, then I propose, "flags are > just another piece of data provided by upstream unless US law makes us > care." +1 to that proposal. Kevin Kofler From awilliam at redhat.com Tue May 19 22:54:13 2009 From: awilliam at redhat.com (Adam Williamson) Date: Tue, 19 May 2009 15:54:13 -0700 Subject: Package Maintainers Flags policy In-Reply-To: <20090519210847.GC7385@nostromo.devel.redhat.com> References: <4A12B940.4050605@redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <200905192226.21739.opensource@till.name> <20090519210847.GC7385@nostromo.devel.redhat.com> Message-ID: <1242773653.5864.2.camel@adam.local.net> On Tue, 2009-05-19 at 17:08 -0400, Bill Nottingham wrote: > (drifiting afield from this specific issue now, but it's related) > > And really... it's not about being 'easier for package maintainers'. I'm > really tired of hearing that trope applied any time any sort of policy > is applied or suggested, whether it be: > > - not having flags in packages > - having actual update notes in bodhi (or even using bodhi at all) > - not pushing new libraries to every release immediately > - not cursing out your fellow developers Those cases are different. In those cases (arguably except for the last), the 'difficult' bit increases the actual quality of the product we are producing. Carrying eternal patches to remove certain images for reasons of political appeasement does not improve the actual quality of Fedora. It is fine to impose burdens on maintainers where that leads to a reasonable improvement in the quality of the product they're building, but placing significant burdens on maintainers in order to please certain external bodies is a far tougher sell. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From a.badger at gmail.com Tue May 19 22:55:44 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 19 May 2009 15:55:44 -0700 Subject: Package Maintainers Flags policy In-Reply-To: <4A1329D9.1070007@redhat.com> References: <4A12DAE8.8040903@gmail.com> <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> <20090519181454.GA4397@nostromo.devel.redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <20090519202228.GE32139@macmahon.me.uk> <20090519203722.GB7385@nostromo.devel.redhat.com> <4A132821.1030504@poolshark.org> <4A1329D9.1070007@redhat.com> Message-ID: <4A1338F0.5050606@gmail.com> On 05/19/2009 02:51 PM, Tom "spot" Callaway wrote: > On 05/19/2009 05:44 PM, Denis Leroy wrote: >> That's a pretty vague sentence. Do we have something more specific to >> work with, to justify this whole fiasco ? Have people complained ? Were >> threats made ? Bugzilla tickets filed ? Did the PRC threaten to add >> fedoraproject.org to the big firewall if we don't stop shipping FreeCIV >> immediately (a CeasePackage-and-desist letter :-) ) ? > > People complained. I was asked to write a policy draft to handle flags. > Well, to be specific, I was asked to document the unwritten "no flags" > policy that we'd had from the Red Hat Linux days, but after giving it > thought and consulting with Red Hat Legal, I came up with the current > policy which: > > * permits flags in optional subpackages > * permits flags when their use is not technically or substantively > essential to the package s/not// ? > * gives an explicit exception to flags when they are generic (fictional > countries count as generic) Note that this one is tricky. A generic flag is fine. But if a real group (not necessarily a country) associates themselves with the flag, it would become banned under the current policy. > * has an exception clause where a packager can plead their case to FESCo > > This is substantially divergent from "No Flags". > -Toshio From kevin.kofler at chello.at Tue May 19 22:51:11 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 20 May 2009 00:51:11 +0200 Subject: Package Maintainers Flags policy References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <20090519111017.GA32139@macmahon.me.uk> Message-ID: Ewan Mac Mahon wrote: > It is for some packages. I can't see any sane way to package FreeCiv, > for example, without using flags. At that point, do we just accept the > package (Tibettan nation and flag and all) or drop perfectly good Free > software from the distribution? A non-game example would be an application to teach geography. That clearly has concrete educational value. But even if you remove the Taiwanese flag, you still end up with Taiwan shown as a country. Now if you patch the app to consider it part of China, how's that not a political stand (and very likely to offend people in Taiwan, too)? Are we now banned from teaching our children geography? Kevin Kofler From jkeating at redhat.com Tue May 19 23:04:09 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 19 May 2009 16:04:09 -0700 Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <20090519111017.GA32139@macmahon.me.uk> Message-ID: <1242774249.3029.32.camel@localhost.localdomain> On Wed, 2009-05-20 at 00:51 +0200, Kevin Kofler wrote: > > A non-game example would be an application to teach geography. That clearly > has concrete educational value. But even if you remove the Taiwanese flag, > you still end up with Taiwan shown as a country. Now if you patch the app > to consider it part of China, how's that not a political stand (and very > likely to offend people in Taiwan, too)? Are we now banned from teaching > our children geography? Depends on what version of geography you want to teach them, and where you live. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From akurtako at redhat.com Tue May 19 23:06:11 2009 From: akurtako at redhat.com (Alexander Kurtakov) Date: Wed, 20 May 2009 01:06:11 +0200 Subject: Package Maintainers Flags policy In-Reply-To: References: <4A12B940.4050605@redhat.com> <4A131DC6.8000605@gmail.com> Message-ID: <200905200106.11601.akurtako@redhat.com> On Wednesday 20 May 2009 00:46:37 Kevin Kofler wrote: > Toshio Kuratomi wrote: > > If you want something that's truly easier, then I propose, "flags are > > just another piece of data provided by upstream unless US law makes us > > care." > > +1 to that proposal. > > Kevin Kofler +1 from me also https://fedoraproject.org/wiki/Staying_close_to_upstream_projects Alexander Kurtakov From kevin.kofler at chello.at Tue May 19 23:24:38 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 20 May 2009 01:24:38 +0200 Subject: Package Maintainers Flags policy References: <4A12DAE8.8040903@gmail.com> <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> <20090519181454.GA4397@nostromo.devel.redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <20090519202228.GE32139@macmahon.me.uk> <20090519203722.GB7385@nostromo.devel.redhat.com> <4A132821.1030504@poolshark.org> <4A1329D9.1070007@redhat.com> <4A1338F0.5050606@gmail.com> Message-ID: Toshio Kuratomi wrote: > Note that this one is tricky. A generic flag is fine. But if a real > group (not necessarily a country) associates themselves with the flag, > it would become banned under the current policy. Then what would a "generic" flag be? Single-color flags are often used by political groups (e.g. all black = fascist, so if you thought to avoid the issue by using that, you've just made it worse). The only reasonable definition of "generic" I can see is "this flag is not used to represent a country", e.g. a set of flags being used as an icon for "localization". Kevin Kofler From kevin.kofler at chello.at Tue May 19 23:28:55 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 20 May 2009 01:28:55 +0200 Subject: Package Maintainers Flags policy References: <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <4A12DAE8.8040903@gmail.com> <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> <20090519181454.GA4397@nostromo.devel.redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <4A131DC6.8000605@gmail.com> <1242767869.3029.13.camel@localhost.localdomain> <4A132914.9040305@gmail.com> <1242771052.3029.22.camel@localhost.localdomain> Message-ID: Jesse Keating wrote: > Right. In case it wasn't obvious, I don't like the proposed policy. Neither do I. > I'd much rather we went all the way and just disallowed flags, much like > gnome. I'd much rather we went all the way and just allowed flags, much like KDE. That said, I think the approved compromise sucks less than banning flags outright. But not much, it's still a problem for several packages. Kevin Kofler From khc at pm.waw.pl Tue May 19 23:32:36 2009 From: khc at pm.waw.pl (Krzysztof Halasa) Date: Wed, 20 May 2009 01:32:36 +0200 Subject: Package Maintainers Flags policy In-Reply-To: (Kevin Kofler's message of "Wed\, 20 May 2009 00\:01\:46 +0200") References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <29fee02b0905190526i593c1c97x840ba64d38455902@mail.gmail.com> Message-ID: Kevin Kofler writes: > We'll end up with not shipping anything at all. I'm sure even the kernel can > offend someone somewhere. (Maybe: "Hey, 'kernel' is the same word > as 'testicle' in my language, it's sexual!") Censorship is stupid. I don't know about "kernel" but "root" - certainly. In English BTW. -- Krzysztof Halasa From a.badger at gmail.com Tue May 19 23:42:01 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 19 May 2009 16:42:01 -0700 Subject: Package Maintainers Flags policy In-Reply-To: References: <4A12DAE8.8040903@gmail.com> <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> <20090519181454.GA4397@nostromo.devel.redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <20090519202228.GE32139@macmahon.me.uk> <20090519203722.GB7385@nostromo.devel.redhat.com> <4A132821.1030504@poolshark.org> <4A1329D9.1070007@redhat.com> <4A1338F0.5050606@gmail.com> Message-ID: <4A1343C9.5070400@gmail.com> On 05/19/2009 04:24 PM, Kevin Kofler wrote: > Toshio Kuratomi wrote: >> Note that this one is tricky. A generic flag is fine. But if a real >> group (not necessarily a country) associates themselves with the flag, >> it would become banned under the current policy. > > Then what would a "generic" flag be? Single-color flags are often used by > political groups (e.g. all black = fascist, so if you thought to avoid the > issue by using that, you've just made it worse). > """ Flag images which are not specific to any location, country, nation, geopolitical entity, language, ethnocultural concept, religion, political movement, or institutions are permitted """ So yep, as you point out, the generic flag exception is somewhat hard to work with. > The only reasonable definition of "generic" I can see is "this flag is not > used to represent a country", e.g. a set of flags being used as an icon > for "localization". > That's unfortunately not the definition being used here. If it was, it would be a more helpful clause. -Toshio From tcallawa at redhat.com Tue May 19 23:59:02 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 19 May 2009 19:59:02 -0400 Subject: Package Maintainers Flags policy In-Reply-To: <4A1338F0.5050606@gmail.com> References: <4A12DAE8.8040903@gmail.com> <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> <20090519181454.GA4397@nostromo.devel.redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <20090519202228.GE32139@macmahon.me.uk> <20090519203722.GB7385@nostromo.devel.redhat.com> <4A132821.1030504@poolshark.org> <4A1329D9.1070007@redhat.com> <4A1338F0.5050606@gmail.com> Message-ID: <4A1347C6.9020103@redhat.com> On 05/19/2009 06:55 PM, Toshio Kuratomi wrote: >> * permits flags when their use is not technically or substantively >> essential to the package > > s/not// Yeah, that's right. My apologies. ~spot From poelstra at redhat.com Wed May 20 00:02:08 2009 From: poelstra at redhat.com (John Poelstra) Date: Tue, 19 May 2009 17:02:08 -0700 Subject: One week slip of Fedora 11 Release In-Reply-To: <1242768563.3029.17.camel@localhost.localdomain> References: <1242768563.3029.17.camel@localhost.localdomain> Message-ID: <4A134880.8010806@redhat.com> Jesse Keating said the following on 05/19/2009 02:29 PM Pacific Time: > In a meeting today between Release Engineering, QA, and various team > leads, we decided to enact a 7 day slip of the Fedora 11 release date. > The primary reason behind this slip is the state of our blocker bug: > https://bugzilla.redhat.com/showdependencytree.cgi?id=F11Blocker&hide_resolved=1 We cannot begin Release Candidate phase until the blocker bugs are closed or at least in MODIFIED state. We are not there today, which would be our last day to enter RC phase and still have enough time to release on the 26th. We hope to enter RC phase in the next couple days, and hit our new target, June 2nd. > > Freeze breaks for critical bugs will still be accepted, however trivial > bug fixes should be pushed as updates via bodhi. Thanks! > > Detailed schedules have been updated to reflect this change and some additional events: 1) Final GA Blocker Bug review meeting on Friday, 2009-05-22 2) "Go/No-Go" Meeting on 2009-05-26 @ 3 PM EDT http://poelstra.fedorapeople.org/schedules/f-11/f-11-releng-tasks.html John _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From jwboyer at gmail.com Wed May 20 01:28:59 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 19 May 2009 21:28:59 -0400 Subject: Ongoing mass rebuild on s390x In-Reply-To: <9497e9990905191530l5b73c707gb2041ec41025b5ca@mail.gmail.com> References: <20090516173539.GD10645@redhat.de> <20090516184326.GB31277@redhat.de> <645d17210905190322v5c56eb9eo35bd71f0e4873bfb@mail.gmail.com> <4A12B277.7060806@redhat.com> <9497e9990905191530l5b73c707gb2041ec41025b5ca@mail.gmail.com> Message-ID: <20090520012859.GA27067@hansolo.jdub.homelinux.org> On Tue, May 19, 2009 at 11:30:03PM +0100, Mat Booth wrote: >On Tue, May 19, 2009 at 2:21 PM, Karsten Hopp wrote: >> Am 19.05.2009 12:22, schrieb Jonathan Underwood: >>> >>> Is there any way to set things up so that package builds include s390 >>> from this point onwards for a package - I'd rather keep packages on >>> all archs "in step" ? >>> >>> Thanks, >>> Jonathan. >>> >> >> AFAIK there's a cron script which needs to run on the koji hub to run those >> builds on the >> secondary archs. This isn't enabled yet as there are still quite a few >> packages missing and >> we'd get too many failures caused by unresolved dependencies. >> But the plan is to enable this as soon as possible. >> >> ? ? ? ? Karsten >> > >Will the secondary arches eventually be integrated into the main koji >instance? I don't really understand the technical need for separate >instances... No. Secondary arches are handled by the arch teams. Only primary arches are hooked up to the main koji hub and get storage on the Fedora Infrastructure. >From a technical standpoint, it could surely happen. From a project standpoint there is a reason the architectures are called 'secondary'. josh From chris.stone at gmail.com Wed May 20 01:58:47 2009 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 19 May 2009 18:58:47 -0700 Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <1242667087.25634.1927.camel@cookie.hadess.net> <200905182239.04065.bjorn@xn--rombobjrn-67a.se> <4ccd9dcb0905190600t30325bf1j56b7f53c5744900c@mail.gmail.com> Message-ID: On Tue, May 19, 2009 at 6:59 AM, Seth Vidal wrote: > What if a non-authoritarian regime didn't want us to distribute a flag that > was offensive to their democratically-empowered populace? Would that be okay > then? Please Seth, a non-authoritarian regime wouldn't be making demands on what you can distribute, if they did, they would be authoritarian. Your logic needs to be improved, and I am in disagreement with you on this topic. -Chris From cmadams at hiwaay.net Wed May 20 02:05:17 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 19 May 2009 21:05:17 -0500 Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <1242667087.25634.1927.camel@cookie.hadess.net> <200905182239.04065.bjorn@xn--rombobjrn-67a.se> <4ccd9dcb0905190600t30325bf1j56b7f53c5744900c@mail.gmail.com> Message-ID: <20090520020517.GA1432245@hiwaay.net> Once upon a time, Christopher Stone said: > Please Seth, a non-authoritarian regime wouldn't be making demands on > what you can distribute, if they did, they would be authoritarian. Can you name a non-authoritarian regime then? Hint: China isn't the only country that restricts flags. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From awilliam at redhat.com Wed May 20 02:05:53 2009 From: awilliam at redhat.com (Adam Williamson) Date: Tue, 19 May 2009 19:05:53 -0700 Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <1242667087.25634.1927.camel@cookie.hadess.net> <200905182239.04065.bjorn@xn--rombobjrn-67a.se> <4ccd9dcb0905190600t30325bf1j56b7f53c5744900c@mail.gmail.com> Message-ID: <1242785153.8848.52.camel@adam.local.net> On Tue, 2009-05-19 at 18:58 -0700, Christopher Stone wrote: > On Tue, May 19, 2009 at 6:59 AM, Seth Vidal wrote: > > What if a non-authoritarian regime didn't want us to distribute a flag that > > was offensive to their democratically-empowered populace? Would that be okay > > then? > > Please Seth, a non-authoritarian regime wouldn't be making demands on > what you can distribute, if they did, they would be authoritarian. Germany has fairly strong (democratically imposed) restrictions on freedom of speech as it relates to the Nazi regime and the Holocaust. If Fedora were to include some software which impinged on those restrictions in some way, it wouldn't be legal to distribute it in Germany. It's perfectly possible to envisage a situation in which a piece of software would be non-distributable in Germany, a country few would describe as an 'authoritarian regime'. (In fact, it's happened. The game Wolfenstein 3-D had to be substantially modified for distribution in Germany. http://en.wikipedia.org/wiki/Wolfenstein_3D#Controversy ) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From chris.stone at gmail.com Wed May 20 02:13:24 2009 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 19 May 2009 19:13:24 -0700 Subject: Package Maintainers Flags policy In-Reply-To: <1242785153.8848.52.camel@adam.local.net> References: <20090518090953.5698908a@ohm.scrye.com> <1242667087.25634.1927.camel@cookie.hadess.net> <200905182239.04065.bjorn@xn--rombobjrn-67a.se> <4ccd9dcb0905190600t30325bf1j56b7f53c5744900c@mail.gmail.com> <1242785153.8848.52.camel@adam.local.net> Message-ID: On Tue, May 19, 2009 at 7:05 PM, Adam Williamson wrote: > On Tue, 2009-05-19 at 18:58 -0700, Christopher Stone wrote: >> On Tue, May 19, 2009 at 6:59 AM, Seth Vidal wrote: >> > What if a non-authoritarian regime didn't want us to distribute a flag that >> > was offensive to their democratically-empowered populace? Would that be okay >> > then? >> >> Please Seth, a non-authoritarian regime wouldn't be making demands on >> what you can distribute, if they did, they would be authoritarian. > > Germany has fairly strong (democratically imposed) restrictions on > freedom of speech as it relates to the Nazi regime and the Holocaust. If > Fedora were to include some software which impinged on those > restrictions in some way, it wouldn't be legal to distribute it in > Germany. It's perfectly possible to envisage a situation in which a > piece of software would be non-distributable in Germany, a country few > would describe as an 'authoritarian regime'. Did you know that the Nevada state convention last year had to be indefinitely postponed because Ron Paul was going to win the majority of delegates? No, I cannot name a non-authoritarian regime. From skvidal at fedoraproject.org Wed May 20 02:19:11 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 19 May 2009 22:19:11 -0400 (EDT) Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <1242667087.25634.1927.camel@cookie.hadess.net> <200905182239.04065.bjorn@xn--rombobjrn-67a.se> <4ccd9dcb0905190600t30325bf1j56b7f53c5744900c@mail.gmail.com> Message-ID: On Tue, 19 May 2009, Christopher Stone wrote: > On Tue, May 19, 2009 at 6:59 AM, Seth Vidal wrote: >> What if a non-authoritarian regime didn't want us to distribute a flag that >> was offensive to their democratically-empowered populace? Would that be okay >> then? > > Please Seth, a non-authoritarian regime wouldn't be making demands on > what you can distribute, if they did, they would be authoritarian. > Your logic needs to be improved, and I am in disagreement with you on > this topic. Making laws does not make a gov't authoritarian. or rather if you believe that making laws makes a gov't authoritarian then there is no point in continuing the conversation. Germany bans nazi flags - that's a classic example of a non-authoritarian gov't keeping us from distributing specific flags. -sv From chris.stone at gmail.com Wed May 20 02:30:07 2009 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 19 May 2009 19:30:07 -0700 Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <1242667087.25634.1927.camel@cookie.hadess.net> <200905182239.04065.bjorn@xn--rombobjrn-67a.se> <4ccd9dcb0905190600t30325bf1j56b7f53c5744900c@mail.gmail.com> Message-ID: On Tue, May 19, 2009 at 7:19 PM, Seth Vidal wrote: > > > On Tue, 19 May 2009, Christopher Stone wrote: > >> On Tue, May 19, 2009 at 6:59 AM, Seth Vidal >> wrote: >>> >>> What if a non-authoritarian regime didn't want us to distribute a flag >>> that >>> was offensive to their democratically-empowered populace? Would that be >>> okay >>> then? >> >> Please Seth, a non-authoritarian regime wouldn't be making demands on >> what you can distribute, if they did, they would be authoritarian. >> Your logic needs to be improved, and I am in disagreement with you on >> this topic. > > Making laws does not make a gov't authoritarian. > > or rather if you believe that making laws makes a gov't authoritarian then > there is no point in continuing the conversation. > > Germany bans nazi flags - that's a classic example of a non-authoritarian > gov't keeping us from distributing specific flags. I would argue that it depends on the law. I would also argue that banning something like a flag means that you fear what that flag represents. The Chinese have to censor a lot of information because they fear it. The Communist party fears losing its power, that is why they censor and ban certain information. From skvidal at fedoraproject.org Wed May 20 02:48:03 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 19 May 2009 22:48:03 -0400 (EDT) Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <1242667087.25634.1927.camel@cookie.hadess.net> <200905182239.04065.bjorn@xn--rombobjrn-67a.se> <4ccd9dcb0905190600t30325bf1j56b7f53c5744900c@mail.gmail.com> Message-ID: On Tue, 19 May 2009, Christopher Stone wrote: > On Tue, May 19, 2009 at 7:19 PM, Seth Vidal wrote: >> >> >> On Tue, 19 May 2009, Christopher Stone wrote: >> >>> On Tue, May 19, 2009 at 6:59 AM, Seth Vidal >>> wrote: >>>> >>>> What if a non-authoritarian regime didn't want us to distribute a flag >>>> that >>>> was offensive to their democratically-empowered populace? Would that be >>>> okay >>>> then? >>> >>> Please Seth, a non-authoritarian regime wouldn't be making demands on >>> what you can distribute, if they did, they would be authoritarian. >>> Your logic needs to be improved, and I am in disagreement with you on >>> this topic. >> >> Making laws does not make a gov't authoritarian. >> >> or rather if you believe that making laws makes a gov't authoritarian then >> there is no point in continuing the conversation. >> >> Germany bans nazi flags - that's a classic example of a non-authoritarian >> gov't keeping us from distributing specific flags. > > I would argue that it depends on the law. I would also argue that > banning something like a flag means that you fear what that flag > represents. The Chinese have to censor a lot of information because > they fear it. The Communist party fears losing its power, that is why > they censor and ban certain information. we don't care why they do it. only that it hurts fedora there. -sv From chris.stone at gmail.com Wed May 20 02:56:01 2009 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 19 May 2009 19:56:01 -0700 Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <1242667087.25634.1927.camel@cookie.hadess.net> <200905182239.04065.bjorn@xn--rombobjrn-67a.se> <4ccd9dcb0905190600t30325bf1j56b7f53c5744900c@mail.gmail.com> Message-ID: On Tue, May 19, 2009 at 7:48 PM, Seth Vidal wrote: > we don't care why they do it. > > only that it hurts fedora there. So let the paid employees at the RedHat offices in China figure it out on a case by case basis. Seems like the most rational solution to me. From poelstra at redhat.com Wed May 20 03:02:52 2009 From: poelstra at redhat.com (John Poelstra) Date: Tue, 19 May 2009 20:02:52 -0700 Subject: Package Maintainers Flags policy In-Reply-To: <4A12CBE7.406@gmail.com> References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <1242737946.30251.189.camel@macbook.infradead.org> <20090519132756.GJ5760@localhost.localdomain> <4A12C0D9.1080706@freenet.de> <4A12CBE7.406@gmail.com> Message-ID: <4A1372DC.9070401@redhat.com> Toshio Kuratomi said the following on 05/19/2009 08:10 AM Pacific Time: > On 05/19/2009 07:23 AM, Ralf Corsepius wrote: >> Paul W. Frields wrote: >>> I do feel strongly that FESCo, as a community elected >>> body, >> 1/2 community elected. >> > The Board is half elected, half appointed. FESCo is wholly elected. > > -Toshio > Where "half elected" is 5 of 9 seats :) https://fedoraproject.org/wiki/Board John From rc040203 at freenet.de Wed May 20 04:03:04 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 20 May 2009 06:03:04 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <4A131DC6.8000605@gmail.com> References: <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <4A12DAE8.8040903@gmail.com> <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> <20090519181454.GA4397@nostromo.devel.redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <4A131DC6.8000605@gmail.com> Message-ID: <4A1380F8.6080106@freenet.de> Toshio Kuratomi wrote: > > If you want something that's truly easier, then I propose, "flags are > just another piece of data provided by upstream unless US law makes us > care." +1 ... very reasonable. Ralf From arjan at infradead.org Wed May 20 05:12:38 2009 From: arjan at infradead.org (Arjan van de Ven) Date: Tue, 19 May 2009 22:12:38 -0700 Subject: Fedora and the moblin2 fork In-Reply-To: <5256d0b0905191547w1d5725c3i2cd4338723cecc64@mail.gmail.com> References: <5256d0b0905191547w1d5725c3i2cd4338723cecc64@mail.gmail.com> Message-ID: <20090519221238.608afa5d@infradead.org> On Tue, 19 May 2009 23:47:23 +0100 Peter Robinson wrote: > Hi All, > > I know it was discussed a while ago. Specifically the difference > between Fedora and moblin and why not upstream. It seems this blog > post [1] explains some of the cross pollination :) So who wants to > contribute to Fedora Mini [2] to get this in for Fedora 12? with the 40 to 50% we borrow from fedora should mean that it's not too hard to get various pieces into Fedora; our developers tend to use autoconf/automake/pkgconfig/etc ... (Yes I know some people will count differently. I don't count anything for which we autogenerate the spec files as borrowed...) -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org From maxamillion at gmail.com Wed May 20 06:13:02 2009 From: maxamillion at gmail.com (Adam Miller) Date: Wed, 20 May 2009 01:13:02 -0500 Subject: Fedora and the moblin2 fork In-Reply-To: <20090519221238.608afa5d@infradead.org> References: <5256d0b0905191547w1d5725c3i2cd4338723cecc64@mail.gmail.com> <20090519221238.608afa5d@infradead.org> Message-ID: I would be happy to participate how ever I am able. I've attempted to get information on work needing to be done for the Fedora Mini SIG in the past so that I could join but got no reply. -Adam (From my G1) On May 20, 2009 12:13 AM, "Arjan van de Ven" wrote: On Tue, 19 May 2009 23:47:23 +0100 Peter Robinson wrote: > Hi All, > > I kn... with the 40 to 50% we borrow from fedora should mean that it's not too hard to get various pieces into Fedora; our developers tend to use autoconf/automake/pkgconfig/etc ... (Yes I know some people will count differently. I don't count anything for which we autogenerate the spec files as borrowed...) -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/list... -------------- next part -------------- An HTML attachment was scrubbed... URL: From dchen at redhat.com Wed May 20 06:18:47 2009 From: dchen at redhat.com (Ding-Yi Chen) Date: Wed, 20 May 2009 16:18:47 +1000 Subject: Package Maintainers Flags policy In-Reply-To: <20090519155546.GD32139@macmahon.me.uk> References: <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <20090519155546.GD32139@macmahon.me.uk> Message-ID: <1242800327.4500.9.camel@dhcp-0-207.bne.redhat.com> ? ??2009-05-19 ? 16:55 +0100?Ewan Mac Mahon ??? > On Tue, May 19, 2009 at 10:59:07AM -0400, Colin Walters wrote: > > The main thing we want to squash is things like flags in input > > method selection which is very prominent in the UI, and flags in > > bittorrent clients whose removal doesn't at all substantially affect > > the operation of the software. > > > That's a reasonable postion, but it's not quite the same as the current > policy. > Using flags in input methods along is not very informative. For example, there are dozens (if not hundreds) of Chinese IMs. How do you know which one should be associated with China flags? Should it be pinyin? wubi? cangjie3? cangjie5? It's a good thing that almost all input methods already have their own icons. -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ From pbrobinson at gmail.com Wed May 20 06:51:54 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 20 May 2009 07:51:54 +0100 Subject: Fedora and the moblin2 fork In-Reply-To: References: <5256d0b0905191547w1d5725c3i2cd4338723cecc64@mail.gmail.com> <20090519221238.608afa5d@infradead.org> Message-ID: <5256d0b0905192351q2b83333fgcb738c7f29334686@mail.gmail.com> Where did you send the query? Its been a little slower than I would have liked to getting it moving as shiny bits in the olpc corner sort of distracted me. Peter On Wed, May 20, 2009 at 7:13 AM, Adam Miller wrote: > I would be happy to participate how ever I am able. I've attempted to get > information on work needing to be done for the Fedora Mini SIG in the past > so that I could join but got no reply. > > -Adam > (From my G1) > > On May 20, 2009 12:13 AM, "Arjan van de Ven" wrote: > > On Tue, 19 May 2009 23:47:23 +0100 Peter Robinson > wrote: > Hi All, > > I kn... > > with the 40 to 50% we borrow from fedora should mean that it's not too > hard to get various pieces into Fedora; our developers tend to use > autoconf/automake/pkgconfig/etc ... > > (Yes I know some people will count differently. I don't count anything > for which we autogenerate the spec files as borrowed...) > > > > -- > Arjan van de Ven ? ? ? ?Intel Open Source Technology Centre > For development, discussion and tips for power savings, > visit http://www.lesswatts.org > > -- fedora-devel-list mailing list fedora-devel-list at redhat.com > https://www.redhat.com/mailman/list... > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From pertusus at free.fr Wed May 20 07:07:23 2009 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 20 May 2009 09:07:23 +0200 Subject: In which country should Fedora be legal? In-Reply-To: References: <20090519195838.GC4558@free.fr> <20090519203305.GA7385@nostromo.devel.redhat.com> Message-ID: <20090520070723.GA2822@free.fr> On Tue, May 19, 2009 at 05:45:02PM -0400, Gregory Maxwell wrote: > > There is a lot of wrong headed flag usage out there in any case. For > example, flags should never be used to identify languages. At best any > effort to do so is going to be inaccurate. At worst the result is > offensive to some people and illegal in some places. ? yet there is a > lot of free software that conflates flags and languages. That's an upstream issue, not a Fedora issue. This issue can be solved in Fedora, sure, but I don't think that it should be solved with a policy. -- Pat From denis at poolshark.org Wed May 20 07:07:50 2009 From: denis at poolshark.org (Denis Leroy) Date: Wed, 20 May 2009 09:07:50 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <1242771052.3029.22.camel@localhost.localdomain> References: <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <4A12DAE8.8040903@gmail.com> <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> <20090519181454.GA4397@nostromo.devel.redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <4A131DC6.8000605@gmail.com> <1242767869.3029.13.camel@localhost.localdomain> <4A132914.9040305@gmail.com> <1242771052.3029.22.camel@localhost.localdomain> Message-ID: <4A13AC46.1040005@poolshark.org> On 05/20/2009 12:10 AM, Jesse Keating wrote: > On Tue, 2009-05-19 at 14:48 -0700, Toshio Kuratomi wrote: >> RHEL has to do that even with this policy. The policy doesn't ban >> flags. It doesn't even banish them to subpackages in all cases. > > Right. In case it wasn't obvious, I don't like the proposed policy. > I'd much rather we went all the way and just disallowed flags, much like > gnome. Gnome is an upstream project, while Fedora is not. So this "simple" solution of yours is a mandated deviation from upstream, something that is not very Fedora-like to start with, simply based on an irrational fear of flags and on a single bugzilla complaint. If this is not an absurd overreaction, I don't know what is. From surenkarapetyan at gmail.com Wed May 20 07:07:30 2009 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Wed, 20 May 2009 12:07:30 +0500 Subject: Package Maintainers Flags policy In-Reply-To: <1242800327.4500.9.camel@dhcp-0-207.bne.redhat.com> References: <4A127B5E.2080600@poolshark.org> <20090519155546.GD32139@macmahon.me.uk> <1242800327.4500.9.camel@dhcp-0-207.bne.redhat.com> Message-ID: <200905201207.31072.surenkarapetyan@gmail.com> On Wednesday 20 May 2009 11:18:47 Ding-Yi Chen wrote: > ? ??2009-05-19 ? 16:55 +0100?Ewan Mac Mahon ??? > > > On Tue, May 19, 2009 at 10:59:07AM -0400, Colin Walters wrote: > > > The main thing we want to squash is things like flags in input > > > method selection which is very prominent in the UI, and flags in > > > bittorrent clients whose removal doesn't at all substantially affect > > > the operation of the software. > > > > That's a reasonable postion, but it's not quite the same as the current > > policy. > > Using flags in input methods along is not very informative. > For example, there are dozens (if not hundreds) of Chinese IMs. > How do you know which one should be associated with China flags? > Should it be pinyin? wubi? cangjie3? cangjie5? > > It's a good thing that almost all input methods already have their own > icons. > That's true if someone is trying to find a language from the full list. But if someone (e.g. me) has already chosen 3 he will be using (e.g. English, Armenian, Russian) it will be much more comfortable for him to see a flag and not a greyish box with greyish white letters (us, am, ru) in it. Suren From awilliam at redhat.com Wed May 20 07:11:14 2009 From: awilliam at redhat.com (Adam Williamson) Date: Wed, 20 May 2009 00:11:14 -0700 Subject: Package Maintainers Flags policy In-Reply-To: <1242800327.4500.9.camel@dhcp-0-207.bne.redhat.com> References: <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <4A12A82B.1080502@poolshark.org> <2d319b780905190650q63820790y83ea295a25263cf0@mail.gmail.com> <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <20090519155546.GD32139@macmahon.me.uk> <1242800327.4500.9.camel@dhcp-0-207.bne.redhat.com> Message-ID: <1242803474.8848.62.camel@adam.local.net> On Wed, 2009-05-20 at 16:18 +1000, Ding-Yi Chen wrote: > Using flags in input methods along is not very informative. > For example, there are dozens (if not hundreds) of Chinese IMs. > How do you know which one should be associated with China flags? > Should it be pinyin? wubi? cangjie3? cangjie5? > > It's a good thing that almost all input methods already have their own > icons. That's essentially irrelevant to this debate. All sorts of things are bad design decisions (or bad coding decisions) but we don't implement a blanket ban on them in Fedora and patch them all out...it's true that flags are a bad idea for various things, but the appropriate place to discuss that is in improvement reports to the upstream developers. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From denis at poolshark.org Wed May 20 07:20:36 2009 From: denis at poolshark.org (Denis Leroy) Date: Wed, 20 May 2009 09:20:36 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <20090518090953.5698908a@ohm.scrye.com> References: <20090518090953.5698908a@ohm.scrye.com> Message-ID: <4A13AF44.6040406@poolshark.org> On 05/18/2009 05:09 PM, Kevin Fenzi wrote: > In FESCo's 2009-03-28 meeting a policy on Flag usage for packages in > Fedora was approved. > > Due to an oversight, this policy was not announced here. ;( > > Please see: > > https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy > > and direct any comments to FESCo in a ticket or via the devel list. Could we have the FESCO meeting IRC log please. thanks From dchen at redhat.com Wed May 20 07:49:40 2009 From: dchen at redhat.com (Ding-Yi Chen) Date: Wed, 20 May 2009 17:49:40 +1000 Subject: Package Maintainers Flags policy In-Reply-To: <200905201207.31072.surenkarapetyan@gmail.com> References: <4A127B5E.2080600@poolshark.org> <20090519155546.GD32139@macmahon.me.uk> <1242800327.4500.9.camel@dhcp-0-207.bne.redhat.com> <200905201207.31072.surenkarapetyan@gmail.com> Message-ID: <1242805780.4500.29.camel@dhcp-0-207.bne.redhat.com> ? ??2009-05-20 ? 12:07 +0500?Suren Karapetyan ??? > On Wednesday 20 May 2009 11:18:47 Ding-Yi Chen wrote: > > ? ??2009-05-19 ? 16:55 +0100?Ewan Mac Mahon ??? > > > > > On Tue, May 19, 2009 at 10:59:07AM -0400, Colin Walters wrote: > > > > The main thing we want to squash is things like flags in input > > > > method selection which is very prominent in the UI, and flags in > > > > bittorrent clients whose removal doesn't at all substantially affect > > > > the operation of the software. > > > > > > That's a reasonable postion, but it's not quite the same as the current > > > policy. > > > > Using flags in input methods along is not very informative. > > For example, there are dozens (if not hundreds) of Chinese IMs. > > How do you know which one should be associated with China flags? > > Should it be pinyin? wubi? cangjie3? cangjie5? > > > > It's a good thing that almost all input methods already have their own > > icons. > > > > That's true if someone is trying to find a language from the full list. > But if someone (e.g. me) has already chosen 3 he will be using (e.g. English, > Armenian, Russian) I have 5 Chinese IMs (mainly for development) pinyin, wubi, Cangjie3, Quick3, and chewing. How could I distinguish these in "Flag-only" schema? Quite a lot of Chinese desktops installed multiple input methods for various reasons. It can be the preferences are differ among family members, or learning/testing some new input methods. Some IMs are capable of input multiple languages, what flags should they use? > it will be much more comfortable for him to see a flag and > not a greyish box with greyish white letters (us, am, ru) in it. > > Suren > That's what icons for. -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ From opensource at till.name Wed May 20 08:05:58 2009 From: opensource at till.name (Till Maas) Date: Wed, 20 May 2009 10:05:58 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <20090519210847.GC7385@nostromo.devel.redhat.com> References: <4A12B940.4050605@redhat.com> <200905192226.21739.opensource@till.name> <20090519210847.GC7385@nostromo.devel.redhat.com> Message-ID: <200905201006.08530.opensource@till.name> On Di Mai 19 2009, Bill Nottingham wrote: > Till Maas (opensource at till.name) said: > > > There is an easier option 3, which is no flags in Fedora period, > > > regardless of what spin. Far easier to implement. > > > > This is not easier for package maintainers who want to maintain a package > > in Fedora that contains flags, because additional work has to be done by > > the package maintainer. Adding some flag to the spec that indicates that > > the package contains political flags is a log easier. > > We carry patches all the time, and if people can't manage to apply patches And in other cases we strictly stick to upstream or push patches to upstream. > And really... it's not about being 'easier for package maintainers'. I'm > really tired of hearing that trope applied any time any sort of policy > is applied or suggested, whether it be: > > - not having flags in packages Not having flags in Fedora is not a technical improvement. Also does having flags in Fedora not stop its existence in its current way, which would happen if it violates US law. > - having actual update notes in bodhi (or even using bodhi at all) I guess there is no majority of packagers that says that actual update notes are bad. But still the process of creating these update notes could be improved to make it easier for packagers. E.g. changes are tracked in three disjunct places, the CVS changelog, the rpm changelog and the bodhi updates notes, which are also disjunct for each Fedora release of the same NVR update in different Fedora releases. Easy workflows will make mistakes less likely and therefore improve the quality of packages or Fedora. With making it easy for package maintainers I do not mean to remove all rules or policies, but to make it as easy as possible to follow to them. And about not using bodhi at all: When bodhi and koji were enrolled, they made package maintainance a lot harder, without these obstacles improving packages. E.g. buildlogs were hidden after a lot more links in koji (and the patch to fix this took several months to be applied) and there was no commandline client for bodhi. > - not pushing new libraries to every release immediately The problem are not new libraries per se, but the problems that they way produce, e.g. broken dependencies. Here it would also help to make it easier for package maintainers to detect these problems to avoid them. > To suggest as prima facie evidence that anything that makes things not > as easy for packagers is bad implies a view where the package maintainer > feels that his needs, his preferred workflow, or his convenience somehow > supercedes the needs of the project itself, or the needs of its users. This is not what I am suggesting. I suggest that if there is anything that can be changed to make Fedora or its packages better, it should be made as easy as possible for packagers to do this. And there were several suggestions to improve this for the flag policy here in this thread. - use a good name for the wiki page - mark packages that use flags in an easier way than to move the flag images to a -flag subpackage - use a yum plugin to make it easier for users to install or not install flags - make the wiki page visible in the wik, mention and link it in the right places Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mhlavink at redhat.com Wed May 20 08:07:30 2009 From: mhlavink at redhat.com (Michal Hlavinka) Date: Wed, 20 May 2009 10:07:30 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <1242805780.4500.29.camel@dhcp-0-207.bne.redhat.com> References: <4A127B5E.2080600@poolshark.org> <200905201207.31072.surenkarapetyan@gmail.com> <1242805780.4500.29.camel@dhcp-0-207.bne.redhat.com> Message-ID: <200905201007.30543.mhlavink@redhat.com> On Wednesday 20 May 2009 09:49:40 Ding-Yi Chen wrote: > ? ??2009-05-20 ? 12:07 +0500?Suren Karapetyan ??? > > > On Wednesday 20 May 2009 11:18:47 Ding-Yi Chen wrote: > > > ? ??2009-05-19 ? 16:55 +0100?Ewan Mac Mahon ??? > > > > > > > On Tue, May 19, 2009 at 10:59:07AM -0400, Colin Walters wrote: > > > > > The main thing we want to squash is things like flags in input > > > > > method selection which is very prominent in the UI, and flags in > > > > > bittorrent clients whose removal doesn't at all substantially > > > > > affect the operation of the software. > > > > > > > > That's a reasonable postion, but it's not quite the same as the > > > > current policy. > > > > > > Using flags in input methods along is not very informative. > > > For example, there are dozens (if not hundreds) of Chinese IMs. > > > How do you know which one should be associated with China flags? > > > Should it be pinyin? wubi? cangjie3? cangjie5? > > > > > > It's a good thing that almost all input methods already have their own > > > icons. > > > > That's true if someone is trying to find a language from the full list. > > But if someone (e.g. me) has already chosen 3 he will be using (e.g. > > English, Armenian, Russian) > > I have 5 Chinese IMs (mainly for development) pinyin, wubi, Cangjie3, > Quick3, and chewing. > How could I distinguish these in "Flag-only" schema? We all know flags : language is not 1:1 relation, but it can help in situations where you use more different languages (mostly english and native language). If flags make it difficult for someone to chose: 1) there is still text over the flag 2) you can use check box in configuration to turn flags off From pertusus at free.fr Wed May 20 08:12:18 2009 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 20 May 2009 10:12:18 +0200 Subject: In which country should Fedora be legal? In-Reply-To: <20090519203305.GA7385@nostromo.devel.redhat.com> References: <20090519195838.GC4558@free.fr> <20090519203305.GA7385@nostromo.devel.redhat.com> Message-ID: <20090520081218.GA2880@free.fr> On Tue, May 19, 2009 at 04:33:06PM -0400, Bill Nottingham wrote: > > Too late. We already remove content from various packages where necessary, > as stated earlier in the thread. I haven't read the whole thread, so I won't say more on that subject, although I am not aware of such packaging guidelines, but I follow Fedora less closely those days. > If you're seriously suggesting we set up legal counsel in all countries > before taking any action, that's not going to happen. Honestly, that > sounds like intentionally setting the bar ridiculously high just for > the purpopse of making sure no one could possibly do anything you might > disagree with. It is not what I wanted to say, but I agree that my phrasing sounded like that. I don't think that a full law review should be a prerequisite for doing an action for a country that Fedora wants to be legal in. But at least the countries should be chosen (I beleive by the Board) and the items that are spotted as illegal in each country should be documented and transformed into guidelines. As more items are discoverd, they should be added. But I think that we also should be proactive, that is, once the countries are chosen, ask on mailing lists (the Fedora Ambassadors are certainly people that should be contacted) what people know about laws that can be broken in the different chosen countries and then have people document it in a wiki. It can be vague at that phase, for example, for France there could be 'only some people are entitled to deliver medical advice', and, if there is enough concern and evidence, and, if possible advice from people really knowing the law, then turn it into guidelines. > Given that I'm fairly sure there are zero countries on the planet > where flags *cannot* be made illegal by some act of the populace > or government, that's a specious argument. What's the 'populace'? I am pretty sure that you can display flags offendant to France without being illegal in France (though I am not a lawyer). And in the US, it seems that there is no problem with the flags. -- Pat From pmatilai at laiskiainen.org Wed May 20 08:19:08 2009 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Wed, 20 May 2009 11:19:08 +0300 (EEST) Subject: rpm hashes In-Reply-To: <1242312742.21675.264.camel@atropine.boston.devel.redhat.com> References: <4A082E70.7030904@TheTroubleshooters.dk> <4A086703.1080906@amiga-hardware.com> <4A094EC4.9030506@TheTroubleshooters.dk> <1242125395.13505.449.camel@breeves.fab.redhat.com> <4A0988DC.8030103@freenet.de> <4A098F11.4080008@freenet.de> <1242225439.21675.81.camel@atropine.boston.devel.redhat.com> <1242312742.21675.264.camel@atropine.boston.devel.redhat.com> Message-ID: On Thu, 14 May 2009, Adam Jackson wrote: > On Thu, 2009-05-14 at 10:46 +0300, Panu Matilainen wrote: >> On Wed, 13 May 2009, Adam Jackson wrote: >>> It would have been really, _really_ nice if sha256 was merely another >>> hash that could be in the payload, instead of forcing you to pick one or >>> the other. For that matter, it would still be really really nice. >> >> Could it have been done that way? Yes, and if it were just per-package >> hash then certainly it would've been done that way. But remember this is >> per-file data, storing two (and when the day comes when sha256 is >> considered insufficient, three etc) hashes per file adds a non-trivial >> amount of header bloat. > > 32 bytes per file, plus another four for the header tag, unless I have > my math wildly wrong and/or I'm misremembering how hashes are stored. > My F11 machine has 430910 files over 2167 packages, so that extra > metadata comes to a massive 14.8M, compared to 11.6G of actual payload. > I have trouble getting worked up over this. People scream BLOAT! for lesser issues. It's data that gets transfered over the wire(less) over and over again, stored on disk in rpmdb (for the average desktop/server its completely irrelevant but not so for smaller devices) .. and the header data size is (artificially) limited to 16MB. Increasing that limit is possible and will sooner or later be necessary (people are occasionally hitting it already), but it's another incompatibility: all the widely deployed versions of rpm will think of a package with > 16MB header as corrupted, refusing to read it at all. > The point about having to store arbitrarily many hashes is certainly > fair, but a) sha512 is only twice as large as sha256, and 0.2% overhead > is still not a lot, b) that seems like a distro policy question. > >> Having the md5 hashes too would've been nice for backwards compatibility >> but actually using them for file conflict calculations would mean (in >> addition to the header bloat): >> - considerable increase in memory use > > I just don't buy this at all. The checksums are computed as part of the > stdio stream, and any competent implementation of a SHA-like algorithm > requires storage that's O(n) on the size of the hash, not on the size of > the file. So you'd need whatever the overhead is for the additional > metadata on the package you're currently inspecting, plus no more than a > page for the additional work area for the second hash. (I assume here > that fileconflict checks are done one package at a time, not by loading > all packages into memory and then checking them for conflicts, since the > latter would be unusable.) Well the assumption is wrong: during file conflict checking, all file-related data of non-installed packages is kept in memory, the full headers that are fed into transaction are discarded to - guess what - save memory, only the absolutely necessary file data is kept. For installed packages, rpm can and does fetch them one at a time from rpmdb as necessary, but for to-be-installed packages, rpm doesn't have the header so it can't go back to them as needed. > Oh, I guess there's also a case where you have to check for > fileconflicts among multiple packages in the same transaction laying > down the same files. Handwave, same problem really. > >> - falling back to md5 for conflict resolution would void the supposed >> extra security of the better hash > > So there's two cases, if rpm would let you carry both hashes. > > 1 is where the file on disk has both MD5 and SHA256 sums, and the new > package has only MD5. You already trust the package on disk, because > you already installed it; so compute the SHA256 of the file you're about > to lay down! Now you have both hashes, and you can compare them both. > The odds of defeating this are the odds of finding a payload that > collides for both MD5 and SHA256, which can't possibly be lower than the > odds of finding a collision for just SHA256 itself. > > 2 is where the file on disk has only MD5, and the package you're about > to install has both. If you have an rpm that only understands MD5, then > whatever, you just ignore the SHA256 hash. If you have an rpm that > understands both, then you have options. If you're being sensible, you > do the same thing as for case 1, which is to generate the SHA256 of the > disk file that's implicitly already trusted and compare both sums, and > presumably you only got to this point because you trust the GPG key that > signed the package you're about to install, so, good enough. (There's a > flaw here if the file on disk is modified. I could see arguments here > for any of rpmnew/rpmsave/fileconflict as the "right thing", which I > leave to someone more detail-oriented than I am.) > > If you're in FIPS mode - that is, if you're _not_ being sensible - then > you fail the transaction, which you ought rightly do anyway since oh no > the package on disk is only hashed with MD5, you're already in trouble. 3) You're installing two new packages with a common file where the other only has md5 hashes and the other has md5 + a stronger hash. Okay, assume a "FIPS mode" exists and it's mostly same as above, either be anal about it or not. But back to the existing implementation: sure it isn't optimal, sure it would be nice if it were backwards compatible all the way to RHEL 2.1 or whatever. It's a trade-off on several fronts, due to many different aspects: limitations of fundamental rpm architecture (inability to calculate the hash from payload on demand), efficiency (memory footprint, bandwidth etc), compatibility (see the point about header size, just stuffing more and more data there can make things even more incompatible)... and I'm a bit tired of people assuming no thought whatsoever was given to the way its done. - Panu - From nicolas.mailhot at laposte.net Wed May 20 08:19:42 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 20 May 2009 10:19:42 +0200 Subject: In which country should Fedora be legal? In-Reply-To: <20090520081218.GA2880@free.fr> References: <20090519195838.GC4558@free.fr> <20090519203305.GA7385@nostromo.devel.redhat.com> <20090520081218.GA2880@free.fr> Message-ID: <5308bb71c4dbc6955d6379d96041496d.squirrel@arekh.dyndns.org> Le Mer 20 mai 2009 10:12, Patrice Dumas a ?crit : > What's the 'populace'? I am pretty sure that you can display flags > offendant to France without being illegal in France (though I am not > a lawyer). And in the US, it seems that there is no problem with > the flags. Well, just try to display an abkhaz or palestinian flag in the US and you'll see if no one objects. -- Nicolas Mailhot From denis at poolshark.org Wed May 20 08:25:37 2009 From: denis at poolshark.org (Denis Leroy) Date: Wed, 20 May 2009 10:25:37 +0200 Subject: In which country should Fedora be legal? In-Reply-To: <5308bb71c4dbc6955d6379d96041496d.squirrel@arekh.dyndns.org> References: <20090519195838.GC4558@free.fr> <20090519203305.GA7385@nostromo.devel.redhat.com> <20090520081218.GA2880@free.fr> <5308bb71c4dbc6955d6379d96041496d.squirrel@arekh.dyndns.org> Message-ID: <4A13BE81.9080500@poolshark.org> On 05/20/2009 10:19 AM, Nicolas Mailhot wrote: > > Le Mer 20 mai 2009 10:12, Patrice Dumas a ??crit : > >> What's the 'populace'? I am pretty sure that you can display flags >> offendant to France without being illegal in France (though I am not >> a lawyer). And in the US, it seems that there is no problem with >> the flags. > > Well, just try to display an abkhaz or palestinian flag in the US and > you'll see if no one objects. So ? They can't sue. From pertusus at free.fr Wed May 20 08:27:30 2009 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 20 May 2009 10:27:30 +0200 Subject: In which country should Fedora be legal? In-Reply-To: <5308bb71c4dbc6955d6379d96041496d.squirrel@arekh.dyndns.org> References: <20090519195838.GC4558@free.fr> <20090519203305.GA7385@nostromo.devel.redhat.com> <20090520081218.GA2880@free.fr> <5308bb71c4dbc6955d6379d96041496d.squirrel@arekh.dyndns.org> Message-ID: <20090520082730.GB2880@free.fr> On Wed, May 20, 2009 at 10:19:42AM +0200, Nicolas Mailhot wrote: > > > Le Mer 20 mai 2009 10:12, Patrice Dumas a ?crit : > > > What's the 'populace'? I am pretty sure that you can display flags > > offendant to France without being illegal in France (though I am not > > a lawyer). And in the US, it seems that there is no problem with > > the flags. > > Well, just try to display an abkhaz or palestinian flag in the US and > you'll see if no one objects. Do we really care about that at the Fedora level? I think this is an upstream issue. Fedora packager can do patches and so on, but I don't think that it should be a guideline, nor a policy. -- Pat From ewan at macmahon.me.uk Wed May 20 08:32:57 2009 From: ewan at macmahon.me.uk (Ewan Mac Mahon) Date: Wed, 20 May 2009 09:32:57 +0100 Subject: Package Maintainers Flags policy In-Reply-To: <4A13AF44.6040406@poolshark.org> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> Message-ID: <20090520083257.GG32139@macmahon.me.uk> On Wed, May 20, 2009 at 09:20:36AM +0200, Denis Leroy wrote: > On 05/18/2009 05:09 PM, Kevin Fenzi wrote: >> In FESCo's 2009-03-28 meeting a policy on Flag usage for packages in >> Fedora was approved. >> >> Due to an oversight, this policy was not announced here. ;( >> >> Please see: >> >> https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy >> >> and direct any comments to FESCo in a ticket or via the devel list. > > Could we have the FESCO meeting IRC log please. > It would appear to be originally discussed here: http://bpepple.fedorapeople.org/fesco/FESCo-2009-03-20.html where some concerns (including FreeCiv, in fact) were raised, then it was approved here: http://bpepple.fedorapeople.org/fesco/FESCo-2009-03-27.html Ewan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Wed May 20 08:44:12 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 20 May 2009 10:44:12 +0200 Subject: In which country should Fedora be legal? In-Reply-To: <4A13BE81.9080500@poolshark.org> References: <20090519195838.GC4558@free.fr> <20090519203305.GA7385@nostromo.devel.redhat.com> <20090520081218.GA2880@free.fr> <5308bb71c4dbc6955d6379d96041496d.squirrel@arekh.dyndns.org> <4A13BE81.9080500@poolshark.org> Message-ID: <3c5cec27241dd9cacae968bdf0fa33d9.squirrel@arekh.dyndns.org> Le Mer 20 mai 2009 10:25, Denis Leroy a ?crit : > > On 05/20/2009 10:19 AM, Nicolas Mailhot wrote: >> >> Le Mer 20 mai 2009 10:12, Patrice Dumas a ??crit : >> >>> What's the 'populace'? I am pretty sure that you can display flags >>> offendant to France without being illegal in France (though I am >>> not >>> a lawyer). And in the US, it seems that there is no problem with >>> the flags. >> >> Well, just try to display an abkhaz or palestinian flag in the US >> and >> you'll see if no one objects. > > So ? They can't sue. They can blacklist us in the organisations they have an influence on. -- Nicolas Mailhot From pingou at pingoured.fr Wed May 20 08:54:38 2009 From: pingou at pingoured.fr (Pierre-Yves) Date: Wed, 20 May 2009 10:54:38 +0200 Subject: Blocker ? Message-ID: <1242809678.3275.1.camel@localhost.localdomain> Dear all, Could someone have a look at this bug? https://bugzilla.redhat.com/show_bug.cgi?id=501664 It looks to me quite similar to https://bugzilla.redhat.com/show_bug.cgi?id=498155 which is a blocker. Should the first one be consider as a blocker as well ? Thanks, Regards, Pierre From pertusus at free.fr Wed May 20 08:56:19 2009 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 20 May 2009 10:56:19 +0200 Subject: In which country should Fedora be legal? In-Reply-To: <3c5cec27241dd9cacae968bdf0fa33d9.squirrel@arekh.dyndns.org> References: <20090519195838.GC4558@free.fr> <20090519203305.GA7385@nostromo.devel.redhat.com> <20090520081218.GA2880@free.fr> <5308bb71c4dbc6955d6379d96041496d.squirrel@arekh.dyndns.org> <4A13BE81.9080500@poolshark.org> <3c5cec27241dd9cacae968bdf0fa33d9.squirrel@arekh.dyndns.org> Message-ID: <20090520085619.GC2880@free.fr> On Wed, May 20, 2009 at 10:44:12AM +0200, Nicolas Mailhot wrote: > > They can blacklist us in the organisations they have an influence on. And so what? -- Pat From nicolas.mailhot at laposte.net Wed May 20 09:02:31 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 20 May 2009 11:02:31 +0200 Subject: In which country should Fedora be legal? In-Reply-To: <20090520085619.GC2880@free.fr> References: <20090519195838.GC4558@free.fr> <20090519203305.GA7385@nostromo.devel.redhat.com> <20090520081218.GA2880@free.fr> <5308bb71c4dbc6955d6379d96041496d.squirrel@arekh.dyndns.org> <4A13BE81.9080500@poolshark.org> <3c5cec27241dd9cacae968bdf0fa33d9.squirrel@arekh.dyndns.org> <20090520085619.GC2880@free.fr> Message-ID: <78a7e7761d21dc09599427f6e2cf2444.squirrel@arekh.dyndns.org> Le Mer 20 mai 2009 10:56, Patrice Dumas a ?crit : > > On Wed, May 20, 2009 at 10:44:12AM +0200, Nicolas Mailhot wrote: >> >> They can blacklist us in the organisations they have an influence >> on. > > And so what? And so that's a stupid way to get blacklisted and lose contributors. -- Nicolas Mailhot From martin.langhoff at gmail.com Wed May 20 09:04:22 2009 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Wed, 20 May 2009 11:04:22 +0200 Subject: In which country should Fedora be legal? In-Reply-To: <20090520081218.GA2880@free.fr> References: <20090519195838.GC4558@free.fr> <20090519203305.GA7385@nostromo.devel.redhat.com> <20090520081218.GA2880@free.fr> Message-ID: <46a038f90905200204j22c06943oa2e33188bed6b0b8@mail.gmail.com> On Wed, May 20, 2009 at 10:12 AM, Patrice Dumas wrote: > that is, once the countries are chosen, ask on mailing lists (the Fedora > Ambassadors are certainly people that should be contacted) what people > know about laws that can be broken in the different chosen countries > and then have people document it in a wiki. It can be vague at that phase, Asking legal advise on (presumably technical) mailing lists? Or are there dedicated lawyers' lists you're thinking of? Sounds like a recipe for big flamefests, and self-important people stroking their self-steem by claiming you can't do that without royal decree. Legal bikeshedding that is sane to keep far far from any productive project. For an illustrative example, see the debian-legal archives :-) FWIW, it _is_ a UI bug to match flags with languages, but it's just that: a UI bug. Any nutter can go sue half the multi-lingual websites on the intarwebs. cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From denis at poolshark.org Wed May 20 09:05:45 2009 From: denis at poolshark.org (Denis Leroy) Date: Wed, 20 May 2009 11:05:45 +0200 Subject: In which country should Fedora be legal? In-Reply-To: <78a7e7761d21dc09599427f6e2cf2444.squirrel@arekh.dyndns.org> References: <20090519195838.GC4558@free.fr> <20090519203305.GA7385@nostromo.devel.redhat.com> <20090520081218.GA2880@free.fr> <5308bb71c4dbc6955d6379d96041496d.squirrel@arekh.dyndns.org> <4A13BE81.9080500@poolshark.org> <3c5cec27241dd9cacae968bdf0fa33d9.squirrel@arekh.dyndns.org> <20090520085619.GC2880@free.fr> <78a7e7761d21dc09599427f6e2cf2444.squirrel@arekh.dyndns.org> Message-ID: <4A13C7E9.8020802@poolshark.org> On 05/20/2009 11:02 AM, Nicolas Mailhot wrote: > > Le Mer 20 mai 2009 10:56, Patrice Dumas a ??crit : >> On Wed, May 20, 2009 at 10:44:12AM +0200, Nicolas Mailhot wrote: >>> They can blacklist us in the organisations they have an influence >>> on. >> And so what? > > And so that's a stupid way to get blacklisted and lose contributors. You may lose contributors either way From pertusus at free.fr Wed May 20 09:07:31 2009 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 20 May 2009 11:07:31 +0200 Subject: In which country should Fedora be legal? In-Reply-To: <78a7e7761d21dc09599427f6e2cf2444.squirrel@arekh.dyndns.org> References: <20090519195838.GC4558@free.fr> <20090519203305.GA7385@nostromo.devel.redhat.com> <20090520081218.GA2880@free.fr> <5308bb71c4dbc6955d6379d96041496d.squirrel@arekh.dyndns.org> <4A13BE81.9080500@poolshark.org> <3c5cec27241dd9cacae968bdf0fa33d9.squirrel@arekh.dyndns.org> <20090520085619.GC2880@free.fr> <78a7e7761d21dc09599427f6e2cf2444.squirrel@arekh.dyndns.org> Message-ID: <20090520090731.GD2880@free.fr> On Wed, May 20, 2009 at 11:02:31AM +0200, Nicolas Mailhot wrote: > > > Le Mer 20 mai 2009 10:56, Patrice Dumas a ?crit : > > > > On Wed, May 20, 2009 at 10:44:12AM +0200, Nicolas Mailhot wrote: > >> > >> They can blacklist us in the organisations they have an influence > >> on. > > > > And so what? > > And so that's a stupid way to get blacklisted and lose contributors. I don't think this should be a policy or a guideline. This should be left to the package maintainer, and, in my opinion, preferably upstream. Or the target of people that we want to please should explicitly listed by the Board, but I think it is a bad idea. -- Pat From denis at poolshark.org Wed May 20 09:08:09 2009 From: denis at poolshark.org (Denis Leroy) Date: Wed, 20 May 2009 11:08:09 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <20090520083257.GG32139@macmahon.me.uk> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> Message-ID: <4A13C879.4080002@poolshark.org> On 05/20/2009 10:32 AM, Ewan Mac Mahon wrote: > On Wed, May 20, 2009 at 09:20:36AM +0200, Denis Leroy wrote: >> On 05/18/2009 05:09 PM, Kevin Fenzi wrote: >>> In FESCo's 2009-03-28 meeting a policy on Flag usage for packages in >>> Fedora was approved. >>> >>> Due to an oversight, this policy was not announced here. ;( >>> >>> Please see: >>> >>> https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy >>> >>> and direct any comments to FESCo in a ticket or via the devel list. >> Could we have the FESCO meeting IRC log please. >> > It would appear to be originally discussed here: > http://bpepple.fedorapeople.org/fesco/FESCo-2009-03-20.html > where some concerns (including FreeCiv, in fact) were raised, then it > was approved here: > http://bpepple.fedorapeople.org/fesco/FESCo-2009-03-27.html Thanks Ewan, To summarize the votes: Dennis Gilmore: +1 David Woodhouse: +1 Bill Nottingham: +1 Jon Stanley: +1 Dan Horak: +1 Kevin Fenzi: +1 The logs include some pearls, like this one: nirik:ok. I'm unclear what problem this is solving off hand... jds2001: So reading this, it appears that this came from legal. I'm fine with this policy. nirik: ok, if it's legal I'm fine with it... Nobody is even questioning whether the policy is worth the effort, since people think this is mandated by Legal. No debate about the proposal consequences and impact over Fedora packagers. No clear definition about "there are some flags we can't ship to certain places" and what that actually means technically. What, you're going to block download requests coming from the PRC ? What about mirrors ? No debate about how the RPM split has zero impact over this anyways, and how the "substantively essential" clause bypasses this also. Not even an attempt to identify the list of affected packages. Of those 6, only 2 commented on this thread, and only 1 admitted this could have been communicated/handled better (and he gets my respect). I can only fear the other 4 do not read this mailing list. Frankly, this is the worst FeSCo we have had in years, and I'd like those people to resign immediately from FeSCo and early elections to take place. From pertusus at free.fr Wed May 20 09:09:07 2009 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 20 May 2009 11:09:07 +0200 Subject: In which country should Fedora be legal? In-Reply-To: <46a038f90905200204j22c06943oa2e33188bed6b0b8@mail.gmail.com> References: <20090519195838.GC4558@free.fr> <20090519203305.GA7385@nostromo.devel.redhat.com> <20090520081218.GA2880@free.fr> <46a038f90905200204j22c06943oa2e33188bed6b0b8@mail.gmail.com> Message-ID: <20090520090907.GE2880@free.fr> On Wed, May 20, 2009 at 11:04:22AM +0200, Martin Langhoff wrote: > On Wed, May 20, 2009 at 10:12 AM, Patrice Dumas wrote: > > that is, once the countries are chosen, ask on mailing lists (the Fedora > > Ambassadors are certainly people that should be contacted) what people > > know about laws that can be broken in the different chosen countries > > and then have people document it in a wiki. It can be vague at that phase, > > Asking legal advise on (presumably technical) mailing lists? Or are > there dedicated lawyers' lists you're thinking of? > > Sounds like a recipe for big flamefests, and self-important people > stroking their self-steem by claiming you can't do that without royal > decree. Legal bikeshedding that is sane to keep far far from any > productive project. You should read what I wrote until th eend, I address this concern. -- Pat From cweyl at alumni.drew.edu Wed May 20 09:10:09 2009 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Wed, 20 May 2009 02:10:09 -0700 Subject: In which country should Fedora be legal? In-Reply-To: <20090519203305.GA7385@nostromo.devel.redhat.com> References: <20090519195838.GC4558@free.fr> <20090519203305.GA7385@nostromo.devel.redhat.com> Message-ID: <7dd7ab490905200210t6403f6bfo1a4ef574b333f1ac@mail.gmail.com> On Tue, May 19, 2009 at 1:33 PM, Bill Nottingham wrote: > Patrice Dumas (pertusus at free.fr) said: > > I think that the flag policy is the wrong way to look at a real issue. > > First, it tries to solve 2 issues > > 1. being legal in some countries > > 2. avoid pissing people > > > > I think that the second issue should be brought upstream and not solved > > at the Fedora level. > > Too late. We already remove content from various packages where necessary, > as stated earlier in the thread. > True, but a touch disingenuous: as a project of a US company, we remove content where it is illegal for a company registered under the laws of the State of North Carolina or the United States to distribute (e.g. patent-violating *cough*mp3*cough* code, or, until recently, strong encryption). The "flags policy" is totally different; that is, it requires the removal of content that may or may not be illegal to distribute under the laws of some other jurisdiction somewhere in the world. Any jurisdiction. Anywhere. -Chris -- Chris Weyl Ex astris, scientia -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.mailhot at laposte.net Wed May 20 09:15:50 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 20 May 2009 11:15:50 +0200 Subject: In which country should Fedora be legal? In-Reply-To: <4A13C7E9.8020802@poolshark.org> References: <20090519195838.GC4558@free.fr> <20090519203305.GA7385@nostromo.devel.redhat.com> <20090520081218.GA2880@free.fr> <5308bb71c4dbc6955d6379d96041496d.squirrel@arekh.dyndns.org> <4A13BE81.9080500@poolshark.org> <3c5cec27241dd9cacae968bdf0fa33d9.squirrel@arekh.dyndns.org> <20090520085619.GC2880@free.fr> <78a7e7761d21dc09599427f6e2cf2444.squirrel@arekh.dyndns.org> <4A13C7E9.8020802@poolshark.org> Message-ID: <7af3c8f6a72b81ee2ad74d7fe3ac69c5.squirrel@arekh.dyndns.org> Le Mer 20 mai 2009 11:05, Denis Leroy a ?crit : > > On 05/20/2009 11:02 AM, Nicolas Mailhot wrote: >> >> Le Mer 20 mai 2009 10:56, Patrice Dumas a ??crit : >>> On Wed, May 20, 2009 at 10:44:12AM +0200, Nicolas Mailhot wrote: >>>> They can blacklist us in the organisations they have an influence >>>> on. >>> And so what? >> >> And so that's a stupid way to get blacklisted and lose contributors. > > You may lose contributors either way When you have the potential of country-wide bans, it's not the same level at all. -- Nicolas Mailhot From martin.langhoff at gmail.com Wed May 20 09:18:15 2009 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Wed, 20 May 2009 11:18:15 +0200 Subject: In which country should Fedora be legal? In-Reply-To: <20090520090907.GE2880@free.fr> References: <20090519195838.GC4558@free.fr> <20090519203305.GA7385@nostromo.devel.redhat.com> <20090520081218.GA2880@free.fr> <46a038f90905200204j22c06943oa2e33188bed6b0b8@mail.gmail.com> <20090520090907.GE2880@free.fr> Message-ID: <46a038f90905200218p47eb542csd3d35e1b1ff3b573@mail.gmail.com> On Wed, May 20, 2009 at 11:09 AM, Patrice Dumas wrote: > You should read what I wrote until th eend, I address this concern. Yes. You propose getting hold of "people who really know the law" after stoking the flamefest. How about skipping the flames part? :-) cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From denis at poolshark.org Wed May 20 09:41:23 2009 From: denis at poolshark.org (Denis Leroy) Date: Wed, 20 May 2009 11:41:23 +0200 Subject: In which country should Fedora be legal? In-Reply-To: <7af3c8f6a72b81ee2ad74d7fe3ac69c5.squirrel@arekh.dyndns.org> References: <20090519195838.GC4558@free.fr> <20090519203305.GA7385@nostromo.devel.redhat.com> <20090520081218.GA2880@free.fr> <5308bb71c4dbc6955d6379d96041496d.squirrel@arekh.dyndns.org> <4A13BE81.9080500@poolshark.org> <3c5cec27241dd9cacae968bdf0fa33d9.squirrel@arekh.dyndns.org> <20090520085619.GC2880@free.fr> <78a7e7761d21dc09599427f6e2cf2444.squirrel@arekh.dyndns.org> <4A13C7E9.8020802@poolshark.org> <7af3c8f6a72b81ee2ad74d7fe3ac69c5.squirrel@arekh.dyndns.org> Message-ID: <4A13D043.8050204@poolshark.org> On 05/20/2009 11:15 AM, Nicolas Mailhot wrote: > When you have the potential of country-wide bans, it's not the same > level at all. Nicolas, you're mixing two different things. Patrice nailed it on the head in his top post. Your "certain flags in the US" is case 2, while a country-wide ban is case 1. Besides, this whole debate goes so much outside of Fedora' scope that it's almost pointless. This is a FOSS-wide debate, and mostly an upstream debate at that. From pertusus at free.fr Wed May 20 09:50:42 2009 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 20 May 2009 11:50:42 +0200 Subject: In which country should Fedora be legal? In-Reply-To: <46a038f90905200218p47eb542csd3d35e1b1ff3b573@mail.gmail.com> References: <20090519195838.GC4558@free.fr> <20090519203305.GA7385@nostromo.devel.redhat.com> <20090520081218.GA2880@free.fr> <46a038f90905200204j22c06943oa2e33188bed6b0b8@mail.gmail.com> <20090520090907.GE2880@free.fr> <46a038f90905200218p47eb542csd3d35e1b1ff3b573@mail.gmail.com> Message-ID: <20090520095042.GF2880@free.fr> On Wed, May 20, 2009 at 11:18:15AM +0200, Martin Langhoff wrote: > On Wed, May 20, 2009 at 11:09 AM, Patrice Dumas wrote: > > You should read what I wrote until th eend, I address this concern. > > Yes. You propose getting hold of "people who really know the law" > after stoking the flamefest. How about skipping the flames part? :-) As Bill said, this rises the bar too high. I think that a flexible approach like I propose is a better middle ground than one policy (for the flags) coming out of nowhere, and a detaile dexamination of all country laws. Set up target, gather information, including from people who are not specialists, and refine information when possible. -- Pat From markmc at redhat.com Wed May 20 10:10:20 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 20 May 2009 11:10:20 +0100 Subject: Blocker ? In-Reply-To: <1242809678.3275.1.camel@localhost.localdomain> References: <1242809678.3275.1.camel@localhost.localdomain> Message-ID: <1242814220.19243.5.camel@blaa> Hi Pierre, Friendly suggestion - quote the bug summaries along with the URL so people have some idea without clicking whether the bug is interesting to them. On Wed, 2009-05-20 at 10:54 +0200, Pierre-Yves wrote: > Dear all, > > Could someone have a look at this bug? > https://bugzilla.redhat.com/show_bug.cgi?id=501664 Can not find root system > It looks to me quite similar to > https://bugzilla.redhat.com/show_bug.cgi?id=498155 LiveUSB boot failure: Unable to find root filesystem > which is a blocker. > > Should the first one be consider as a blocker as well ? Thanks, Mark. From mschwendt at gmail.com Wed May 20 10:37:15 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 20 May 2009 12:37:15 +0200 Subject: rpms/nqc/EL-5 .cvsignore,1.3,1.4 nqc.spec,1.7,1.8 sources,1.3,1.4 In-Reply-To: <20090514203051.DB67E70123@cvs1.fedora.phx.redhat.com> References: <20090514203051.DB67E70123@cvs1.fedora.phx.redhat.com> Message-ID: <20090520123715.78077414@faldor.intranet> On Thu, 14 May 2009 20:30:51 +0000 (UTC), Jr. wrote: > Author: rvinyard > > Update of /cvs/pkgs/rpms/nqc/EL-5 > +%files doc-nl > +%defattr(-,root,root,-) > +%doc nqc-tutorial-nl.doc > + > +%files doc-de > +%defattr(-,root,root,-) > +%doc nqc-tutorial-de.doc You could mark these files with %lang, such as %lang(de). From jwboyer at gmail.com Wed May 20 11:25:26 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 20 May 2009 07:25:26 -0400 Subject: Package Maintainers Flags policy In-Reply-To: <4A13AF44.6040406@poolshark.org> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> Message-ID: <20090520112526.GA345@hansolo.jdub.homelinux.org> On Wed, May 20, 2009 at 09:20:36AM +0200, Denis Leroy wrote: > On 05/18/2009 05:09 PM, Kevin Fenzi wrote: >> In FESCo's 2009-03-28 meeting a policy on Flag usage for packages in >> Fedora was approved. >> >> Due to an oversight, this policy was not announced here. ;( >> >> Please see: >> >> https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy >> >> and direct any comments to FESCo in a ticket or via the devel list. > > Could we have the FESCO meeting IRC log please. http://bpepple.fedorapeople.org/fesco/FESCo-2009-03-27.html josh From jwboyer at gmail.com Wed May 20 11:27:52 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 20 May 2009 07:27:52 -0400 Subject: Package Maintainers Flags policy In-Reply-To: <4A13C879.4080002@poolshark.org> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> Message-ID: <20090520112752.GB345@hansolo.jdub.homelinux.org> On Wed, May 20, 2009 at 11:08:09AM +0200, Denis Leroy wrote: > To summarize the votes: > > Dennis Gilmore: +1 > David Woodhouse: +1 > Bill Nottingham: +1 > Jon Stanley: +1 > Dan Horak: +1 > Kevin Fenzi: +1 > > The logs include some pearls, like this one: > > nirik:ok. I'm unclear what problem this is solving off hand... > jds2001: So reading this, it appears that this came from legal. I'm fine > with this policy. > nirik: ok, if it's legal I'm fine with it... > > Nobody is even questioning whether the policy is worth the effort, since > people think this is mandated by Legal. No debate about the proposal > consequences and impact over Fedora packagers. No clear definition about > "there are some flags we can't ship to certain places" and what that > actually means technically. What, you're going to block download > requests coming from the PRC ? What about mirrors ? No debate about how > the RPM split has zero impact over this anyways, and how the > "substantively essential" clause bypasses this also. Not even an attempt > to identify the list of affected packages. > > Of those 6, only 2 commented on this thread, and only 1 admitted this > could have been communicated/handled better (and he gets my respect). I > can only fear the other 4 do not read this mailing list. > > Frankly, this is the worst FeSCo we have had in years, and I'd like > those people to resign immediately from FeSCo and early elections to > take place. I suggest you run for FESCo instead. While you may like for those 6 people to resign, I doubt they will. The election happens rather soon, so you have every opportunity to become elected yourself. josh From jarod at redhat.com Wed May 20 13:07:39 2009 From: jarod at redhat.com (Jarod Wilson) Date: Wed, 20 May 2009 09:07:39 -0400 Subject: latest f11 kmail update eating email? Message-ID: <4A14009B.7060505@redhat.com> Uhm... So yeah. I installed the latest kmail update in the f11 tree (via kdepim-4.2.3-1.fc11), and one by one, emails in my inbox started disappearing. Opened up Thunderbird instead, and the emails are definitely gone. Uh. WTF?!? -- Jarod Wilson jarod at redhat.com From rawhide at fedoraproject.org Wed May 20 13:18:12 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Wed, 20 May 2009 13:18:12 +0000 (UTC) Subject: rawhide report: 20090520 changes Message-ID: <20090520131812.1F0001B8003@releng2.fedora.phx.redhat.com> Compose started at Wed May 20 06:15:04 UTC 2009 Updated Packages: anaconda-11.5.0.54-1.fc11 ------------------------- * Tue May 19 2009 Chris Lumens - 11.5.0.54-1 - We are not guaranteed to have a partedDisk in the udev code (#501556, - The location of the options wiki page has changed. (clumens) - Disable BETANAG. (clumens) - Install a en_US.UTF-8 locale in the first stage image. (notting) - Reset font when changing language. (notting) - Set locale to en_US.UTF-8 when initializing the console. (notting) libtirpc-0.1.10-7.fc11 ---------------------- * Tue May 19 2009 Tom "spot" Callaway 0.1.10-7 - Replace the Sun RPC license with the BSD license, with the explicit permission of Sun Microsystems mkinitrd-6.0.85-1.fc11 ---------------------- * Tue May 19 2009 Peter Jones - 6.0.85-1 - Handle F9's crypttab format as well (#501198) nfs-utils-1.1.5-6.fc11 ---------------------- * Tue May 19 2009 Tom "spot" Callaway 1.1.5-6 - Replace the Sun RPC license with the BSD license, with the explicit permission of Sun Microsystems * Mon Apr 20 2009 Steve Dickson 1.1.5-5 - Update nfsstat with --sleep and --list options - Fixed umount from using non-privilege ports (bz 492598) nfs-utils-lib-1.1.4-6.fc11 -------------------------- * Tue May 19 2009 Tom "spot" Callaway 1.1.4-6 - Replace the Sun RPC license with the BSD license, with the explicit permission of Sun Microsystems rhythmbox-0.12.1-3.fc11 ----------------------- * Thu May 07 2009 Bastien Nocera 0.12.1-3 - Add patch for sound-juicer changes rpcbind-0.1.7-3.fc11 -------------------- * Tue May 19 2009 Tom "spot" Callaway - 0.1.7-3 - Replace the Sun RPC license with the BSD license, with the explicit permission of Sun Microsystems Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 7 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From jarod at redhat.com Wed May 20 13:37:06 2009 From: jarod at redhat.com (Jarod Wilson) Date: Wed, 20 May 2009 09:37:06 -0400 Subject: latest f11 kmail update eating email? In-Reply-To: <4A14009B.7060505@redhat.com> References: <4A14009B.7060505@redhat.com> Message-ID: <4A140782.70707@redhat.com> On 05/20/2009 09:07 AM, Jarod Wilson wrote: > Uhm... So yeah. I installed the latest kmail update in the f11 tree (via > kdepim-4.2.3-1.fc11), and one by one, emails in my inbox started > disappearing. Opened up Thunderbird instead, and the emails are > definitely gone. Uh. WTF?!? Some additional details: - I was running the prior version w/o a problem. I quit it prior to yum actually updating kdepim. After the update was done, I relaunched kmail. (i.e., not a case of leaving the old version running during the upgrade, which could theoretically maybe do something bad -- see firefox). - There's one email account configured, using imap over ssl. - I'm makin' copies of stuff so I can relaunch kmail and watch carefully while it eats... -- Jarod Wilson jarod at redhat.com From jarod at redhat.com Wed May 20 13:47:10 2009 From: jarod at redhat.com (Jarod Wilson) Date: Wed, 20 May 2009 09:47:10 -0400 Subject: latest f11 kmail update eating email? In-Reply-To: <4A140782.70707@redhat.com> References: <4A14009B.7060505@redhat.com> <4A140782.70707@redhat.com> Message-ID: <4A1409DE.5050401@redhat.com> On 05/20/2009 09:37 AM, Jarod Wilson wrote: > On 05/20/2009 09:07 AM, Jarod Wilson wrote: >> Uhm... So yeah. I installed the latest kmail update in the f11 tree (via >> kdepim-4.2.3-1.fc11), and one by one, emails in my inbox started >> disappearing. Opened up Thunderbird instead, and the emails are >> definitely gone. Uh. WTF?!? > > Some additional details: > > - I was running the prior version w/o a problem. I quit it prior to yum > actually updating kdepim. After the update was done, I relaunched kmail. > (i.e., not a case of leaving the old version running during the upgrade, > which could theoretically maybe do something bad -- see firefox). > > - There's one email account configured, using imap over ssl. > > - I'm makin' copies of stuff so I can relaunch kmail and watch carefully > while it eats... Yep, still happening, got some interesting console output... Bugzilla'd. https://bugzilla.redhat.com/show_bug.cgi?id=501721 -- Jarod Wilson jarod at redhat.com From notting at redhat.com Wed May 20 13:57:17 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 20 May 2009 09:57:17 -0400 Subject: Package Maintainers Flags policy In-Reply-To: <4A13C879.4080002@poolshark.org> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> Message-ID: <20090520135717.GA13882@nostromo.devel.redhat.com> Denis Leroy (denis at poolshark.org) said: > To summarize the votes: > > Dennis Gilmore: +1 > David Woodhouse: +1 > Bill Nottingham: +1 > Jon Stanley: +1 > Dan Horak: +1 > Kevin Fenzi: +1 ... > Nobody is even questioning whether the policy is worth the effort, since > people think this is mandated by Legal. Well, if you want a longer version of my opinion... There are places where the use of certain flags is verboten; in this case, the use & distribution of Fedora would be verboten if it prominently used them. One of our Fedora goals (stated very clearly, see Overview on the wiki) is to be usable and redistributable *by ALL*. Now, we don't always succeed here; take, for example, countries where we're unable to distribute to because of US restrictions (such as Iran, Cuba, etc.) However, we should certainly strive towards this goal. By making this change, we allow people in China, or similarly restricted locales, to be able to use & contribute to Fedora in a way that's safer and more legal for them. (As to the question whether it's enough for there; given the preexisting example of something like Red Hat Linux in that locale that had a 'no flags' policy, by first glance it is enough.) Is it catering to paranoia of a particular government? Yes. (So are the T-6 restriction, FWIW.) Is it annoying? Yes. However, changing the scope of various governments is fairly out of scope of Fedora; let's stick to what we can change. It comes down to a tradeoff; it's essentially a pragmatic decision. Are the gains by making it acceptable in China (or similar locales) worth the effort in changing/removing some small number of packages? Given the benefits in opening up the community to 1/6 of the planet's population, and the fact that in most all cases, the flags aren't a crucial portion of the functionality *of the project* that is exposed to users, I think so. Other restrictions in other locales can be handled as need be. For example, the costs in removing encryption to satisfy some theoretical edict from a non-US government *wouldn't* be worth the trade-off, as that's a core functionality that affects pretty much all of our users. If you want me to resign over making that choice, I'm afraid you'll be disappointed. But you're certainly welcome to run for a seat and vote in the next election. Bill From notting at redhat.com Wed May 20 14:04:20 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 20 May 2009 10:04:20 -0400 Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <4A11984F.2060605@poolshark.org> <20090518173651.GA6318@nostromo.devel.redhat.com> <4A127B5E.2080600@poolshark.org> <1242729579.30251.156.camel@macbook.infradead.org> <29fee02b0905190526i593c1c97x840ba64d38455902@mail.gmail.com> <1242737529.30251.182.camel@macbook.infradead.org> <4A12B130.5040107@poolshark.org> Message-ID: <20090520140420.GB13882@nostromo.devel.redhat.com> Kevin Kofler (kevin.kofler at chello.at) said: > > There isn't a 1:1 mapping between flags and languages, and arguably an > > educational suite should be avoiding encouraging that confusion in > > children. > > And how do you expect a child below reading age to read what you're writing > on the screen? Because that's the target userbase of GCompris. To give a counter example - are the millions of children in the United States that speak Spanish at home really going to know to look for a flag of *Spain* if they're already too young to know the word Spanish (or Espa?ol, which the UI doesn't even offer)? For the overwhelming majority of them, they're not going to identify with Spain as a nation. It's just not a good UI to use flags for this. Bill From maxamillion at gmail.com Wed May 20 14:02:41 2009 From: maxamillion at gmail.com (Adam Miller) Date: Wed, 20 May 2009 09:02:41 -0500 Subject: Fedora and the moblin2 fork In-Reply-To: <5256d0b0905192351q2b83333fgcb738c7f29334686@mail.gmail.com> References: <5256d0b0905191547w1d5725c3i2cd4338723cecc64@mail.gmail.com> <20090519221238.608afa5d@infradead.org> <5256d0b0905192351q2b83333fgcb738c7f29334686@mail.gmail.com> Message-ID: On Wed, May 20, 2009 at 1:51 AM, Peter Robinson wrote: > Where did you send the query? Its been a little slower than I would > have liked to getting it moving as shiny bits in the olpc corner sort > of distracted me. > > Peter > I know this is the worst possible answer, but I honestly don't remember. It has been months since I stumbled across the wiki page for the project which is when I started trying to dig around for information. But I'm glad to know that the SIG is still active and I would be very happy to help as much as I possibly can. I have an Acer Aspire One that I can help test stuff on and I'm also planning on getting a Dell Mini as soon as I have the spare money. -Adam -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From notting at redhat.com Wed May 20 14:05:38 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 20 May 2009 10:05:38 -0400 Subject: Package Maintainers Flags policy In-Reply-To: References: <4A12B940.4050605@redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <200905192226.21739.opensource@till.name> <20090519210847.GC7385@nostromo.devel.redhat.com> Message-ID: <20090520140538.GC13882@nostromo.devel.redhat.com> Kevin Kofler (kevin.kofler at chello.at) said: > Bill Nottingham wrote: > > (really, this will affect only a small number of packagers, anyway.) > > I think you (and others) are significantly underestimating the number of > affected packages. The previous unwritten policy (from RHL times) not to > ship any flags wasn't enforced for community-maintained packages, several > packages include flags and some (e.g. freeciv) need them for proper > operation. All you've mentioned are the same packages I already know about: - kdebase (or some similar package in KDE) - gcompris - freeciv If there's really a lot of packages, I'd like actual data as to what they are; vague descriptions of 'several' doesn't really help frame the discussion of the amount of work. Bill From rvinyard at cs.nmsu.edu Wed May 20 14:11:13 2009 From: rvinyard at cs.nmsu.edu (Rick L. Vinyard, Jr.) Date: Wed, 20 May 2009 08:11:13 -0600 (MDT) Subject: rpms/nqc/EL-5 .cvsignore, 1.3, 1.4 nqc.spec, 1.7, 1.8 sources, 1.3, 1.4 In-Reply-To: <20090520123715.78077414@faldor.intranet> References: <20090514203051.DB67E70123@cvs1.fedora.phx.redhat.com> <20090520123715.78077414@faldor.intranet> Message-ID: <59035.155.148.81.31.1242828673.squirrel@intranet.cs.nmsu.edu> Michael Schwendt wrote: > On Thu, 14 May 2009 20:30:51 +0000 (UTC), Jr. wrote: > >> Author: rvinyard >> >> Update of /cvs/pkgs/rpms/nqc/EL-5 > >> +%files doc-nl >> +%defattr(-,root,root,-) >> +%doc nqc-tutorial-nl.doc >> + >> +%files doc-de >> +%defattr(-,root,root,-) >> +%doc nqc-tutorial-de.doc > > You could mark these files with %lang, such as %lang(de). > I googled it and did a search on the Fedora project wiki and didn't find any more info on where it goes. Does the %lang directive go anywhere after the %files directive like this? %files doc-de %lang(de) %defattr(-,root,root,-) %doc nqc-tutorial-de.doc Also, do you know if the %lang two-letter code parameters are just the ISO-639 codes? Thanks, Rick From bochecha at fedoraproject.org Wed May 20 14:18:14 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Wed, 20 May 2009 16:18:14 +0200 Subject: Fedora and the moblin2 fork In-Reply-To: References: <5256d0b0905191547w1d5725c3i2cd4338723cecc64@mail.gmail.com> <20090519221238.608afa5d@infradead.org> <5256d0b0905192351q2b83333fgcb738c7f29334686@mail.gmail.com> Message-ID: <2d319b780905200718h35bc9c1bsb95c78b29a2fd365@mail.gmail.com> > I'm also planning on > getting a Dell Mini as soon as I have the > spare money. Which might not be the best idea ever: http://www.hadess.net/2009/05/dell-mini-10-gah.html ---------- Mathieu Bridon (bochecha) From maxamillion at gmail.com Wed May 20 14:21:42 2009 From: maxamillion at gmail.com (Adam Miller) Date: Wed, 20 May 2009 09:21:42 -0500 Subject: Fedora and the moblin2 fork In-Reply-To: <2d319b780905200718h35bc9c1bsb95c78b29a2fd365@mail.gmail.com> References: <5256d0b0905191547w1d5725c3i2cd4338723cecc64@mail.gmail.com> <20090519221238.608afa5d@infradead.org> <5256d0b0905192351q2b83333fgcb738c7f29334686@mail.gmail.com> <2d319b780905200718h35bc9c1bsb95c78b29a2fd365@mail.gmail.com> Message-ID: On Wed, May 20, 2009 at 9:18 AM, Mathieu Bridon (bochecha) wrote: >> I'm also planning on >> getting a Dell Mini as soon as I have the >> spare money. > > Which might not be the best idea ever: > http://www.hadess.net/2009/05/dell-mini-10-gah.html > Oh wow, good to know. Any similar reports on the Mini 12? -Adam -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From mschwendt at gmail.com Wed May 20 14:32:06 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 20 May 2009 16:32:06 +0200 Subject: rpms/nqc/EL-5 .cvsignore, 1.3, 1.4 nqc.spec, 1.7, 1.8 sources, 1.3, 1.4 In-Reply-To: <59035.155.148.81.31.1242828673.squirrel@intranet.cs.nmsu.edu> References: <20090514203051.DB67E70123@cvs1.fedora.phx.redhat.com> <20090520123715.78077414@faldor.intranet> <59035.155.148.81.31.1242828673.squirrel@intranet.cs.nmsu.edu> Message-ID: <20090520163206.33e1d1c3@faldor.intranet> On Wed, 20 May 2009 08:11:13 -0600 (MDT), Jr. wrote: > >> +%files doc-de > >> +%defattr(-,root,root,-) > >> +%doc nqc-tutorial-de.doc > > > > You could mark these files with %lang, such as %lang(de). > > > > I googled it and did a search on the Fedora project wiki and didn't find > any more info on where it goes. Does the %lang directive go anywhere after > the %files directive like this? > > %files doc-de > %lang(de) > %defattr(-,root,root,-) > %doc nqc-tutorial-de.doc %doc %lang(de) nqc-tutorial-de.doc or: %lang(de) %doc nqc-tutorial-de.doc > Also, do you know if the %lang two-letter code parameters are just the > ISO-639 codes? Yes, ISO 639-1, two letters. From mike at cchtml.com Wed May 20 14:34:39 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Wed, 20 May 2009 09:34:39 -0500 Subject: Package Maintainers Flags policy In-Reply-To: <20090520140538.GC13882@nostromo.devel.redhat.com> References: <4A12B940.4050605@redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <200905192226.21739.opensource@till.name> <20090519210847.GC7385@nostromo.devel.redhat.com> <20090520140538.GC13882@nostromo.devel.redhat.com> Message-ID: <4A1414FF.7050500@cchtml.com> -------- Original Message -------- Subject: Package Maintainers Flags policy From: Bill Nottingham To: Development discussions related to Fedora Date: 05/20/2009 09:05 AM > > All you've mentioned are the same packages I already know about: > > - kdebase (or some similar package in KDE) > - gcompris > - freeciv > > If there's really a lot of packages, I'd like actual data as to what they > are; vague descriptions of 'several' doesn't really help frame the > discussion of the amount of work. > Ah, so a (previously unwritten) policy was written in stone without any real data to back it up and with zero discussion on a public forum. Sounds like politics to me. I guess my dreams of running for FESCo are crushed because I would never be able to do something like this. From pbrobinson at gmail.com Wed May 20 14:37:19 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 20 May 2009 15:37:19 +0100 Subject: Fedora and the moblin2 fork In-Reply-To: References: <5256d0b0905191547w1d5725c3i2cd4338723cecc64@mail.gmail.com> <20090519221238.608afa5d@infradead.org> <5256d0b0905192351q2b83333fgcb738c7f29334686@mail.gmail.com> <2d319b780905200718h35bc9c1bsb95c78b29a2fd365@mail.gmail.com> Message-ID: <5256d0b0905200737t274c4641sf37c04847eeb7ceb@mail.gmail.com> > wrote: >>> I'm also planning on >>> getting a Dell Mini as soon as I have the >>> spare money. >> >> Which might not be the best idea ever: >> http://www.hadess.net/2009/05/dell-mini-10-gah.html >> > > Oh wow, good to know. Any similar reports on the Mini 12? There's a number of different Dell Mini's. Even the mini 10 vs the mini 10v are different. I would steer clear of anything with the GMA500 GPU as there's no official X support atm on anything but ubuntu, although there are some Fedora people poking at it. Peter From bnocera at redhat.com Wed May 20 14:41:21 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Wed, 20 May 2009 15:41:21 +0100 Subject: Fedora and the moblin2 fork In-Reply-To: References: <5256d0b0905191547w1d5725c3i2cd4338723cecc64@mail.gmail.com> <20090519221238.608afa5d@infradead.org> <5256d0b0905192351q2b83333fgcb738c7f29334686@mail.gmail.com> <2d319b780905200718h35bc9c1bsb95c78b29a2fd365@mail.gmail.com> Message-ID: <1242830481.9894.266.camel@cookie.hadess.net> On Wed, 2009-05-20 at 09:21 -0500, Adam Miller wrote: > On Wed, May 20, 2009 at 9:18 AM, Mathieu Bridon (bochecha) > wrote: > >> I'm also planning on > >> getting a Dell Mini as soon as I have the > >> spare money. > > > > Which might not be the best idea ever: > > http://www.hadess.net/2009/05/dell-mini-10-gah.html > > > > Oh wow, good to know. Any similar reports on the Mini 12? Get the mini 9, if you like that form factor. The mini 10, and 12 are out of bounds for as long as intel doesn't release decent poulsbo drivers. There are certainly other netbooks available... From a.badger at gmail.com Wed May 20 14:49:35 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 20 May 2009 07:49:35 -0700 Subject: Package Maintainers Flags policy In-Reply-To: <20090520135717.GA13882@nostromo.devel.redhat.com> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520135717.GA13882@nostromo.devel.redhat.com> Message-ID: <4A14187F.30207@gmail.com> On 05/20/2009 06:57 AM, Bill Nottingham wrote: >(As to the question whether it's enough for there; > given the preexisting example of something like Red Hat Linux in that > locale that had a 'no flags' policy, by first glance it is enough.) > Part of the problem here is that the current policy is not a "no flags" policy. Flags are allowed into the distribution and they're allowed into the distribution in packages unmarked as containing flags. From the comments given in the first FESCo ticket, it appears that the ability to make exceptions like that was a part of the reason that some FESCo members voted for the policy. In the original ticket comments, I asked that more information about what problems were trying to be solved be put into the policy but that wasn't done. There's no mention in the policy about the goal of not shipping flags. Without an understanding of the goal, there's no way to see that the current policy makes more work for packagers without actually letting us ship to flag banning countries. -Toshio From maxamillion at gmail.com Wed May 20 14:50:37 2009 From: maxamillion at gmail.com (Adam Miller) Date: Wed, 20 May 2009 09:50:37 -0500 Subject: Fedora and the moblin2 fork In-Reply-To: <1242830481.9894.266.camel@cookie.hadess.net> References: <5256d0b0905191547w1d5725c3i2cd4338723cecc64@mail.gmail.com> <20090519221238.608afa5d@infradead.org> <5256d0b0905192351q2b83333fgcb738c7f29334686@mail.gmail.com> <2d319b780905200718h35bc9c1bsb95c78b29a2fd365@mail.gmail.com> <1242830481.9894.266.camel@cookie.hadess.net> Message-ID: > Get the mini 9, if you like that form factor. The mini 10, and 12 are > out of bounds for as long as intel doesn't release decent poulsbo > drivers. > > There are certainly other netbooks available... > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > The HP Mini 1000 is also on my list of considerations. I plan to do plenty of research before making a purchase ... I just don't have the funding yet so I haven't spent a lot of time looking into them. Thanks for the info though, good to know! :) -Adam -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From pbrobinson at gmail.com Wed May 20 14:52:27 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 20 May 2009 15:52:27 +0100 Subject: Fedora and the moblin2 fork In-Reply-To: <1242830481.9894.266.camel@cookie.hadess.net> References: <5256d0b0905191547w1d5725c3i2cd4338723cecc64@mail.gmail.com> <20090519221238.608afa5d@infradead.org> <5256d0b0905192351q2b83333fgcb738c7f29334686@mail.gmail.com> <2d319b780905200718h35bc9c1bsb95c78b29a2fd365@mail.gmail.com> <1242830481.9894.266.camel@cookie.hadess.net> Message-ID: <5256d0b0905200752ye7b1b19yc726fbf8cb37cb7f@mail.gmail.com> >> wrote: >> >> I'm also planning on >> >> getting a Dell Mini as soon as I have the >> >> spare money. >> > >> > Which might not be the best idea ever: >> > http://www.hadess.net/2009/05/dell-mini-10-gah.html >> > >> >> Oh wow, good to know. Any similar reports on the Mini 12? > > Get the mini 9, if you like that form factor. The mini 10, and 12 are > out of bounds for as long as intel doesn't release decent poulsbo > drivers. I think the newly introduced 10v has a 945 gpu. Peter From bruno at wolff.to Wed May 20 14:59:56 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 20 May 2009 09:59:56 -0500 Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <1242667087.25634.1927.camel@cookie.hadess.net> <200905182239.04065.bjorn@xn--rombobjrn-67a.se> <4ccd9dcb0905190600t30325bf1j56b7f53c5744900c@mail.gmail.com> Message-ID: <20090520145956.GA28465@wolff.to> On Tue, May 19, 2009 at 19:30:07 -0700, Christopher Stone wrote: > > I would argue that it depends on the law. I would also argue that > banning something like a flag means that you fear what that flag > represents. The Chinese have to censor a lot of information because > they fear it. The Communist party fears losing its power, that is why > they censor and ban certain information. It's not like noncommunist countries don't have the same issue. In the US the Democrat and Republican parties conspire to make it difficult for any third parties to take hold (which would displace one of the two of them if they did). The currently in power party in an area will often try to affect changes to how voting is done in order to help that party. I suspect that the ruling groups trying to enact policies that keeps them as ruling groups is something that happens almost everywhere. From rjones at redhat.com Wed May 20 15:03:01 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 20 May 2009 16:03:01 +0100 Subject: Heads up: OCaml 3.11.1 in devel, might break things ... Message-ID: <20090520150301.GA23232@amd.home.annexia.org> OCaml 3.11.1 (RC 0) was released yesterday: http://caml.inria.fr/pub/ml-archives/caml-list/2009/05/7eebae1c2938b64ae84ca1d9284fba99.en.html Upstream have asked us to test this release candidate, so over the long weekend I'm going to try to build it for the 'devel' branch (are we calling this 'Rawhide' yet?) This might break lots of dependencies (or maybe won't - I don't actually know). Which I will try to fix up by rebuilding the dependent packages afterwards. There are at least 74 dependent packages that might be affected. A slightly out of date list is here: http://cocan.org/fedora#Package_status Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 75 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From jonathan.underwood at gmail.com Wed May 20 15:08:27 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 20 May 2009 16:08:27 +0100 Subject: Fedora and the moblin2 fork In-Reply-To: References: <5256d0b0905191547w1d5725c3i2cd4338723cecc64@mail.gmail.com> <20090519221238.608afa5d@infradead.org> <5256d0b0905192351q2b83333fgcb738c7f29334686@mail.gmail.com> <2d319b780905200718h35bc9c1bsb95c78b29a2fd365@mail.gmail.com> <1242830481.9894.266.camel@cookie.hadess.net> Message-ID: <645d17210905200808j240faa20m872d66e79179c864@mail.gmail.com> 2009/5/20 Adam Miller : >> Get the mini 9, if you like that form factor. The mini 10, and 12 are >> out of bounds for as long as intel doesn't release decent poulsbo >> drivers. >> >> There are certainly other netbooks available... >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > > The HP Mini 1000 is also on my list of considerations. I plan to do > plenty of research before making a purchase ... I just don't have the > funding yet so I haven't spent a lot of time looking into them. > > Thanks for the info though, good to know! :) I recently purchased an aspire one d150, and have it running F-11 fairly nicely (although the F11 preview iso wouldn't boot from a USB stick, but the KDE spin did). From jreznik at redhat.com Wed May 20 15:30:51 2009 From: jreznik at redhat.com (Jaroslav Reznik) Date: Wed, 20 May 2009 17:30:51 +0200 Subject: PolicyKit changes in F12 In-Reply-To: <1242262846.9432.9.camel@localhost.localdomain> References: <1242262846.9432.9.camel@localhost.localdomain> Message-ID: <200905201730.51182.jreznik@redhat.com> On Jueves 14 Mayo 2009 03:00:46 Matthias Clasen escribi?: > Just a heads-up: > > We hope to land a new PolicyKit version (which will turn into 1.0, > eventually) in F12 soon. The new version simplifies the API and will > require PolicyKit-using application to be ported. For more information, > have a look at the feature page: > > http://fedoraproject.org/wiki/Features/PolicyKitOne > > It also has pointers to api docs and a (terse) porting guide. We already > have a collection of patches for quite a few PolicyKit-using apps, so > the transitions should be relatively painless. Hi, could you be more specific in porting guide with some more real world examples etc. Patches are OK for quick overview what should be done but it's not a good source if you don't know code for those apps. For us (KDE SIG) it's really big problem - PK1 already missed 4.3 release (as it brings old PK support) so it's possible to have it upstream for 4.4 (next year). I'd try to contact upstream to ask them about current status but it looks like nobody is currently working on port but I hope we can help with it (as it comes from Fedora)... Could you add policykit-qt/kde to blockers on PK1 Feature page? How long old PK will be shipped in Fedora? Thanks Jaroslav > > Matthias -- Jaroslav ?ezn?k Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ From jkeating at redhat.com Wed May 20 15:57:02 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 May 2009 08:57:02 -0700 Subject: Package Maintainers Flags policy In-Reply-To: <4A13AC46.1040005@poolshark.org> References: <4A12B940.4050605@redhat.com> <2d319b780905190705p371ed40l475562b563e5d8a0@mail.gmail.com> <20090519144722.GC32139@macmahon.me.uk> <4A12DAE8.8040903@gmail.com> <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> <20090519181454.GA4397@nostromo.devel.redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <4A131DC6.8000605@gmail.com> <1242767869.3029.13.camel@localhost.localdomain> <4A132914.9040305@gmail.com> <1242771052.3029.22.camel@localhost.localdomain> <4A13AC46.1040005@poolshark.org> Message-ID: <1242835022.3029.42.camel@localhost.localdomain> On Wed, 2009-05-20 at 09:07 +0200, Denis Leroy wrote: > Gnome is an upstream project, while Fedora is not. So this "simple" > solution of yours is a mandated deviation from upstream, something that > is not very Fedora-like to start with, simply based on an irrational > fear of flags and on a single bugzilla complaint. If this is not an > absurd overreaction, I don't know what is. There is history here from before Fedora existed. And we make mandated deviation from upstream in other situations too, where the distribution of the content goes against the project goals. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Wed May 20 16:20:21 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 May 2009 09:20:21 -0700 Subject: Blocker ? In-Reply-To: <1242809678.3275.1.camel@localhost.localdomain> References: <1242809678.3275.1.camel@localhost.localdomain> Message-ID: <1242836421.3029.43.camel@localhost.localdomain> On Wed, 2009-05-20 at 10:54 +0200, Pierre-Yves wrote: > > Could someone have a look at this bug? > https://bugzilla.redhat.com/show_bug.cgi?id=501664 The anaconda team is aware of it, and will promote it to blocker status if necessary. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kevin at scrye.com Wed May 20 16:27:30 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 20 May 2009 10:27:30 -0600 Subject: Package Maintainers Flags policy In-Reply-To: <4A13C879.4080002@poolshark.org> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> Message-ID: <20090520102730.45a3b7d4@ohm.scrye.com> On Wed, 20 May 2009 11:08:09 +0200 Denis Leroy wrote: > Thanks Ewan, > > To summarize the votes: > > Dennis Gilmore: +1 > David Woodhouse: +1 > Bill Nottingham: +1 > Jon Stanley: +1 > Dan Horak: +1 > Kevin Fenzi: +1 > > The logs include some pearls, like this one: > > nirik:ok. I'm unclear what problem this is solving off hand... > jds2001: So reading this, it appears that this came from legal. I'm > fine with this policy. > nirik: ok, if it's legal I'm fine with it... > > Nobody is even questioning whether the policy is worth the effort, > since people think this is mandated by Legal. No debate about the > proposal consequences and impact over Fedora packagers. No clear > definition about "there are some flags we can't ship to certain > places" and what that actually means technically. What, you're going > to block download requests coming from the PRC ? What about mirrors ? > No debate about how the RPM split has zero impact over this anyways, > and how the "substantively essential" clause bypasses this also. Not > even an attempt to identify the list of affected packages. I agree that we could come up with a better policy. I think the number of packages is pretty limited here. I know of about 5 so far. Unfortunately I don't know an easy way to identify any beyond that. Do you? The policy "came from" legal concerns. Thus I think it's a a good idea to address it before we have to scramble to do so. I thought it was a better policy than 'no flags', but perhaps it's not. My understanding is that we split out things to make it easier for places that dislike flags to filter or otherwise block them. I agree that base packages that have essential flags wouldn't be identified then. > Of those 6, only 2 commented on this thread, and only 1 admitted this > could have been communicated/handled better (and he gets my respect). > I can only fear the other 4 do not read this mailing list. I do. I however have a day job and figure I can spend my time more productively for Fedora than responding to each of the 278 posts in this thread. Many of which are not constructive or useful. Out of those 278 posts, there have been I think about 4 counter proposals. For those that were constructive and offered them up I thank you. Personally I think this thread could have been about 10 posts: - Point out the problems with the passed policy (Which I admit freely it has). (one or two posts. Or even the paragraph above does that). - Offer some specific counter proposal or changes to the existing policy to make it more clear or better suit fedora's goals. - Someone could have figured out a list of affected packages. (How many of these affected packages do you maintain?) The "fesco is lazy and should resign" or "I just hate this" or "Here's specific examples of flags" I don't find productive or useful. The policy is not good, we should address it and get one thats better. We will. > Frankly, this is the worst FeSCo we have had in years, and I'd like > those people to resign immediately from FeSCo and early elections to > take place. Elections are taking place soon. Feel free to run. I note that the majority of the current fesco has served many times before, so I don't think this is any radical change of elected members. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From kevin at scrye.com Wed May 20 16:29:29 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 20 May 2009 10:29:29 -0600 Subject: Package Maintainers Flags policy In-Reply-To: <20090520140538.GC13882@nostromo.devel.redhat.com> References: <4A12B940.4050605@redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <200905192226.21739.opensource@till.name> <20090519210847.GC7385@nostromo.devel.redhat.com> <20090520140538.GC13882@nostromo.devel.redhat.com> Message-ID: <20090520102929.3a592b4b@ohm.scrye.com> On Wed, 20 May 2009 10:05:38 -0400 Bill Nottingham wrote: > Kevin Kofler (kevin.kofler at chello.at) said: > > Bill Nottingham wrote: > > > (really, this will affect only a small number of packagers, > > > anyway.) > > > > I think you (and others) are significantly underestimating the > > number of affected packages. The previous unwritten policy (from > > RHL times) not to ship any flags wasn't enforced for > > community-maintained packages, several packages include flags and > > some (e.g. freeciv) need them for proper operation. > > All you've mentioned are the same packages I already know about: > > - kdebase (or some similar package in KDE) > - gcompris > - freeciv - xfce4-xkb-plugin is another one. > If there's really a lot of packages, I'd like actual data as to what > they are; vague descriptions of 'several' doesn't really help frame > the discussion of the amount of work. Totally agreed. > Bill kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From rc040203 at freenet.de Wed May 20 17:24:44 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 20 May 2009 19:24:44 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <20090520102730.45a3b7d4@ohm.scrye.com> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520102730.45a3b7d4@ohm.scrye.com> Message-ID: <4A143CDC.8040400@freenet.de> Kevin Fenzi wrote: > On Wed, 20 May 2009 11:08:09 +0200 > Denis Leroy wrote: > >> Thanks Ewan, >> >> To summarize the votes: >> >> Dennis Gilmore: +1 >> David Woodhouse: +1 >> Bill Nottingham: +1 >> Jon Stanley: +1 >> Dan Horak: +1 >> Kevin Fenzi: +1 > I agree that we could come up with a better policy. Yes, tabling this issue and working out a sustainable solution would have been the appropriate approach. So far, to me, FESCO's decision is a short-sighted hip-shot, without any foundation nor long term-perspective. Harmful to FESCO, harmful to Fedora, without providing a solution. > The policy "came from" legal concerns. Thus I think it's a a good idea > to address it before we have to scramble to do so. I thought it was a > better policy than 'no flags', but perhaps it's not. Well, I am sure, FESCO will now will initiate the necessary measures to initiate the "youth protection" certification processes, whose absence so far legally threads Fedora vendors/distributors from different countries around the globe? > The "fesco is lazy and should resign" or "I just hate this" or > "Here's specific examples of flags" I don't find productive or useful. > The policy is not good, we should address it and get one thats better. > We will. > >> Frankly, this is the worst FeSCo we have had in years, ACK. > Elections are taking place soon. Feel free to run. Pardom? In a democracy, the natural consequence of people feeling dissatisfied with the ruling party, is to vote against them or to abstain from voting, when feeling "there is no voteable candidate" or when feeling "voting is useless". Ralf From loganjerry at gmail.com Wed May 20 17:26:01 2009 From: loganjerry at gmail.com (Jerry James) Date: Wed, 20 May 2009 11:26:01 -0600 Subject: Package Maintainers Flags policy In-Reply-To: <20090520102730.45a3b7d4@ohm.scrye.com> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520102730.45a3b7d4@ohm.scrye.com> Message-ID: <870180fe0905201026k254e0663h7a2a9649c73c84ef@mail.gmail.com> On Wed, May 20, 2009 at 10:27 AM, Kevin Fenzi wrote: > The policy "came from" legal concerns. Thus I think it's a a good idea > to address it before we have to scramble to do so. I thought it was a > better policy than 'no flags', but perhaps it's not. s/legal concerns/political concerns/ Right? -- Jerry James http://www.jamezone.org/ From kevin.kofler at chello.at Wed May 20 17:26:59 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 20 May 2009 19:26:59 +0200 Subject: Package Maintainers Flags policy References: <4A127B5E.2080600@poolshark.org> <20090519155546.GD32139@macmahon.me.uk> <1242800327.4500.9.camel@dhcp-0-207.bne.redhat.com> <200905201207.31072.surenkarapetyan@gmail.com> Message-ID: Suren Karapetyan wrote: > That's true if someone is trying to find a language from the full list. > But if someone (e.g. me) has already chosen 3 he will be using (e.g. > English, Armenian, Russian) it will be much more comfortable for him to > see a flag and not a greyish box with greyish white letters (us, am, ru) > in it. Those are keyboard layouts, not input methods, and there are indeed no standard icons for those, which is why those flags are used. Of course, flags are a bad match for them, as are language names (!). For example, the Swiss German-language keyboard is vastly different from the German and Austrian German-language keyboard. And Swiss keyboards for French and Italian are different from those for German. Whereas Germany and Austria use both the same language and the same keyboard, so a German flag is kinda annoying for users in Austria (the language name is slightly more correct, but see Switzerland?). It really looks like there's no good solution for this mess. Kevin Kofler From tcallawa at redhat.com Wed May 20 17:35:32 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 20 May 2009 13:35:32 -0400 Subject: Youth Protection: Was Re: Package Maintainers Flags policy In-Reply-To: <4A143CDC.8040400@freenet.de> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520102730.45a3b7d4@ohm.scrye.com> <4A143CDC.8040400@freenet.de> Message-ID: <4A143F64.5080002@redhat.com> On 05/20/2009 01:24 PM, Ralf Corsepius wrote: > Well, I am sure, FESCO will now will initiate the necessary measures to > initiate the "youth protection" certification processes, whose absence > so far legally threads Fedora vendors/distributors from different > countries around the globe? We actually have this pretty well covered wrt to US laws. :) ~spot From jwboyer at gmail.com Wed May 20 18:17:28 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 20 May 2009 14:17:28 -0400 Subject: Package Maintainers Flags policy In-Reply-To: <4A143CDC.8040400@freenet.de> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520102730.45a3b7d4@ohm.scrye.com> <4A143CDC.8040400@freenet.de> Message-ID: <20090520181728.GA2456@hansolo.jdub.homelinux.org> On Wed, May 20, 2009 at 07:24:44PM +0200, Ralf Corsepius wrote: >> Elections are taking place soon. Feel free to run. > Pardom? In a democracy, the natural consequence of people feeling > dissatisfied with the ruling party, is to vote against them or to > abstain from voting, when feeling "there is no voteable candidate" or > when feeling "voting is useless". You are free to vote against candidates. Or not vote for them. Or even not vote. But a more effective manner of being able to influence things is to actually run for office. This is significantly more of an option in Fedora than it is in true government elections, because the campaign doesn't cost millions of dollars. All it costs is the candidate's time. They may win, they may not. But at least they cared enough to try. Expecting things to change without having actual candidates pushing for that change is a bit absurd. I'm not sure what anyone would expect to actually accomplish by not voting and then just criticizing the elected body they didn't vote for. To truly be part of a community, one needs to participate it the actual workings of that community. josh From pertusus at free.fr Wed May 20 18:57:02 2009 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 20 May 2009 20:57:02 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <20090520135717.GA13882@nostromo.devel.redhat.com> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520135717.GA13882@nostromo.devel.redhat.com> Message-ID: <20090520185702.GA2827@free.fr> On Wed, May 20, 2009 at 09:57:17AM -0400, Bill Nottingham wrote: > > Well, if you want a longer version of my opinion... I think that such explanation is clearly missing, and i also think that it should be expanded and explicited by the board such that Fedora contributors know what are the practical goals. So far, the only rule I knew was about US laws, your opinion (which is very reasonable, in my opinion) goes much further, which is certainly good, but should be 'officially' said. > One of our Fedora goals (stated very clearly, see Overview on the wiki) is > to be usable and redistributable *by ALL*. Now, we don't always succeed here; > take, for example, countries where we're unable to distribute to because > of US restrictions (such as Iran, Cuba, etc.) What does that exactly mean? Are the Fedora mirrors unreachable from those countries? > However, we should certainly strive towards this goal. > > By making this change, we allow people in China, or similarly restricted > locales, to be able to use & contribute to Fedora in a way that's safer > and more legal for them. (As to the question whether it's enough for there; > given the preexisting example of something like Red Hat Linux in that > locale that had a 'no flags' policy, by first glance it is enough.) Right, but it also should be more openly assessed. If some countries are a feasible goal for Fedora compliance, and it is known, people can come with their knowledge of the country law and help doing more guidelines to comply to te country law. > It comes down to a tradeoff; it's essentially a pragmatic decision. Are the > gains by making it acceptable in China (or similar locales) worth the effort in > changing/removing some small number of packages? Given the benefits in > opening up the community to 1/6 of the planet's population, and the fact > that in most all cases, the flags aren't a crucial portion of the > functionality *of the project* that is exposed to users, I think so. Once again, no problem with that, but it should be openly said somewhere explicitely, that Fedora should abide to chinese laws in addition to US laws. And it is certainly worth noting which countries are known to be ok or not ok with fedora. > Other restrictions in other locales can be handled as need be. For example, > the costs in removing encryption to satisfy some theoretical edict from > a non-US government *wouldn't* be worth the trade-off, as that's a core > functionality that affects pretty much all of our users. Maybe it could also be said somewhere. -- Pat From ville.skytta at iki.fi Wed May 20 19:29:31 2009 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Wed, 20 May 2009 22:29:31 +0300 Subject: Remaining debuginfo packages without sources (ocaml, haskell, erlang, etc) Message-ID: <200905202229.32245.ville.skytta@iki.fi> Hi, The remaining set of packages with unknown status that have debuginfo packages without sources are somewhat unusual ones. In particular, there's a bunch of Java packages but I suppose those are more or less because of bug #472292. https://fedoraproject.org/wiki/User:Scop/DebugInfoProblems Could people who have a clue about the following languages/packages check if the packages are compiled with the appropriate $RPM_OPT_FLAGS and/or could be modified to produce a usual debuginfo package (one with sources, that is): Ocaml related packages: why, mediawiki, zenon, hevea, planets Haskell related packages: curry Erlang related packages: wings Others: GtkAda, elice, lostlabyrinth, mono-debugger From kevin.kofler at chello.at Wed May 20 19:42:26 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 20 May 2009 21:42:26 +0200 Subject: Package Maintainers Flags policy References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520102730.45a3b7d4@ohm.scrye.com> Message-ID: Kevin Fenzi wrote: > I think the number of packages is pretty limited here. I know of about > 5 so far. I know of 4 more (which I don't think are the sames you're thinking of ? well, 2 of the 4 are subpackages of the same SRPM, but separate versions of the flags), plus the icons for preferences-desktop-locale in pretty much all icon themes (I'm going to write a separate mail on that issue where it fits better in the thread). > The policy "came from" legal concerns. Thus I think it's a a good idea > to address it before we have to scramble to do so. I think we shouldn't unless there's an actual legal issue where Fedora is based (which happens to be the USA). > I note that the majority of the current fesco has served many times > before, so I don't think this is any radical change of elected members. That's an issue of lack of alternatives more than anything else. It also was not really clear in past elections what stand the candidates are taking on individual issues (hopefully the interview process being tried this time will help), and it's especially hard to predict what decisions they'll make on new issues which come up. I'm sorry to say this to you (and it's not against you personally), but most of us really don't know whom we can trust. Kevin Kofler From kevin.kofler at chello.at Wed May 20 19:46:05 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 20 May 2009 21:46:05 +0200 Subject: Package Maintainers Flags policy References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520135717.GA13882@nostromo.devel.redhat.com> <20090520185702.GA2827@free.fr> Message-ID: Patrice Dumas wrote: > On Wed, May 20, 2009 at 09:57:17AM -0400, Bill Nottingham wrote: >> One of our Fedora goals (stated very clearly, see Overview on the wiki) >> is to be usable and redistributable *by ALL*. Now, we don't always >> succeed here; take, for example, countries where we're unable to >> distribute to because of US restrictions (such as Iran, Cuba, etc.) > > What does that exactly mean? Are the Fedora mirrors unreachable from > those countries? No. At least people from Iran have no trouble getting Fedora at all AFAICT, and there's hardly any enforcement of export control. They were banned from using the official FreeMedia project, but online downloads are pretty much impossible to police, most if not all mirrors are wide open to Iran. Kevin Kofler From kevin.kofler at chello.at Wed May 20 19:57:52 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 20 May 2009 21:57:52 +0200 Subject: Package Maintainers Flags policy References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520102730.45a3b7d4@ohm.scrye.com> Message-ID: I wrote: > That's an issue of lack of alternatives more than anything else. It also > was not really clear in past elections what stand the candidates are > taking on individual issues (hopefully the interview process being tried > this time will help), and it's especially hard to predict what decisions > they'll make on new issues which come up. I'm sorry to say this to you > (and it's not against you personally), but most of us really don't know > whom we can trust. PS: Oh, and "If you don't know whom to trust, run for office yourself!" isn't really a satisfying answer. While there should indeed be some people unhappy with the current FESCo running for office to provide a real alternative, if everybody runs and only trusts themselves, we end up with everyone having exactly 1 vote (or rather n "votes" where n is the maximum rating in the range voting system being used), that won't work at all. Another issue is that there are many people whom I totally agreed with on some issues but totally disagreed with on some others in the past. I really don't know what the best solution for those issues would be. Better communication of platforms, goals etc.? Forming factions/parties so we could vote e.g. for KDE SIG? Direct democracy as practiced in Debian? (But I'm not sure any of those really works, Debian's votes have often been total chaos, parties probably don't work for such small committees where there would be just 1 or 2 members of each party, most likely voting for their own position rather than the official party line more often than not, better communication probably doesn't solve the whole problem.) Kevin Kofler From kevin.kofler at chello.at Wed May 20 20:15:23 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 20 May 2009 22:15:23 +0200 Subject: Package Maintainers Flags policy References: <4A12DAE8.8040903@gmail.com> <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> <20090519181454.GA4397@nostromo.devel.redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <20090519202228.GE32139@macmahon.me.uk> <20090519203722.GB7385@nostromo.devel.redhat.com> <4A132821.1030504@poolshark.org> <4A1329D9.1070007@redhat.com> <4A1338F0.5050606@gmail.com> Message-ID: I wrote: > The only reasonable definition of "generic" I can see is "this flag is not > used to represent a country", e.g. a set of flags being used as an icon > for "localization". More on localization icons: I looked at the icon for preferences-desktop-locale in several of our icon themes: * gnome -> UN flag * Mist -> inherited from gnome (UN flag) * Fedora (GNOME) -> inherited from Mist (UN flag) * oxygen -> UN flag * crystalsvg -> US and German flags (uses KDE 3 icon naming, just "locale") * Fedora-KDE -> inherits oxygen (UN flag), crystalsvg (KDE 3 name, 2 flags) * Bluecurve -> US, Italian and Czech flags Not a single of those icon themes is compliant with our policy (which says the UN flag is to be treated like country flags)! Neither our default themes in the 2 primary desktops are (including GNOME which supposedly has a "no flags" policy, apparently that doesn't cover the UN flag unlike ours; GNOME's UN flag is low-res only, so it ends up a bit stilized, but it's recognizable as a UN flag), nor the theme coming to us from RHL which supposedly didn't allow flags (and that one's not even a UN flag, but 3 country flags). Kevin Kofler From rjones at redhat.com Wed May 20 20:20:25 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 20 May 2009 21:20:25 +0100 Subject: Remaining debuginfo packages without sources (ocaml, haskell, erlang, etc) In-Reply-To: <200905202229.32245.ville.skytta@iki.fi> References: <200905202229.32245.ville.skytta@iki.fi> Message-ID: <20090520202025.GA24785@amd.home.annexia.org> On Wed, May 20, 2009 at 10:29:31PM +0300, Ville Skytt? wrote: > Ocaml related packages: why, mediawiki, zenon, hevea, planets I suspect that these packages just need debuginfo turned off. For the majority of OCaml packages we do: %define debug_package %{nil} The reason is that upstream OCaml doesn't generate meaningful dwarf information, and gdb doesn't support OCaml either (there is an OCaml-specific debugger). Both facts are regrettable but require a great deal of effort to fix, which we don't have resources to do. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From a.badger at gmail.com Wed May 20 20:19:55 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 20 May 2009 13:19:55 -0700 Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520102730.45a3b7d4@ohm.scrye.com> Message-ID: <4A1465EB.8010108@gmail.com> On 05/20/2009 12:57 PM, Kevin Kofler wrote: > Another issue is that there are many people whom I totally agreed with on > some issues but totally disagreed with on some others in the past. > This one is actually a feature of republican forms of government. Debating why that is is likely off-topic for Fedora devel. However, dealing with it is: No one who is elected by multiple people can represent all of the people who voted for them all of the time. So the voter has to make a decision: 1) Do you want someone who does what the majority of people think is right? 2) Do you want someone whose judgement you think is sound? 3) Do you want someone who holds the same fundamental values as you do? 4) Do you want someone that you, personally, have influence with? So, to prepare for the next election, it would be good to get some questions posted that speak to the core values that the people hold and to see whether, when they disagree with you, they are doing so with rational arguments that you can understand even if you don't agree with them. -Toshio From limb at jcomserv.net Wed May 20 20:22:46 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 20 May 2009 15:22:46 -0500 Subject: Remaining debuginfo packages without sources (ocaml, haskell, erlang, etc) In-Reply-To: <20090520202025.GA24785@amd.home.annexia.org> References: <200905202229.32245.ville.skytta@iki.fi> <20090520202025.GA24785@amd.home.annexia.org> Message-ID: <4A146696.5060608@jcomserv.net> Richard W.M. Jones wrote: > On Wed, May 20, 2009 at 10:29:31PM +0300, Ville Skytt? wrote: > >> Ocaml related packages: why, mediawiki, zenon, hevea, planets >> > > I suspect that these packages just need debuginfo turned off. For the > majority of OCaml packages we do: > > %define debug_package %{nil} > > The reason is that upstream OCaml doesn't generate meaningful dwarf > information, and gdb doesn't support OCaml either (there is an > OCaml-specific debugger). Both facts are regrettable but require a > great deal of effort to fix, which we don't have resources to do. > > Rich. > > Committing fix for planets. -- in your fear, speak only peace in your fear, seek only love -d. bowie From kevin.kofler at chello.at Wed May 20 20:24:57 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 20 May 2009 22:24:57 +0200 Subject: latest f11 kmail update eating email? References: <4A14009B.7060505@redhat.com> <4A140782.70707@redhat.com> <4A1409DE.5050401@redhat.com> Message-ID: Jarod Wilson wrote: > Yep, still happening, got some interesting console output... Bugzilla'd. > > https://bugzilla.redhat.com/show_bug.cgi?id=501721 It turned out that it's the spam filter going bonkers. I don't know why this happens only now, maybe IMAP filtering was broken in 4.2.2 (there's a fix for several IMAP filtering issues in 4.2.3). Details in the bug report. Kevin Kofler From stickster at gmail.com Wed May 20 20:33:59 2009 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 20 May 2009 16:33:59 -0400 Subject: Package Maintainers Flags policy In-Reply-To: <4A1465EB.8010108@gmail.com> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520102730.45a3b7d4@ohm.scrye.com> <4A1465EB.8010108@gmail.com> Message-ID: <20090520203359.GB528@localhost.localdomain> On Wed, May 20, 2009 at 01:19:55PM -0700, Toshio Kuratomi wrote: > On 05/20/2009 12:57 PM, Kevin Kofler wrote: > >> Another issue is that there are many people whom I totally agreed with on >> some issues but totally disagreed with on some others in the past. >> > This one is actually a feature of republican forms of government. > Debating why that is is likely off-topic for Fedora devel. However, > dealing with it is: > > No one who is elected by multiple people can represent all of the people > who voted for them all of the time. So the voter has to make a decision: > > 1) Do you want someone who does what the majority of people think is right? > 2) Do you want someone whose judgement you think is sound? > 3) Do you want someone who holds the same fundamental values as you do? > 4) Do you want someone that you, personally, have influence with? > > So, to prepare for the next election, it would be good to get some > questions posted that speak to the core values that the people hold and > to see whether, when they disagree with you, they are doing so with > rational arguments that you can understand even if you don't agree with > them. To wit: http://thorstenl.blogspot.com/2009/05/what-questions-would-you-like-to-ask.html -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From jkeating at redhat.com Wed May 20 20:52:12 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 May 2009 13:52:12 -0700 Subject: Package Maintainers Flags policy In-Reply-To: <20090520185702.GA2827@free.fr> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520135717.GA13882@nostromo.devel.redhat.com> <20090520185702.GA2827@free.fr> Message-ID: <1242852732.3029.62.camel@localhost.localdomain> On Wed, 2009-05-20 at 20:57 +0200, Patrice Dumas wrote: > What does that exactly mean? Are the Fedora mirrors unreachable from > those countries? No, but it would be illegal for the Fedora project to actively try to distribute into those countries. The mirrors are supposed to put up a blurb about not downloading if you're in one of those countries, and/or blocking IPs from those areas. It's not easily policable, but it is easy to notice the project entering into any kind of business arrangement or actively helping to distribute into those countries. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From awilliam at redhat.com Wed May 20 20:56:58 2009 From: awilliam at redhat.com (Adam Williamson) Date: Wed, 20 May 2009 13:56:58 -0700 Subject: Fedora and the moblin2 fork In-Reply-To: References: <5256d0b0905191547w1d5725c3i2cd4338723cecc64@mail.gmail.com> <20090519221238.608afa5d@infradead.org> <5256d0b0905192351q2b83333fgcb738c7f29334686@mail.gmail.com> Message-ID: <1242853018.8848.159.camel@adam.local.net> On Wed, 2009-05-20 at 09:02 -0500, Adam Miller wrote: > I know this is the worst possible answer, but I honestly don't > remember. It has been months since I stumbled across the wiki page for > the project which is when I started trying to dig around for > information. But I'm glad to know that the SIG is still active and I > would be very happy to help as much as I possibly can. I have an Acer > Aspire One that I can help test stuff on and I'm also planning on > getting a Dell Mini as soon as I have the > spare money. Don't get the 12 or the 10. The 10v and 9 are OK. The Mini 1000 you mentioned is also OK. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From awilliam at redhat.com Wed May 20 21:02:03 2009 From: awilliam at redhat.com (Adam Williamson) Date: Wed, 20 May 2009 14:02:03 -0700 Subject: Package Maintainers Flags policy In-Reply-To: <1242852732.3029.62.camel@localhost.localdomain> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520135717.GA13882@nostromo.devel.redhat.com> <20090520185702.GA2827@free.fr> <1242852732.3029.62.camel@localhost.localdomain> Message-ID: <1242853323.8848.163.camel@adam.local.net> On Wed, 2009-05-20 at 13:52 -0700, Jesse Keating wrote: > On Wed, 2009-05-20 at 20:57 +0200, Patrice Dumas wrote: > > What does that exactly mean? Are the Fedora mirrors unreachable from > > those countries? > > No, but it would be illegal for the Fedora project to actively try to > distribute into those countries. The mirrors are supposed to put up a > blurb about not downloading if you're in one of those countries, and/or > blocking IPs from those areas. It's not easily policable, but it is > easy to notice the project entering into any kind of business > arrangement or actively helping to distribute into those countries. FWIW, the concept of introducing a policy that "we will adjust the Fedora project and product to enable it to be distributed in China" is a troubling one. There are other, well-known cases of prominent tech companies - Yahoo! China is the obvious example - doing very problematic things to make the Chinese government happy and hence be 'kosher' for distribution / promotion etc in China. I'm not sure that's a road we want to start down. I'm fairly sure that, if it actually happened, Fedora wouldn't do anything really ethically dubious just to continue being distributable in China. However, if it came to that, we'd then have wasted all this effort footling around with flags... I think we need a broader assessment of the overall implications of such a policy before jumping in to it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From denis at poolshark.org Wed May 20 21:51:17 2009 From: denis at poolshark.org (Denis Leroy) Date: Wed, 20 May 2009 23:51:17 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <20090520135717.GA13882@nostromo.devel.redhat.com> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520135717.GA13882@nostromo.devel.redhat.com> Message-ID: <4A147B55.8030006@poolshark.org> On 05/20/2009 03:57 PM, Bill Nottingham wrote: > There are places where the use of certain flags is verboten; in this case, > the use& distribution of Fedora would be verboten if it prominently > used them. Right, we all know that, although it is not a problem *today* (as in, it's blocking F-11). But I don't see how this is related to Spot's proposal. Promoting Fedora in China is a worthy goal of course. Now if we decide to tackle that challenge today, for whatever reason, and we lock up our brightest minds in a room and ask them to come out with a plan for that specific purpose, do you think they'll come out with a policy about isolating flags in subpackages ? No, they'll most likely come up with some grand master plan about creating a community of Chinese Fedora enthusiasts, creating their own SIG and PRC Fedora spin (I don't necessarily mean official SIG or spins), which most likely will black-list some packages, alter the default install, i18n params and comps files, and possibly, on a case-by-case basis, ask some packagers to split some packages in part to make their work possible. That's the way to go, and Fedora keeps a completely neutral stance in this. Any international community can do the same, for whatever political agenda they may have. That's the beauty of FOSS. Or maybe their plan will be to create an "International" Fedora spin (or call it "Export", or "Flagless", or ...), which is a flavour of Fedora minus lots of content considered offending or illegal in a bunch of countries. Now of course, you need volunteers to work that spin. Such that, if someone complains about some offending flag, you can answer "Why, thank you for raising this issue! We are precisely looking for volunteers to help us create your own special flavour of Fedora!". Now, back to Spot's proposal. It does not address any sort of focused and pragmatic problem we have today. Want Fedora to be -friendly ? Great, but first start by designing grand master plan above. Moving US, French and German flags into a bunch of secret subpackages doesn't buy you anything. From poelstra at redhat.com Wed May 20 22:08:05 2009 From: poelstra at redhat.com (John Poelstra) Date: Wed, 20 May 2009 15:08:05 -0700 Subject: Final Blocker Bug Meeting 2009-05-22 (Friday) @ 12:00 EDT / 16:00 UTC Message-ID: <4A147F45.1040409@redhat.com> Release Engineering is hosting a blocker bug review meeting this coming Friday at 12:00 EDT / 16:00 UTC to review and retest the remaining bugs on the Fedora 11 blocker list--https://bugzilla.redhat.com/show_bug.cgi?id=f11blocker This important task will give us a clearer sense as to what decision should be made on Tuesday, May 26 about the readiness of the Fedora 11 Release. Everyone is welcome to join in the fun. We'll be meeting at irc.freenode.net on the #fedora-bugzappers channel. Thanks, John _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From jonathan.underwood at gmail.com Wed May 20 22:57:52 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 20 May 2009 23:57:52 +0100 Subject: LiveCD install and PAE kernel Message-ID: <645d17210905201557u79b19c9cs36be89efb0cf9210@mail.gmail.com> Hi, I installed the i686 from the Preview Release LiveCD image (specifically F11-Preview-i686-Live-KDE.iso). This image booted the non PAE kernel, and when I installed to hard disk, it installs the non PAE kernel. This is on an Atom N280 netbook. If I understand the feature list correctly, actually the installer should have installed the PAE kernel on this hardware. Or does that just refer to DVD installs? i.e. does the LiveCD have any mechanism for chosing PAE/non-PAE or is that just the DVD? If not, then it might be worth detailing in the Release Notes how to install the PAE kernel following a LiveCD install. Cheers, Jonathan. From kyle at mcmartin.ca Wed May 20 23:13:13 2009 From: kyle at mcmartin.ca (Kyle McMartin) Date: Wed, 20 May 2009 19:13:13 -0400 Subject: LiveCD install and PAE kernel In-Reply-To: <645d17210905201557u79b19c9cs36be89efb0cf9210@mail.gmail.com> References: <645d17210905201557u79b19c9cs36be89efb0cf9210@mail.gmail.com> Message-ID: <20090520231313.GA20660@bombadil.infradead.org> On Wed, May 20, 2009 at 11:57:52PM +0100, Jonathan Underwood wrote: > Hi, > > I installed the i686 from the Preview Release LiveCD image > (specifically F11-Preview-i686-Live-KDE.iso). This image booted the > non PAE kernel, and when I installed to hard disk, it installs the non > PAE kernel. This is on an Atom N280 netbook. If I understand the > feature list correctly, actually the installer should have installed > the PAE kernel on this hardware. Or does that just refer to DVD > installs? i.e. does the LiveCD have any mechanism for chosing > PAE/non-PAE or is that just the DVD? > > If not, then it might be worth detailing in the Release Notes how to > install the PAE kernel following a LiveCD install. > The LiveCD is always an i586 kernel, and always installs the one from the cd. regards, Kyle From bojan at rexursive.com Wed May 20 23:22:06 2009 From: bojan at rexursive.com (Bojan Smojver) Date: Thu, 21 May 2009 09:22:06 +1000 Subject: Unisigned package in rawhide: nfs-utils-lib-1.1.4-6.fc11.i586.rpm Message-ID: <1242861726.21223.2.camel@shrek.rexursive.com> Not sure how that got in there. My yum says: ---------------- ... Total size: 5.7 M Downloading Packages: Package nfs-utils-lib-1.1.4-6.fc11.i586.rpm is not signed ---------------- -- Bojan From bojan at rexursive.com Wed May 20 23:32:03 2009 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 20 May 2009 23:32:03 +0000 (UTC) Subject: Unisigned package in rawhide: nfs-utils-lib-1.1.4-6.fc11.i586.rpm References: <1242861726.21223.2.camel@shrek.rexursive.com> Message-ID: Bojan Smojver rexursive.com> writes: > Package nfs-utils-lib-1.1.4-6.fc11.i586.rpm is not signed Ditto: libtirpc-0.1.10-7.fc11.i586.rpm rpcbind-0.1.7-3.fc11.i586.rpm -- Bojan From ian at ianweller.org Wed May 20 23:28:13 2009 From: ian at ianweller.org (Ian Weller) Date: Wed, 20 May 2009 18:28:13 -0500 Subject: Unisigned package in rawhide: nfs-utils-lib-1.1.4-6.fc11.i586.rpm In-Reply-To: <1242861726.21223.2.camel@shrek.rexursive.com> References: <1242861726.21223.2.camel@shrek.rexursive.com> Message-ID: <20090520232813.GA6720@kupenblagster.ianweller.org> On Thu, May 21, 2009 at 09:22:06AM +1000, Bojan Smojver wrote: > Not sure how that got in there. My yum says: > > ---------------- > ... > Total size: 5.7 M > Downloading Packages: > > > Package nfs-utils-lib-1.1.4-6.fc11.i586.rpm is not signed > ---------------- > Same here, the offending package is libtirpc-0.1.10-7.fc11.x86_64.rpm. -- Ian Weller GnuPG fingerprint: E51E 0517 7A92 70A2 4226 B050 87ED 7C97 EFA8 4A36 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From awilliam at redhat.com Thu May 21 00:23:50 2009 From: awilliam at redhat.com (Adam Williamson) Date: Wed, 20 May 2009 17:23:50 -0700 Subject: Unisigned package in rawhide: nfs-utils-lib-1.1.4-6.fc11.i586.rpm In-Reply-To: <1242861726.21223.2.camel@shrek.rexursive.com> References: <1242861726.21223.2.camel@shrek.rexursive.com> Message-ID: <1242865430.8848.173.camel@adam.local.net> On Thu, 2009-05-21 at 09:22 +1000, Bojan Smojver wrote: > Not sure how that got in there. My yum says: > > ---------------- > ... > Total size: 5.7 M > Downloading Packages: > > > Package nfs-utils-lib-1.1.4-6.fc11.i586.rpm is not signed > ---------------- Has already been explained on test-list, in the thread "Lastest F11 updates not signed" (sic): "Yes. This is my fault. I tagged some packages late yesterday for legal reasons and forgot to tell Jesse about them, so they got pushed unsigned. They will be fixed with the next push. My deepest apologies, ~spot" -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From bojan at rexursive.com Thu May 21 02:17:50 2009 From: bojan at rexursive.com (Bojan Smojver) Date: Thu, 21 May 2009 02:17:50 +0000 (UTC) Subject: Unisigned package in rawhide: nfs-utils-lib-1.1.4-6.fc11.i586.rpm References: <1242861726.21223.2.camel@shrek.rexursive.com> <1242865430.8848.173.camel@adam.local.net> Message-ID: Adam Williamson redhat.com> writes: > Has already been explained on test-list Thanks. I hardly ever look there, so I didn't notice it. -- Bojan From rc040203 at freenet.de Thu May 21 03:08:43 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 21 May 2009 05:08:43 +0200 Subject: Youth Protection: Was Re: Package Maintainers Flags policy In-Reply-To: <4A143F64.5080002@redhat.com> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520102730.45a3b7d4@ohm.scrye.com> <4A143CDC.8040400@freenet.de> <4A143F64.5080002@redhat.com> Message-ID: <4A14C5BB.5050401@freenet.de> Tom "spot" Callaway wrote: > On 05/20/2009 01:24 PM, Ralf Corsepius wrote: >> Well, I am sure, FESCO will now will initiate the necessary measures to >> initiate the "youth protection" certification processes, whose absence >> so far legally threads Fedora vendors/distributors from different >> countries around the globe? > > We actually have this pretty well covered wrt to US laws. :) We are talking about the "national laws" threating users/vendors/re-distributors in a particular country. Wrt. "youth protection", US laws are widely irrelevant. It's similar to US "alcohol/tobacco/drug laws", "weapon laws", "medication laws", "car part regulations". At least in my country (Germany), they are widely irrelevant. Relevant wrt. "youth protection" on SW in Germany are computer games. Very oversimplified, in general, it's illegal in Germany to make "non-USK-certified/rated" computer games available to people below certain age, rsp. in some cases, to distribute them at all. Ralf From rc040203 at freenet.de Thu May 21 03:12:17 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 21 May 2009 05:12:17 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <20090520181728.GA2456@hansolo.jdub.homelinux.org> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520102730.45a3b7d4@ohm.scrye.com> <4A143CDC.8040400@freenet.de> <20090520181728.GA2456@hansolo.jdub.homelinux.org> Message-ID: <4A14C691.8050701@freenet.de> Josh Boyer wrote: > On Wed, May 20, 2009 at 07:24:44PM +0200, Ralf Corsepius wrote: >>> Elections are taking place soon. Feel free to run. > Expecting things to change without having actual candidates pushing for that > change is a bit absurd. Well, telling "your representative" that you are dissatisfied with him and that he should do better next time is of no use? Ralf From dchen at redhat.com Thu May 21 04:43:46 2009 From: dchen at redhat.com (Ding-Yi Chen) Date: Thu, 21 May 2009 14:43:46 +1000 Subject: Package Maintainers Flags policy In-Reply-To: <200905201007.30543.mhlavink@redhat.com> References: <4A127B5E.2080600@poolshark.org> <200905201207.31072.surenkarapetyan@gmail.com> <1242805780.4500.29.camel@dhcp-0-207.bne.redhat.com> <200905201007.30543.mhlavink@redhat.com> Message-ID: <1242881026.4596.23.camel@localhost.localdomain> ? ??2009-05-20 ? 10:07 +0200?Michal Hlavinka ??? > On Wednesday 20 May 2009 09:49:40 Ding-Yi Chen wrote: > > ? ??2009-05-20 ? 12:07 +0500?Suren Karapetyan ??? > > > > > On Wednesday 20 May 2009 11:18:47 Ding-Yi Chen wrote: > > > > ? ??2009-05-19 ? 16:55 +0100?Ewan Mac Mahon ??? > > > > > > > > Using flags in input methods along is not very informative. > > > > For example, there are dozens (if not hundreds) of Chinese IMs. > > > > How do you know which one should be associated with China flags? > > > > Should it be pinyin? wubi? cangjie3? cangjie5? > > > > > > > > It's a good thing that almost all input methods already have their own > > > > icons. > > > > > > That's true if someone is trying to find a language from the full list. > > > But if someone (e.g. me) has already chosen 3 he will be using (e.g. > > > English, Armenian, Russian) > > > > I have 5 Chinese IMs (mainly for development) pinyin, wubi, Cangjie3, > > Quick3, and chewing. > > How could I distinguish these in "Flag-only" schema? > > We all know flags : language is not 1:1 relation, but it can help in situations > where you use more different languages (mostly english and native language). But it does not help in my case. Using input method icons, however, solves your case and mine. Note that you might be able to use flag as icon in your input method, providing no other people develop other input methods in your country and challenge you. And how about multilingual countries such as India and Switzerland? What language should be associate their flags? > If flags make it difficult for someone to chose: > 1) there is still text over the flag > 2) you can use check box in configuration to turn flags off In order to know which input method is activated, in your setting, I have to either: 1. Hover the mouse to the flag icon and see the tooltip 2. Type a few key and find out I am at wrong input method. Both ways are not as convenient as using an input method icons. -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ From cweyl at alumni.drew.edu Thu May 21 04:58:21 2009 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Wed, 20 May 2009 21:58:21 -0700 Subject: Youth Protection: Was Re: Package Maintainers Flags policy In-Reply-To: <4A14C5BB.5050401@freenet.de> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520102730.45a3b7d4@ohm.scrye.com> <4A143CDC.8040400@freenet.de> <4A143F64.5080002@redhat.com> <4A14C5BB.5050401@freenet.de> Message-ID: <7dd7ab490905202158sc923880ge50c81bceb580024@mail.gmail.com> On Wed, May 20, 2009 at 8:08 PM, Ralf Corsepius wrote: > Tom "spot" Callaway wrote: > >> On 05/20/2009 01:24 PM, Ralf Corsepius wrote: >> >>> Well, I am sure, FESCO will now will initiate the necessary measures to >>> initiate the "youth protection" certification processes, whose absence >>> so far legally threads Fedora vendors/distributors from different >>> countries around the globe? >>> >> >> We actually have this pretty well covered wrt to US laws. :) >> > > We are talking about the "national laws" threating > users/vendors/re-distributors in a particular country. > > Wrt. "youth protection", US laws are widely irrelevant. It's similar to US > "alcohol/tobacco/drug laws", "weapon laws", "medication laws", "car part > regulations". At least in my country (Germany), they are widely irrelevant. > > Relevant wrt. "youth protection" on SW in Germany are computer games. Very > oversimplified, in general, it's illegal in Germany to make > "non-USK-certified/rated" computer games available to people below certain > age, rsp. in some cases, to distribute them at all. > Fedora, as a project of a US corporation, is liable for violation of the laws of the State of North Carolina and of the United States. We're not liable for violation of the laws of any other jurisdiction... Whether it's over "protect teh [sic] children!", maps that have Israel on them, or flags. Do we really want to start excluding content just because it's illegal in some other jurisdiction? This seems.... slippery. -Chris -- Chris Weyl Ex astris, scientia -------------- next part -------------- An HTML attachment was scrubbed... URL: From rc040203 at freenet.de Thu May 21 05:24:00 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 21 May 2009 07:24:00 +0200 Subject: Youth Protection: Was Re: Package Maintainers Flags policy In-Reply-To: <7dd7ab490905202158sc923880ge50c81bceb580024@mail.gmail.com> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520102730.45a3b7d4@ohm.scrye.com> <4A143CDC.8040400@freenet.de> <4A143F64.5080002@redhat.com> <4A14C5BB.5050401@freenet.de> <7dd7ab490905202158sc923880ge50c81bceb580024@mail.gmail.com> Message-ID: <4A14E570.1000705@freenet.de> Chris Weyl wrote: > On Wed, May 20, 2009 at 8:08 PM, Ralf Corsepius wrote: > >> Tom "spot" Callaway wrote: >> >>> On 05/20/2009 01:24 PM, Ralf Corsepius wrote: >>> >>>> Well, I am sure, FESCO will now will initiate the necessary measures to >>>> initiate the "youth protection" certification processes, whose absence >>>> so far legally threads Fedora vendors/distributors from different >>>> countries around the globe? >>>> >>> We actually have this pretty well covered wrt to US laws. :) >>> >> We are talking about the "national laws" threating >> users/vendors/re-distributors in a particular country. >> >> Wrt. "youth protection", US laws are widely irrelevant. It's similar to US >> "alcohol/tobacco/drug laws", "weapon laws", "medication laws", "car part >> regulations". At least in my country (Germany), they are widely irrelevant. >> >> Relevant wrt. "youth protection" on SW in Germany are computer games. Very >> oversimplified, in general, it's illegal in Germany to make >> "non-USK-certified/rated" computer games available to people below certain >> age, rsp. in some cases, to distribute them at all. >> > > Fedora, as a project of a US corporation, is liable for violation of the > laws of the State of North Carolina and of the United States. We're not > liable for violation of the laws of any other jurisdiction... ACK. > Whether it's > over "protect teh [sic] children!", maps that have Israel on them, or flags. ACK, nor Tibet, or Nagorno-Karabakh, Kosovo, FYR of Macedonia, Cuba, Palestina, just to mention a few other controversial countries .... > Do we really want to start excluding content just because it's illegal in > some other jurisdiction? This seems.... slippery. ACK. I am simply trying to demonstrate the impact of the can of worms Spot, FESCO and RH-Legal have opened. If they were consequent, they now _will have to take care_ with this kind of issues, world-wide! Ralf From kevin.kofler at chello.at Thu May 21 05:23:53 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 21 May 2009 07:23:53 +0200 Subject: Package Maintainers Flags policy References: <4A127B5E.2080600@poolshark.org> <200905201207.31072.surenkarapetyan@gmail.com> <1242805780.4500.29.camel@dhcp-0-207.bne.redhat.com> <200905201007.30543.mhlavink@redhat.com> <1242881026.4596.23.camel@localhost.localdomain> Message-ID: Ding-Yi Chen wrote: > Using input method icons, however, solves your case and mine. What icons? There may be standard icons for Chinese input methods, but there are no standard icons for keyboard layouts. The language code is nonsense, as e.g. English and German have different keyboards depending on the country. > And how about multilingual countries such as India and Switzerland? For Switzerland, the different layouts are implemented as variants of the ch layout, so putting the ch layout up with a Swiss flag and then letting you pick the variant (which is what KDE does) is the best way to handle it. If you disagree with them being handled as variants, complain to the xkb folks, they're setting it up that way. India is a much more complex case though. Kevin Kofler From jonathan at jonmasters.org Thu May 21 05:49:46 2009 From: jonathan at jonmasters.org (Jon Masters) Date: Thu, 21 May 2009 01:49:46 -0400 Subject: [RFC] Increase default ulimit nofile Message-ID: <1242884986.4509.12.camel@localhost.localdomain> Folks, While digging through a fault in GNOME and Rhythmbox this evening, I happened upon this nugget. By default, we're still living in 1970: [jcm at tonnant ~]$ ulimit -n 1024 Now. This might be great for a honking great shared UNIX server from the days of yore, but it's not remotely appropriate for a modern desktop. Especially not one layered with so many per-user daemons and layers of abstraction as we have on modern Linux systems. I suggest /etc/security/limits.conf be modified to include something like the following, along with advice for sysadmins: * - nofile 8192 Discuss. --- background to discovering this problem --- I like podcasts. A lot. I also like rhythmbox (mostly). I've been wondering recently why I would occasionally not be able to download podcasts in rhythmbox. It seemed to be related to when I was connected to a particular VPN and so I had dismissed it as being network DNSness weirdness. But then it started happening much more often. Tonight, I decided it was probably more than occasional network weirdness. So I decided "I'll just fire up gdb on rhythmbox". Many debuginfo packages, cscopes, hacked up source, etc. later on, I discover the "problem" is in abstraction layer number 2 - totem-pl-parser. So I download the source to this package also, rebuild and hack it up. I eventually discovered that various GError objects were happily telling me that the maximum number of open files had been exceeded, but totem never exposes this to rhythmbox, and the latter just has no idea what the heck is causing it to fail. Some serious fail happening there. Jon. From dsteven at bigpond.net.au Thu May 21 06:02:00 2009 From: dsteven at bigpond.net.au (Darren Steven) Date: Thu, 21 May 2009 16:02:00 +1000 Subject: LiveCD install and PAE kernel In-Reply-To: <20090520231313.GA20660@bombadil.infradead.org> References: <645d17210905201557u79b19c9cs36be89efb0cf9210@mail.gmail.com> <20090520231313.GA20660@bombadil.infradead.org> Message-ID: I just rebuilt an older box (Athlon XP, VIA chipset - KM400 I think, openchrome X driver). Preview KDE Live CD works fine, but when I installed the full preview release from DVD, X terminates when Kwin starts (need to use metacity as KDEWM, or run Gnome). Not found any useful log indicating why. Could PAE kernel cause this? I'll try installing the i586 non PAE kernel (only 1G RAM anyway), and see how it goes (and file a bug perhaps) Darren On Thu, May 21, 2009 at 9:13 AM, Kyle McMartin wrote: > On Wed, May 20, 2009 at 11:57:52PM +0100, Jonathan Underwood wrote: > > Hi, > > > > I installed the i686 from the Preview Release LiveCD image > > (specifically F11-Preview-i686-Live-KDE.iso). This image booted the > > non PAE kernel, and when I installed to hard disk, it installs the non > > PAE kernel. This is on an Atom N280 netbook. If I understand the > > feature list correctly, actually the installer should have installed > > the PAE kernel on this hardware. Or does that just refer to DVD > > installs? i.e. does the LiveCD have any mechanism for chosing > > PAE/non-PAE or is that just the DVD? > > > > If not, then it might be worth detailing in the Release Notes how to > > install the PAE kernel following a LiveCD install. > > > > The LiveCD is always an i586 kernel, and always installs the one from > the cd. > > regards, Kyle > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jruohonen at iki.fi Thu May 21 06:30:07 2009 From: jruohonen at iki.fi (Jukka Ruohonen) Date: Thu, 21 May 2009 09:30:07 +0300 Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520102730.45a3b7d4@ohm.scrye.com> Message-ID: <20090521063007.GA21181@marx.bitnet> On 20.05.2009, Kevin Kofler wrote: > I really don't know what the best solution for those issues would be. Better > communication of platforms, goals etc.? Forming factions/parties so we > could vote e.g. for KDE SIG? Direct democracy as practiced in Debian? (But > I'm not sure any of those really works, Debian's votes have often been > total chaos, parties probably don't work for such small committees where > there would be just 1 or 2 members of each party, most likely voting for > their own position rather than the official party line more often than not, > better communication probably doesn't solve the whole problem.) I usually try to stay away from threads like this. With that excuse: I really hope this does not increase bureaucracy. There are hardly any examples where a bureaucratic/democractic governance model would have had any real positive impact on open source projects, quite the contrary. When policies start to matter more than technical questions, you are already lost. Personally, I would rather give FESCo more power. Perhaps this could at least end the shouting contest that Fedora developer mailing list has become. Two cents from a Fedora user, Jukka. From jonstanley at gmail.com Thu May 21 04:33:49 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Thu, 21 May 2009 00:33:49 -0400 Subject: FESCo election nominations now open Message-ID: Election season is here again in Fedora! Nominations are now open for the five open seats on FESCo. The following members have terms expiring this cycle: * Kevin Fenzi * Dennis Gilmore * Bill Nottingham * Brian Pepple * David Woodhouse Any interested Fedora packager may run for FESCo, the only requirement is membership in the 'packager' group in FAS. Especially noteworthy is that 'provenpackager' or sponsor status is not required - this keeps the bar low for new members. Nominations are open through 29 May 09 at https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations. More general information about the election process can be found at https://fedoraproject.org/wiki/Elections _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From rc040203 at freenet.de Thu May 21 06:44:42 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 21 May 2009 08:44:42 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <20090521063007.GA21181@marx.bitnet> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520102730.45a3b7d4@ohm.scrye.com> <20090521063007.GA21181@marx.bitnet> Message-ID: <4A14F85A.6030607@freenet.de> Jukka Ruohonen wrote: > Personally, I would rather give FESCo more power. Why? They already have almost "unlimited", almost "almighty" powers. > Perhaps this could at > least end the shouting contest that Fedora developer mailing list has > become. They are being shouted at, because people do not agree with their "almighty wisdom". Ralf From mcepl at redhat.com Thu May 21 07:26:32 2009 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 21 May 2009 07:26:32 +0000 (UTC) Subject: Sound doesn't work, again! References: <1242495430.3022.40.camel@dimi.lattica.com> <4A0F3AE1.3090709@comcast.net> <1242517467.3022.57.camel@dimi.lattica.com> <4A0F5FA8.9060302@comcast.net> <4A0F9F17.1090209@stacken.kth.se> <4A100346.20400@comcast.net> <3adc77210905170743k3e640fabx2c0b6b3f957b2cf2@mail.gmail.com> Message-ID: Naheem Zaffar, Sun, 17 May 2009 15:43:15 +0100: > I would think that "frozen" rawhid just before a release is a different > matter - if no serious bugs are reported in the software, that is the > software that will make it into a final release. The schedule of release of this frozen Rawhide slipped by a week because of too many release critical bugs. ... Mat?j From mcepl at redhat.com Thu May 21 07:49:24 2009 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 21 May 2009 07:49:24 +0000 (UTC) Subject: Where to post an experimental package? (java-1.7.0-openjdk) References: <4A0C2DBA.4080502@redhat.com> <1242316501.6282.56.camel@localhost.localdomain> <4A0C54C0.1010605@redhat.com> Message-ID: Lillian Angel, Thu, 14 May 2009 13:28:32 -0400: > 6 or 7 packages in total. No interdependencies. Size is what matters ... check you quota on fedorapeople (and ask for extension, if necessary). Mat?j From rms at 1407.org Thu May 21 09:26:05 2009 From: rms at 1407.org (Rui Miguel Silva Seabra) Date: Thu, 21 May 2009 10:26:05 +0100 Subject: In which country should Fedora be legal? In-Reply-To: <20090519215536.GB4623@roque.1407.org> References: <20090519195838.GC4558@free.fr> <20090519215536.GB4623@roque.1407.org> Message-ID: <20090521092605.GB4792@roque.1407.org> On Tue, May 19, 2009 at 10:55:36PM +0100, Rui Miguel Silva Seabra wrote: > On Tue, May 19, 2009 at 09:58:38PM +0200, Patrice Dumas wrote: > > Hello, > > > > I think that the flag policy is the wrong way to look at a real issue. > > First, it tries to solve 2 issues > > 1. being legal in some countries > > It'll very likely become downright illegal in many countries in Europe > depending on Cibercrime implementations. And also some EUCD implementations (like France's, where maybe cp and mv might be illegal if they don't respect DRM) Why are you worried about flags *sheesh*? :) Rui -- You are what you see. Today is Sweetmorn, the 68th day of Discord in the YOLD 3175 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? From christoph.wickert at googlemail.com Thu May 21 10:14:03 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Thu, 21 May 2009 12:14:03 +0200 Subject: I must be doing somthing seriously wrong... Message-ID: <1242900843.3685.26.camel@localhost.localdomain> The "Package Maintainers Flags policy" thread already counts more than 225 mails, but nobody bothered to answer 7 simple (?) questions I asked in my mail [1], although it was one of the very first three mails on the topic. So what did I do wrong? Was it that I mentioned the missing FESCo meeting minutes? If 8 out of 21 summaries are missing, IMHO this is a fact worth mentioning. I'm one of the few maintainers who directly is affected by the policy. Would somebody - preferably a FESCo member, who voted for the flags proposal - please be so kind to answer my questions. TIA! Kind regards, Christoph [1] https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01414.html From jwboyer at gmail.com Thu May 21 10:43:31 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 21 May 2009 06:43:31 -0400 Subject: Package Maintainers Flags policy In-Reply-To: <4A14C691.8050701@freenet.de> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520102730.45a3b7d4@ohm.scrye.com> <4A143CDC.8040400@freenet.de> <20090520181728.GA2456@hansolo.jdub.homelinux.org> <4A14C691.8050701@freenet.de> Message-ID: <20090521104331.GA9004@hansolo.jdub.homelinux.org> On Thu, May 21, 2009 at 05:12:17AM +0200, Ralf Corsepius wrote: > Josh Boyer wrote: >> On Wed, May 20, 2009 at 07:24:44PM +0200, Ralf Corsepius wrote: >>>> Elections are taking place soon. Feel free to run. > >> Expecting things to change without having actual candidates pushing for that >> change is a bit absurd. > Well, telling "your representative" that you are dissatisfied with him > and that he should do better next time is of no use? No, that certainly is of use. And representatives should listen to feedback on individual issues. However, if one is dissatisfied with the elected body overall, then changing the composition of that body through newly elected candidates seems to be the only way to possibly change that. Forgive me for picking your particular email to reply to, but a number of people have expressed that they feel this is 'the worst FESCo in a long time' and I'm just trying to point out that FESCo is simply composed of people that cared enough to run for election. BTW, personaly I disagree with the 'worst FESCo' statement and not because I'm on FESCo. There have just been a number of issues this term that actually require FESCo to do something other than approve Features and Sponsors. It's been interesting, but overall there has really only been the flags item that really needs revisiting. josh From jwboyer at gmail.com Thu May 21 10:45:03 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 21 May 2009 06:45:03 -0400 Subject: Package Maintainers Flags policy In-Reply-To: <4A14F85A.6030607@freenet.de> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520102730.45a3b7d4@ohm.scrye.com> <20090521063007.GA21181@marx.bitnet> <4A14F85A.6030607@freenet.de> Message-ID: <20090521104503.GB9004@hansolo.jdub.homelinux.org> On Thu, May 21, 2009 at 08:44:42AM +0200, Ralf Corsepius wrote: > Jukka Ruohonen wrote: >> Personally, I would rather give FESCo more power. > Why? They already have almost "unlimited", almost "almighty" powers. This is untrue. >> Perhaps this could at >> least end the shouting contest that Fedora developer mailing list has >> become. > They are being shouted at, because people do not agree with their > "almighty wisdom". And that's fine. I don't think anyone on FESCo would claim they are almighty though. Please refrain from being inflammatory. josh From jwboyer at gmail.com Thu May 21 11:31:19 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 21 May 2009 07:31:19 -0400 Subject: I must be doing somthing seriously wrong... In-Reply-To: <1242900843.3685.26.camel@localhost.localdomain> References: <1242900843.3685.26.camel@localhost.localdomain> Message-ID: <20090521113119.GA9316@hansolo.jdub.homelinux.org> On Thu, May 21, 2009 at 12:14:03PM +0200, Christoph Wickert wrote: >The "Package Maintainers Flags policy" thread already counts more than >225 mails, but nobody bothered to answer 7 simple (?) questions I asked >in my mail [1], although it was one of the very first three mails on the >topic. So what did I do wrong? Was it that I mentioned the missing FESCo That's the problem with email threads that are so large. People miss things because they don't always read every single email, regardless of what position in the thread it was. Even if they do, they might be busy replying to flames and other useless junk instead of important stuff. >meeting minutes? If 8 out of 21 summaries are missing, IMHO this is a >fact worth mentioning. They are missing because the minutes are done by FESCo members themselves and we are humans. That isn't to say that the minutes aren't important, but that people make mistakes and are busy and at times, things get missed. The IRC logs for almost all the meetings should be available though. Earlier in the year we tried a rotation of minutes takers to alleviate the burden on one person, but that seems to have failed. If someone wanted to volunteer to be the FESCo secretary, I'm sure we would welcome that. >I'm one of the few maintainers who directly is affected by the policy. >Would somebody - preferably a FESCo member, who voted for the flags >proposal - please be so kind to answer my questions. TIA! >https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01414.html 1) The rationale was given by spot here: https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01427.html or was that not what you were looking for? 2) The advantage for the project was to codify something that has been dealt with silently since the RHL days. That being said, the guideline itself is going to be revisited. 3) Your example of keyboard layout selection seems akin to language selection. In my opinion, under the existing guideline, the flags would not be allowed but you could ask FESCo for an exemption. Note, that is just my opinion and I don't speak for FESCo as a whole. 4) This is a good question. If you have specific examples of things that are not obviously 'religion' that you would like to have evaluated that might help. 5) I don't know the answer to your question, nor do I find it relevant in a discussion about flags. It's been pointed out several times that the flags policy opens doors to madness through defining 'acceptable' content, so let's not start yet another massive thread about that at the moment. 6) How do you make sure users are aware of -docs packages, or -devel packages? I see no difference here. 7) As FESCo for an exemption under the current guideline. josh From rc040203 at freenet.de Thu May 21 11:33:59 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 21 May 2009 13:33:59 +0200 Subject: Package Maintainers Flags policy In-Reply-To: <20090521104503.GB9004@hansolo.jdub.homelinux.org> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520102730.45a3b7d4@ohm.scrye.com> <20090521063007.GA21181@marx.bitnet> <4A14F85A.6030607@freenet.de> <20090521104503.GB9004@hansolo.jdub.homelinux.org> Message-ID: <4A153C27.7070103@freenet.de> Josh Boyer wrote: > On Thu, May 21, 2009 at 08:44:42AM +0200, Ralf Corsepius wrote: >> Jukka Ruohonen wrote: >>> Personally, I would rather give FESCo more power. >> Why? They already have almost "unlimited", almost "almighty" powers. > > This is untrue. Elaborate. What is untrue about this? The only restrictions imposed to FESCO are * FPB interfering * By law * Them being ignored. >>> Perhaps this could at >>> least end the shouting contest that Fedora developer mailing list has >>> become. >> They are being shouted at, because people do not agree with their >> "almighty wisdom". > > And that's fine. I don't think anyone on FESCo would claim they are almighty > though. Please refrain from being inflammatory. C.f. the rest of this thread. It clearly demonstrates FESCO's almightiness. From christoph.wickert at googlemail.com Thu May 21 12:20:52 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Thu, 21 May 2009 14:20:52 +0200 Subject: I must be doing something seriously wrong... In-Reply-To: <20090521113119.GA9316@hansolo.jdub.homelinux.org> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> Message-ID: <1242908453.6300.44.camel@localhost.localdomain> Josh, first of all I'd like to thank you for taking the time to answer my question. I really appreciate it. On Thu, 2009-05-21 at 07:31 -0400, Josh Boyer wrote: > On Thu, May 21, 2009 at 12:14:03PM +0200, Christoph Wickert wrote: > [snipped] > >meeting minutes? If 8 out of 21 summaries are missing, IMHO this is a > >fact worth mentioning. > > They are missing because the minutes are done by FESCo members themselves and > we are humans. That isn't to say that the minutes aren't important, but that > people make mistakes and are busy and at times, things get missed. The IRC > logs for almost all the meetings should be available though. Yes, but without the meeting minutes people might not even know there was a FESCo meeting, e. g. if it was an irregular one. FESCo cannot expect people to check for new logs every day just to be on the safe side. > Earlier in the year we tried a rotation of minutes takers to alleviate the > burden on one person, but that seems to have failed. If someone wanted to > volunteer to be the FESCo secretary, I'm sure we would welcome that. I don't think FESCo needs a secretary. Being a FESCo member gives you privileges, so one should also pull his duties. If not, IMHO the person is not qualified for FESCo, simple as that. (Sorry if this sounds harsh) > >I'm one of the few maintainers who directly is affected by the policy. > >Would somebody - preferably a FESCo member, who voted for the flags > >proposal - please be so kind to answer my questions. TIA! > > >https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01414.html > > 1) The rationale was given by spot here: > > https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01427.html > > or was that not what you were looking for? Not really. Spot just explained the rationale for writing the policy, but as I already outlined that the policy does not cover all the cases it was designed for. Maybe I should have asked more precisely: What is the use of a policy that does not really solve the problems? > 2) The advantage for the project was to codify something that has been > dealt with silently since the RHL days. That being said, the guideline itself > is going to be revisited. I agree that codification is a good thing, but I really don't see the benefit (see above) and your answer does not solve the apparent contradiction between "follow upstream" and "remove flags". We have two conflicting guidelines here, so which one is more important? > 3) Your example of keyboard layout selection seems akin to language selection. > In my opinion, under the existing guideline, the flags would not be allowed but > you could ask FESCo for an exemption. Note, that is just my opinion and I don't > speak for FESCo as a whole. Ok, then please some FESCo members please speak up. > 4) This is a good question. If you have specific examples of things that are > not obviously 'religion' that you would like to have evaluated that might help. How about Scientology, is it a religion? I don't think so, but I know there are people who see this differently, especially in the US. Also you only answered my question partly, I asked for a definition of an "ethnocultural concept". Even the assumed trivial terms are hard to define. What is "country"? Is Tibet one or Taiwan? > 5) I don't know the answer to your question, nor do I find it relevant in a > discussion about flags. It's been pointed out several times that the flags > policy opens doors to madness through defining 'acceptable' content, so let's > not start yet another massive thread about that at the moment. I do think it is relevant. The policy deals with religious flags, but it does not deal with religions symbols. I could draw a square around symbol and call it a flag. > 6) How do you make sure users are aware of -docs packages, or -devel packages? > I see no difference here. I do. -devel packages for example show up in comps and can be installed with groupinstall, but -flags can't. While developing or building a package you will most likely be pointed to a missing -devel package by a configure script or a failed make, but what will point you to the missing flags? Docs don't affect runtime of a program (as per packaging guidelines), but flags do. Not necessarily the fundamental functions of a package, but they *do* make the program behave differently than intended by it's developers. Just take deluge or my xfce4-xkp-plugin as examples. > 7) As FESCo for an exemption under the current guideline. Will do. Regards, Christoph From jwboyer at gmail.com Thu May 21 12:34:35 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 21 May 2009 08:34:35 -0400 Subject: Package Maintainers Flags policy In-Reply-To: <4A153C27.7070103@freenet.de> References: <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520102730.45a3b7d4@ohm.scrye.com> <20090521063007.GA21181@marx.bitnet> <4A14F85A.6030607@freenet.de> <20090521104503.GB9004@hansolo.jdub.homelinux.org> <4A153C27.7070103@freenet.de> Message-ID: <20090521123435.GA10004@hansolo.jdub.homelinux.org> On Thu, May 21, 2009 at 01:33:59PM +0200, Ralf Corsepius wrote: > Josh Boyer wrote: >> On Thu, May 21, 2009 at 08:44:42AM +0200, Ralf Corsepius wrote: >>> Jukka Ruohonen wrote: >>>> Personally, I would rather give FESCo more power. >>> Why? They already have almost "unlimited", almost "almighty" powers. >> >> This is untrue. > > Elaborate. What is untrue about this? > > The only restrictions imposed to FESCO are > * FPB interfering > * By law > * Them being ignored. Funny. All of those are the only restrictions applied to any existing packager too. Seems we're on even playing ground then, and FESCo really is an elected body that is _representative_ of the technical Fedora community. josh From jwboyer at gmail.com Thu May 21 12:46:54 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 21 May 2009 08:46:54 -0400 Subject: I must be doing something seriously wrong... In-Reply-To: <1242908453.6300.44.camel@localhost.localdomain> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> Message-ID: <20090521124654.GB10004@hansolo.jdub.homelinux.org> On Thu, May 21, 2009 at 02:20:52PM +0200, Christoph Wickert wrote: >Josh, > >first of all I'd like to thank you for taking the time to answer my >question. I really appreciate it. Sure, no problem. >On Thu, 2009-05-21 at 07:31 -0400, Josh Boyer wrote: >> On Thu, May 21, 2009 at 12:14:03PM +0200, Christoph Wickert wrote: >> [snipped] >> >meeting minutes? If 8 out of 21 summaries are missing, IMHO this is a >> >fact worth mentioning. >> >> They are missing because the minutes are done by FESCo members themselves and >> we are humans. That isn't to say that the minutes aren't important, but that >> people make mistakes and are busy and at times, things get missed. The IRC >> logs for almost all the meetings should be available though. > >Yes, but without the meeting minutes people might not even know there >was a FESCo meeting, e. g. if it was an irregular one. FESCo cannot >expect people to check for new logs every day just to be on the safe >side. Agreed. We're working on getting better about it again after our failed experiment. >> Earlier in the year we tried a rotation of minutes takers to alleviate the >> burden on one person, but that seems to have failed. If someone wanted to >> volunteer to be the FESCo secretary, I'm sure we would welcome that. > >I don't think FESCo needs a secretary. Being a FESCo member gives you I didn't say need. I was simply saying if someone wanted to help, that would be great. >privileges, so one should also pull his duties. If not, IMHO the person >is not qualified for FESCo, simple as that. (Sorry if this sounds harsh) It doesn't sound particularly harsh, but I wonder what privileges you think you get when you are in FESCo? >> >I'm one of the few maintainers who directly is affected by the policy. >> >Would somebody - preferably a FESCo member, who voted for the flags >> >proposal - please be so kind to answer my questions. TIA! >> >> >https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01414.html >> >> 1) The rationale was given by spot here: >> >> https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01427.html >> >> or was that not what you were looking for? > >Not really. Spot just explained the rationale for writing the policy, >but as I already outlined that the policy does not cover all the cases >it was designed for. Maybe I should have asked more precisely: What is >the use of a policy that does not really solve the problems? I see. I think that is why a ticket has been opened to revisit this. Stay tuned! >> 2) The advantage for the project was to codify something that has been >> dealt with silently since the RHL days. That being said, the guideline itself >> is going to be revisited. > >I agree that codification is a good thing, but I really don't see the >benefit (see above) and your answer does not solve the apparent >contradiction between "follow upstream" and "remove flags". We have two >conflicting guidelines here, so which one is more important? In general terms, 'follow the Fedora policy' trumps 'follow upstream' (see mp3). I think we try to make sure the policies don't conflict with upstream where we can. The flags issue certainly does though. >> 3) Your example of keyboard layout selection seems akin to language selection. >> In my opinion, under the existing guideline, the flags would not be allowed but >> you could ask FESCo for an exemption. Note, that is just my opinion and I don't >> speak for FESCo as a whole. > >Ok, then please some FESCo members please speak up. Honestly, I think it would be best to let the revisit of the guideline happen first. If nothing changes as an outcome of that, then we can start soliciting opinions on specific items (or opening tickets for exemptions). >> 4) This is a good question. If you have specific examples of things that are >> not obviously 'religion' that you would like to have evaluated that might help. > >How about Scientology, is it a religion? I don't think so, but I know >there are people who see this differently, especially in the US. Also >you only answered my question partly, I asked for a definition of an >"ethnocultural concept". Even the assumed trivial terms are hard to >define. What is "country"? Is Tibet one or Taiwan? This is a good question, and I don't have an answer for you off the top of my head. >> 5) I don't know the answer to your question, nor do I find it relevant in a >> discussion about flags. It's been pointed out several times that the flags >> policy opens doors to madness through defining 'acceptable' content, so let's >> not start yet another massive thread about that at the moment. > >I do think it is relevant. The policy deals with religious flags, but it >does not deal with religions symbols. I could draw a square around >symbol and call it a flag. And I could remove a square from the flag and call it a symbol. Discussing theoreticals at this point is only going to lead us to more and more absurd cases. I don't think we're here to draft policies that cover every possible situation whether it will ever happen in real life or not. > >> 6) How do you make sure users are aware of -docs packages, or -devel packages? >> I see no difference here. > >I do. -devel packages for example show up in comps and can be installed >with groupinstall, but -flags can't. While developing or building a Why can't they show up in comps? >package you will most likely be pointed to a missing -devel package by a >configure script or a failed make, but what will point you to the >missing flags? >Docs don't affect runtime of a program (as per packaging guidelines), >but flags do. Not necessarily the fundamental functions of a package, >but they *do* make the program behave differently than intended by it's >developers. Just take deluge or my xfce4-xkp-plugin as examples. You asked about how we make sure users are aware of -flags packages. I stated that I see no difference from how we make users aware of -docs packages. Your reply doesn't address that. Instead you described the functional difference between -flags and -docs. The original question was about advertising to the users. So how do we advertise -docs packages to users, and why isn't that sufficient for -flags? josh From zprikryl at redhat.com Thu May 21 12:47:14 2009 From: zprikryl at redhat.com (Zdenek Prikryl) Date: Thu, 21 May 2009 14:47:14 +0200 Subject: Abrt - should this be a feature? In-Reply-To: References: <4A0DC949.7000601@fedoraproject.org> <4A116F78.3020607@redhat.com> <4A118A4C.3050909@fedoraproject.org> <4A1290AD.90205@redhat.com> Message-ID: <4A154D52.1000500@redhat.com> Colin Walters wrote: > On Tue, May 19, 2009 at 6:57 AM, Jiri Moskovcak wrote: >> Because if the crash is handled by bb abrt won't detect it at all. It's the >> same for applications which have their own crash handlers (like pidgin). > > We can disable bug-buddy very easily (trivially) if ABRT is ready (is > it?). An important concern is having a story to tell the GNOME > project for how we're going to be providing them with bug data. If > ABRT's server side component had say a filtered list of crashes in > GNOME projects, or some automated way for developers to get at that > data that'd be useful. > ABRT can catch all bugs, which bb can. It is ready in this point of view. But right now there is no way how to filter out gnome or kde stuff and report it to their bz. if ABRT detect a problem and an user wants to report it, the report can go either to our bz or it is just logged or whatever (it depends on configuration). -- Zdenek Prikryl From joe at nall.com Thu May 21 12:57:46 2009 From: joe at nall.com (Joe Nall) Date: Thu, 21 May 2009 07:57:46 -0500 Subject: [RFC] Increase default ulimit nofile In-Reply-To: <1242884986.4509.12.camel@localhost.localdomain> References: <1242884986.4509.12.camel@localhost.localdomain> Message-ID: On May 21, 2009, at 12:49 AM, Jon Masters wrote: > Folks, > > While digging through a fault in GNOME and Rhythmbox this evening, I > happened upon this nugget. By default, we're still living in 1970: > > [jcm at tonnant ~]$ ulimit -n > 1024 > > Now. This might be great for a honking great shared UNIX server from > the > days of yore, but it's not remotely appropriate for a modern desktop. > Especially not one layered with so many per-user daemons and layers of > abstraction as we have on modern Linux systems. > > I suggest /etc/security/limits.conf be modified to include something > like the following, along with advice for sysadmins: > > * - nofile 8192 > > Discuss. > > --- background to discovering this problem --- > > I like podcasts. A lot. I also like rhythmbox (mostly). I've been > wondering recently why I would occasionally not be able to download > podcasts in rhythmbox. It seemed to be related to when I was connected > to a particular VPN and so I had dismissed it as being network DNSness > weirdness. But then it started happening much more often. Tonight, I > decided it was probably more than occasional network weirdness. > > So I decided "I'll just fire up gdb on rhythmbox". Many debuginfo > packages, cscopes, hacked up source, etc. later on, I discover the > "problem" is in abstraction layer number 2 - totem-pl-parser. So I > download the source to this package also, rebuild and hack it up. I > eventually discovered that various GError objects were happily telling > me that the maximum number of open files had been exceeded, but totem > never exposes this to rhythmbox, and the latter just has no idea what > the heck is causing it to fail. Some serious fail happening there. Isn't that like putting a bigger gas tank on your Hummer? Did you file a bz on the file descriptor leak in totem-pl-parser? joe From jreznik at redhat.com Thu May 21 13:11:13 2009 From: jreznik at redhat.com (Jaroslav Reznik) Date: Thu, 21 May 2009 09:11:13 -0400 (EDT) Subject: Abrt - should this be a feature? In-Reply-To: <4A154D52.1000500@redhat.com> Message-ID: <1701675198.906261242911473116.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com> ----- "Zdenek Prikryl" wrote: > Colin Walters wrote: > > On Tue, May 19, 2009 at 6:57 AM, Jiri Moskovcak > wrote: > >> Because if the crash is handled by bb abrt won't detect it at all. > It's the > >> same for applications which have their own crash handlers (like > pidgin). > > > > We can disable bug-buddy very easily (trivially) if ABRT is ready > (is > > it?). An important concern is having a story to tell the GNOME > > project for how we're going to be providing them with bug data. If > > ABRT's server side component had say a filtered list of crashes in > > GNOME projects, or some automated way for developers to get at that > > data that'd be useful. > > > > ABRT can catch all bugs, which bb can. It is ready in this point of > view. But > right now there is no way how to filter out gnome or kde stuff and > report it to > their bz. if ABRT detect a problem and an user wants to report it, the > report > can go either to our bz or it is just logged or whatever (it depends > on > configuration). KDE have brand new Dr. Konqui - in term of features it's quite similar to what ABRT offers but it's KDE only. Still I think it's better to use it for KDE crashes. It's part of 4.3 (in rawhide) - so F12 stuff. But try it - there are still some bugs. Some nice features are starring usefulness of bug (eg. no backtraces), duplicates etc. with nice easy to use GUI for users. For sysconfigs we have SCTCPBRT now, it's more BRT than your BRT :-) Actually it could be part of your BRT if you're interested, it's our internal tool to report sysconfigs bugs. Jaroslav > -- > Zdenek Prikryl > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From mzerqung at 0pointer.de Thu May 21 13:14:19 2009 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Thu, 21 May 2009 15:14:19 +0200 Subject: [RFC] Increase default ulimit nofile In-Reply-To: <1242884986.4509.12.camel@localhost.localdomain> References: <1242884986.4509.12.camel@localhost.localdomain> Message-ID: <20090521131419.GA16340@tango.0pointer.de> On Thu, 21.05.09 01:49, Jon Masters (jonathan at jonmasters.org) wrote: Heya! > I like podcasts. A lot. I also like rhythmbox (mostly). I've been > wondering recently why I would occasionally not be able to download > podcasts in rhythmbox. It seemed to be related to when I was connected > to a particular VPN and so I had dismissed it as being network DNSness > weirdness. But then it started happening much more often. Tonight, I > decided it was probably more than occasional network weirdness. > > So I decided "I'll just fire up gdb on rhythmbox". Many debuginfo > packages, cscopes, hacked up source, etc. later on, I discover the > "problem" is in abstraction layer number 2 - totem-pl-parser. So I > download the source to this package also, rebuild and hack it up. I > eventually discovered that various GError objects were happily telling > me that the maximum number of open files had been exceeded, but totem > never exposes this to rhythmbox, and the latter just has no idea what > the heck is causing it to fail. Some serious fail happening there. I am pretty sure this is an fd leak somewhere in totem. Normally a gnome process should need not more than 50, maybe 100 fds. In fact, if I do the following line in my GNOME session (which has been running since a week or so and is running all kinds of processes, including Firefox with two windows and 20 tabs, and so on): for a in /proc/*/fd/ ; do ls $a 2> /dev/null | wc -l ; done | sort -n Then the biggest number I get is 78 (firefox) -- with the exception of a BitTorrent client, that is at 250 -- probably rightfully so. Before you ask for a higher resource limit, file a bug and find out if this isn't a simple leak that needs to be fixed. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From pingou at pingoured.fr Thu May 21 13:09:19 2009 From: pingou at pingoured.fr (Pierre-Yves) Date: Thu, 21 May 2009 15:09:19 +0200 Subject: I must be doing something seriously wrong... In-Reply-To: <20090521124654.GB10004@hansolo.jdub.homelinux.org> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <20090521124654.GB10004@hansolo.jdub.homelinux.org> Message-ID: <1242911359.3356.13.camel@red.localdomain> On Thu, 2009-05-21 at 08:46 -0400, Josh Boyer wrote: > > The original question was about advertising to the users. So how do > we > advertise -docs packages to users, and why isn't that sufficient for > -flags? > Do we ? I'm aware of -docs package because I'm involved enough in the project and know how to use yum or how to find information. However, I have never seen (or very little) advertisement around -docs package. Actually I think the only case that comes in my mind are tutorials and documentation where is written yum install apache-docs to install apache (that way the -docs package brings the normal one). Maybe packageKit pointing out / highlighting package that have subpackage (such as -docs or -flags) might help this advertisement. Best regards, Pierre From jwboyer at gmail.com Thu May 21 13:28:09 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 21 May 2009 09:28:09 -0400 Subject: I must be doing something seriously wrong... In-Reply-To: <1242911359.3356.13.camel@red.localdomain> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <20090521124654.GB10004@hansolo.jdub.homelinux.org> <1242911359.3356.13.camel@red.localdomain> Message-ID: <20090521132809.GA10282@hansolo.jdub.homelinux.org> On Thu, May 21, 2009 at 03:09:19PM +0200, Pierre-Yves wrote: >On Thu, 2009-05-21 at 08:46 -0400, Josh Boyer wrote: >> >> The original question was about advertising to the users. So how do >> we >> advertise -docs packages to users, and why isn't that sufficient for >> -flags? >> >Do we ? > >I'm aware of -docs package because I'm involved enough in the project >and know how to use yum or how to find information. However, I have >never seen (or very little) advertisement around -docs package. >Actually I think the only case that comes in my mind are tutorials and >documentation where is written yum install apache-docs to install apache >(that way the -docs package brings the normal one). Right. That was sort of my point :). >Maybe packageKit pointing out / highlighting package that have >subpackage (such as -docs or -flags) might help this advertisement. Possibly. Something like: "Want to learn more about this application? Install foo-doc" I dunno. I suck at designing user interfaces. As long as PK doesn't grow a 'helpful' paperclip, I don't care. josh From rawhide at fedoraproject.org Thu May 21 13:40:19 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Thu, 21 May 2009 13:40:19 +0000 (UTC) Subject: rawhide report: 20090521 changes Message-ID: <20090521134019.265D41B8003@releng2.fedora.phx.redhat.com> Compose started at Thu May 21 06:15:04 UTC 2009 Updated Packages: DeviceKit-disks-004-3.fc11 -------------------------- * Tue May 19 2009 David Zeuthen - 004-3.fc11 - Avoid checking whether device is ATA SMART capable if the device reports removable media (#494932) e2fsprogs-1.41.4-10.fc11 ------------------------ * Wed May 20 2009 Eric Sandeen 1.41.4-10 - Fix minimum resize calculation and enforce it (#499452) fedora-logos-11.0.6-1.fc11 -------------------------- * Mon May 18 2009 Tom "spot" Callaway 11.0.6-1 - drop "lowres" image, saves a small amount of diskspace kernel-2.6.29.3-155.fc11 ------------------------ * Wed May 20 2009 Kyle McMartin 2.6.29.3-154 - disable e820 backports, causes problems in some places, bz#499396. linux-2.6-e820-save-restore-edi-ebp.patch linux-2.6-e820-acpi3-bios-workaround.patch linux-2.6-e820-guard-against-pre-acpi3.patch * Wed May 20 2009 - 2.6.29.3-155 - Add drm-intel-i8xx-cursors.patch to fix cursors on i8xx desktop chipsets (#488980). - Add drm-intel-vmalloc.patch as part of the fix for #498131. * Tue May 19 2009 Kyle McMartin 2.6.29.3-151 - net-revert-forcedeth-power-down-phy-when-interface-is.patch: revert only hunks that powered down the phy. fixes rhbz#501249. * Tue May 19 2009 Kyle McMartin 2.6.29.3-153 - drm-intel-gem-use-dma32-on-pae.patch: Force GEM allocations to be DMA32 when using PAE. This should fix bz#493526. Leave the gfp flags for every other chipset (radeon, really...) unset so we don't fribble the flags. - agp-set_memory_ucwb.patch: comment out rejecting hunk that's no longer necessary (forcing gem on with highmem64g.) * Mon May 18 2009 Josef Bacik - fix page_mkwrite in btrfs * Mon May 18 2009 Justin M. Forbes - xen/blkfront: fix warning when deleting gendisk on unplug/shutdown. BZ# 499621 - xen/blkfront: allow xenbus state transition to closing->closed when not connected * Mon May 18 2009 Kyle McMartin - increase-MAX_LOCKDEP_ENTRIES.patch: suck in upstream fix d80c19df5fcceb8c741e96f09f275c2da719efef * Mon May 18 2009 Justin M. Forbes - Disable GB pages for Xen guests BZ# 499592 * Mon May 18 2009 Adam Jackson - Expose whether VGA devices were active at boot or not in sysfs. * Mon May 18 2009 Kyle McMartin - drm-intel-include-965gme-pci-id.patch: add patch patch from git head to treat 965GME like 965GM. module-init-tools-3.7-9.fc11 ---------------------------- * Tue May 19 2009 Jeremy Katz - 3.7-9 - Move /etc/modprobe.d/anaconda if it exists (#496261) * Mon May 11 2009 Jon Masters - 3.7-8 (pre9) - Rename /etc/modprobe.conf to /etc/modprobe.d/local.conf on upgrade (#488768) nautilus-2.26.3-1.fc11 ---------------------- * Tue May 19 2009 Tomas Bzatek - 2.26.3-1 - Update to 2.26.3 pungi-2.0.15-1.fc11 ------------------- * Tue May 19 2009 Jesse Keating - 2.0.15-1 - Split media on demand rather than via guess work. selinux-policy-3.6.12-39.fc11 ----------------------------- * Wed May 20 2009 Dan Walsh 3.6.12-39 - Allow fprintd to access sys_ptrace - Add sandbox policy * Mon May 18 2009 Dan Walsh 3.6.12-38 - Add varnishd policy * Thu May 14 2009 Dan Walsh 3.6.12-37 - Fixes for kpropd * Tue May 12 2009 Dan Walsh 3.6.12-36 - Allow brctl to r/w tun_tap_device_t xorg-x11-drv-synaptics-1.1.0-7.fc11 ----------------------------------- * Tue May 19 2009 Peter Hutterer 1.1.0-7 - Update synaptics-1.1.0-nograb-fail.patch: bad return value led to non-synaptics devices to be treated as synaptics devices (#499792) * Mon May 18 2009 Peter Hutterer 1.1.0-6 - synaptics-1.1.0-synclient-accel-max.patch: update synclient's maximum value for AccelFactor to 1.0. Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 9 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From markg85 at gmail.com Thu May 21 14:04:45 2009 From: markg85 at gmail.com (Mark) Date: Thu, 21 May 2009 16:04:45 +0200 Subject: FESCo election nominations now open In-Reply-To: References: Message-ID: <6e24a8e80905210704n3a9d7174v768860a4b1315c7f@mail.gmail.com> On Thu, May 21, 2009 at 6:33 AM, Jon Stanley wrote: > Election season is here again in Fedora! ?Nominations are now open for > the five open seats on FESCo. ?The following members have terms > expiring this cycle: > > * Kevin Fenzi > * Dennis Gilmore > * Bill Nottingham > * Brian Pepple > * David Woodhouse > > Any interested Fedora packager may run for FESCo, the only requirement > is membership in the 'packager' group in FAS. ?Especially noteworthy > is that 'provenpackager' or sponsor status is not required - this > keeps the bar low for new members. > > Nominations are open through 29 May 09 at > https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations. > > More general information about the election process can be found at > https://fedoraproject.org/wiki/Elections Just wondering one thing. Why can "packagers" (and only those) apply for fesco? Is there any special reason for that? From poelstra at redhat.com Thu May 21 14:07:38 2009 From: poelstra at redhat.com (John Poelstra) Date: Thu, 21 May 2009 07:07:38 -0700 Subject: FESCo election nominations now open In-Reply-To: References: Message-ID: <4A15602A.90100@redhat.com> Jon Stanley said the following on 05/20/2009 09:33 PM Pacific Time: > Election season is here again in Fedora! Nominations are now open for > the five open seats on FESCo. The following members have terms > expiring this cycle: > > * Kevin Fenzi > * Dennis Gilmore > * Bill Nottingham > * Brian Pepple > * David Woodhouse > > Any interested Fedora packager may run for FESCo, the only requirement > is membership in the 'packager' group in FAS. Especially noteworthy > is that 'provenpackager' or sponsor status is not required - this > keeps the bar low for new members. Is this a new requirement--being a "Fedora packager"--and if so where is it documented? I can see the logic, but I do not recall seeing this requirement in the past. John From walters at verbum.org Thu May 21 14:14:20 2009 From: walters at verbum.org (Colin Walters) Date: Thu, 21 May 2009 10:14:20 -0400 Subject: [RFC] Increase default ulimit nofile In-Reply-To: <1242884986.4509.12.camel@localhost.localdomain> References: <1242884986.4509.12.camel@localhost.localdomain> Message-ID: On Thu, May 21, 2009 at 1:49 AM, Jon Masters wrote: > > Now. This might be great for a honking great shared UNIX server from the > days of yore, but it's not remotely appropriate for a modern desktop. > Especially not one layered with so many per-user daemons and layers of > abstraction as we have on modern Linux systems. Well, one of the design points of DBus is that you only have a total of one file descriptor for normal processes to do most IPC to others, routed via the message bus; as opposed to say ORBit where it scales as O(N). So adding more daemons and components shouldn't normally equate to more file descriptors. In other words agree with Lennart that it likely makes more sense to find this specific bug rather than globally increase the limit, in the absence of other examples at least. From bpepple at fedoraproject.org Thu May 21 14:26:06 2009 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 21 May 2009 10:26:06 -0400 Subject: FESCo election nominations now open In-Reply-To: <4A15602A.90100@redhat.com> References: <4A15602A.90100@redhat.com> Message-ID: <1242915966.4320.3.camel@localhost.localdomain> On Thu, 2009-05-21 at 07:07 -0700, John Poelstra wrote: > Is this a new requirement--being a "Fedora packager"--and if so where is > it documented? I can see the logic, but I do not recall seeing this > requirement in the past. Our election policy states that 'Candidates may be any member of the cvsextras group in the Fedora Accounts System'. http://fedoraproject.org/wiki/PackageMaintainers/Policy/FESCoElections Later, /B -- Brian Pepple https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jcm at redhat.com Thu May 21 14:26:56 2009 From: jcm at redhat.com (Jon Masters) Date: Thu, 21 May 2009 10:26:56 -0400 Subject: [RFC] Increase default ulimit nofile In-Reply-To: <20090521131419.GA16340@tango.0pointer.de> References: <1242884986.4509.12.camel@localhost.localdomain> <20090521131419.GA16340@tango.0pointer.de> Message-ID: <1242916016.10339.4.camel@localhost.localdomain> On Thu, 2009-05-21 at 15:14 +0200, Lennart Poettering wrote: > I am pretty sure this is an fd leak somewhere in totem. Not sure yet - it's possible. However, let's bear in mind regardless of this that 1024 is /way/ the heck too low when we allow a user to spawn 1024 /processes/. And they only get one file each?!!! We should have, for example, 8 x tasks, which is where 8192 came from. Jon. From jcm at redhat.com Thu May 21 14:29:10 2009 From: jcm at redhat.com (Jon Masters) Date: Thu, 21 May 2009 10:29:10 -0400 Subject: [RFC] Increase default ulimit nofile In-Reply-To: References: <1242884986.4509.12.camel@localhost.localdomain> Message-ID: <1242916150.10339.6.camel@localhost.localdomain> On Thu, 2009-05-21 at 10:14 -0400, Colin Walters wrote: > In other words agree with Lennart that it likely makes more sense to > find this specific bug rather than globally increase the limit, in the > absence of other examples at least. I'll agree that totem also needs fixing, especially they need to learn how to push error messages back up the stack so software can use it. Jon. From mitr at volny.cz Thu May 21 14:31:02 2009 From: mitr at volny.cz (Miloslav =?UTF-8?Q?Trma=C4=8D?=) Date: Thu, 21 May 2009 14:31:02 +0000 Subject: [RFC] Increase default ulimit nofile In-Reply-To: <1242916016.10339.4.camel@localhost.localdomain> References: <1242884986.4509.12.camel@localhost.localdomain> <20090521131419.GA16340@tango.0pointer.de> <1242916016.10339.4.camel@localhost.localdomain> Message-ID: <1242916262.3341.7.camel@localhost.localdomain> Jon Masters p??e v ?t 21. 05. 2009 v 10:26 -0400: > On Thu, 2009-05-21 at 15:14 +0200, Lennart Poettering wrote: > > > I am pretty sure this is an fd leak somewhere in totem. > > Not sure yet - it's possible. However, let's bear in mind regardless of > this that 1024 is /way/ the heck too low when we allow a user to spawn > 1024 /processes/. And they only get one file each?!!! We should have, > for example, 8 x tasks, which is where 8192 came from. RLIMIT_NOFILE is a per-process limit. Mirek From walters at verbum.org Thu May 21 14:35:39 2009 From: walters at verbum.org (Colin Walters) Date: Thu, 21 May 2009 10:35:39 -0400 Subject: Abrt - should this be a feature? In-Reply-To: <4A154D52.1000500@redhat.com> References: <4A0DC949.7000601@fedoraproject.org> <4A116F78.3020607@redhat.com> <4A118A4C.3050909@fedoraproject.org> <4A1290AD.90205@redhat.com> <4A154D52.1000500@redhat.com> Message-ID: On Thu, May 21, 2009 at 8:47 AM, Zdenek Prikryl wrote: > > ABRT can catch all bugs, which bb can. It is ready in this point of view. But > right now there is no way how to filter out gnome or kde stuff and report it to > their bz. if ABRT detect a problem and an user wants to report it, the report > can go either to our bz or it is just logged or whatever (it depends on > configuration). That sounds fine, the filtering/export is something we can add later. I forgot to mention the most important thing, which is that right now bug-buddy is limited in usefulness to the GNOME project because of the -debuginfo split; concretely because stack traces in bugzilla are essentially just lots of "??". To pick a random one, http://bugzilla.gnome.org/show_bug.cgi?id=565819 I'm reading the architecture page now, but I'm not seeing how ABRT works in this respect. Does ABRT have a "retracer" server component like Apport/Breakpad, or does it somehow ensure -debuginfo gets installed on the client? Or does it rely on a modified gdb to just-in-time fetch the data from an ABRT web service? Something else? Basically, if ABRT solves this problem we should just replace bug-buddy without hesitation. Should we consider this in an F11 update, or move to F12? From langel at redhat.com Thu May 21 15:04:03 2009 From: langel at redhat.com (Lillian Angel) Date: Thu, 21 May 2009 11:04:03 -0400 Subject: Where to post an experimental package? (java-1.7.0-openjdk) In-Reply-To: References: <4A0C2DBA.4080502@redhat.com> <1242316501.6282.56.camel@localhost.localdomain> <4A0C54C0.1010605@redhat.com> Message-ID: <4A156D63.3040707@redhat.com> Matej Cepl wrote: > Lillian Angel, Thu, 14 May 2009 13:28:32 -0400: > >> 6 or 7 packages in total. No interdependencies. >> > > Size is what matters ... check you quota on fedorapeople (and ask for > extension, if necessary). Oh yes. Any idea who I would contact for that? The quota is set to 150MB, and I will need much more than that... 500MB-1GB. Thanks, Lillian From sundaram at fedoraproject.org Thu May 21 15:12:14 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 21 May 2009 20:42:14 +0530 Subject: Where to post an experimental package? (java-1.7.0-openjdk) In-Reply-To: <4A156D63.3040707@redhat.com> References: <4A0C2DBA.4080502@redhat.com> <1242316501.6282.56.camel@localhost.localdomain> <4A0C54C0.1010605@redhat.com> <4A156D63.3040707@redhat.com> Message-ID: <4A156F4E.40708@fedoraproject.org> On 05/21/2009 08:34 PM, Lillian Angel wrote: > Matej Cepl wrote: >> Lillian Angel, Thu, 14 May 2009 13:28:32 -0400: >> >>> 6 or 7 packages in total. No interdependencies. >>> >> >> Size is what matters ... check you quota on fedorapeople (and ask for >> extension, if necessary). > > Oh yes. Any idea who I would contact for that? The quota is set to > 150MB, and I will need much more than that... 500MB-1GB. You have to contact Fedora infrastructure team. Catch-all id is admin AT fedoraproject.org Rahul From sundaram at fedoraproject.org Thu May 21 15:15:13 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 21 May 2009 20:45:13 +0530 Subject: FESCo election nominations now open In-Reply-To: <1242915966.4320.3.camel@localhost.localdomain> References: <4A15602A.90100@redhat.com> <1242915966.4320.3.camel@localhost.localdomain> Message-ID: <4A157001.80107@fedoraproject.org> On 05/21/2009 07:56 PM, Brian Pepple wrote: > On Thu, 2009-05-21 at 07:07 -0700, John Poelstra wrote: >> Is this a new requirement--being a "Fedora packager"--and if so where is >> it documented? I can see the logic, but I do not recall seeing this >> requirement in the past. > > Our election policy states that 'Candidates may be any member of the > cvsextras group in the Fedora Accounts System'. > > http://fedoraproject.org/wiki/PackageMaintainers/Policy/FESCoElections IMO, it made sense only during the time when it was a steering committee for the Fedora Extras repository. Now FESCo duties are broad and I don't see why someone only involved with artwork, L10N or documentation but not packaging shouldn't be a leader. Rahul From cmadams at hiwaay.net Thu May 21 15:22:21 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 21 May 2009 10:22:21 -0500 Subject: [RFC] Increase default ulimit nofile In-Reply-To: <1242916016.10339.4.camel@localhost.localdomain> References: <1242884986.4509.12.camel@localhost.localdomain> <20090521131419.GA16340@tango.0pointer.de> <1242916016.10339.4.camel@localhost.localdomain> Message-ID: <20090521152221.GC620322@hiwaay.net> Once upon a time, Jon Masters said: > On Thu, 2009-05-21 at 15:14 +0200, Lennart Poettering wrote: > > I am pretty sure this is an fd leak somewhere in totem. > > Not sure yet - it's possible. However, let's bear in mind regardless of > this that 1024 is /way/ the heck too low when we allow a user to spawn > 1024 /processes/. And they only get one file each?!!! We should have, > for example, 8 x tasks, which is where 8192 came from. That is a per-process limit, not per-user. Also, if something is leaking up to 1024, and you raise the limit, who's to say it won't leak right up to 8192 next? For the vast majority of programs, 1024 is way more than they'd ever need (or be able to manage properly). The few that can really use more typically daemons that are started by root and know how to raise the limit themselves. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From a.badger at gmail.com Thu May 21 15:26:54 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 21 May 2009 08:26:54 -0700 Subject: I must be doing somthing seriously wrong... In-Reply-To: <20090521113119.GA9316@hansolo.jdub.homelinux.org> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> Message-ID: <4A1572BE.7010907@gmail.com> On 05/21/2009 04:31 AM, Josh Boyer wrote: > On Thu, May 21, 2009 at 12:14:03PM +0200, Christoph Wickert wrote: > > That's the problem with email threads that are so large. People miss things > because they don't always read every single email, regardless of what position > in the thread it was. Even if they do, they might be busy replying to flames > and other useless junk instead of important stuff. > [...] > >> https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01414.html > Note, as mentioned there, the questions I raised in the original ticket[1]_ still weren't answered either. Those questions were about applying the policy to real packages to delimit the intended scope. Here's a summary: The policy contains: """ * Flags used for gaming purposes, such as a game that uses flags to represent country/language selection In this specific case, the flag usage is not acceptable. The flag use here is almost certainly not essential. """ Is the flag usage not-acceptable because the flag is being used for language selection? Or is it not-acceptable because the flag is being used in a game? If it's because it's in a game the example is broader than the policy. A WWII simulation would have a real justification to use flags from the countries involved. freeciv gives the player the option to play as a historical leader from an actual country with appropriate background. These seem to be technically (user interface requires something that denotes a specific country) and substantively (other information linking to real geopolitical entities is given) necessary. I go on to ask about games which need to have team identifiers and presently use flags but don't have other identifying elements as a followup. [...] >> 7. What to do with a package that wont work without flags? > > 7) As FESCo for an exemption under the current guideline. > Note, the policy portion of the current document and the examples are in conflict over whether FESCo needs to be asked for an exemption and should be clarified along with the other changes made to it: The policy says this: """ When a package contains flag images [...] where such use is not technically or substantively essential to the package, those flag images must be placed in an -flags subpackage. """ In this section the policy is saying which packages it applies to. Packages not covered by this statement should not be handled by the policy. (ie, if flag usage is technically or substantively essential than the policy does not apply to it). However, in the Examples area it says: """ Flags used for educational purposes, [...] In this specific case, the flag usage would be acceptable. Instances like this must be examined on a case-by-case basis by FESCo, but they will often be acceptable because they are substantively essential to the core function of the package. """ Instead of saying that those types of packages are not covered by the Policy, it is saying that those types of packages are covered by the Policy but are likely candidates for an exemption due to the technical and substantive clause. There are two ways to fix that: 1) Change the example to say "In this specific case, the flag usage would be acceptable because they are substantively essential to the core function of the package." 2) Move the technical and substantive clause into the exceptions section of the policy: """ == Exceptions == Any packager who feels that they should be granted an exception to this policy should escalate the issue to FESCo for review. Common reasons for exceptions are that the flag usage is technically and substantively required by the package. """ When designing Fedora Packaging Guidelines we try to avoid having guidelines that require exceptions to be granted if we can elucidate the reasons that an exception would be granted. This leads to less of a burden on FESCo to review the exceptions and better expectations by packager and reviewer of what is meant by the guidelines. For those reasons, #1 seems like the better option to me. Since this is a FESCo policy, not a Packaging Guideline, you'll need to decide if that's a goal for yourself, though. .. _[1]: https://fedorahosted.org/fesco/ticket/110 From jkeating at redhat.com Thu May 21 15:28:13 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 21 May 2009 08:28:13 -0700 Subject: FESCo election nominations now open In-Reply-To: <4A157001.80107@fedoraproject.org> References: <4A15602A.90100@redhat.com> <1242915966.4320.3.camel@localhost.localdomain> <4A157001.80107@fedoraproject.org> Message-ID: <1242919693.3029.83.camel@localhost.localdomain> On Thu, 2009-05-21 at 20:45 +0530, Rahul Sundaram wrote: > IMO, it made sense only during the time when it was a steering committee > for the Fedora Extras repository. Now FESCo duties are broad and I don't > see why someone only involved with artwork, L10N or documentation but > not packaging shouldn't be a leader. That would make sense if they were making decisions and guidance over those groups, only I don't think they are. FESCo's primarily concerned with the packages and distribution release side of the house. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From matt at truch.net Thu May 21 15:32:21 2009 From: matt at truch.net (Matthew D Truch) Date: Thu, 21 May 2009 11:32:21 -0400 Subject: [RFC] Increase default ulimit nofile In-Reply-To: References: <1242884986.4509.12.camel@localhost.localdomain> Message-ID: <20090521153221.GF8782@truch.net> > > Now. This might be great for a honking great shared UNIX server from the > > days of yore, but it's not remotely appropriate for a modern desktop. > > Especially not one layered with so many per-user daemons and layers of > > abstraction as we have on modern Linux systems. > > Well, one of the design points of DBus is that you only have a total > of one file descriptor for normal processes to do most IPC to others, > routed via the message bus; as opposed to say ORBit where it scales as > O(N). So adding more daemons and components shouldn't normally equate > to more file descriptors. > > In other words agree with Lennart that it likely makes more sense to > find this specific bug rather than globally increase the limit, in the > absence of other examples at least. Well, I've certainly had to bump it up to 8192 on several of the machines I run. The short version is we have a data aquisition system which records many timestreams of data. For ease of processing (and display of subsets of the data) we save each raw timestream as an individual file (using the getdata library, http://getdata.sourceforge.net/). We sometimes have run into the 1024 limit on the project I work on, and some of the projects my collegues work on always run into this (having a few thousand timestreams to record concurently). Obviously any file-descriptor leak should be fixed, but there are cases where a couple thousand files need to be opened simultaneously. -- "If you drop your keys into a river of molten lava, forget about them, they're gone!" -------------------------- Matthew Truch Department of Physics and Astronomy University of Pennsylvania matt at truch.net http://matt.truch.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Thu May 21 15:38:58 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 21 May 2009 21:08:58 +0530 Subject: FESCo election nominations now open In-Reply-To: <1242919693.3029.83.camel@localhost.localdomain> References: <4A15602A.90100@redhat.com> <1242915966.4320.3.camel@localhost.localdomain> <4A157001.80107@fedoraproject.org> <1242919693.3029.83.camel@localhost.localdomain> Message-ID: <4A157592.9060704@fedoraproject.org> On 05/21/2009 08:58 PM, Jesse Keating wrote: > On Thu, 2009-05-21 at 20:45 +0530, Rahul Sundaram wrote: >> IMO, it made sense only during the time when it was a steering committee >> for the Fedora Extras repository. Now FESCo duties are broad and I don't >> see why someone only involved with artwork, L10N or documentation but >> not packaging shouldn't be a leader. > > That would make sense if they were making decisions and guidance over > those groups, only I don't think they are. FESCo has grown from being a group concerned only about packages in a add-on repository into something much larger. FESCo is responsible for all technical decisions in Fedora including those that affect these groups. Rahul From jwboyer at gmail.com Thu May 21 15:44:03 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 21 May 2009 11:44:03 -0400 Subject: FESCo election nominations now open In-Reply-To: <4A157592.9060704@fedoraproject.org> References: <4A15602A.90100@redhat.com> <1242915966.4320.3.camel@localhost.localdomain> <4A157001.80107@fedoraproject.org> <1242919693.3029.83.camel@localhost.localdomain> <4A157592.9060704@fedoraproject.org> Message-ID: <20090521154403.GA10929@hansolo.jdub.homelinux.org> On Thu, May 21, 2009 at 09:08:58PM +0530, Rahul Sundaram wrote: >On 05/21/2009 08:58 PM, Jesse Keating wrote: >> On Thu, 2009-05-21 at 20:45 +0530, Rahul Sundaram wrote: >>> IMO, it made sense only during the time when it was a steering committee >>> for the Fedora Extras repository. Now FESCo duties are broad and I don't >>> see why someone only involved with artwork, L10N or documentation but >>> not packaging shouldn't be a leader. >> >> That would make sense if they were making decisions and guidance over >> those groups, only I don't think they are. > >FESCo has grown from being a group concerned only about packages in a >add-on repository into something much larger. FESCo is responsible for >all technical decisions in Fedora including those that affect these groups. Not that I'm disagreeing with you, but what technical decisions effect artwork or translations or the management of documentation? I cannot remember ever dealing with anything involving artwork in my entire tenure in FESCo. Documentation is impacted from a content point of view, but they have their own committee and aside from the Feature stuff FESCo doesn't really have any direct impact on them. Similarly for translation. josh From ewan at macmahon.me.uk Thu May 21 15:52:53 2009 From: ewan at macmahon.me.uk (Ewan Mac Mahon) Date: Thu, 21 May 2009 16:52:53 +0100 Subject: Package Maintainers Flags policy In-Reply-To: <1242767869.3029.13.camel@localhost.localdomain> References: <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> <20090519181454.GA4397@nostromo.devel.redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <4A131DC6.8000605@gmail.com> <1242767869.3029.13.camel@localhost.localdomain> Message-ID: <20090521155252.GH32139@macmahon.me.uk> On Tue, May 19, 2009 at 02:17:49PM -0700, Jesse Keating wrote: > On Tue, 2009-05-19 at 13:59 -0700, Toshio Kuratomi wrote: > > That's easier for releng but just as hard for the packager. > > Yes, it is unfortunate that our package set got to the point where flags > existed in some of the packages, and that the unwritten rule from RHL > and Fedora Core didn't make it forward into Fedora, the no flags rule. I've just been having a look back at the FreeCiv versions from RHL and Fedora core. It's not an exhaustive survey, but at least RHL 5.2, 6.2, 7.3, 8 and 9, and Fedora Cores 1, 2 and 3 contained FreeCiv packages, complete with various flags. As of FC4 the package seems to disappear from Core, probably in favour of the one in Extras, and the earlier versions of RHL seem to have bits missing from the copies on archive.download.redhat.com, so it's hard to tell whether they included FreeCiv or not. I think it's safe to say that if this unwritten rule ever existed, it certainly wasn't enforced. Ewan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at gmail.com Thu May 21 15:54:09 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 21 May 2009 11:54:09 -0400 Subject: I must be doing somthing seriously wrong... In-Reply-To: <4A1572BE.7010907@gmail.com> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <4A1572BE.7010907@gmail.com> Message-ID: <20090521155409.GB10929@hansolo.jdub.homelinux.org> On Thu, May 21, 2009 at 08:26:54AM -0700, Toshio Kuratomi wrote: > On 05/21/2009 04:31 AM, Josh Boyer wrote: >> On Thu, May 21, 2009 at 12:14:03PM +0200, Christoph Wickert wrote: >> >> That's the problem with email threads that are so large. People miss things >> because they don't always read every single email, regardless of what position >> in the thread it was. Even if they do, they might be busy replying to flames >> and other useless junk instead of important stuff. >> > [...] >> >>> https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01414.html >> > Note, as mentioned there, the questions I raised in the original > ticket[1]_ still weren't answered either. Those questions were about > applying the policy to real packages to delimit the intended scope. I am aware of this. So, I could go on answering your perfectly valid questions based on my own opinion, which may or may not have any relevance to what FESCo decides. We could rinse and repeat all of that for whatever FESCo member chose to do so. We could further have more questions on this list directed at FESCo and expecting individual replies to them based on official statements from a _committee_. Or instead, we could state that this questions are noted, valued, and important and let FESCo discuss them as a _committee_ during it's designated _meeting_ it has weekly to discuss such issues. That would seem to be more prudent than just having a bunch of people reply with "I don't speak for FESCo but...". Toshio, I realize that your questions were asked before FESCo originally voted on the proposal. The fact that they weren't answered by the committee when they seem entirely relevant would appear to be a mistake on FESCo's part. Now that the issue has been raised again for discussion, perhaps we can wait for the meeting tomorrow and see what comes of it. josh From jkeating at redhat.com Thu May 21 16:03:17 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 21 May 2009 09:03:17 -0700 Subject: I must be doing something seriously wrong... In-Reply-To: <1242908453.6300.44.camel@localhost.localdomain> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> Message-ID: <1242921797.3029.84.camel@localhost.localdomain> On Thu, 2009-05-21 at 14:20 +0200, Christoph Wickert wrote: > Not really. Spot just explained the rationale for writing the policy, > but as I already outlined that the policy does not cover all the cases > it was designed for. Maybe I should have asked more precisely: What is > the use of a policy that does not really solve the problems? The policy of "No flags" solved the problem enough for RHT and RHL so that it was distributable and RHEL was sellable into China. Anything less than that policy is going to be up for debate as to if it "solves the problem". -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Thu May 21 16:05:51 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 21 May 2009 09:05:51 -0700 Subject: I must be doing something seriously wrong... In-Reply-To: <1242911359.3356.13.camel@red.localdomain> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <20090521124654.GB10004@hansolo.jdub.homelinux.org> <1242911359.3356.13.camel@red.localdomain> Message-ID: <1242921951.3029.86.camel@localhost.localdomain> On Thu, 2009-05-21 at 15:09 +0200, Pierre-Yves wrote: > Maybe packageKit pointing out / highlighting package that have > subpackage (such as -docs or -flags) might help this advertisement. There is an Online Docs group that has the -docs subpackage for many of the system-config-* packages. It uses conditionals which are painful, but would be a way for more -docs subpackages to be visible, and if the user wishes to have local documentation, if available, for the packages they've chosen, they can pick that group. The group name is a bit... wrong, but maybe a group of people that care about documentation could help come up with a better name, and help to ensure that all the available -docs packages get listed in this group. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bnocera at redhat.com Thu May 21 16:07:22 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Thu, 21 May 2009 17:07:22 +0100 Subject: [RFC] Increase default ulimit nofile In-Reply-To: <1242884986.4509.12.camel@localhost.localdomain> References: <1242884986.4509.12.camel@localhost.localdomain> Message-ID: <1242922042.13791.197.camel@cookie.hadess.net> On Thu, 2009-05-21 at 01:49 -0400, Jon Masters wrote: > I like podcasts. A lot. I also like rhythmbox (mostly). I've been > wondering recently why I would occasionally not be able to download > podcasts in rhythmbox. It seemed to be related to when I was connected > to a particular VPN and so I had dismissed it as being network DNSness > weirdness. But then it started happening much more often. Tonight, I > decided it was probably more than occasional network weirdness. > > So I decided "I'll just fire up gdb on rhythmbox". Many debuginfo > packages, cscopes, hacked up source, etc. later on, I discover the > "problem" is in abstraction layer number 2 - totem-pl-parser. So I > download the source to this package also, rebuild and hack it up. I > eventually discovered that various GError objects were happily telling > me that the maximum number of open files had been exceeded, but totem > never exposes this to rhythmbox, and the latter just has no idea what > the heck is causing it to fail. Some serious fail happening there. Can I have my bugzilla? (and some proof that totem-pl-parser is leaking descriptors...). Cheers From a.badger at gmail.com Thu May 21 16:07:37 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 21 May 2009 09:07:37 -0700 Subject: FESCo election nominations now open In-Reply-To: <20090521154403.GA10929@hansolo.jdub.homelinux.org> References: <4A15602A.90100@redhat.com> <1242915966.4320.3.camel@localhost.localdomain> <4A157001.80107@fedoraproject.org> <1242919693.3029.83.camel@localhost.localdomain> <4A157592.9060704@fedoraproject.org> <20090521154403.GA10929@hansolo.jdub.homelinux.org> Message-ID: <4A157C49.30907@gmail.com> On 05/21/2009 08:44 AM, Josh Boyer wrote: > On Thu, May 21, 2009 at 09:08:58PM +0530, Rahul Sundaram wrote: >> On 05/21/2009 08:58 PM, Jesse Keating wrote: >>> On Thu, 2009-05-21 at 20:45 +0530, Rahul Sundaram wrote: >>>> IMO, it made sense only during the time when it was a steering committee >>>> for the Fedora Extras repository. Now FESCo duties are broad and I don't >>>> see why someone only involved with artwork, L10N or documentation but >>>> not packaging shouldn't be a leader. >>> That would make sense if they were making decisions and guidance over >>> those groups, only I don't think they are. >> FESCo has grown from being a group concerned only about packages in a >> add-on repository into something much larger. FESCo is responsible for >> all technical decisions in Fedora including those that affect these groups. > > Not that I'm disagreeing with you, but what technical decisions effect artwork > or translations or the management of documentation? > > I cannot remember ever dealing with anything involving artwork in my entire > tenure in FESCo. Documentation is impacted from a content point of view, but > they have their own committee and aside from the Feature stuff FESCo doesn't > really have any direct impact on them. Similarly for translation. > Why, just last week! :-) https://fedorahosted.org/fesco/ticket/142 which was discussed in: http://bpepple.fedorapeople.org/fesco/FESCo-2009-05-15.html I'll note that FESCo left the decision to mizmo and ianweller as representatives of the art and website teams. But FESCo didn't say that they didn't have jurisdiction here... FESCo assumed it had the authority to play mediator in the dispute. This relationship seems to be pretty close to the FESCo <=> FPC relationship where the FPC is largely autonomous but definitely comes under the wings of FESCo. -Toshio From jkeating at redhat.com Thu May 21 16:09:17 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 21 May 2009 09:09:17 -0700 Subject: Package Maintainers Flags policy In-Reply-To: <20090521155252.GH32139@macmahon.me.uk> References: <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> <20090519181454.GA4397@nostromo.devel.redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <4A131DC6.8000605@gmail.com> <1242767869.3029.13.camel@localhost.localdomain> <20090521155252.GH32139@macmahon.me.uk> Message-ID: <1242922157.3029.87.camel@localhost.localdomain> On Thu, 2009-05-21 at 16:52 +0100, Ewan Mac Mahon wrote: > I think it's safe to say that if this unwritten rule ever existed, it > certainly wasn't enforced. Oh my yes, we were terrible about rule enforcement within RHT. If it wasn't a QA check item, it didn't get seen. Note the terrible package quality. The customers who complained about the flags likely never ran FreeCiv and thus never noticed the flags within. Had they noticed, FreeCiv likely would have been altered, or removed. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From wb8rcr at arrl.net Thu May 21 16:10:09 2009 From: wb8rcr at arrl.net (John J. McDonough) Date: Thu, 21 May 2009 12:10:09 -0400 Subject: FESCo election nominations now open References: <4A15602A.90100@redhat.com><1242915966.4320.3.camel@localhost.localdomain><4A157001.80107@fedoraproject.org><1242919693.3029.83.camel@localhost.localdomain><4A157592.9060704@fedoraproject.org> <20090521154403.GA10929@hansolo.jdub.homelinux.org> Message-ID: <9591A13BD95A48EEBABC228132B9DB37@Aidan> ----- Original Message ----- From: "Josh Boyer" To: "Development discussions related to Fedora" Sent: Thursday, May 21, 2009 11:44 AM Subject: Re: FESCo election nominations now open > On Thu, May 21, 2009 at 09:08:58PM +0530, Rahul Sundaram wrote: >>On 05/21/2009 08:58 PM, Jesse Keating wrote: >>> On Thu, 2009-05-21 at 20:45 +0530, Rahul Sundaram wrote: >>>> IMO, it made sense only during the time when it was a steering >>>> committee >>>> for the Fedora Extras repository. Now FESCo duties are broad and I >>>> don't >>>> see why someone only involved with artwork, L10N or documentation but >>>> not packaging shouldn't be a leader. >>> >>> That would make sense if they were making decisions and guidance over >>> those groups, only I don't think they are. >> >>FESCo has grown from being a group concerned only about packages in a >>add-on repository into something much larger. FESCo is responsible for >>all technical decisions in Fedora including those that affect these >>groups. > > Not that I'm disagreeing with you, but what technical decisions effect > artwork > or translations or the management of documentation? Since when does FESCo limit itself to technical decisions? FESCo makes decisions on policy, features, schedules, OK, maybe the occasional technical decision sneaks in there. One could argue that Docs, being on the tail end of that train, gets whipped around by those decisions more than anyone. (Obviously a personal perspective, maybe L10N is even worse). Even so, I guess I'm a fan of having those decisions made by folks with a strong technical background, so I don't have a problem with the requirement. But let's not labor under the illusion that FESCo's decisions are solely technical. --McD From jkeating at redhat.com Thu May 21 16:10:31 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 21 May 2009 09:10:31 -0700 Subject: FESCo election nominations now open In-Reply-To: <20090521154403.GA10929@hansolo.jdub.homelinux.org> References: <4A15602A.90100@redhat.com> <1242915966.4320.3.camel@localhost.localdomain> <4A157001.80107@fedoraproject.org> <1242919693.3029.83.camel@localhost.localdomain> <4A157592.9060704@fedoraproject.org> <20090521154403.GA10929@hansolo.jdub.homelinux.org> Message-ID: <1242922231.3029.88.camel@localhost.localdomain> On Thu, 2009-05-21 at 11:44 -0400, Josh Boyer wrote: > > I cannot remember ever dealing with anything involving artwork in my entire > tenure in FESCo. Documentation is impacted from a content point of view, but > they have their own committee and aside from the Feature stuff FESCo doesn't > really have any direct impact on them. Similarly for translation. I don't recall any significant issues regarding those groups during my time as FESCo either. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From christoph.wickert at googlemail.com Thu May 21 16:11:22 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Thu, 21 May 2009 18:11:22 +0200 Subject: I must be doing something seriously wrong... In-Reply-To: <20090521124654.GB10004@hansolo.jdub.homelinux.org> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <20090521124654.GB10004@hansolo.jdub.homelinux.org> Message-ID: <1242922282.8758.13.camel@localhost.localdomain> Am Donnerstag, den 21.05.2009, 08:46 -0400 schrieb Josh Boyer: > On Thu, May 21, 2009 at 02:20:52PM +0200, Christoph Wickert wrote: > [snipped] > > >privileges, so one should also pull his duties. If not, IMHO the person > >is not qualified for FESCo, simple as that. (Sorry if this sounds harsh) > > It doesn't sound particularly harsh, but I wonder what privileges you think > you get when you are in FESCo? As a FESCo member you are to decide over the direction that Fedora takes, this is the biggest privilege I can think of inside a FOSS project. > >> >I'm one of the few maintainers who directly is affected by the policy. > >> >Would somebody - preferably a FESCo member, who voted for the flags > >> >proposal - please be so kind to answer my questions. TIA! > >> > >> >https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01414.html > >> > >> 1) The rationale was given by spot here: > >> > >> https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01427.html > >> > >> or was that not what you were looking for? > > > >Not really. Spot just explained the rationale for writing the policy, > >but as I already outlined that the policy does not cover all the cases > >it was designed for. Maybe I should have asked more precisely: What is > >the use of a policy that does not really solve the problems? > > I see. I think that is why a ticket has been opened to revisit this. Stay > tuned! > > >> 2) The advantage for the project was to codify something that has been > >> dealt with silently since the RHL days. That being said, the guideline itself > >> is going to be revisited. > > > >I agree that codification is a good thing, but I really don't see the > >benefit (see above) and your answer does not solve the apparent > >contradiction between "follow upstream" and "remove flags". We have two > >conflicting guidelines here, so which one is more important? > > In general terms, 'follow the Fedora policy' trumps 'follow upstream' (see mp3). > I think we try to make sure the policies don't conflict with upstream where we > can. The flags issue certainly does though. > > >> 3) Your example of keyboard layout selection seems akin to language selection. > >> In my opinion, under the existing guideline, the flags would not be allowed but > >> you could ask FESCo for an exemption. Note, that is just my opinion and I don't > >> speak for FESCo as a whole. > > > >Ok, then please some FESCo members please speak up. > > Honestly, I think it would be best to let the revisit of the guideline happen > first. If nothing changes as an outcome of that, then we can start soliciting > opinions on specific items (or opening tickets for exemptions). > > >> 4) This is a good question. If you have specific examples of things that are > >> not obviously 'religion' that you would like to have evaluated that might help. > > > >How about Scientology, is it a religion? I don't think so, but I know > >there are people who see this differently, especially in the US. Also > >you only answered my question partly, I asked for a definition of an > >"ethnocultural concept". Even the assumed trivial terms are hard to > >define. What is "country"? Is Tibet one or Taiwan? > > This is a good question, and I don't have an answer for you off the top of my > head. I think Toshio already uttered similar concerns, so FESCo should have dealt with them *before* ratifying the policy. Looking at the IRC log I see there was *zero* discussion but only +1s. (This is how I'd expect a vote in the Communist Party of China but not in Fedora - SCNR) > >> 5) I don't know the answer to your question, nor do I find it relevant in a > >> discussion about flags. It's been pointed out several times that the flags > >> policy opens doors to madness through defining 'acceptable' content, so let's > >> not start yet another massive thread about that at the moment. > > > >I do think it is relevant. The policy deals with religious flags, but it > >does not deal with religions symbols. I could draw a square around > >symbol and call it a flag. > > And I could remove a square from the flag and call it a symbol. Discussing > theoreticals at this point is only going to lead us to more and more absurd > cases. I don't think we're here to draft policies that cover every possible > situation whether it will ever happen in real life or not. I know I'm just to negative sometimes. I think we always need to be prepared for worst case scenarios, which also includes theoretical questions. Others say that this or that will never happen because we are all in the same boat, but I think history has proven different. > >> 6) How do you make sure users are aware of -docs packages, or -devel packages? > >> I see no difference here. > > > >I do. -devel packages for example show up in comps and can be installed > >with groupinstall, but -flags can't. While developing or building a > > Why can't they show up in comps? Maybe this already pisses some states and regimes off? Also showing up in comps was only half of it, the other one was groupinstall. 'yum groupinstall flags' won't work. > >package you will most likely be pointed to a missing -devel package by a > >configure script or a failed make, but what will point you to the > >missing flags? > > >Docs don't affect runtime of a program (as per packaging guidelines), > >but flags do. Not necessarily the fundamental functions of a package, > >but they *do* make the program behave differently than intended by it's > >developers. Just take deluge or my xfce4-xkp-plugin as examples. > > You asked about how we make sure users are aware of -flags packages. I stated > that I see no difference from how we make users aware of -docs packages. Your > reply doesn't address that. Instead you described the functional difference > between -flags and -docs. Exactly. To show you that your argument is very different and IMHO doesn't hold up at all. > The original question was about advertising to the users. So how do we > advertise -docs packages to users, and why isn't that sufficient for -flags? I still think you put it wrong because IMO you are comparing apples and oranges. 1. In a perfect world (TM) there is no need for docs because everything is self self-explanatory. 2. At least users *should* not need docs at least none that are not installed by default. Our -docs packages are mostly targeted at developers and system administrators. 3. If someone really needs docs, he will realize this himself, because he is missing knowledge. For flags he doesn't. How is a deluge user supposed the realize the lack of a function? > > josh Regards, Christoph From christoph.wickert at googlemail.com Thu May 21 16:11:48 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Thu, 21 May 2009 18:11:48 +0200 Subject: I must be doing something seriously wrong... In-Reply-To: <1242921797.3029.84.camel@localhost.localdomain> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <1242921797.3029.84.camel@localhost.localdomain> Message-ID: <1242922308.8758.14.camel@localhost.localdomain> Am Donnerstag, den 21.05.2009, 09:03 -0700 schrieb Jesse Keating: > On Thu, 2009-05-21 at 14:20 +0200, Christoph Wickert wrote: > > Not really. Spot just explained the rationale for writing the policy, > > but as I already outlined that the policy does not cover all the cases > > it was designed for. Maybe I should have asked more precisely: What is > > the use of a policy that does not really solve the problems? > > The policy of "No flags" solved the problem enough for RHT and RHL so > that it was distributable and RHEL was sellable into China. Anything > less than that policy is going to be up for debate as to if it "solves > the problem". If China was the problem, why not name names here? (or even better in the policy itself) In my mail I gave an example that is not addressed by the proposal. Regards, Christoph From jcm at redhat.com Thu May 21 16:15:27 2009 From: jcm at redhat.com (Jon Masters) Date: Thu, 21 May 2009 12:15:27 -0400 Subject: [RFC] Increase default ulimit nofile In-Reply-To: <20090521152221.GC620322@hiwaay.net> References: <1242884986.4509.12.camel@localhost.localdomain> <20090521131419.GA16340@tango.0pointer.de> <1242916016.10339.4.camel@localhost.localdomain> <20090521152221.GC620322@hiwaay.net> Message-ID: <1242922527.13757.7.camel@localhost.localdomain> On Thu, 2009-05-21 at 10:22 -0500, Chris Adams wrote: > Once upon a time, Jon Masters said: > > On Thu, 2009-05-21 at 15:14 +0200, Lennart Poettering wrote: > > > I am pretty sure this is an fd leak somewhere in totem. > > > > Not sure yet - it's possible. However, let's bear in mind regardless of > > this that 1024 is /way/ the heck too low when we allow a user to spawn > > 1024 /processes/. And they only get one file each?!!! We should have, > > for example, 8 x tasks, which is where 8192 came from. > > That is a per-process limit, not per-user. Late night, you're right. Strangely, I remembered where in fs.h it's defined but somehow forgot it was per task, and not global. Anyway, after having had some coffee I am willing to concede the only remaining bug here is in that ugly totem code. > Also, if something is leaking up to 1024, and you raise the limit, who's > to say it won't leak right up to 8192 next? Yeah. And I guess 1M nr_open gels well with 1024 per task. Makes sense when you think about it. In any case, the totem code also needs fixing to actually handle the error properly. I'll send them a bunch of debug info, and let them poke at it. Jon. From jcm at redhat.com Thu May 21 16:31:09 2009 From: jcm at redhat.com (Jon Masters) Date: Thu, 21 May 2009 12:31:09 -0400 Subject: [RFC] Increase default ulimit nofile In-Reply-To: <1242922042.13791.197.camel@cookie.hadess.net> References: <1242884986.4509.12.camel@localhost.localdomain> <1242922042.13791.197.camel@cookie.hadess.net> Message-ID: <1242923469.13757.19.camel@localhost.localdomain> On Thu, 2009-05-21 at 17:07 +0100, Bastien Nocera wrote: > On Thu, 2009-05-21 at 01:49 -0400, Jon Masters wrote: > > > I like podcasts. A lot. I also like rhythmbox (mostly). I've been > > wondering recently why I would occasionally not be able to download > > podcasts in rhythmbox. It seemed to be related to when I was connected > > to a particular VPN and so I had dismissed it as being network DNSness > > weirdness. But then it started happening much more often. Tonight, I > > decided it was probably more than occasional network weirdness. > > > > So I decided "I'll just fire up gdb on rhythmbox". Many debuginfo > > packages, cscopes, hacked up source, etc. later on, I discover the > > "problem" is in abstraction layer number 2 - totem-pl-parser. So I > > download the source to this package also, rebuild and hack it up. I > > eventually discovered that various GError objects were happily telling > > me that the maximum number of open files had been exceeded, but totem > > never exposes this to rhythmbox, and the latter just has no idea what > > the heck is causing it to fail. Some serious fail happening there. > > Can I have my bugzilla? Filing upstream totem bug and RH BZ at the moment. > (and some proof that totem-pl-parser is leaking descriptors...). There's some code in there looking for a PROP_DEBUG set on the parser - am I supposed to set that by passing some option to rhythmbox? rhymbox -d didn't seem sufficient. Isn't there some ENV var I can set to get it to spew out a lot more useful info? I think all you need to do is create a long playlist of podcasts and watch what's happening in totem-pl-parser. Aside from the possible leaking of descriptors, if you look at around line 660, you'll see: stream = g_file_read (file, NULL, &error); if (stream == NULL) { } The GError 'error' object knows what failed though. Jon. From dimi at lattica.com Thu May 21 16:39:47 2009 From: dimi at lattica.com (Dimi Paun) Date: Thu, 21 May 2009 12:39:47 -0400 Subject: Packages not signed? Message-ID: <1242923987.3022.658.camel@dimi.lattica.com> OK, that's the deal here? [root at dimi dimi]# yum update nfs-utils Loaded plugins: refresh-packagekit Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package nfs-utils.i586 1:1.1.5-6.fc11 set to be updated --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Updating: nfs-utils i586 1:1.1.5-6.fc11 fedora 310 k Transaction Summary ================================================================================ Install 0 Package(s) Update 1 Package(s) Remove 0 Package(s) Total size: 310 k Is this ok [y/N]: y Downloading Packages: Package nfs-utils-1.1.5-6.fc11.i586.rpm is not signed -- Dimi Paun Lattica, Inc. From limb at jcomserv.net Thu May 21 16:41:10 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 21 May 2009 11:41:10 -0500 Subject: Packages not signed? In-Reply-To: <1242923987.3022.658.camel@dimi.lattica.com> References: <1242923987.3022.658.camel@dimi.lattica.com> Message-ID: <4A158426.6040001@jcomserv.net> Dimi Paun wrote: > OK, that's the deal here? > > [root at dimi dimi]# yum update nfs-utils > Loaded plugins: refresh-packagekit > Setting up Update Process > Resolving Dependencies > --> Running transaction check > ---> Package nfs-utils.i586 1:1.1.5-6.fc11 set to be updated > --> Finished Dependency Resolution > > Dependencies Resolved > > ================================================================================ > Package Arch Version Repository Size > ================================================================================ > Updating: > nfs-utils i586 1:1.1.5-6.fc11 fedora 310 k > > Transaction Summary > ================================================================================ > Install 0 Package(s) > Update 1 Package(s) > Remove 0 Package(s) > > Total size: 310 k > Is this ok [y/N]: y > Downloading Packages: > > > Package nfs-utils-1.1.5-6.fc11.i586.rpm is not signed > > Minor wire-crossing in rel-eng, since rectified. Should be fixed on a mirror near you in the very near future. -- in your fear, speak only peace in your fear, seek only love -d. bowie From jwboyer at gmail.com Thu May 21 16:41:22 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 21 May 2009 12:41:22 -0400 Subject: FESCo election nominations now open In-Reply-To: <4A157C49.30907@gmail.com> References: <4A15602A.90100@redhat.com> <1242915966.4320.3.camel@localhost.localdomain> <4A157001.80107@fedoraproject.org> <1242919693.3029.83.camel@localhost.localdomain> <4A157592.9060704@fedoraproject.org> <20090521154403.GA10929@hansolo.jdub.homelinux.org> <4A157C49.30907@gmail.com> Message-ID: <20090521164122.GA11110@hansolo.jdub.homelinux.org> On Thu, May 21, 2009 at 09:07:37AM -0700, Toshio Kuratomi wrote: > On 05/21/2009 08:44 AM, Josh Boyer wrote: >> On Thu, May 21, 2009 at 09:08:58PM +0530, Rahul Sundaram wrote: >>> On 05/21/2009 08:58 PM, Jesse Keating wrote: >>>> On Thu, 2009-05-21 at 20:45 +0530, Rahul Sundaram wrote: >>>>> IMO, it made sense only during the time when it was a steering committee >>>>> for the Fedora Extras repository. Now FESCo duties are broad and I don't >>>>> see why someone only involved with artwork, L10N or documentation but >>>>> not packaging shouldn't be a leader. >>>> That would make sense if they were making decisions and guidance over >>>> those groups, only I don't think they are. >>> FESCo has grown from being a group concerned only about packages in a >>> add-on repository into something much larger. FESCo is responsible for >>> all technical decisions in Fedora including those that affect these groups. >> >> Not that I'm disagreeing with you, but what technical decisions effect artwork >> or translations or the management of documentation? >> >> I cannot remember ever dealing with anything involving artwork in my entire >> tenure in FESCo. Documentation is impacted from a content point of view, but >> they have their own committee and aside from the Feature stuff FESCo doesn't >> really have any direct impact on them. Similarly for translation. >> > > Why, just last week! :-) > https://fedorahosted.org/fesco/ticket/142 > > which was discussed in: > > http://bpepple.fedorapeople.org/fesco/FESCo-2009-05-15.html > > I'll note that FESCo left the decision to mizmo and ianweller as > representatives of the art and website teams. But FESCo didn't say that > they didn't have jurisdiction here... FESCo assumed it had the authority > to play mediator in the dispute. This relationship seems to be pretty > close to the FESCo <=> FPC relationship where the FPC is largely > autonomous but definitely comes under the wings of FESCo. OK, so odd example, but yes I guess that does have some impact to the website team. I know that when I was reviewing that, I was looking at it from the technical standpoint of 'should we be preferring x86_64 for installs' and not from an asthetic point of view. That is perhaps weasely, but true. See how my brain works? "Evaluate the technical aspects, leave the non-technical stuff to people that know and care about it." josh From jkeating at redhat.com Thu May 21 16:43:04 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 21 May 2009 09:43:04 -0700 Subject: I must be doing something seriously wrong... In-Reply-To: <1242922308.8758.14.camel@localhost.localdomain> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> Message-ID: <1242924184.3029.96.camel@localhost.localdomain> On Thu, 2009-05-21 at 18:11 +0200, Christoph Wickert wrote: > If China was the problem, why not name names here? (or even better in > the policy itself) Probably because RHT and then spot/FESCo didn't want to single this out as a "China" policy, as that would almost seem as siding with China on the debate, rather than withdrawing from the debate entirely. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jwboyer at gmail.com Thu May 21 16:47:02 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 21 May 2009 12:47:02 -0400 Subject: FESCo election nominations now open In-Reply-To: <9591A13BD95A48EEBABC228132B9DB37@Aidan> References: <4A15602A.90100@redhat.com> <1242915966.4320.3.camel@localhost.localdomain> <4A157001.80107@fedoraproject.org> <1242919693.3029.83.camel@localhost.localdomain> <4A157592.9060704@fedoraproject.org> <20090521154403.GA10929@hansolo.jdub.homelinux.org> <9591A13BD95A48EEBABC228132B9DB37@Aidan> Message-ID: <20090521164702.GB11110@hansolo.jdub.homelinux.org> On Thu, May 21, 2009 at 12:10:09PM -0400, John J. McDonough wrote: >> Not that I'm disagreeing with you, but what technical decisions effect >> artwork >> or translations or the management of documentation? > > Since when does FESCo limit itself to technical decisions? FESCo makes > decisions on policy, features, schedules, OK, maybe the occasional Aside from the flags discussion, most of the policies FESCo deal with the technical aspects of Fedora. Schedules are primarily driven by John and rel-eng. FESCo just approves them. Why, I have no idea. > technical decision sneaks in there. One could argue that Docs, being on > the tail end of that train, gets whipped around by those decisions more > than anyone. (Obviously a personal perspective, maybe L10N is even > worse). >From a content point of view, yes. But FESCo doesn't dictate anything about your schedule, how you do documentation, what you document, etc. > Even so, I guess I'm a fan of having those decisions made by folks with a > strong technical background, so I don't have a problem with the > requirement. But let's not labor under the illusion that FESCo's > decisions are solely technical. I'm not sure I would say they are soley technical. But they are most certainly technically oriented for the vast majority of items. josh From jcm at redhat.com Thu May 21 16:52:24 2009 From: jcm at redhat.com (Jon Masters) Date: Thu, 21 May 2009 12:52:24 -0400 Subject: [RFC] Increase default ulimit nofile In-Reply-To: <1242923469.13757.19.camel@localhost.localdomain> References: <1242884986.4509.12.camel@localhost.localdomain> <1242922042.13791.197.camel@cookie.hadess.net> <1242923469.13757.19.camel@localhost.localdomain> Message-ID: <1242924744.13757.31.camel@localhost.localdomain> On Thu, 2009-05-21 at 12:31 -0400, Jon Masters wrote: > On Thu, 2009-05-21 at 17:07 +0100, Bastien Nocera wrote: > > On Thu, 2009-05-21 at 01:49 -0400, Jon Masters wrote: > > > > > I like podcasts. A lot. I also like rhythmbox (mostly). I've been > > > wondering recently why I would occasionally not be able to download > > > podcasts in rhythmbox. It seemed to be related to when I was connected > > > to a particular VPN and so I had dismissed it as being network DNSness > > > weirdness. But then it started happening much more often. Tonight, I > > > decided it was probably more than occasional network weirdness. > > > > > > So I decided "I'll just fire up gdb on rhythmbox". Many debuginfo > > > packages, cscopes, hacked up source, etc. later on, I discover the > > > "problem" is in abstraction layer number 2 - totem-pl-parser. So I > > > download the source to this package also, rebuild and hack it up. I > > > eventually discovered that various GError objects were happily telling > > > me that the maximum number of open files had been exceeded, but totem > > > never exposes this to rhythmbox, and the latter just has no idea what > > > the heck is causing it to fail. Some serious fail happening there. > > > > Can I have my bugzilla? > > Filing upstream totem bug and RH BZ at the moment. So the upstream totem-pl-parser bug (not catching max open files exceeded) you need is: http://bugzilla.gnome.org/show_bug.cgi?id=583473 > > (and some proof that totem-pl-parser is leaking descriptors...). For clarity, rhythmbox is obviously responsible for the exceeded max open descriptors and I don't think that is directly the fault of totem-pl-parser. The problem with totem-pl-parser is that you wind up receiving an ambiguous mime error that has nothing to do with the actual problem, which is that the max open fds was exceeded. I've also filed upstream rhythmbox bug: http://bugzilla.gnome.org/show_bug.cgi?id=583476 Maybe if I have some time on a weekend I'll try to fix the bug - it's unfortunately increasingly difficult for a 'non-GNOME' person to keep up with all the goings on there...perhaps you need a podcast? ;) Jon. From jwboyer at gmail.com Thu May 21 17:07:23 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 21 May 2009 13:07:23 -0400 Subject: I must be doing something seriously wrong... In-Reply-To: <1242922282.8758.13.camel@localhost.localdomain> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <20090521124654.GB10004@hansolo.jdub.homelinux.org> <1242922282.8758.13.camel@localhost.localdomain> Message-ID: <20090521170723.GA11191@hansolo.jdub.homelinux.org> On Thu, May 21, 2009 at 06:11:22PM +0200, Christoph Wickert wrote: >Am Donnerstag, den 21.05.2009, 08:46 -0400 schrieb Josh Boyer: >> On Thu, May 21, 2009 at 02:20:52PM +0200, Christoph Wickert wrote: >> [snipped] >> >> >privileges, so one should also pull his duties. If not, IMHO the person >> >is not qualified for FESCo, simple as that. (Sorry if this sounds harsh) >> >> It doesn't sound particularly harsh, but I wonder what privileges you think >> you get when you are in FESCo? > >As a FESCo member you are to decide over the direction that Fedora >takes, this is the biggest privilege I can think of inside a FOSS >project. 1) Yes, I do consider that a privilege. It is also a burden :) 2) Mostly we vote on policies and proposals and Features that the fedora contributors submit. So while FESCo approves those, the direction that Fedora takes is almost entirely driven by those submissions. >I think Toshio already uttered similar concerns, so FESCo should have >dealt with them *before* ratifying the policy. Looking at the IRC log I >see there was *zero* discussion but only +1s. (This is how I'd expect a >vote in the Communist Party of China but not in Fedora - SCNR) Quite possibly, yes. >> >I do think it is relevant. The policy deals with religious flags, but it >> >does not deal with religions symbols. I could draw a square around >> >symbol and call it a flag. >> >> And I could remove a square from the flag and call it a symbol. Discussing >> theoreticals at this point is only going to lead us to more and more absurd >> cases. I don't think we're here to draft policies that cover every possible >> situation whether it will ever happen in real life or not. > >I know I'm just to negative sometimes. I think we always need to be >prepared for worst case scenarios, which also includes theoretical >questions. Others say that this or that will never happen because we are >all in the same boat, but I think history has proven different. It's a prudent approach. I find that preparing for the worst case scenario can often lead to an entirely sub-optimal normal case scenario though. A balance needs to be achieved. >> The original question was about advertising to the users. So how do we >> advertise -docs packages to users, and why isn't that sufficient for -flags? > >I still think you put it wrong because IMO you are comparing apples and >oranges. > 1. In a perfect world (TM) there is no need for docs because > everything is self self-explanatory. In a perfect world, there is no need for flags because humanity is united and we have reached utopia. We don't live in a perfect world. > 2. At least users *should* not need docs at least none that are not > installed by default. Our -docs packages are mostly targeted at > developers and system administrators. And our flags packages would be targeted at whom? > 3. If someone really needs docs, he will realize this himself, > because he is missing knowledge. For flags he doesn't. How is a > deluge user supposed the realize the lack of a function? Deluge is clearly spelled out in the guideline as not needing flags for functionality. Is that statement incorrect? josh From inode0 at gmail.com Thu May 21 17:08:02 2009 From: inode0 at gmail.com (inode0) Date: Thu, 21 May 2009 12:08:02 -0500 Subject: FESCo election nominations now open In-Reply-To: <20090521154403.GA10929@hansolo.jdub.homelinux.org> References: <4A15602A.90100@redhat.com> <1242915966.4320.3.camel@localhost.localdomain> <4A157001.80107@fedoraproject.org> <1242919693.3029.83.camel@localhost.localdomain> <4A157592.9060704@fedoraproject.org> <20090521154403.GA10929@hansolo.jdub.homelinux.org> Message-ID: On Thu, May 21, 2009 at 10:44 AM, Josh Boyer wrote: > On Thu, May 21, 2009 at 09:08:58PM +0530, Rahul Sundaram wrote: >>On 05/21/2009 08:58 PM, Jesse Keating wrote: >>> On Thu, 2009-05-21 at 20:45 +0530, Rahul Sundaram wrote: >>>> IMO, it made sense only during the time when it was a steering committee >>>> for the Fedora Extras repository. Now FESCo duties are broad and I don't >>>> see why someone only involved with artwork, L10N or documentation but >>>> not packaging shouldn't be a leader. >>> >>> That would make sense if they were making decisions and guidance over >>> those groups, only I don't think they are. >> >>FESCo has grown from being a group concerned only about packages in a >>add-on repository into something much larger. FESCo is responsible for >>all technical decisions in Fedora including those that affect these groups. > > Not that I'm disagreeing with you, but what technical decisions effect artwork > or translations or the management of documentation? > > I cannot remember ever dealing with anything involving artwork in my entire > tenure in FESCo. ?Documentation is impacted from a content point of view, but > they have their own committee and aside from the Feature stuff FESCo doesn't > really have any direct impact on them. ?Similarly for translation. Well, letting a much broader segment of the Fedora community vote causes a disconnect with me. If they aren't "fit" to run for an open seat why are they "fit" to elect those who are? I think the question of whether being in the packager group is still really relevant is a fair question to reflect on. I'm not suggesting the requirement no longer makes sense, but I haven't really heard a reason why it does yet. I think it is also fair to reflect on the composition of the electorate and whether FAS+1 really makes sense for FESCo elections. John From jleddy at redhat.com Thu May 21 17:14:05 2009 From: jleddy at redhat.com (James M. Leddy) Date: Thu, 21 May 2009 13:14:05 -0400 Subject: Package Maintainers Flags policy In-Reply-To: <870180fe0905180845j553c38d9k3865089ea9dc1505@mail.gmail.com> References: <20090518090953.5698908a@ohm.scrye.com> <870180fe0905180845j553c38d9k3865089ea9dc1505@mail.gmail.com> Message-ID: <4A158BDD.3040701@redhat.com> On 05/18/2009 11:45 AM, Jerry James wrote: > On Mon, May 18, 2009 at 9:09 AM, Kevin Fenzi wrote: >> In FESCo's 2009-03-28 meeting a policy on Flag usage for packages in >> Fedora was approved. >> >> Due to an oversight, this policy was not announced here. ;( >> >> Please see: >> >> https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy >> >> and direct any comments to FESCo in a ticket or via the devel list. >> >> Thanks, and sorry for the oversight. ;( >> >> kevin This policy tries to please everyone and in the end pleases no one. There are two possibilities: A) You cannot display certain flags in your country B) You are free to display whichever country flags you want In the first case (read China), you can't use fedora because it includes -flag packages. Are we going to make a separate yum repo for -flag as well? It's more likely that countries like these already roll their own distros anyway. After all, it's free software. If you don't like it, change it. http://en.wikipedia.org/wiki/Red_Flag_Linux In the second case, you create a lot more work for volunteers and raise the ire of -devel-list (see 15k posts above this). Sure, there was a debian developer that quit because the RoC flag didn't get cleaned from the repo. The questions that still has yet to be asked is, "How many volunteer maintainers didn't quit because of draconian packaging guidelines?" I hope whomever makes the ultimate decision keeps this in mind. -- James M. Leddy From mcepl at redhat.com Thu May 21 17:16:24 2009 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 21 May 2009 17:16:24 +0000 (UTC) Subject: Abrt - should this be a feature? References: <4A0DC949.7000601@fedoraproject.org> <4A116F78.3020607@redhat.com> <4A118A4C.3050909@fedoraproject.org> <4A1290AD.90205@redhat.com> <4A154D52.1000500@redhat.com> Message-ID: Colin Walters, Thu, 21 May 2009 10:35:39 -0400: > I'm reading the architecture page now, but I'm not seeing how ABRT works > in this respect. Does ABRT have a "retracer" server component like > Apport/Breakpad, or does it somehow ensure -debuginfo gets installed on > the client? Or does it rely on a modified gdb to just-in-time fetch the > data from an ABRT web service? Something else? http://fedoraproject.org/wiki/Features/DebuginfoFS it slipped to Fedora 12 but when it is ready, it should take of debuginfo, right? Matej From mcepl at redhat.com Thu May 21 17:27:12 2009 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 21 May 2009 17:27:12 +0000 (UTC) Subject: Empathy Tracker bug? Message-ID: When looking at https://fedoraproject.org/wiki/Features/Empathy, I found it contains it owns a list of bugs blocking its acceptance as a default IM client. However, I have filed (after discussion with maintainers on IRC) a special tracking bug for this purpose in our Bugzilla -- https://bugzilla.redhat.com/show_bug.cgi?id=494985 Somebody should decide which method is the one (I like bugzilla, but that maybe just me, maybe random wikipage is better tool for that purpose) and eliminate the other one. Mat?j From jwboyer at gmail.com Thu May 21 17:51:53 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 21 May 2009 13:51:53 -0400 Subject: FESCo election nominations now open In-Reply-To: References: <4A15602A.90100@redhat.com> <1242915966.4320.3.camel@localhost.localdomain> <4A157001.80107@fedoraproject.org> <1242919693.3029.83.camel@localhost.localdomain> <4A157592.9060704@fedoraproject.org> <20090521154403.GA10929@hansolo.jdub.homelinux.org> Message-ID: <20090521175153.GA11344@hansolo.jdub.homelinux.org> On Thu, May 21, 2009 at 12:08:02PM -0500, inode0 wrote: >> I cannot remember ever dealing with anything involving artwork in my entire >> tenure in FESCo. ?Documentation is impacted from a content point of view, but >> they have their own committee and aside from the Feature stuff FESCo doesn't >> really have any direct impact on them. ?Similarly for translation. > >Well, letting a much broader segment of the Fedora community vote >causes a disconnect with me. If they aren't "fit" to run for an open >seat why are they "fit" to elect those who are? At one point, they weren't. People complained about this, for good reason, and the voting requirement was changed from cvs_extras to cla_done +1 FAS group. At least that is what I think happened. >I think the question of whether being in the packager group is still >really relevant is a fair question to reflect on. I'm not suggesting >the requirement no longer makes sense, but I haven't really heard a >reason why it does yet. > >I think it is also fair to reflect on the composition of the >electorate and whether FAS+1 really makes sense for FESCo elections. Honestly, if we want to open up the candidate pool to the same thing as the voting pool that is fine with me. If you think it's important enough, you could certainly file a ticket with FESCo and we can discuss it. josh From inode0 at gmail.com Thu May 21 18:06:57 2009 From: inode0 at gmail.com (inode0) Date: Thu, 21 May 2009 13:06:57 -0500 Subject: FESCo election nominations now open In-Reply-To: <20090521175153.GA11344@hansolo.jdub.homelinux.org> References: <4A15602A.90100@redhat.com> <1242915966.4320.3.camel@localhost.localdomain> <4A157001.80107@fedoraproject.org> <1242919693.3029.83.camel@localhost.localdomain> <4A157592.9060704@fedoraproject.org> <20090521154403.GA10929@hansolo.jdub.homelinux.org> <20090521175153.GA11344@hansolo.jdub.homelinux.org> Message-ID: On Thu, May 21, 2009 at 12:51 PM, Josh Boyer wrote: > On Thu, May 21, 2009 at 12:08:02PM -0500, inode0 wrote: >>I think it is also fair to reflect on the composition of the >>electorate and whether FAS+1 really makes sense for FESCo elections. > > Honestly, if we want to open up the candidate pool to the same thing as the > voting pool that is fine with me. ?If you think it's important enough, you > could certainly file a ticket with FESCo and we can discuss it. I would just as likely think the voting pool should be constricted to be aligned with the candidate pool. Without thoughtful deliberation and some understanding of the reasoning behind its current structure it just seems rather arbitrary to me. And I'm sure there was plenty of thoughtful deliberation at the time, but I'm unaware of what it was. Whatever election system works for FESCo that results in a good committee that is capable of moving the Fedora Project ahead is really fine with me personally. John From bjorn at xn--rombobjrn-67a.se Thu May 21 18:07:15 2009 From: bjorn at xn--rombobjrn-67a.se (=?iso-8859-1?q?Bj=F6rn_Persson?=) Date: Thu, 21 May 2009 20:07:15 +0200 Subject: Remaining debuginfo packages without sources (ocaml, haskell, erlang, etc) In-Reply-To: <200905202229.32245.ville.skytta@iki.fi> References: <200905202229.32245.ville.skytta@iki.fi> Message-ID: <200905212007.29214.bjorn@xn--rombobjrn-67a.se> Ville Skytt? wrote: > The remaining set of packages with unknown status that have debuginfo > packages without sources are somewhat unusual ones. [...] > Others: GtkAda, elice, lostlabyrinth, mono-debugger I bet GTKada has the same problem as I ran into. I'm working on some Ada packages that I hope to submit for review soon. I disabled the debuginfo packages because they contained no sources and the .debug files referenced the sources in my RPM build directory. The .debug files worked fine with GDB but only as long as the RPM build directory was still present. None of the causes listed in https://fedoraproject.org/wiki/Packaging/Debuginfo applied. I read /usr/lib/rpm/find-debuginfo.sh and found that it expects /usr/lib/rpm/debugedit to write a list of source files to a temporary file called debugsources.list. That file was empty. I haven't debugged past that point so I don't know whether the problem is in Debugedit or GNAT, but I get the impression that GNAT (package gcc-gnat) writes the filenames in a format that GDB understands but Debugedit doesn't. Bj?rn Persson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From awilliam at redhat.com Thu May 21 18:36:25 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 21 May 2009 11:36:25 -0700 Subject: I must be doing something seriously wrong... In-Reply-To: <1242924184.3029.96.camel@localhost.localdomain> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> Message-ID: <1242930985.8848.188.camel@adam.local.net> On Thu, 2009-05-21 at 09:43 -0700, Jesse Keating wrote: > On Thu, 2009-05-21 at 18:11 +0200, Christoph Wickert wrote: > > If China was the problem, why not name names here? (or even better in > > the policy itself) > > Probably because RHT and then spot/FESCo didn't want to single this out > as a "China" policy, as that would almost seem as siding with China on > the debate, rather than withdrawing from the debate entirely. This is, however, not convincing. Even if you convert it to a general policy - "no flags!" - and try to present it as "wellll, flags are just a dicey issue in general", everyone knows that it would never have come up as a live issue unless China were known to be not exactly keen on Taiwanese / Tibetan flags. We've discussed the complementary issues of other countries with other flags, but I sincerely doubt we would have come up with an invasive, distro-wide policy like this in response to, e.g., Germany's ban on the Nazi flag, or American sensibilities about Confederate flags, or anything like that. China is the elephant in the room, here. I agree with Christoph - this policy is essentially about China, and that needs to be openly and clearly discussed. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From awilliam at redhat.com Thu May 21 18:39:02 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 21 May 2009 11:39:02 -0700 Subject: Empathy Tracker bug? In-Reply-To: References: Message-ID: <1242931142.8848.189.camel@adam.local.net> On Thu, 2009-05-21 at 17:27 +0000, Matej Cepl wrote: > When looking at https://fedoraproject.org/wiki/Features/Empathy, I found > it contains it owns a list of bugs blocking its acceptance as a default > IM client. However, I have filed (after discussion with maintainers on > IRC) a special tracking bug for this purpose in our Bugzilla -- > https://bugzilla.redhat.com/show_bug.cgi?id=494985 > > Somebody should decide which method is the one (I like bugzilla, but that > maybe just me, maybe random wikipage is better tool for that purpose) and > eliminate the other one. This is something I discussed with jlaska a while back. We agreed in principle that each feature for the F12 feature list should have a tracker bug in Bugzilla, and the Wiki page for the feature should link to the tracker bug. It clearly makes more sense to track this in Bugzilla, where it's properly handled, than on a manually edited Wiki page. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From notting at redhat.com Thu May 21 18:53:42 2009 From: notting at redhat.com (Bill Nottingham) Date: Thu, 21 May 2009 14:53:42 -0400 Subject: I must be doing something seriously wrong... In-Reply-To: <1242930985.8848.188.camel@adam.local.net> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> <1242930985.8848.188.camel@adam.local.net> Message-ID: <20090521185342.GA6176@nostromo.devel.redhat.com> > China is the elephant in the > room, here. I agree with Christoph - this policy is essentially about > China, and that needs to be openly and clearly discussed. Sure. Honestly, I think the approved policy sort of sucks - it should either be a full 'no flags except for specifc exceptions'[1], or 'hey, ship all the flags you like'. In between adds a lot of technical apparatus that doesn't bring in much gain. As I said, it's a trade-off between: Benefits: - allows roughly 1/6 of the world's population to use Fedora freely Demerits: - requires ongoing maintenance work on some packages - may require removing packages that can't comply without being broken I feel the benefits in this case outweigh the demerits, and the amount of work required to be greatly exaggerated. Furthermore, making Fedora available for all to use freely is a fundamental goal of the project; ensuring the presence of, say, gcompris in a form that exactly matches upstream is much lower down the totem pole.[2] Now, if we can discuss the benefits and demerits without resorting to reducuing it to 'aah! slippery slope' or 'I'm offended by yellow, take that out too!', it would help, as those are sort of missing the point. Bill [1] I can see the argument for freeciv. I can't see the argument for someone using flags to pick languages, input methods, etc. [2] In the same way that each packager's own preferred workflow does not override the needs of the project as a whole, neither does the upstream composition or use of any particlar package override the needs of the project as a whole. Sure, we may bend a little bit for the kernel... From tcallawa at redhat.com Thu May 21 18:55:33 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 21 May 2009 14:55:33 -0400 Subject: Youth Protection: Was Re: Package Maintainers Flags policy In-Reply-To: <7dd7ab490905202158sc923880ge50c81bceb580024@mail.gmail.com> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520102730.45a3b7d4@ohm.scrye.com> <4A143CDC.8040400@freenet.de> <4A143F64.5080002@redhat.com> <4A14C5BB.5050401@freenet.de> <7dd7ab490905202158sc923880ge50c81bceb580024@mail.gmail.com> Message-ID: <4A15A3A5.4090004@redhat.com> On 05/21/2009 12:58 AM, Chris Weyl wrote: > Do we really want to start excluding content just because it's illegal > in some other jurisdiction? This seems.... slippery. In fact, this was not the intention behind the flags proposal, rather that: * Use of Flags in Fedora has a history of causing controversy between groups (political, rather than legal) * Use of Flags in Fedora may prevent Fedora from being available in some areas (again, political rather than legal) If FESCo decides that they are okay with Fedora including all sorts of flags, there is no legal reason for that decision to be overturned. ~spot, with his Fedora Legal hat on From tcallawa at redhat.com Thu May 21 18:56:02 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 21 May 2009 14:56:02 -0400 Subject: Youth Protection: Was Re: Package Maintainers Flags policy In-Reply-To: <7dd7ab490905202158sc923880ge50c81bceb580024@mail.gmail.com> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520102730.45a3b7d4@ohm.scrye.com> <4A143CDC.8040400@freenet.de> <4A143F64.5080002@redhat.com> <4A14C5BB.5050401@freenet.de> <7dd7ab490905202158sc923880ge50c81bceb580024@mail.gmail.com> Message-ID: <4A15A3C2.40000@redhat.com> On 05/21/2009 12:58 AM, Chris Weyl wrote: > Fedora, as a project of a US corporation, is liable for violation of the > laws of the State of North Carolina and of the United States. Well, its actually the laws of the State of Delaware, but I digress. ;) ~spot From craftjml at gmail.com Thu May 21 19:03:16 2009 From: craftjml at gmail.com (Jud Craft) Date: Thu, 21 May 2009 14:03:16 -0500 Subject: I must be doing something seriously wrong... In-Reply-To: <20090521185342.GA6176@nostromo.devel.redhat.com> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> Message-ID: <20d6441a0905211203l6c460666pbaf3b56d410118d2@mail.gmail.com> On Thu, May 21, 2009 at 1:53 PM, Bill Nottingham wrote: >> China is the elephant in the >> room, here. I agree with Christoph - this policy is essentially about >> China, and that needs to be openly and clearly discussed. We could do a reduction to the absurd here. You have an idea of the legal freedom to use Fedora, as long as you meet the legal criteria to distribute it in China. But if China has the ability to set the terms under which you distribute Fedora, it is not inconceivable that they could also arbitrarily limit the freedom to use Fedora itself. China never said it agreed with Fedora's goals, and trying to adapt Fedora to meet China's criteria could work well, or it could be a futile effort that China could easily reject on its own in the end, for just as arbitrary reasons as restricting flags and art. (I don't mean to be disagreeable -- I actually think the flag decision was pragmatic, and understandable -- but I think I have some logical point here. If you are trying to strike a compromise with an arbitrary standard, you can never be quite sure about the body you're negotiating with. Maybe you could be sure enough though, that Fedora in China would be successful. Something to keep in mind.) From mw_triad at users.sourceforge.net Thu May 21 19:21:03 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 21 May 2009 14:21:03 -0500 Subject: I must be doing something seriously wrong... In-Reply-To: <20090521170723.GA11191@hansolo.jdub.homelinux.org> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <20090521124654.GB10004@hansolo.jdub.homelinux.org> <1242922282.8758.13.camel@localhost.localdomain> <20090521170723.GA11191@hansolo.jdub.homelinux.org> Message-ID: Josh Boyer wrote: > On Thu, May 21, 2009 at 06:11:22PM +0200, Christoph Wickert wrote: >> 1. In a perfect world (TM) there is no need for docs because >> everything is self self-explanatory. > > In a perfect world, there is no need for flags because humanity is united and > we have reached utopia. We don't live in a perfect world. "In a perfect world there is no need to assign names or other mnemonics to places"... huh? How does that work? Do we just use latitude/longitude coordinates for everything? >> 2. At least users *should* not need docs at least none that are not >> installed by default. Our -docs packages are mostly targeted at >> developers and system administrators. > > And our flags packages would be targeted at whom? Everyone that wants their systems to be fully functional? (Well, "everyone" that doesn't live in the PRC/Germany/etc. anyway.) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- This is not a sig. I am too lazy to steal one, perhaps you could loan me yours? -- Unknown From paul at xelerance.com Thu May 21 19:04:10 2009 From: paul at xelerance.com (Paul Wouters) Date: Thu, 21 May 2009 15:04:10 -0400 (EDT) Subject: Youth Protection: Was Re: Package Maintainers Flags policy In-Reply-To: <4A15A3A5.4090004@redhat.com> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520102730.45a3b7d4@ohm.scrye.com> <4A143CDC.8040400@freenet.de> <4A143F64.5080002@redhat.com> <4A14C5BB.5050401@freenet.de> <7dd7ab490905202158sc923880ge50c81bceb580024@mail.gmail.com> <4A15A3A5.4090004@redhat.com> Message-ID: On Thu, 21 May 2009, Tom "spot" Callaway wrote: > * Use of Flags in Fedora has a history of causing controversy between > groups (political, rather than legal) > * Use of Flags in Fedora may prevent Fedora from being available in some > areas (again, political rather than legal) Only include flags in the Everything repo? Never on the install media? Though it seems rather silly to me. Would we also not allow little flags to show language preferences (eg french canadian vs american english)? If one people's republic does not like the other people's republic flags, they can re-spin their own? Paul ps. The really interesting question is: If a Fedora DVD image contains a US flag, can you still burn it? :) From limb at jcomserv.net Thu May 21 19:28:13 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 21 May 2009 14:28:13 -0500 Subject: Youth Protection: Was Re: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520102730.45a3b7d4@ohm.scrye.com> <4A143CDC.8040400@freenet.de> <4A143F64.5080002@redhat.com> <4A14C5BB.5050401@freenet.de> <7dd7ab490905202158sc923880ge50c81bceb580024@mail.gmail.com> <4A15A3A5.4090004@redhat.com> Message-ID: <4A15AB4D.5050208@jcomserv.net> Paul Wouters wrote: > > ps. The really interesting question is: If a Fedora DVD image contains a > US flag, can you still burn it? :) > You owe me a new keyboard. -- in your fear, speak only peace in your fear, seek only love -d. bowie From awilliam at redhat.com Thu May 21 19:29:54 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 21 May 2009 12:29:54 -0700 Subject: I must be doing something seriously wrong... In-Reply-To: <20090521185342.GA6176@nostromo.devel.redhat.com> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> Message-ID: <1242934194.8848.202.camel@adam.local.net> On Thu, 2009-05-21 at 14:53 -0400, Bill Nottingham wrote: > > China is the elephant in the > > room, here. I agree with Christoph - this policy is essentially about > > China, and that needs to be openly and clearly discussed. > > Sure. Honestly, I think the approved policy sort of sucks - it should > either be a full 'no flags except for specifc exceptions'[1], or > 'hey, ship all the flags you like'. In between adds a lot of technical > apparatus that doesn't bring in much gain. > > As I said, it's a trade-off between: > > Benefits: > - allows roughly 1/6 of the world's population to use Fedora freely > > Demerits: > - requires ongoing maintenance work on some packages > - may require removing packages that can't comply without being broken > > I feel the benefits in this case outweigh the demerits, and the > amount of work required to be greatly exaggerated. Furthermore, > making Fedora available for all to use freely is a fundamental > goal of the project; ensuring the presence of, say, gcompris in > a form that exactly matches upstream is much lower down the totem > pole.[2] > Now, if we can discuss the benefits and demerits without resorting > to reducuing it to 'aah! slippery slope' or 'I'm offended by > yellow, take that out too!', it would help, as those are sort > of missing the point. I don't think they're missing the point, as they raise valid problems with your categorization. I don't agree with your 'Benefit', for the following reasons: 1: a lot of that 1/6th of the world's population does not own a computer. Or an internet connection. (Or, in many cases, a reliable electricity supply). Let's not have any illusions about China: it contains a huge amount of people, but a rather smaller amount of possible potential Fedora users. 1a: Fedora is not, in point of practical reality, unavailable to China at present. Even if, by official Chinese government policy, Fedora contains material that should not be distributed in China, it has been reported that - in practice - it is perfectly possible to download Fedora in China from many different mirrors, flags and all. 2: it has not by any means been established that solely removing flags from the distribution would be sufficient for the Chinese government to be happy with Fedora being actively promoted / distributed within China. The Chinese government is known to behave in fairly quixotic ways. AFAIK, no-one has done the shovel work to actually establish parameters in this case - i.e. determine whether a flagless Fedora would be welcomed in China. It's entirely possible that this would actually require more substantial changes which we would not wish to make, and that would make all the changes necessary to satisfy the flag policy essentially wasted effort. 3: it has not been established that the proposed policy even achieves the goal if we accept as a parameter that flags in Fedora a) *is* a problem for distribution in China, and b) is the *only* problem for distribution in China. Because, as has been pointed out, the proposed policy doesn't actually remove all flags (or, in fact, any flags...) from the distribution. It relocates most flags to subpackages, and allows flags to be left in packages in certain circumstances. This feels like a compromise that isn't going to achieve anyone's goals. (You address this in the mail I'm replying to, advocating a full 'no flags' policy, which would satisfy this problem - but that proposal hasn't been accepted yet.) 4: even if we take it as a given that flags in Fedora are a problem for China, *and* are the only problem for China, *and* whatever policy we wind up with that involves changing the main set of official Fedora packages solves the problem, it has not been established that this is the best way to solve the problem. Other proposals have been made - such as delegating the modification work to some kind of SIG, working on a special spin of Fedora for China - and I haven't seen anyone explain why that's a worse idea than making all the changes directly in the main Fedora package repositories. hope that's a good summary of the issues :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From frankly3d at gmail.com Thu May 21 19:31:03 2009 From: frankly3d at gmail.com (Frank Murphy (Frankly3d)) Date: Thu, 21 May 2009 20:31:03 +0100 Subject: Youth Protection: Was Re: Package Maintainers Flags policy In-Reply-To: <7dd7ab490905202158sc923880ge50c81bceb580024@mail.gmail.com> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520102730.45a3b7d4@ohm.scrye.com> <4A143CDC.8040400@freenet.de> <4A143F64.5080002@redhat.com> <4A14C5BB.5050401@freenet.de> <7dd7ab490905202158sc923880ge50c81bceb580024@mail.gmail.com> Message-ID: <4A15ABF7.4080904@gmail.com> Chris Weyl wrote: > > > > Fedora, as a project of a US corporation, is liable for violation of the > laws of the State of North Carolina and of the United States. We're not > liable for violation of the laws of any other jurisdiction... Maybe not so: ALL *US* made films, have to be incompliance with EU laws. If necessary to comply, ratings will be up or down. To suit EU\ evenindividual member state laws. IANAL Frank -- msn: frankly3d skype: frankly3d Mailing-List Reply to: Mailing-List Still Learning, Unicode where possible From skvidal at fedoraproject.org Thu May 21 19:30:34 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 21 May 2009 15:30:34 -0400 (EDT) Subject: Youth Protection: Was Re: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520102730.45a3b7d4@ohm.scrye.com> <4A143CDC.8040400@freenet.de> <4A143F64.5080002@redhat.com> <4A14C5BB.5050401@freenet.de> <7dd7ab490905202158sc923880ge50c81bceb580024@mail.gmail.com> <4A15A3A5.4090004@redhat.com> Message-ID: On Thu, 21 May 2009, Paul Wouters wrote: > Only include flags in the Everything repo? Never on the install media? > > Though it seems rather silly to me. Would we also not allow little flags > to show language preferences (eg french canadian vs american english)? > > If one people's republic does not like the other people's republic flags, > they can re-spin their own? > > Paul > ps. The really interesting question is: If a Fedora DVD image contains a > US flag, can you still burn it? :) > I don't know where people have gotten the idea that burning a US flag is illegal. It's not. It's been found to be protected speech repeatedly. Defacing a flag is an act of protected speech under the First Amendment to the United States Constitution, as established in Texas v. Johnson, 491 U.S. 397 (1989), and reaffirmed in U.S. v. Eichman, 496 U.S. 310 (1990). It's also off-topic from this thread, I think. -sv From skvidal at fedoraproject.org Thu May 21 19:33:06 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 21 May 2009 15:33:06 -0400 (EDT) Subject: I must be doing something seriously wrong... In-Reply-To: <1242934194.8848.202.camel@adam.local.net> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> <1242934194.8848.202.camel@adam.local.net> Message-ID: On Thu, 21 May 2009, Adam Williamson wrote: > I don't think they're missing the point, as they raise valid problems > with your categorization. I don't agree with your 'Benefit', for the > following reasons: > > 1: a lot of that 1/6th of the world's population does not own a > computer. Or an internet connection. (Or, in many cases, a reliable > electricity supply). Let's not have any illusions about China: it > contains a huge amount of people, but a rather smaller amount of > possible potential Fedora users. http://www.pcworld.com/businesscenter/article/145108/china_tops_us_for_internet_population_lead.html 228million people in china with internet access. That's 2/3rd the population of the United states and 8million more internet accessing people than the US. Let's not underestimate this market, shall we? -sv From jkeating at redhat.com Thu May 21 19:36:03 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 21 May 2009 12:36:03 -0700 Subject: Youth Protection: Was Re: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520102730.45a3b7d4@ohm.scrye.com> <4A143CDC.8040400@freenet.de> <4A143F64.5080002@redhat.com> <4A14C5BB.5050401@freenet.de> <7dd7ab490905202158sc923880ge50c81bceb580024@mail.gmail.com> <4A15A3A5.4090004@redhat.com> Message-ID: <1242934563.3217.3.camel@localhost.localdomain> On Thu, 2009-05-21 at 15:04 -0400, Paul Wouters wrote: > > Only include flags in the Everything repo? Never on the install media? That gets hard, as there are also the spins we do to consider, and the fact that you can enable the Everything repo at install time. Also the contents of the install media change over time as deps change, so it's something that would have to be constantly monitored. > > Though it seems rather silly to me. Would we also not allow little flags > to show language preferences (eg french canadian vs american english)? That's precisely where we don't want to show flags. A) it's bad UI, and B) it's rather noticeable. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Thu May 21 19:46:50 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 22 May 2009 01:16:50 +0530 Subject: FESCo election nominations now open In-Reply-To: <20090521175153.GA11344@hansolo.jdub.homelinux.org> References: <4A15602A.90100@redhat.com> <1242915966.4320.3.camel@localhost.localdomain> <4A157001.80107@fedoraproject.org> <1242919693.3029.83.camel@localhost.localdomain> <4A157592.9060704@fedoraproject.org> <20090521154403.GA10929@hansolo.jdub.homelinux.org> <20090521175153.GA11344@hansolo.jdub.homelinux.org> Message-ID: <4A15AFAA.5000303@fedoraproject.org> On 05/21/2009 11:21 PM, Josh Boyer wrote: > > Honestly, if we want to open up the candidate pool to the same thing as the > voting pool that is fine with me. If you think it's important enough, you > could certainly file a ticket with FESCo and we can discuss it. Wouldn't it be a board decision? Rahul From awilliam at redhat.com Thu May 21 19:44:49 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 21 May 2009 12:44:49 -0700 Subject: I must be doing something seriously wrong... In-Reply-To: <1242934194.8848.202.camel@adam.local.net> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> <1242934194.8848.202.camel@adam.local.net> Message-ID: <1242935089.8848.208.camel@adam.local.net> On Thu, 2009-05-21 at 12:29 -0700, Adam Williamson wrote: > 4: even if we take it as a given that flags in Fedora are a problem > for > China, *and* are the only problem for China, *and* whatever policy we > wind up with that involves changing the main set of official Fedora > packages solves the problem, it has not been established that this is > the best way to solve the problem. Other proposals have been made - > such > as delegating the modification work to some kind of SIG, working on a > special spin of Fedora for China - and I haven't seen anyone explain > why > that's a worse idea than making all the changes directly in the main > Fedora package repositories. Given the above, here's my practical proposal, if we decided we really wanted to go through with this: * Those willing to make the effort to make significant ongoing changes to Fedora packages to make it acceptable to the Chinese government should form a SIG * Members of that SIG should be granted co-maintainer status on affected packages * They (not the main maintainers) should adjust affected packages to include a build-time conditional which adjusts the build to be acceptable for China: for instance, for a flag issue, they would introduce a --with-china build conditional which, when set to 1, would patch out the flags * They (the China SIG) should set up a separate repository for affected packages; in this repository, the packages would be built with the China build conditional set. In the official repositories, they would be built without it, and hence would work exactly as if the China changes did not exist * They (the China SIG) would be responsible for producing custom spins for each release, using the packages from the China repository This has the advantage that it places no extra burden on regular maintainers, and if the China changes break, it doesn't affect the main Fedora repositories. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From jonstanley at gmail.com Thu May 21 19:53:30 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Thu, 21 May 2009 15:53:30 -0400 Subject: FESCo election nominations now open In-Reply-To: <4A15AFAA.5000303@fedoraproject.org> References: <4A15602A.90100@redhat.com> <1242915966.4320.3.camel@localhost.localdomain> <4A157001.80107@fedoraproject.org> <1242919693.3029.83.camel@localhost.localdomain> <4A157592.9060704@fedoraproject.org> <20090521154403.GA10929@hansolo.jdub.homelinux.org> <20090521175153.GA11344@hansolo.jdub.homelinux.org> <4A15AFAA.5000303@fedoraproject.org> Message-ID: On Thu, May 21, 2009 at 3:46 PM, Rahul Sundaram wrote: > Wouldn't it be a board decision? I don't believe so - I don't believe that the board weighed in on the Docs decision to do away with FDSco, if I'm not mistaken. Individual commitees should be free to decide their own voting policy and the qualifications of their own candidates. Of course if the board had differences with whatever we decided, they would be well within their purview to intervene. From awilliam at redhat.com Thu May 21 19:55:47 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 21 May 2009 12:55:47 -0700 Subject: I must be doing something seriously wrong... In-Reply-To: References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> <1242934194.8848.202.camel@adam.local.net> Message-ID: <1242935747.8848.212.camel@adam.local.net> On Thu, 2009-05-21 at 15:33 -0400, Seth Vidal wrote: > > 1: a lot of that 1/6th of the world's population does not own a > > computer. Or an internet connection. (Or, in many cases, a reliable > > electricity supply). Let's not have any illusions about China: it > > contains a huge amount of people, but a rather smaller amount of > > possible potential Fedora users. > http://www.pcworld.com/businesscenter/article/145108/china_tops_us_for_internet_population_lead.html > > 228million people in china with internet access. > > That's 2/3rd the population of the United states and 8million more > internet accessing people than the US. The Chinese government body providing that number uses a rather lax standard: "CNNIC defines a user as anyone who uses the Internet at least once per month for any function." That does not require that the person has consistent access to the internet connection (which is close to a necessity for using Fedora). It also doesn't require that the internet connection be attached to a personal computer; any cellphone with a data connection satisfies that definition. I would suspect a large amount of the 228m are made up of people who own cellphones (but not, necessarily, personal computers - in Africa, for instance, many people own cellphones who could never afford a computer or a regular internet connection, I would not be surprised if this were the same in some areas of China), or people with access to shared facilities (universities or internet cafes). > Let's not underestimate this market, shall we? Pet peeve: it's not a market, for us. We're not trying to sell them anything, after all. To RHEL, it's a market. To Fedora, it's a potential user / contributor base. As you were :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From sundaram at fedoraproject.org Thu May 21 20:07:06 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 22 May 2009 01:37:06 +0530 Subject: FESCo election nominations now open In-Reply-To: References: <4A15602A.90100@redhat.com> <1242915966.4320.3.camel@localhost.localdomain> <4A157001.80107@fedoraproject.org> <1242919693.3029.83.camel@localhost.localdomain> <4A157592.9060704@fedoraproject.org> <20090521154403.GA10929@hansolo.jdub.homelinux.org> <20090521175153.GA11344@hansolo.jdub.homelinux.org> <4A15AFAA.5000303@fedoraproject.org> Message-ID: <4A15B46A.8090107@fedoraproject.org> On 05/22/2009 01:23 AM, Jon Stanley wrote: > On Thu, May 21, 2009 at 3:46 PM, Rahul Sundaram > wrote: > >> Wouldn't it be a board decision? > > I don't believe so - I don't believe that the board weighed in on the > Docs decision to do away with FDSco, if I'm not mistaken. Individual > commitees should be free to decide their own voting policy and the > qualifications of their own candidates. I don't think docs committee and FESCo is not at the same level which is why I believe others should be allowed to vote in the first place. Anyway advisory board is copied and they can be aware. I will raise it up to the board if necessary. Meanwhile filed a ticket at https://fedorahosted.org/fesco/ticket/156 Thank you for your consideration. Rahul From cweyl at alumni.drew.edu Thu May 21 20:02:44 2009 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Thu, 21 May 2009 13:02:44 -0700 Subject: Youth Protection: Was Re: Package Maintainers Flags policy In-Reply-To: <4A15A3C2.40000@redhat.com> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520102730.45a3b7d4@ohm.scrye.com> <4A143CDC.8040400@freenet.de> <4A143F64.5080002@redhat.com> <4A14C5BB.5050401@freenet.de> <7dd7ab490905202158sc923880ge50c81bceb580024@mail.gmail.com> <4A15A3C2.40000@redhat.com> Message-ID: <7dd7ab490905211302t2a65343dj2a3b61d4947850dd@mail.gmail.com> On Thu, May 21, 2009 at 11:56 AM, Tom "spot" Callaway wrote: > On 05/21/2009 12:58 AM, Chris Weyl wrote: > > Fedora, as a project of a US corporation, is liable for violation of the > > laws of the State of North Carolina and of the United States. > > Well, its actually the laws of the State of Delaware, but I digress. ;) > Man. Is my $work the only corporation left in the US _not_ incorporated in Delaware?! :) -Chris -- Chris Weyl Ex astris, scientia -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Thu May 21 20:03:13 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 21 May 2009 13:03:13 -0700 Subject: I must be doing something seriously wrong... In-Reply-To: <1242935089.8848.208.camel@adam.local.net> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> <1242934194.8848.202.camel@adam.local.net> <1242935089.8848.208.camel@adam.local.net> Message-ID: <1242936193.3217.4.camel@localhost.localdomain> On Thu, 2009-05-21 at 12:44 -0700, Adam Williamson wrote: > > This has the advantage that it places no extra burden on regular > maintainers, and if the China changes break, it doesn't affect the main > Fedora repositories. Seems like an awful lot of effort and bullcrap for the 5 or 6 packages involved. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From cweyl at alumni.drew.edu Thu May 21 20:04:11 2009 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Thu, 21 May 2009 13:04:11 -0700 Subject: Youth Protection: Was Re: Package Maintainers Flags policy In-Reply-To: <1242934563.3217.3.camel@localhost.localdomain> References: <20090518090953.5698908a@ohm.scrye.com> <4A13C879.4080002@poolshark.org> <20090520102730.45a3b7d4@ohm.scrye.com> <4A143CDC.8040400@freenet.de> <4A143F64.5080002@redhat.com> <4A14C5BB.5050401@freenet.de> <7dd7ab490905202158sc923880ge50c81bceb580024@mail.gmail.com> <4A15A3A5.4090004@redhat.com> <1242934563.3217.3.camel@localhost.localdomain> Message-ID: <7dd7ab490905211304x23b37c26ubdcb5ad0494056e7@mail.gmail.com> On Thu, May 21, 2009 at 12:36 PM, Jesse Keating wrote: > On Thu, 2009-05-21 at 15:04 -0400, Paul Wouters wrote: > > Though it seems rather silly to me. Would we also not allow little flags > > to show language preferences (eg french canadian vs american english)? > > That's precisely where we don't want to show flags. A) it's bad UI, and > B) it's rather noticeable. > Ah, excellent! So when are we going to start auditing all packages in Fedora for "bad UI"? :) -Chris -- Chris Weyl Ex astris, scientia -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonstanley at gmail.com Thu May 21 20:10:55 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Thu, 21 May 2009 16:10:55 -0400 Subject: FESCo election nominations now open In-Reply-To: <4A15B46A.8090107@fedoraproject.org> References: <4A157001.80107@fedoraproject.org> <1242919693.3029.83.camel@localhost.localdomain> <4A157592.9060704@fedoraproject.org> <20090521154403.GA10929@hansolo.jdub.homelinux.org> <20090521175153.GA11344@hansolo.jdub.homelinux.org> <4A15AFAA.5000303@fedoraproject.org> <4A15B46A.8090107@fedoraproject.org> Message-ID: On Thu, May 21, 2009 at 4:07 PM, Rahul Sundaram wrote: > https://fedorahosted.org/fesco/ticket/156 > > Thank you for your consideratio No problem, caught me right as I was doing the agenda. Will be on the agenda for tomorrow, 1700UTC. From jonstanley at gmail.com Thu May 21 20:16:00 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Thu, 21 May 2009 16:16:00 -0400 Subject: Plans for tomorrow's (20090522) FESCo meeting Message-ID: Following are the topics that are likely to be discussed at tomorrows's FESCo meeting, taking place at 1700UTC (1300EDT) in #fedora-meeting on irc.freenode.net: 152 provenpackager request - iarnell 153 Provenpackager request: hadess 154 Revert the recently published Flag policy 156 FESCo should allow non packagers to be committee members 157 OSGi Auto Dependencies - https://fedoraproject.org/wiki/Features/OSGiAutoDeps For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor. From wb8rcr at arrl.net Thu May 21 20:23:17 2009 From: wb8rcr at arrl.net (John J. McDonough) Date: Thu, 21 May 2009 16:23:17 -0400 Subject: FESCo election nominations now open References: <4A15602A.90100@redhat.com><1242915966.4320.3.camel@localhost.localdomain> <4A157001.80107@fedoraproject.org><1242919693.3029.83.camel@localhost.localdomain> <4A157592.9060704@fedoraproject.org><20090521154403.GA10929@hansolo.jdub.homelinux.org> <20090521175153.GA11344@hansolo.jdub.homelinux.org><4A15AFAA.5000303@fedoraproject.org> Message-ID: ----- Original Message ----- From: "Jon Stanley" To: Cc: "Development discussions related to Fedora" Sent: Thursday, May 21, 2009 3:53 PM Subject: Re: FESCo election nominations now open > I don't believe so - I don't believe that the board weighed in on the > Docs decision to do away with FDSco, if I'm not mistaken. You are correct, the board was not consulted. Basically, the team concluded that since a relatively small number of folks actually work on Docs, it made no sense to have a separate steering team. The FPL was involved in those discussions, but he had no more votes than anyone else. As I recall, it was a concensus decision. --McD From christoph.wickert at googlemail.com Thu May 21 20:35:58 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Thu, 21 May 2009 22:35:58 +0200 Subject: I must be doing something seriously wrong... In-Reply-To: <20090521170723.GA11191@hansolo.jdub.homelinux.org> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <20090521124654.GB10004@hansolo.jdub.homelinux.org> <1242922282.8758.13.camel@localhost.localdomain> <20090521170723.GA11191@hansolo.jdub.homelinux.org> Message-ID: <1242938158.2974.17.camel@localhost.localdomain> Am Donnerstag, den 21.05.2009, 13:07 -0400 schrieb Josh Boyer: > On Thu, May 21, 2009 at 06:11:22PM +0200, Christoph Wickert wrote: > >Am Donnerstag, den 21.05.2009, 08:46 -0400 schrieb Josh Boyer: > >> On Thu, May 21, 2009 at 02:20:52PM +0200, Christoph Wickert wrote: > >> [snipped] > >> > >> >privileges, so one should also pull his duties. If not, IMHO the person > >> >is not qualified for FESCo, simple as that. (Sorry if this sounds harsh) > >> > >> It doesn't sound particularly harsh, but I wonder what privileges you think > >> you get when you are in FESCo? > > > >As a FESCo member you are to decide over the direction that Fedora > >takes, this is the biggest privilege I can think of inside a FOSS > >project. > > 1) Yes, I do consider that a privilege. It is also a burden :) > > 2) Mostly we vote on policies and proposals and Features that the fedora > contributors submit. So while FESCo approves those, the direction that Fedora > takes is almost entirely driven by those submissions. Correct me if I'm wrong: A good number of proposals are made by people who are also in FESCo, right? Also I've got a notion that FESCo recently approves more and more proposals without asking the community for opinions first and even in opposition to the community. > >I think Toshio already uttered similar concerns, so FESCo should have > >dealt with them *before* ratifying the policy. Looking at the IRC log I > >see there was *zero* discussion but only +1s. (This is how I'd expect a > >vote in the Communist Party of China but not in Fedora - SCNR) > > Quite possibly, yes. > > >> >I do think it is relevant. The policy deals with religious flags, but it > >> >does not deal with religions symbols. I could draw a square around > >> >symbol and call it a flag. > >> > >> And I could remove a square from the flag and call it a symbol. Discussing > >> theoreticals at this point is only going to lead us to more and more absurd > >> cases. I don't think we're here to draft policies that cover every possible > >> situation whether it will ever happen in real life or not. > > > >I know I'm just to negative sometimes. I think we always need to be > >prepared for worst case scenarios, which also includes theoretical > >questions. Others say that this or that will never happen because we are > >all in the same boat, but I think history has proven different. > > It's a prudent approach. I find that preparing for the worst case scenario can > often lead to an entirely sub-optimal normal case scenario though. A balance > needs to be achieved. Agreed, but IMO this balance is missing in this case. Most likely we have a different POV here. > >> The original question was about advertising to the users. So how do we > >> advertise -docs packages to users, and why isn't that sufficient for -flags? > > > >I still think you put it wrong because IMO you are comparing apples and > >oranges. > > 1. In a perfect world (TM) there is no need for docs because > > everything is self self-explanatory. > > In a perfect world, there is no need for flags because humanity is united and > we have reached utopia. We don't live in a perfect world. Even in the Star Trek universe there are still flags ;) > > 2. At least users *should* not need docs at least none that are not > > installed by default. Our -docs packages are mostly targeted at > > developers and system administrators. > > And our flags packages would be targeted at whom? Users in free countries. > > 3. If someone really needs docs, he will realize this himself, > > because he is missing knowledge. For flags he doesn't. How is a > > deluge user supposed the realize the lack of a function? > > Deluge is clearly spelled out in the guideline as not needing flags for > functionality. Is that statement incorrect? Please note the difference between "a function" and "functionality". Of course the missing flags do not impact the basic function of deluge which is sharing files, but there is certain functionality missing. People can no longer see the location of their peers on a quick glance and have to read instead. > josh Regards, Christoph From notting at redhat.com Thu May 21 20:38:36 2009 From: notting at redhat.com (Bill Nottingham) Date: Thu, 21 May 2009 16:38:36 -0400 Subject: I must be doing something seriously wrong... In-Reply-To: <1242934194.8848.202.camel@adam.local.net> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> <1242934194.8848.202.camel@adam.local.net> Message-ID: <20090521203836.GB7210@nostromo.devel.redhat.com> Adam Williamson (awilliam at redhat.com) said: > > Benefits: > > - allows roughly 1/6 of the world's population to use Fedora freely > > > > Demerits: > > - requires ongoing maintenance work on some packages > > - may require removing packages that can't comply without being broken > > > > I feel the benefits in this case outweigh the demerits, and the > > amount of work required to be greatly exaggerated. Furthermore, > > making Fedora available for all to use freely is a fundamental > > goal of the project; ensuring the presence of, say, gcompris in > > a form that exactly matches upstream is much lower down the totem > > pole.[2] > > > Now, if we can discuss the benefits and demerits without resorting > > to reducuing it to 'aah! slippery slope' or 'I'm offended by > > yellow, take that out too!', it would help, as those are sort > > of missing the point. > > I don't think they're missing the point, as they raise valid problems > with your categorization. I don't agree with your 'Benefit', for the > following reasons: > > 1: a lot of that 1/6th of the world's population does not own a > computer. Or an internet connection. (Or, in many cases, a reliable > electricity supply). Let's not have any illusions about China: it > contains a huge amount of people, but a rather smaller amount of > possible potential Fedora users. You could say that about many countries. In any case, even if 1/10 of one percent of those people are viable users... that still dwarfs the affected packager base by many orders of magnitude. > 1a: Fedora is not, in point of practical reality, unavailable to China > at present. Even if, by official Chinese government policy, Fedora > contains material that should not be distributed in China, it has been > reported that - in practice - it is perfectly possible to download > Fedora in China from many different mirrors, flags and all. Possible? Sure. It doesn't mean it's necessarily a good idea to knowingly provide software to people that can get them in trouble with their local authorities. > 2: it has not by any means been established that solely removing flags > from the distribution would be sufficient for the Chinese government to > be happy with Fedora being actively promoted / distributed within China. Given that related operating systems with *ONLY* these changes are allowed, it's a fair assumption to make. Honestly, I think the proof is on others that it wouldn't be enough, given that existing evidence points to the positive. > the best way to solve the problem. Other proposals have been made - such > as delegating the modification work to some kind of SIG, working on a > special spin of Fedora for China - and I haven't seen anyone explain why > that's a worse idea than making all the changes directly in the main > Fedora package repositories. Proliferation of spins and maintenance for specific geographies is a waste of space and effort, if it can be avoided. That's why we have languages included on the Desktop spin, instead of 15 different localized ones. Bill From andreas at bawue.net Thu May 21 21:23:33 2009 From: andreas at bawue.net (Andreas Thienemann) Date: Thu, 21 May 2009 23:23:33 +0200 (CEST) Subject: FESCo election nominations now open In-Reply-To: References: <4A15602A.90100@redhat.com> <1242915966.4320.3.camel@localhost.localdomain> <4A157001.80107@fedoraproject.org> <1242919693.3029.83.camel@localhost.localdomain> <4A157592.9060704@fedoraproject.org> <20090521154403.GA10929@hansolo.jdub.homelinux.org> <20090521175153.GA11344@hansolo.jdub.homelinux.org> Message-ID: On Thu, 21 May 2009, inode0 wrote: > I would just as likely think the voting pool should be constricted to > be aligned with the candidate pool. Without thoughtful deliberation > and some understanding of the reasoning behind its current structure > it just seems rather arbitrary to me. And I'm sure there was plenty of > thoughtful deliberation at the time, but I'm unaware of what it was. I was actually starting to write what a terrible idea this would be, as we'd be taking a step back from being a truly open project... But then it occured to me, that we've never really been an open project. There's no way to vote for a feature which will then be implemented as a simple example. If you want a feature, implement it or persuade someone that it is important enough for him to write the necessary code. Fedora has always been (more or less) a meritocracy. Whoever does the work, has the power to define the direction fedora is taking. >From what I gather, everybody is happy with this approach. Allowing everybody with cla_done plus one additional group to vote for the Fedora steering organizations is actually going against the meritocracy. Fedora ismostly a collection of software packages. Therefore it is consistent with the idea of a meritocracy to restrict the candidate pool for the steering committee to the people working on the software, that is everyone with cvs access. Limiting the group of people eligble to cast votes to the same group of people is actually not a bad idea. That way, the only the people having to live under the new management can vote for it. This reasoning has a certain appeal to me even though I know that it disregards the contributions by the art team, the translators etc. On the other hand, as it was mentioned in this thread several times, Fesco doesn't really set much policy for their work either. Thus it's an acceptable trade off. As supporting evidence a simple example from the top of my head: The Fedora Ambassadors Steering Committee can only be elected by members of the ambassador group. regards, andreas From kevin.kofler at chello.at Thu May 21 23:09:34 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 22 May 2009 01:09:34 +0200 Subject: Package Maintainers Flags policy References: <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> <20090519181454.GA4397@nostromo.devel.redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <4A131DC6.8000605@gmail.com> <1242767869.3029.13.camel@localhost.localdomain> <20090521155252.GH32139@macmahon.me.uk> <1242922157.3029.87.camel@localhost.localdomain> Message-ID: Jesse Keating wrote: > Oh my yes, we were terrible about rule enforcement within RHT. If it > wasn't a QA check item, it didn't get seen. Note the terrible package > quality. The customers who complained about the flags likely never ran > FreeCiv and thus never noticed the flags within. Had they noticed, > FreeCiv likely would have been altered, or removed. The Bluecurve icon theme, which was even DEVELOPED at RH, also contains country flags (see the preferences-desktop-locale.png icon). Kevin Kofler From christoph.wickert at googlemail.com Thu May 21 23:13:36 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Fri, 22 May 2009 01:13:36 +0200 Subject: I must be doing something seriously wrong... In-Reply-To: <1242936193.3217.4.camel@localhost.localdomain> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> <1242934194.8848.202.camel@adam.local.net> <1242935089.8848.208.camel@adam.local.net> <1242936193.3217.4.camel@localhost.localdomain> Message-ID: <1242947616.2974.33.camel@localhost.localdomain> Am Donnerstag, den 21.05.2009, 13:03 -0700 schrieb Jesse Keating: > On Thu, 2009-05-21 at 12:44 -0700, Adam Williamson wrote: > > > > This has the advantage that it places no extra burden on regular > > maintainers, and if the China changes break, it doesn't affect the main > > Fedora repositories. > > Seems like an awful lot of effort and bullcrap for the 5 or 6 packages > involved. So does the policy. You just managed to nullify the policy and the whole discussion in a single sentence. If it's just 5 or 6 packages anyway, who needs a policy? Regards, Christoph From jkeating at redhat.com Thu May 21 23:24:43 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 21 May 2009 16:24:43 -0700 Subject: Package Maintainers Flags policy In-Reply-To: References: <20090519163232.GA3247@nostromo.devel.redhat.com> <20090519174232.GA3984@nostromo.devel.redhat.com> <20090519181454.GA4397@nostromo.devel.redhat.com> <4A130827.6040103@gmail.com> <1242762936.3029.6.camel@localhost.localdomain> <4A131DC6.8000605@gmail.com> <1242767869.3029.13.camel@localhost.localdomain> <20090521155252.GH32139@macmahon.me.uk> <1242922157.3029.87.camel@localhost.localdomain> Message-ID: <1242948283.3217.8.camel@localhost.localdomain> On Fri, 2009-05-22 at 01:09 +0200, Kevin Kofler wrote: > > The Bluecurve icon theme, which was even DEVELOPED at RH, also contains > country flags (see the preferences-desktop-locale.png icon). Yep, RHT isn't perfect (who said they were?). This doesn't invalidate what I wrote though. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kevin.kofler at chello.at Thu May 21 23:41:30 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 22 May 2009 01:41:30 +0200 Subject: I must be doing something seriously wrong... References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> Message-ID: Christoph Wickert wrote: >> 5) I don't know the answer to your question, nor do I find it relevant in >> a discussion about flags. It's been pointed out several times that the >> flags policy opens doors to madness through defining 'acceptable' >> content, so let's not start yet another massive thread about that at the >> moment. > > I do think it is relevant. The policy deals with religious flags, but it > does not deal with religions symbols. I could draw a square around > symbol and call it a flag. You make a good point there: So a Fedora package can contain all the svastikas it wants as long as they aren't in a flag?! What sense does that make? Kevin Kofler From kevin.kofler at chello.at Thu May 21 23:54:03 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 22 May 2009 01:54:03 +0200 Subject: I must be doing something seriously wrong... References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> <1242934194.8848.202.camel@adam.local.net> <1242935747.8848.212.camel@adam.local.net> Message-ID: Adam Williamson wrote: > The Chinese government body providing that number uses a rather lax > standard: > > "CNNIC defines a user as anyone who uses the Internet at least once per > month for any function." > > That does not require that the person has consistent access to the > internet connection (which is close to a necessity for using Fedora). It > also doesn't require that the internet connection be attached to a > personal computer; any cellphone with a data connection satisfies that > definition. > > I would suspect a large amount of the 228m are made up of people who own > cellphones (but not, necessarily, personal computers - in Africa, for > instance, many people own cellphones who could never afford a computer > or a regular internet connection, I would not be surprised if this were > the same in some areas of China), or people with access to shared > facilities (universities or internet cafes). In addition, even for those who do have a personal Internet connection attached to a computer, nothing is said about speed. A slow dial-up connection is not of much use for Fedora with its many huge updates. >> Let's not underestimate this market, shall we? > > Pet peeve: it's not a market, for us. We're not trying to sell them > anything, after all. To RHEL, it's a market. To Fedora, it's a potential > user / contributor base. As you were :) Right. We should not think like a business, as we aren't a business, and the company we're all thinking of doesn't make any money out of us. Kevin Kofler From mjg at redhat.com Thu May 21 23:56:09 2009 From: mjg at redhat.com (Matthew Garrett) Date: Fri, 22 May 2009 00:56:09 +0100 Subject: I must be doing something seriously wrong... In-Reply-To: References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> Message-ID: <20090521235609.GA2150@srcf.ucam.org> On Fri, May 22, 2009 at 01:41:30AM +0200, Kevin Kofler wrote: > Christoph Wickert wrote: > > I do think it is relevant. The policy deals with religious flags, but it > > does not deal with religions symbols. I could draw a square around > > symbol and call it a flag. > > You make a good point there: So a Fedora package can contain all the > svastikas it wants as long as they aren't in a flag?! What sense does that > make? Are you really suggesting that the project needs a policy to cover common sense? -- Matthew Garrett | mjg59 at srcf.ucam.org From kevin.kofler at chello.at Thu May 21 23:55:50 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 22 May 2009 01:55:50 +0200 Subject: I must be doing something seriously wrong... References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> <1242934194.8848.202.camel@adam.local.net> <1242935089.8848.208.camel@adam.local.net> <1242936193.3217.4.camel@localhost.localdomain> Message-ID: Jesse Keating wrote: > Seems like an awful lot of effort and bullcrap for the 5 or 6 packages > involved. I know of at least 5 others which haven't been listed yet, and I'm sure there are several more. Kevin Kofler From kevin.kofler at chello.at Fri May 22 00:09:48 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 22 May 2009 02:09:48 +0200 Subject: I must be doing something seriously wrong... References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> <1242934194.8848.202.camel@adam.local.net> <20090521203836.GB7210@nostromo.devel.redhat.com> Message-ID: Bill Nottingham wrote: > You could say that about many countries. In any case, even if 1/10 of one > percent of those people are viable users... that still dwarfs the affected > packager base by many orders of magnitude. But not the affected user base if you remove useful apps like geography learning apps because they show Taiwan as a country complete with flag. (And yes, at least one such app exists.) > Given that related operating systems with *ONLY* these changes are > allowed, it's a fair assumption to make. But what about the many distros which do not do these changes? Kubuntu ships the Taiwanese flag, see: http://packages.ubuntu.com/jaunty/all/kdebase-runtime-data-common/filelist Yet they even have a .org.cn site: http://www.kubuntu.org.cn/ which appears to be hosted inside mainland China. > Proliferation of spins and maintenance for specific geographies is > a waste of space and effort, if it can be avoided. That's why we > have languages included on the Desktop spin, instead of 15 different > localized ones. That's how it works for GNOME, but KDE *needs* localized spins anyway as there's no way to fit all the huge kde-l10n-* packages on a CD. The KDE spin does *NOT* include any translations. Kevin Kofler From kevin.kofler at chello.at Fri May 22 00:10:48 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 22 May 2009 02:10:48 +0200 Subject: I must be doing something seriously wrong... References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> <1242934194.8848.202.camel@adam.local.net> <1242935089.8848.208.camel@adam.local.net> <1242936193.3217.4.camel@localhost.localdomain> Message-ID: I wrote: > I know of at least 5 others which haven't been listed yet, and I'm sure > there are several more. PS: And those 5 DO NOT INCLUDE the icon themes I reported at: https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01708.html Kevin Kofler From oget.fedora at gmail.com Fri May 22 00:54:09 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Thu, 21 May 2009 20:54:09 -0400 Subject: I must be doing something seriously wrong... In-Reply-To: References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> Message-ID: On Thu, May 21, 2009 at 7:41 PM, Kevin Kofler wrote: > Christoph Wickert wrote: >>> 5) I don't know the answer to your question, nor do I find it relevant in >>> a discussion about flags. ?It's been pointed out several times that the >>> flags policy opens doors to madness through defining 'acceptable' >>> content, so let's not start yet another massive thread about that at the >>> moment. >> >> I do think it is relevant. The policy deals with religious flags, but it >> does not deal with religions symbols. I could draw a square around >> symbol and call it a flag. > > You make a good point there: So a Fedora package can contain all the > svastikas it wants as long as they aren't in a flag?! What sense does that > make? What about football team flags? If we include FC Barcelona flag in Fedora, Real Madrid fans (a couple hundreds of millions of people) might get offended and they might stop using Fedora. So where do we draw the line? Orcan From dchen at redhat.com Fri May 22 01:52:32 2009 From: dchen at redhat.com (Ding-Yi Chen) Date: Fri, 22 May 2009 11:52:32 +1000 Subject: Package Maintainers Flags policy In-Reply-To: References: <4A127B5E.2080600@poolshark.org> <200905201207.31072.surenkarapetyan@gmail.com> <1242805780.4500.29.camel@dhcp-0-207.bne.redhat.com> <200905201007.30543.mhlavink@redhat.com> <1242881026.4596.23.camel@localhost.localdomain> Message-ID: <1242957152.6598.34.camel@dhcp-0-207.bne.redhat.com> ? ??2009-05-21 ? 07:23 +0200?Kevin Kofler ??? > Ding-Yi Chen wrote: > > Using input method icons, however, solves your case and mine. > > What icons? There may be standard icons for Chinese input methods, but there > are no standard icons for keyboard layouts. The language code is nonsense, > as e.g. English and German have different keyboards depending on the > country. There are no such "standard Chinese IM icons", IM developers can use whatever icons they like to distinguish their input methods. key layout icons can do the similar way, icons can be either designed by the key-layout switch developers or community. This also solve the problem related to US-qwerty and US-dvorak. > > > And how about multilingual countries such as India and Switzerland? > > For Switzerland, the different layouts are implemented as variants of the ch > layout, so putting the ch layout up with a Swiss flag and then letting you > pick the variant (which is what KDE does) is the best way to handle it. If > you disagree with them being handled as variants, complain to the xkb > folks, they're setting it up that way. > > India is a much more complex case though. > > Kevin Kofler Actually the ibus do the similar way: You can enable the IMs by their languages, but without showing flags. But I quite doubt the KDE's country oriented scheme is better. For example, English and Australian might be somewhat disappointed that their flags are not in the list, while language oriented scheme does not have such problems. -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ From paul at xelerance.com Fri May 22 01:57:43 2009 From: paul at xelerance.com (Paul Wouters) Date: Thu, 21 May 2009 21:57:43 -0400 (EDT) Subject: I must be doing something seriously wrong... In-Reply-To: <20090521185342.GA6176@nostromo.devel.redhat.com> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> Message-ID: On Thu, 21 May 2009, Bill Nottingham wrote: > As I said, it's a trade-off between: > > Benefits: > - allows roughly 1/6 of the world's population to use Fedora freely Fedora is already allowed to be used freely. If your country does not allow you to use free software, that's a problem out of scope of Fedora. > I feel the benefits in this case outweigh the demerits, and the The benefits takes away my freedoms of referencing a country my flag and image that my own country recognises. > amount of work required to be greatly exaggerated. Because a 3 second check already spotted non-flag issue?s Should these go to: /usr/lib64/openoffice.org/basis3.1/share/template/wizard/bitmap/taiwan.gif /usr/share/texmf/omega/otp/otibet/tibadjusttsheg.otp /usr/lib64/pango/1.6.0/modules/pango-tibetan-fc.so Today flags. tomorrow geography? Next week a language? Next year a culture? > making Fedora available for all to use freely is a fundamental > goal of the project; You cannot give Chinese people the freedom to see flags. Only China can. If you want to free them, show them freedom, don't take freedom away from us. > Now, if we can discuss the benefits and demerits without resorting > to reducuing it to 'aah! slippery slope' or 'I'm offended by > yellow, take that out too!', it would help, as those are sort > of missing the point. Those are not missing the point though. Would you have banned a game that included an (illegal) photo of a coffin of a dead US soldier, when that was illegal in the Bush regime too? What about marihuana leaves (legal where I come from)? Or some chemistry software that displaces a cocaine molecule? Or the above references of a piece of the earth called Taiwan? How about navigation software that tells you how to go to Cuba from Florida? A chemistry book that tells you how to make gun powder? What if Taiwan goes DNSSEC and I want to add the DNSKEY to the dnssec-conf package? Should 10/10th of the world not have DNSSEC protection to save 1/6th of the world from not having Fedora? Russians officially are not allowed to use RSA and should use GOST, are you going to exclude that too to help them, as the US does not ban use of GOST so clearly using GOST would have the benefit of 1/10 of the population of this planet to use Fedora? The whole point is about a slippery slope, and the only way out is not to play. Fedora is already free. It does not need to be more free. If people need to make changes, because their government puts additional restrictions on top of international rule, then let the Newspeak Department of said country respin the free software themselves into a Fedora NewSpeak. Paul From andreas at bawue.net Fri May 22 02:28:25 2009 From: andreas at bawue.net (Andreas Thienemann) Date: Fri, 22 May 2009 04:28:25 +0200 (CEST) Subject: I must be doing something seriously wrong... In-Reply-To: References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> Message-ID: On Thu, 21 May 2009, Paul Wouters wrote: I'm intrigued by your ideas and would like to subscribe to your newsletter. On a more serious note: I assume you know about ? I tried adding the reasons pro and con the flag-banning to the ticket in order to lead fesco to the right decision... I'd be happy if you could add any more points you have to that ticket, but please "be excellent". :) regards, andreas From kevin.kofler at chello.at Fri May 22 02:58:21 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 22 May 2009 04:58:21 +0200 Subject: Package Maintainers Flags policy References: <4A127B5E.2080600@poolshark.org> <200905201207.31072.surenkarapetyan@gmail.com> <1242805780.4500.29.camel@dhcp-0-207.bne.redhat.com> <200905201007.30543.mhlavink@redhat.com> <1242881026.4596.23.camel@localhost.localdomain> <1242957152.6598.34.camel@dhcp-0-207.bne.redhat.com> Message-ID: Ding-Yi Chen wrote: > There are no such "standard Chinese IM icons", IM developers can use > whatever icons they like to distinguish their input methods. And where do they come from and how do they make the user understand what they're about to select? > key layout icons can do the similar way, icons can be either designed by > the key-layout switch developers or community. But the icons need to be recognizable by the user! If I draw a beautiful flower to represent, say, the German keyboard layout, how do people know the flower corresponds to a German keyboard layout? Well, I could use an Edelweiss which is common in Austria (which uses the same layout) and Bavaria (part of Germany), but it's also common in Alpine regions of Italy, in Switzerland and in a few other countries which all do not use the same keyboard layout. That kind of regional symbols doesn't work any better than flags. A picture of the keyboard with keys printed on it isn't going to work either, at the size of a systray icon the letters are all condensed at best to single pixels, you can't recognize anything at all. 2-letter layout names are the best we can have without flags, but 1. it's text, not an icon and 2. the layout names aren't really any more neutral than the flags (they are mostly country names, sometimes language names). > For example, English and Australian might be somewhat disappointed that > their flags are not in the list, while language oriented scheme does not > have such problems. * The United Kingdom is actually in the list. * Language-oriented does not work. German and English are both spoken in different countries with different keyboard layouts! While Austria and Germany use the same layout, Switzerland uses a different one. And the UK layout is also significantly different from the US one. Ireland also has its own layout (and no, Irish is not the native language of most people there, English is). The list of keyboard layouts is neither per country nor per language. Kevin Kofler From dchen at redhat.com Fri May 22 04:13:16 2009 From: dchen at redhat.com (Ding-Yi Chen) Date: Fri, 22 May 2009 14:13:16 +1000 Subject: Package Maintainers Flags policy In-Reply-To: References: <4A127B5E.2080600@poolshark.org> <200905201207.31072.surenkarapetyan@gmail.com> <1242805780.4500.29.camel@dhcp-0-207.bne.redhat.com> <200905201007.30543.mhlavink@redhat.com> <1242881026.4596.23.camel@localhost.localdomain> <1242957152.6598.34.camel@dhcp-0-207.bne.redhat.com> Message-ID: <1242965596.6598.78.camel@dhcp-0-207.bne.redhat.com> ? ??2009-05-22 ? 04:58 +0200?Kevin Kofler ??? > Ding-Yi Chen wrote: > > There are no such "standard Chinese IM icons", IM developers can use > > whatever icons they like to distinguish their input methods. > > And where do they come from and how do they make the user understand what > they're about to select? No problem. Normally we just pick the first or significant character of the input method name. Like "?" "?", "?", "?", or input method specific icon like "?". Smaller characters on the bottom right to show the variance. If your script is horizontal like English, you can either stretch the text or leave the button space to show the variance. > > key layout icons can do the similar way, icons can be either designed by > > the key-layout switch developers or community. > > But the icons need to be recognizable by the user! If I draw a beautiful > flower to represent, say, the German keyboard layout, how do people know > the flower corresponds to a German keyboard layout? Well, I could use an > Edelweiss which is common in Austria (which uses the same layout) and > Bavaria (part of Germany), but it's also common in Alpine regions of Italy, > in Switzerland and in a few other countries which all do not use the same > keyboard layout. That kind of regional symbols doesn't work any better than > flags. A picture of the keyboard with keys printed on it isn't going to > work either, at the size of a systray icon the letters are all condensed at > best to single pixels, you can't recognize anything at all. I agree with your first sentence. But no worry, icons that cannot be recognized by its users will not get into the package if the developers and community are sensible. > 2-letter layout names are the best we can have without flags, but 1. it's > text, not an icon and 2. the layout names aren't really any more neutral > than the flags (they are mostly country names, sometimes language names). Flags do have issues. Haven't you seen the whole thread? But 2-letter layout name don't. Have you seen any article mention about it? BTW, where does the 2-letter layout came from? > > For example, English and Australian might be somewhat disappointed that > > their flags are not in the list, while language oriented scheme does not > > have such problems. > > * The United Kingdom is actually in the list. But Australia and New zealand are not. > The list of keyboard layouts is neither per country nor > per language. > > Kevin Kofler If the list of keyboard layouts is neither per country nor per language, how come there is a "Show country flags" option? -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ From maxamillion at gmail.com Fri May 22 04:25:07 2009 From: maxamillion at gmail.com (Adam Miller) Date: Thu, 21 May 2009 23:25:07 -0500 Subject: Fedora and the moblin2 fork In-Reply-To: <1242853018.8848.159.camel@adam.local.net> References: <5256d0b0905191547w1d5725c3i2cd4338723cecc64@mail.gmail.com> <20090519221238.608afa5d@infradead.org> <5256d0b0905192351q2b83333fgcb738c7f29334686@mail.gmail.com> <1242853018.8848.159.camel@adam.local.net> Message-ID: In an attempt to get the ball rolling, I was hoping that we might be able to get some direction on where bits need work and/or what parts of Moblin we would like to include with Fedora. If this is already outlined somewhere and I might have simply missed it, please post me the URL so that I can try and start working on bits a pieces I am able as soon as I get some free time. Thank you, -Adam -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From a.badger at gmail.com Fri May 22 05:21:40 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 21 May 2009 22:21:40 -0700 Subject: Orphaning python-cjson Message-ID: <4A163664.9070309@gmail.com> Hey all, I'm orphaning python-cjson as I don't use it for anything. This is a python module that has a few simple functions for reading and writing json serialized data. In python-2.6 and above, python has a stdlibrary module for doing that based on python-simplejson. In python before python-2.6, this is one of several competing modules for working with json. sugar-datastore looks like it's the only package in Fedora that uses it. If you have a program that depends on python-cjson but you'd rather port to python-simplejson/the python module in python-2.6's stdlibrary it's usually fairly easy to switch. cjson has two methods, one for serializing an object into a string and one for parsing the string into an object. The equivalents in simplejson are: cjson simplejson decode() loads() encode() dumps() -Toshio From pbrobinson at gmail.com Fri May 22 08:20:31 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Fri, 22 May 2009 09:20:31 +0100 Subject: Fedora and the moblin2 fork In-Reply-To: References: <5256d0b0905191547w1d5725c3i2cd4338723cecc64@mail.gmail.com> <20090519221238.608afa5d@infradead.org> <5256d0b0905192351q2b83333fgcb738c7f29334686@mail.gmail.com> <1242853018.8848.159.camel@adam.local.net> Message-ID: <5256d0b0905220120o455496feie68a799d13ca7c05@mail.gmail.com> On Fri, May 22, 2009 at 5:25 AM, Adam Miller wrote: > In an attempt to get the ball rolling, I was hoping that we might be > able to get some direction on where bits need work and/or what parts > of Moblin we would like to include with Fedora. > > If this is already outlined somewhere and I might have simply missed > it, please post me the URL so that I can try and start working on bits > a pieces I am able as soon as I get some free time. Not yet, but its on my todo list. I might even get to it over the weekend. Peter From mschwendt at gmail.com Fri May 22 08:24:58 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 22 May 2009 08:24:58 -0000 Subject: Broken dependencies in Fedora 11 - 2009-05-22 Message-ID: <20090522082458.5441.81333@faldor.intranet> ====================================================================== The results in this summary consider Test Updates! ====================================================================== Summary of broken packages (by src.rpm name): cabal2spec mingw32-libglademm24 mingw32-plotmm qbittorrent Summary of broken packages (by primary owner): leigh123linux AT googlemail com qbittorrent petersen AT redhat com cabal2spec (1 co-owner) t.sailer AT alumni.ethz ch mingw32-libglademm24 (1 co-owner) mingw32-plotmm (1 co-owner) ====================================================================== Broken packages in fedora-development-ppc64: cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 ====================================================================== Broken packages in fedora-updates-11-i386: mingw32-libglademm24-2.6.7-6.fc11.noarch requires mingw32(libgtkmm-2.4-1.dll) mingw32-plotmm-0.1.2-2.fc11.noarch requires mingw32(libgtkmm-2.4-1.dll) mingw32-plotmm-0.1.2-2.fc11.noarch requires mingw32(libgdkmm-2.4-1.dll) mingw32-plotmm-0.1.2-2.fc11.noarch requires mingw32(libatkmm-1.6-1.dll) qbittorrent-1.3.3-4.fc11.i586 requires libtorrent-rasterbar.so.3 ====================================================================== Broken packages in fedora-updates-11-ppc: mingw32-libglademm24-2.6.7-6.fc11.noarch requires mingw32(libgtkmm-2.4-1.dll) mingw32-plotmm-0.1.2-2.fc11.noarch requires mingw32(libgtkmm-2.4-1.dll) mingw32-plotmm-0.1.2-2.fc11.noarch requires mingw32(libgdkmm-2.4-1.dll) mingw32-plotmm-0.1.2-2.fc11.noarch requires mingw32(libatkmm-1.6-1.dll) qbittorrent-1.3.3-4.fc11.ppc requires libtorrent-rasterbar.so.3 ====================================================================== Broken packages in fedora-updates-11-ppc64: mingw32-libglademm24-2.6.7-6.fc11.noarch requires mingw32(libgtkmm-2.4-1.dll) mingw32-plotmm-0.1.2-2.fc11.noarch requires mingw32(libgtkmm-2.4-1.dll) mingw32-plotmm-0.1.2-2.fc11.noarch requires mingw32(libgdkmm-2.4-1.dll) mingw32-plotmm-0.1.2-2.fc11.noarch requires mingw32(libatkmm-1.6-1.dll) qbittorrent-1.3.3-4.fc11.ppc64 requires libtorrent-rasterbar.so.3()(64bit) ====================================================================== Broken packages in fedora-updates-11-x86_64: mingw32-libglademm24-2.6.7-6.fc11.noarch requires mingw32(libgtkmm-2.4-1.dll) mingw32-plotmm-0.1.2-2.fc11.noarch requires mingw32(libgtkmm-2.4-1.dll) mingw32-plotmm-0.1.2-2.fc11.noarch requires mingw32(libgdkmm-2.4-1.dll) mingw32-plotmm-0.1.2-2.fc11.noarch requires mingw32(libatkmm-1.6-1.dll) qbittorrent-1.3.3-4.fc11.x86_64 requires libtorrent-rasterbar.so.3()(64bit) From rawhide at fedoraproject.org Fri May 22 13:07:26 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Fri, 22 May 2009 13:07:26 +0000 (UTC) Subject: rawhide report: 20090522 changes Message-ID: <20090522130726.2D0571F8217@releng2.fedora.phx.redhat.com> Compose started at Fri May 22 06:15:04 UTC 2009 Updated Packages: alsa-lib-1.0.20-1.fc11 ---------------------- * Wed May 06 2009 Jaroslav Kysela - 1.0.20-1 - Updated to 1.0.20 final gallery2-2.3-11.fc11 -------------------- * Thu May 21 2009 Jon Ciesla - 2.3-11 - Patch to fix SMTP, 501868. - Patch to fix captcha, 501871. * Thu May 14 2009 Jon Ciesla - 2.3-10 - Fine-tuning of symlink script. pungi-2.0.16-1.fc11 ------------------- * Thu May 21 2009 Jesse Keating - 2.0.16-1 - Fix boot.iso being on DVD images tigervnc-0.0.90-0.10.fc11 ------------------------- * Thu May 21 2009 Adam Tkac 0.0.90-10 - rebuild against 1.6.1.901 X server (#497835) - disable i18n, vncviewer is not UTF-8 compatible (#501832) Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 4 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From jmoskovc at redhat.com Fri May 22 13:10:33 2009 From: jmoskovc at redhat.com (Jiri Moskovcak) Date: Fri, 22 May 2009 15:10:33 +0200 Subject: Abrt - should this be a feature? In-Reply-To: References: <4A0DC949.7000601@fedoraproject.org> <4A116F78.3020607@redhat.com> <4A118A4C.3050909@fedoraproject.org> <4A1290AD.90205@redhat.com> <4A154D52.1000500@redhat.com> Message-ID: <4A16A449.1010602@redhat.com> Matej Cepl wrote: > Colin Walters, Thu, 21 May 2009 10:35:39 -0400: >> I'm reading the architecture page now, but I'm not seeing how ABRT works >> in this respect. Does ABRT have a "retracer" server component like >> Apport/Breakpad, or does it somehow ensure -debuginfo gets installed on >> the client? Or does it rely on a modified gdb to just-in-time fetch the >> data from an ABRT web service? Something else? > > http://fedoraproject.org/wiki/Features/DebuginfoFS it slipped to Fedora > 12 but when it is ready, it should take of debuginfo, right? > > Matej > Yes, that is the intention, but for now we simply use debuginfo-install, which really far from optimal solution :-/ If some has better idea how to get usefull BT without installing the debuginfo packages it'll be more than welcome... Jirka -------------- next part -------------- A non-text attachment was scrubbed... Name: jmoskovc.vcf Type: text/x-vcard Size: 126 bytes Desc: not available URL: From maxamillion at gmail.com Fri May 22 13:11:20 2009 From: maxamillion at gmail.com (Adam Miller) Date: Fri, 22 May 2009 08:11:20 -0500 Subject: Fedora and the moblin2 fork In-Reply-To: <5256d0b0905220120o455496feie68a799d13ca7c05@mail.gmail.com> References: <5256d0b0905191547w1d5725c3i2cd4338723cecc64@mail.gmail.com> <20090519221238.608afa5d@infradead.org> <5256d0b0905192351q2b83333fgcb738c7f29334686@mail.gmail.com> <1242853018.8848.159.camel@adam.local.net> <5256d0b0905220120o455496feie68a799d13ca7c05@mail.gmail.com> Message-ID: > > Not yet, but its on my todo list. I might even get to it over the weekend. > > Peter Awesome, sounds good. Just let me know, I have installed the Moblin 2 Beta on my Aspire One and I couldn't be more pleased. Very excited to get this stuff mixed into Fedora! -Adam -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From jan.kratochvil at redhat.com Fri May 22 13:28:01 2009 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Fri, 22 May 2009 15:28:01 +0200 Subject: Abrt - should this be a feature? In-Reply-To: <4A16A449.1010602@redhat.com> References: <4A0DC949.7000601@fedoraproject.org> <4A116F78.3020607@redhat.com> <4A118A4C.3050909@fedoraproject.org> <4A1290AD.90205@redhat.com> <4A154D52.1000500@redhat.com> <4A16A449.1010602@redhat.com> Message-ID: <20090522132801.GA21545@host0.dyn.jankratochvil.net> On Fri, 22 May 2009 15:10:33 +0200, Jiri Moskovcak wrote: > Yes, that is the intention, but for now we simply use debuginfo-install, > which really far from optimal solution :-/ If some has better idea how > to get usefull BT without installing the debuginfo packages it'll be > more than welcome... Without any debuginfos still as all the rpms are built using gcc option -fasynchronous-unwind-tables GDB will print the backtraces correctly but only with numeric addresses (no function names) and without any function parameters or local variables printed. In some specific cases IIRC the backtrace will stop at some point. These cases should be fixed and there are just missing bugreports/reproducers for them. I do not know of such case offhand myself now, if it did happen at all. One should also write down build-ids (sort of =NVRs) to be able to later retrace the numerical backtraces on some debuginfo-featuring server. Regards, Jan From j.w.r.degoede at hhs.nl Fri May 22 13:40:08 2009 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 22 May 2009 15:40:08 +0200 Subject: Review swapsies Message-ID: <4A16AB38.6000906@hhs.nl> Hi, Anyone wants to swap 2 reviews with me ? Review Request: libglpng - Toolkit for loading PNG images as OpenGL textures https://bugzilla.redhat.com/show_bug.cgi?id=502189 Review Request: chromium-bsu - Fast paced, arcade-style, top-scrolling space shooter https://bugzilla.redhat.com/show_bug.cgi?id=502191 Regards, Hans From notting at redhat.com Fri May 22 14:19:21 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 22 May 2009 10:19:21 -0400 Subject: I must be doing something seriously wrong... In-Reply-To: References: <1242908453.6300.44.camel@localhost.localdomain> <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> <1242934194.8848.202.camel@adam.local.net> <1242935089.8848.208.camel@adam.local.net> <1242936193.3217.4.camel@localhost.localdomain> Message-ID: <20090522141921.GB15667@nostromo.devel.redhat.com> Kevin Kofler (kevin.kofler at chello.at) said: > Jesse Keating wrote: > > Seems like an awful lot of effort and bullcrap for the 5 or 6 packages > > involved. > > I know of at least 5 others which haven't been listed yet, and I'm sure > there are several more. Perhaps you'd like to explicitly list them, rather than just stating this repeatedly? Bill From notting at redhat.com Fri May 22 14:36:08 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 22 May 2009 10:36:08 -0400 Subject: I must be doing something seriously wrong... In-Reply-To: References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> Message-ID: <20090522143608.GC15667@nostromo.devel.redhat.com> Paul Wouters (paul at xelerance.com) said: >> Benefits: >> - allows roughly 1/6 of the world's population to use Fedora freely > > Fedora is already allowed to be used freely. If your country does not > allow you to use free software, that's a problem out of scope of Fedora. Given what Fedora does with respect to software patents in otherwise free software, I think you're wrong here. We *do* make that choice and related modifications all the time. >> I feel the benefits in this case outweigh the demerits, and the > > The benefits takes away my freedoms of referencing a country my flag and > image that my own country recognises. I am not removing any choice from *you*. You are free to reference it as you see fit. In the same way, you're free to have a desktop background that consists entirely of naked people, or some derogatory cartoon of religious icons. It does not mean *Fedora* is going to ship that way, as such a thing doesn't bring real benefits to the project, only demerits. >> amount of work required to be greatly exaggerated. > > Because a 3 second check already spotted non-flag issue?s Should these > go to: > > /usr/lib64/openoffice.org/basis3.1/share/template/wizard/bitmap/taiwan.gif > /usr/share/texmf/omega/otp/otibet/tibadjusttsheg.otp > /usr/lib64/pango/1.6.0/modules/pango-tibetan-fc.so > > Today flags. tomorrow geography? Next week a language? Next year a culture? 1) The first is a picture of an island, it has no official designation 2) The second and third are programatic ways to display particular font scripts You know, this is the *exact* sort of thing I mentioned about absurd arguments. If you honestly believe that we're going to remove these in the future by using this policy as precedent... I'm not sure we can ever engage in a reasonable discussion. (If you're curious, we've done reviews of the image in OO.o before - it's fine.) > Those are not missing the point though. Sure they are. Unless you're saying that *nothing* ever considered offensive or illegal anywhere should be removed or patched out of Fedora, regardless of the consequences, and we should open every graphical login with developer's performances of "The Aristocrats", complete in patent-encumbered format with 'free' software code. Which is a rather ridiculous statement, and now you've got me playing this reductio ad absurdum game. Only the zealots deal in absolutes. Bill From notting at redhat.com Fri May 22 14:51:05 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 22 May 2009 10:51:05 -0400 Subject: I must be doing something seriously wrong... In-Reply-To: References: <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> <1242934194.8848.202.camel@adam.local.net> <20090521203836.GB7210@nostromo.devel.redhat.com> Message-ID: <20090522145104.GA16138@nostromo.devel.redhat.com> Kevin Kofler (kevin.kofler at chello.at) said: > > You could say that about many countries. In any case, even if 1/10 of one > > percent of those people are viable users... that still dwarfs the affected > > packager base by many orders of magnitude. > > But not the affected user base if you remove useful apps like geography > learning apps because they show Taiwan as a country complete with flag. > (And yes, at least one such app exists.) Well, then, if nothing else, you're giving lie to the idea that including the flags is a 'neutral' proposition, if your reasoning is that you want to include it specifically to recognize a country. > > Given that related operating systems with *ONLY* these changes are > > allowed, it's a fair assumption to make. > > But what about the many distros which do not do these changes? Kubuntu ships > the Taiwanese flag, see: > http://packages.ubuntu.com/jaunty/all/kdebase-runtime-data-common/filelist > > Yet they even have a .org.cn site: http://www.kubuntu.org.cn/ which appears > to be hosted inside mainland China. And other distributions ship patented code that we do not, or trademarked images that we do not... that doesn't generally change Fedora's stance on such items. > > Proliferation of spins and maintenance for specific geographies is > > a waste of space and effort, if it can be avoided. That's why we > > have languages included on the Desktop spin, instead of 15 different > > localized ones. > > That's how it works for GNOME, but KDE *needs* localized spins anyway as > there's no way to fit all the huge kde-l10n-* packages on a CD. The KDE > spin does *NOT* include any translations. Perhaps such packages should be re-engineered so they aren't wasting space by including lots of translations for programs that may not be installed if you just want the base translations. :) Even so, where we can, we don't want anyone who tries to do a localized spin to have to worry about forking packages or doing other machinations. (Yes, I'm still not thrilled about BRoffice.) Bill From a.badger at gmail.com Fri May 22 15:06:23 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 22 May 2009 08:06:23 -0700 Subject: I must be doing something seriously wrong... In-Reply-To: <20090522143608.GC15667@nostromo.devel.redhat.com> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> <20090522143608.GC15667@nostromo.devel.redhat.com> Message-ID: <4A16BF6F.1000200@gmail.com> On 05/22/2009 07:36 AM, Bill Nottingham wrote: > Paul Wouters (paul at xelerance.com) said: >>> Benefits: >>> - allows roughly 1/6 of the world's population to use Fedora freely >> >> Fedora is already allowed to be used freely. If your country does not >> allow you to use free software, that's a problem out of scope of Fedora. > > Given what Fedora does with respect to software patents in otherwise > free software, I think you're wrong here. We *do* make that choice > and related modifications all the time. > That situation is different, though, as Fedora has been told that there isn't a choice WRT patents. The decree of eliminating patents has come down from Red Hat legal so unless Fedora has the wherewithal to be funded by someone else than Red Hat there is no choice being made here. Fedora does have a choice WRT flags. There is a benefit to not shipping flags but it isn't a matter of if we do ship flags, Red Hat will no longer sponsor us. >>> I feel the benefits in this case outweigh the demerits, and the >> >> The benefits takes away my freedoms of referencing a country my flag and >> image that my own country recognises. > > I am not removing any choice from *you*. You are free to reference > it as you see fit. > > In the same way, you're free to have a desktop background that consists > entirely of naked people, or some derogatory cartoon of religious icons. > It does not mean *Fedora* is going to ship that way, as such a thing doesn't > bring real benefits to the project, only demerits. > You can't argue this without having a solid proposal to reference. If the proposal you're arguing under is that there's no flags in the distribution, then you are removing the choice from people as there's no way for maintainers to ship that user interface decision in Fedora, there's no way to ship certain packages, and there's no way for users to download the packages to optionally install on their systems. If you're arguing versus the current policy, then there's no additional demerits in shipping all flags in unmodified packages as we can't ship to China anyway so there's additional work for no gain. People need to reference the pros and cons of specific proposals otherwise there's just confusion. -Toshio From mcepl at redhat.com Fri May 22 15:44:03 2009 From: mcepl at redhat.com (Matej Cepl) Date: Fri, 22 May 2009 15:44:03 +0000 (UTC) Subject: Abrt - should this be a feature? References: <4A0DC949.7000601@fedoraproject.org> <4A116F78.3020607@redhat.com> <4A118A4C.3050909@fedoraproject.org> <4A1290AD.90205@redhat.com> <4A154D52.1000500@redhat.com> <4A16A449.1010602@redhat.com> <20090522132801.GA21545@host0.dyn.jankratochvil.net> Message-ID: Jan Kratochvil, Fri, 22 May 2009 15:28:01 +0200: > In some specific cases IIRC the backtrace will stop at some point. > These cases should be fixed and there are just missing > bugreports/reproducers for them. I do not know of such case offhand > myself now, if it did happen at all. Would it make sense to do some kind of test-day-in-the-middle-of-way (meaning testing just for collecting bug reports knowing very well, that it isn't ready yet)? Mat?j From choeger at cs.tu-berlin.de Fri May 22 15:51:50 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Fri, 22 May 2009 17:51:50 +0200 Subject: Abrt - should this be a feature? In-Reply-To: <4A16A449.1010602@redhat.com> References: <4A0DC949.7000601@fedoraproject.org> <4A116F78.3020607@redhat.com> <4A118A4C.3050909@fedoraproject.org> <4A1290AD.90205@redhat.com> <4A154D52.1000500@redhat.com> <4A16A449.1010602@redhat.com> Message-ID: <1243007510.2617.3.camel@choeger6> Does abrt offer the installation of degubinfo for the just-crashed application? Packagekit should make that a two click operation. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From notting at redhat.com Fri May 22 16:36:47 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 22 May 2009 12:36:47 -0400 Subject: I must be doing something seriously wrong... In-Reply-To: <4A16BF6F.1000200@gmail.com> References: <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> <20090522143608.GC15667@nostromo.devel.redhat.com> <4A16BF6F.1000200@gmail.com> Message-ID: <20090522163647.GA17232@nostromo.devel.redhat.com> Toshio Kuratomi (a.badger at gmail.com) said: >> Given what Fedora does with respect to software patents in otherwise >> free software, I think you're wrong here. We *do* make that choice >> and related modifications all the time. >> > That situation is different, though, as Fedora has been told that there > isn't a choice WRT patents. The decree of eliminating patents has come > down from Red Hat legal so unless Fedora has the wherewithal to be > funded by someone else than Red Hat there is no choice being made here. > > Fedora does have a choice WRT flags. There is a benefit to not shipping > flags but it isn't a matter of if we do ship flags, Red Hat will no > longer sponsor us. It is still a situation where, due to the legal and cultural climate of a particular country or countries, we draw the line as to content & code that we include. To reference my later point, I feel fairly comfortable saying that we're not going to be shipping default backgrounds consisting of naked people, or photographs of open surgical procedures, or overtly religious iconography, or any variety of things, even though we have no legal obligation to in that regard. Do we need an explicit policy on that too? (I'm sure someone will argue that we should go ahead and ship all those things if upstream includes them; I most assuredly do not agree.) It's why I feel slippery slope arguments are missing the point - the line as to what we'll ship and what we won't ship is already there, even outside of legal obligations; this discussion about flags is essentially where to place the line. Bill From a.badger at gmail.com Fri May 22 17:22:18 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 22 May 2009 10:22:18 -0700 Subject: I must be doing something seriously wrong... In-Reply-To: <20090522163647.GA17232@nostromo.devel.redhat.com> References: <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> <20090522143608.GC15667@nostromo.devel.redhat.com> <4A16BF6F.1000200@gmail.com> <20090522163647.GA17232@nostromo.devel.redhat.com> Message-ID: <4A16DF4A.20306@gmail.com> On 05/22/2009 09:36 AM, Bill Nottingham wrote: > Toshio Kuratomi (a.badger at gmail.com) said: >>> Given what Fedora does with respect to software patents in otherwise >>> free software, I think you're wrong here. We *do* make that choice >>> and related modifications all the time. >>> >> That situation is different, though, as Fedora has been told that there >> isn't a choice WRT patents. The decree of eliminating patents has come >> down from Red Hat legal so unless Fedora has the wherewithal to be >> funded by someone else than Red Hat there is no choice being made here. >> >> Fedora does have a choice WRT flags. There is a benefit to not shipping >> flags but it isn't a matter of if we do ship flags, Red Hat will no >> longer sponsor us. > > It is still a situation where, due to the legal and cultural climate > of a particular country or countries, we draw the line as to content > & code that we include. No to the countries portion. Patents are due to the legal rules of a particular country. The country that Red Hat is incorporated in and therefore the country that we cannot violate the laws of and remain a project supported and funded to a high level by Red Hat. > To reference my later point, I feel fairly comfortable > saying that we're not going to be shipping default backgrounds consisting > of naked people, or photographs of open surgical procedures, or overtly > religious iconography, or any variety of things, even though we have no > legal obligation to in that regard. Do we need an explicit policy on that > too? (I'm sure someone will argue that we should go ahead and ship all > those things if upstream includes them; I most assuredly do not agree.) > Oh definitely someone. Fpr instance, I disagree on some of your points here. What if there was an open source reader integrated with content for a specific format of medical textbook? That would be something we ship despite having photography of surgical procedures in it. We already ship sword and gnome-sword which is religious. So, since we disagree, how do we resolve the impasse? Popular vote? rock scissors paper? You argue that banning flags is not a slippery slope and yet the examples you cite here just show that we are already on a slippery slope, flags would just be sliding further. There are things that we must leave out of the distribution because of laws in the country Red Hat is incorporated in (patents). There are separate choices we make about not including open source software/pieces of open source software (webcollage). For the things we do have a choice over, we need to be explicit in what goals we are trying to achieve. Enumerating our goals shows where we are headed as a project. Showing that "Be downloadable by anyone in any country not barred by US law" trumps "Package any maintained open source software" or vice versa is a good piece of information about who we are that people looking to contribute to a Linux distribution would like to know. > It's why I feel slippery slope arguments are missing the point - the > line as to what we'll ship and what we won't ship is already there, even > outside of legal obligations; this discussion about flags is essentially where > to place the line. > I try to avoid being extremist about things but if you're saying the reason we're justified in banning flags is because we're already patching out other things then perhaps we need to reexamine those other things and reincorporate them into the distribution. Slippery slope is a problem that should be solved, not an excuse for doing it more. -Toshio From awilliam at redhat.com Fri May 22 17:33:42 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 22 May 2009 10:33:42 -0700 Subject: I must be doing something seriously wrong... In-Reply-To: <20090522163647.GA17232@nostromo.devel.redhat.com> References: <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> <20090522143608.GC15667@nostromo.devel.redhat.com> <4A16BF6F.1000200@gmail.com> <20090522163647.GA17232@nostromo.devel.redhat.com> Message-ID: <1243013622.16232.17.camel@adam.local.net> On Fri, 2009-05-22 at 12:36 -0400, Bill Nottingham wrote: > Toshio Kuratomi (a.badger at gmail.com) said: > >> Given what Fedora does with respect to software patents in otherwise > >> free software, I think you're wrong here. We *do* make that choice > >> and related modifications all the time. > >> > > That situation is different, though, as Fedora has been told that there > > isn't a choice WRT patents. The decree of eliminating patents has come > > down from Red Hat legal so unless Fedora has the wherewithal to be > > funded by someone else than Red Hat there is no choice being made here. > > > > Fedora does have a choice WRT flags. There is a benefit to not shipping > > flags but it isn't a matter of if we do ship flags, Red Hat will no > > longer sponsor us. > > It is still a situation where, due to the legal and cultural climate > of a particular country or countries, we draw the line as to content > & code that we include. It's not 'a particular country or countries', it's the country where all the icky physical legal bits of Fedora are incorporated. It would be very difficult for Fedora to keep existing if it didn't comply with U.S. law. Chinese law? Not such a big deal. There's a clear distinction here, just as we don't appear to care very much about the implications of some of the sillier laws passed in Europe lately. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From notting at redhat.com Fri May 22 18:02:16 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 22 May 2009 14:02:16 -0400 Subject: I must be doing something seriously wrong... In-Reply-To: <4A16DF4A.20306@gmail.com> References: <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> <20090522143608.GC15667@nostromo.devel.redhat.com> <4A16BF6F.1000200@gmail.com> <20090522163647.GA17232@nostromo.devel.redhat.com> <4A16DF4A.20306@gmail.com> Message-ID: <20090522180215.GA18436@nostromo.devel.redhat.com> Toshio Kuratomi (a.badger at gmail.com) said: >> To reference my later point, I feel fairly comfortable >> saying that we're not going to be shipping default backgrounds consisting >> of naked people, or photographs of open surgical procedures, or overtly >> religious iconography, or any variety of things, even though we have no >> legal obligation to in that regard. Do we need an explicit policy on that >> too? (I'm sure someone will argue that we should go ahead and ship all >> those things if upstream includes them; I most assuredly do not agree.) >> > Oh definitely someone. Fpr instance, I disagree on some of your points > here. What if there was an open source reader integrated with content > for a specific format of medical textbook? That would be something we > ship despite having photography of surgical procedures in it. We > already ship sword and gnome-sword which is religious. So, since we > disagree, how do we resolve the impasse? Note the point where I said "default backgrounds". It's about including material that could be deemed controversial in places where it is not appropriate. In the majority of cases where flags are being used, it's really not appropriate. Part of me just finds it weird that it's now become a politcal cause c?l?bre to use high idealistic principles... to justify shipping bad UI to all our users and not having a policy to change it. But that's an entirely separate idealism vs pragmatism discussion. Bill From jan.kratochvil at redhat.com Fri May 22 18:22:07 2009 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Fri, 22 May 2009 20:22:07 +0200 Subject: Abrt - should this be a feature? In-Reply-To: References: <4A116F78.3020607@redhat.com> <4A118A4C.3050909@fedoraproject.org> <4A1290AD.90205@redhat.com> <4A154D52.1000500@redhat.com> <4A16A449.1010602@redhat.com> <20090522132801.GA21545@host0.dyn.jankratochvil.net> Message-ID: <20090522182207.GA5237@host0.dyn.jankratochvil.net> On Fri, 22 May 2009 17:44:03 +0200, Matej Cepl wrote: > Jan Kratochvil, Fri, 22 May 2009 15:28:01 +0200: > > In some specific cases IIRC the backtrace will stop at some point. > > These cases should be fixed and there are just missing > > bugreports/reproducers for them. I do not know of such case offhand > > myself now, if it did happen at all. > > Would it make sense to do some kind of test-day-in-the-middle-of-way > (meaning testing just for collecting bug reports knowing very well, that > it isn't ready yet)? Tried x86_64 Firefox backtracing with and without debuginfo and it works OK. So if there exist such problems they are some exception which can get fixed and does not need to change the project design. Regards, Jan From jeff at ocjtech.us Fri May 22 18:28:12 2009 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Fri, 22 May 2009 13:28:12 -0500 Subject: rawhide report: 20090522 changes In-Reply-To: <20090522130726.2D0571F8217@releng2.fedora.phx.redhat.com> References: <20090522130726.2D0571F8217@releng2.fedora.phx.redhat.com> Message-ID: <935ead450905221128o514056cbtbcd59022e5ac9375@mail.gmail.com> On Fri, May 22, 2009 at 8:07 AM, Rawhide Report wrote: > > tigervnc-0.0.90-0.10.fc11 > ------------------------- > * Thu May 21 2009 Adam Tkac 0.0.90-10 > - rebuild against 1.6.1.901 X server (#497835) > - disable i18n, vncviewer is not UTF-8 compatible (#501832) This package does not appear to be signed. -- Jeff Ollie From kevin.kofler at chello.at Fri May 22 18:37:54 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 22 May 2009 20:37:54 +0200 Subject: I must be doing something seriously wrong... References: <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> <20090522143608.GC15667@nostromo.devel.redhat.com> <4A16BF6F.1000200@gmail.com> <20090522163647.GA17232@nostromo.devel.redhat.com> <4A16DF4A.20306@gmail.com> <20090522180215.GA18436@nostromo.devel.redhat.com> Message-ID: Bill Nottingham wrote: > Part of me just finds it weird that it's now become a politcal cause > c?l?bre to use high idealistic principles... to justify shipping bad > UI to all our users and not having a policy to change it. But that's > an entirely separate idealism vs pragmatism discussion. Bad UI is an upstream issue. While we may wish to override upstream, that should be the maintainer's call, not a distro-wide mandate. If your problem is really just "bad UI", then any mandatory policy is way overkill. Kevin Kofler From paul at xelerance.com Fri May 22 18:43:48 2009 From: paul at xelerance.com (Paul Wouters) Date: Fri, 22 May 2009 14:43:48 -0400 (EDT) Subject: I must be doing something seriously wrong... In-Reply-To: <20090522143608.GC15667@nostromo.devel.redhat.com> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> <20090522143608.GC15667@nostromo.devel.redhat.com> Message-ID: On Fri, 22 May 2009, Bill Nottingham wrote: >> Fedora is already allowed to be used freely. If your country does not >> allow you to use free software, that's a problem out of scope of Fedora. > > Given what Fedora does with respect to software patents in otherwise > free software, I think you're wrong here. We *do* make that choice > and related modifications all the time. That was based on the laws in Fedora's country, the US. >> The benefits takes away my freedoms of referencing a country my flag and >> image that my own country recognises. > > I am not removing any choice from *you*. You are free to reference > it as you see fit. But your crippling my tools. >> /usr/lib64/openoffice.org/basis3.1/share/template/wizard/bitmap/taiwan.gif >> /usr/share/texmf/omega/otp/otibet/tibadjusttsheg.otp >> /usr/lib64/pango/1.6.0/modules/pango-tibetan-fc.so >> >> Today flags. tomorrow geography? Next week a language? Next year a culture? > > 1) The first is a picture of an island, it has no official designation In that sense, a flag is just "a mixture of colours", it has no official designation. > Only the zealots deal in absolutes. Funny how you did not comment to the part on DNSSEC keys of the Taiwan situation, the one that actualy refers to me as a maintainer of dnssec-conf, and which could be a real life scenario that goes beyond pictures of flags. Paul From kevin.kofler at chello.at Fri May 22 18:45:06 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 22 May 2009 20:45:06 +0200 Subject: I must be doing something seriously wrong... References: <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> <1242934194.8848.202.camel@adam.local.net> <20090521203836.GB7210@nostromo.devel.redhat.com> <20090522145104.GA16138@nostromo.devel.redhat.com> Message-ID: Bill Nottingham wrote: > Kevin Kofler (kevin.kofler at chello.at) said: >> But not the affected user base if you remove useful apps like geography >> learning apps because they show Taiwan as a country complete with flag. >> (And yes, at least one such app exists.) > > Well, then, if nothing else, you're giving lie to the idea that > including the flags is a 'neutral' proposition, if your reasoning > is that you want to include it specifically to recognize a country. If you draw Taiwan as part of China in the geography app, it's also not neutral. There's no way to be neutral and still teach geography. >> But what about the many distros which do not do these changes? Kubuntu >> ships the Taiwanese flag, see: >> http://packages.ubuntu.com/jaunty/all/kdebase-runtime-data-common/filelist >> >> Yet they even have a .org.cn site: http://www.kubuntu.org.cn/ which >> appears to be hosted inside mainland China. > > And other distributions ship patented code that we do not, or trademarked > images that we do not... that doesn't generally change Fedora's stance > on such items. Yet it proves that the argument that anything containing that flag supposedly cannot be distributed in China is moot. > Perhaps such packages should be re-engineered so they aren't wasting > space by including lots of translations for programs that may not be > installed if you just want the base translations. :) Most of the translations are for programs which *are* installed. Translations for stuff like extragear applications or KOffice are *not* part of kde-l10n. (For extragear apps, they're shipped with the respective apps, for KOffice, there are separate language packs.) kde-l10n is just for the core KDE 4 modules. I don't think trimming out the translations for the apps we don't install by default would do anything to solve the problem. We could ship at most half the apps if we tried to ship all the translations, and that's already an optimistic estimate. I see localized spins as the only viable solution for fully-featured CD-sized spins. Kevin Kofler From mschwendt at gmail.com Fri May 22 18:57:03 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 22 May 2009 18:57:03 -0000 Subject: (1/3) Broken dependencies in Fedora 12 Development - 2009-05-22 Message-ID: <20090522185703.20074.55314@faldor.intranet> Summary of broken packages (by src.rpm name): adminutil alsa-firmware asc barry bmpx bzrtools cas ccsm cduce chess cinepaint CodeAnalyst-gui conexus cyrus-imapd dwdiff esperanza fedora-ds-admin fedora-ds-dsgw fetchmail firebird firstaidkit frei0r-plugins fuse-encfs gadget gambas2 gcl ghc-ghc-paths ghc-haskell-src-exts ghc-uniplate glest-data glob2 gnash gnome-commander gnote gnu-smalltalk gprolog guimup haddock HippoDraw hscolour hugin inkscape k3d kipi-plugins koffice libprojectM liveusb-creator lmms mapnik me-tv Miro mkvtoolnix mrpt msort ocaml-augeas ocaml-bisect ocaml-bitstring ocaml-cairo ocaml-calendar ocaml-camlidl ocaml-camlimages ocaml-camlp5 ocaml-camomile ocaml-cil ocaml-cryptokit ocaml-csv ocaml-curl ocaml-curses ocaml-dbus ocaml-deriving ocaml-expat ocaml-extlib ocaml-facile ocaml-fileutils ocaml-findlib ocaml-gettext ocaml-gsl ocaml-json-static ocaml-json-wheel ocaml-lablgl ocaml-lablgtk ocaml-lacaml ocaml-libvirt ocaml-lwt ocaml-mikmatch ocaml-mlgmpidl ocaml-mysql ocaml-newt ocaml-ocamlgraph ocaml-ocamlnet ocaml-openin ocaml-ounit ocaml-p3l ocaml-pa-do ocaml-pa-monad ocaml-pcre ocaml-perl4caml ocaml-pgocaml ocaml-postgresql ocaml-preludeml ocaml-pxp ocaml-reins ocaml-res ocaml-SDL ocaml-sexplib ocaml-sqlite ocaml-ssl ocaml-type-conv ocaml-ulex ocaml-xml-light ocaml-xmlrpc-light ocaml-zip openoffice.org openvrml pdf2djvu pdfcube player plplot pyexiv2 python-cclib python-kinterbasdb python-mwlib python-paida python-polybori python-tag qbittorrent qmforge qpidc QuantLib R-RScaLAPACK rcsslogplayer rcssserver referencer samba4 showimg soci source-highlight spring spring-maps-default sword tellico twinkle vegastrike wp_tray xmms2 yafc yaz Summary of broken packages (by primary owner): Jochen AT herr-schmitt de gnu-smalltalk (1 co-owner) gprolog (1 co-owner) a.badger AT gmail com bzrtools (3 co-owners) aconway AT redhat com qpidc (1 co-owner) adam.stokes AT gmail com cas adrian AT lisas de source-highlight akahl AT iconmobile com bmpx (1 co-owner) amdunn AT gmail com ocaml-mlgmpidl ocaml-ocamlgraph andreas.bierfert AT lowlatency de koffice (4 co-owners) braden AT endoframe com openvrml bruno AT postle net hugin (1 co-owner) caolanm AT redhat com openoffice.org cristian.balint AT gmail com mapnik (1 co-owner) dakingun AT gmail com referencer (1 co-owner) sword denis.arnaud_fedora AT m4x org soci denis AT poolshark org k3d wp_tray gauret AT free fr glest-data showimg spring spring-maps-default gemi AT bluewin ch ocaml-lablgl (1 co-owner) ocaml-lablgtk (3 co-owners) hdegoede AT redhat com asc chess (1 co-owner) vegastrike (1 co-owner) hedayat AT grad com rcsslogplayer rcssserver ian AT ianweller org python-mwlib (1 co-owner) imntreal AT gmail com libprojectM jamatos AT fc.up pt tellico (1 co-owner) jhrozek AT redhat com dwdiff joseluisblancoc AT gmail com mrpt jussi.lehtola AT iki fi python-cclib python-paida qmforge kagesenshi.87 AT gmail com ccsm kevin AT tigcc.ticalc org gnash (2 co-owners) ocaml-facile (1 co-owner) kevin AT tummy com twinkle (1 co-owner) konrad AT tylerc org ghc-haskell-src-exts (1 co-owner) ghc-uniplate python-polybori kushaldas AT gmail com liveusb-creator (1 co-owner) kwizart AT gmail com cinepaint frei0r-plugins leigh123linux AT googlemail com qbittorrent lemenkov AT gmail com fuse-encfs lists AT forevermore net yafc lkundrak AT v3 sk inkscape (1 co-owner) loganjerry AT gmail com gcl (1 co-owner) makowski.fedora AT gmail com firebird python-kinterbasdb matthias AT rpmforge net python-tag maxx AT krakoa dk pdfcube mbarnes AT redhat com samba4 (1 co-owner) mcepl AT redhat com pyexiv2 mhlavink AT redhat com cyrus-imapd (1 co-owner) mricon AT gmail com yaz msivak AT redhat com firstaidkit (2 co-owners) mtasaka AT ioa.s.u-tokyo.ac jp gnome-commander orion AT cora.nwra com plplot paulfkunz AT gmail com HippoDraw petersen AT redhat com ghc-ghc-paths (1 co-owner) haddock (2 co-owners) hscolour (1 co-owner) quantumburnz AT hotmail com barry rafalzaq AT gmail com glob2 rdieter AT math.unl edu kipi-plugins (5 co-owners) rjones AT redhat com cduce (1 co-owner) ocaml-SDL (1 co-owner) ocaml-augeas (1 co-owner) ocaml-bisect (1 co-owner) ocaml-bitstring (1 co-owner) ocaml-cairo (1 co-owner) ocaml-calendar (2 co-owners) ocaml-camlidl (1 co-owner) ocaml-camlimages (1 co-owner) ocaml-camlp5 (1 co-owner) ocaml-camomile (1 co-owner) ocaml-cil (1 co-owner) ocaml-cryptokit ocaml-csv (1 co-owner) ocaml-curl (2 co-owners) ocaml-curses (1 co-owner) ocaml-dbus (1 co-owner) ocaml-deriving (1 co-owner) ocaml-expat (2 co-owners) ocaml-extlib (3 co-owners) ocaml-fileutils (1 co-owner) ocaml-findlib (2 co-owners) ocaml-gettext (1 co-owner) ocaml-gsl (2 co-owners) ocaml-json-static (1 co-owner) ocaml-json-wheel (1 co-owner) ocaml-lacaml (1 co-owner) ocaml-libvirt (2 co-owners) ocaml-lwt (1 co-owner) ocaml-mikmatch (1 co-owner) ocaml-mysql (1 co-owner) ocaml-newt (1 co-owner) ocaml-ocamlnet (2 co-owners) ocaml-openin (1 co-owner) ocaml-ounit (1 co-owner) ocaml-p3l ocaml-pa-do ocaml-pa-monad (1 co-owner) ocaml-pcre (3 co-owners) ocaml-perl4caml (1 co-owner) ocaml-pgocaml (1 co-owner) ocaml-postgresql (1 co-owner) ocaml-preludeml (1 co-owner) ocaml-pxp (1 co-owner) ocaml-reins (1 co-owner) ocaml-res (1 co-owner) ocaml-sexplib (1 co-owner) ocaml-sqlite (1 co-owner) ocaml-ssl (2 co-owners) ocaml-type-conv (1 co-owner) ocaml-ulex (2 co-owners) ocaml-xml-light (1 co-owner) ocaml-xmlrpc-light (1 co-owner) ocaml-zip (1 co-owner) rmeggins AT redhat com adminutil (3 co-owners) fedora-ds-admin (2 co-owners) fedora-ds-dsgw (2 co-owners) rpandit AT redhat com pdf2djvu rpm AT greysector net mkvtoolnix rpm AT timj.co uk alsa-firmware rvinyard AT cs.nmsu edu conexus simon AT schampijer de gadget (1 co-owner) sundaram AT redhat com gnote (1 co-owner) suravee.suthikulpanit AT amd com CodeAnalyst-gui (1 co-owner) tcallawa AT redhat com QuantLib R-RScaLAPACK esperanza gambas2 xmms2 terjeros AT phys.ntnu no msort th0br0 AT mkdir name guimup thomas.moschny AT gmx de lmms tim AT niemueller de player (1 co-owner) tscherf AT redhat com Miro (3 co-owners) vcrhonek AT redhat com fetchmail (1 co-owner) zarko.pintar AT gmail com me-tv ====================================================================== Broken packages in dist-f12-build-current-i386: 1:openoffice.org-core-3.1.0-11.2.fc11.i586 requires libicudata.so.40 1:openoffice.org-core-3.1.0-11.2.fc11.i586 requires libicui18n.so.40 1:openoffice.org-core-3.1.0-11.2.fc11.i586 requires libicuuc.so.40 1:openoffice.org-core-3.1.0-11.2.fc11.i586 requires libicule.so.40 1:openoffice.org-pdfimport-3.1.0-11.2.fc11.i586 requires libpoppler.so.4 1:openoffice.org-writer-core-3.1.0-11.2.fc11.i586 requires libicuuc.so.40 2:koffice-krita-1.9.99.0-1.fc12.i586 requires libpoppler.so.4 CodeAnalyst-gui-2.8.38-11.fc11.i586 requires libbfd-2.19.51.0.2-17.fc11.so HippoDraw-python-1.21.1-9.fc11.i586 requires libboost_python.so.4 Miro-2.0.3-2.fc12.i586 requires libboost_python.so.4 QuantLib-test-0.9.7-5.fc11.i586 requires libboost_unit_test_framework.so.4 R-RScaLAPACK-0.5.1-19.fc11.i586 requires openmpi-libs adminutil-1.1.8-1.fc11.i586 requires libicudata.so.40 adminutil-1.1.8-1.fc11.i586 requires libicui18n.so.40 adminutil-1.1.8-1.fc11.i586 requires libicuuc.so.40 alsa-firmware-1.0.20-1.fc12.noarch requires alsa-tools-firmware >= 0:1.0.20 asc-2.2.0.0-3.fc11.i586 requires libboost_regex.so.4 barry-0.15-0.5.20090109git.fc11.i586 requires libboost_serialization.so.4 bmpx-0.40.14-8.fc11.i386 requires libboost_regex-mt.so.4 bmpx-0.40.14-8.fc11.i386 requires libboost_iostreams-mt.so.4 bzrtools-1.14.0-1.fc11.i586 requires bzr < 0:1.15 cduce-0.5.2.1-14.fc11.i586 requires ocaml(runtime) = 0:3.11.0 cduce-0.5.2.1-14.fc11.i586 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 cduce-ocamlduce-0.5.2.1-14.fc11.i586 requires ocaml(runtime) = 0:3.11.0 chess-1.0-24.fc11.i586 requires libboost_thread-mt.so.4 chess-1.0-24.fc11.i586 requires libCEGUIOgreRenderer-1.6.1.so chess-1.0-24.fc11.i586 requires libOgreMain-1.6.1.so cinepaint-libs-0.22.1-12.fc11.2.i586 requires libftgl.so.0 conexus-gtkmm-devel-0.7.0-1.fc12.i586 requires sysfs-devel cyrus-imapd-2.3.14-1.fc11.i586 requires libkrb4.so.2 cyrus-imapd-2.3.14-1.fc11.i586 requires libkrb4.so.2(krb4_2_MIT) cyrus-imapd-utils-2.3.14-1.fc11.i586 requires libkrb4.so.2 dwdiff-1.5-3.fc11.i586 requires libicuuc.so.40 dwdiff-1.5-3.fc11.i586 requires libicudata.so.40 dwdiff-1.5-3.fc11.i586 requires libicui18n.so.40 esperanza-0.4.0-2.fc11.i586 requires libboost_signals.so.4 fedora-ds-admin-1.1.7-4.fc11.i586 requires libicuuc.so.40 fedora-ds-admin-1.1.7-4.fc11.i586 requires libicui18n.so.40 fedora-ds-admin-1.1.7-4.fc11.i586 requires libicudata.so.40 fedora-ds-dsgw-1.1.2-1.fc11.i586 requires libicudata.so.40 fedora-ds-dsgw-1.1.2-1.fc11.i586 requires libicui18n.so.40 fedora-ds-dsgw-1.1.2-1.fc11.i586 requires libicuuc.so.40 fetchmail-6.3.9-3.fc11.i586 requires libkrb4.so.2(krb4_2_MIT) fetchmail-6.3.9-3.fc11.i586 requires libkrb4.so.2 firebird-2.1.2.18118.0-7.fc10.i386 requires libicudata.so.40 firebird-2.1.2.18118.0-7.fc10.i386 requires libicui18n.so.40 firebird-2.1.2.18118.0-7.fc10.i386 requires libicuuc.so.40 firebird-libfbembed-2.1.2.18118.0-7.fc10.i386 requires libicudata.so.40 firebird-libfbembed-2.1.2.18118.0-7.fc10.i386 requires libicui18n.so.40 firebird-libfbembed-2.1.2.18118.0-7.fc10.i386 requires libicuuc.so.40 firebird-superserver-2.1.2.18118.0-7.fc10.i386 requires libicudata.so.40 firebird-superserver-2.1.2.18118.0-7.fc10.i386 requires libicui18n.so.40 firebird-superserver-2.1.2.18118.0-7.fc10.i386 requires libicuuc.so.40 frei0r-plugins-1.1.22-1.fc11.i586 requires libml.so.1 frei0r-plugins-1.1.22-1.fc11.i586 requires libcv.so.1 frei0r-plugins-1.1.22-1.fc11.i586 requires libcxcore.so.1 frei0r-plugins-1.1.22-1.fc11.i586 requires libhighgui.so.1 frei0r-plugins-1.1.22-1.fc11.i586 requires libcvaux.so.1 fuse-encfs-1.5-6.fc11.i586 requires libboost_filesystem-mt.so.4 fuse-encfs-1.5-6.fc11.i586 requires libboost_serialization-mt.so.4 gambas2-gb-pdf-2.13.0-1.fc12.i586 requires libpoppler.so.4 ghc-ghc-paths-devel-0.1.0.5-6.fc12.i586 requires ghc = 0:6.10.2 ghc-ghc-paths-doc-0.1.0.5-6.fc12.i586 requires ghc-doc = 0:6.10.2 ghc-ghc-paths-prof-0.1.0.5-6.fc12.i586 requires ghc-prof = 0:6.10.2 ghc-haddock-devel-2.4.2-2.fc12.i586 requires ghc = 0:6.10.2 ghc-haddock-doc-2.4.2-2.fc12.i586 requires ghc-doc = 0:6.10.2 ghc-haddock-prof-2.4.2-2.fc12.i586 requires ghc-prof = 0:6.10.2 ghc-haskell-src-exts-devel-0.4.8-5.fc12.i586 requires ghc = 0:6.10.2 ghc-haskell-src-exts-doc-0.4.8-5.fc12.i586 requires ghc-doc = 0:6.10.2 ghc-haskell-src-exts-prof-0.4.8-5.fc12.i586 requires ghc-prof = 0:6.10.2 ghc-hscolour-devel-1.12-3.fc12.i586 requires ghc = 0:6.10.2 ghc-hscolour-doc-1.12-3.fc12.i586 requires ghc-doc = 0:6.10.2 ghc-hscolour-prof-1.12-3.fc12.i586 requires ghc-prof = 0:6.10.2 ghc-uniplate-devel-1.2.0.3-3.fc11.i586 requires ghc = 0:6.10.1 ghc-uniplate-doc-1.2.0.3-3.fc11.i586 requires ghc-doc = 0:6.10.1 ghc-uniplate-prof-1.2.0.3-3.fc11.i586 requires ghc-prof = 0:6.10.1 glob2-0.9.3-2.fc11.i386 requires libboost_thread-mt.so.4 gnash-0.8.5-3.fc11.i586 requires libboost_date_time-mt.so.4 gnash-0.8.5-3.fc11.i586 requires libboost_thread-mt.so.4 gnash-cygnal-0.8.5-3.fc11.i586 requires libboost_thread-mt.so.4 gnome-commander-1.3-0.1.svn2532_13dev.fc12.i586 requires libpoppler.so.4 gnote-0.1.2-2.fc12.i586 requires libboost_regex-mt.so.4 gnote-0.1.2-2.fc12.i586 requires libboost_filesystem-mt.so.4 gnote-0.1.2-2.fc12.i586 requires libboost_system-mt.so.4 guimup-0.1.4-6.c.fc12.i586 requires mpd haddock-2.4.2-2.fc12.i586 requires ghc = 0:6.10.2 hugin-0.7.0-5.fc11.i586 requires libboost_thread-mt.so.4 hugin-base-0.7.0-5.fc11.i586 requires libboost_thread-mt.so.4 inkscape-0.47-0.9.20090518svn.fc12.i586 requires libpoppler.so.4 inkscape-view-0.47-0.9.20090518svn.fc12.i586 requires libpoppler.so.4 k3d-0.7.11.0-1.fc11.i586 requires libboost_regex-mt.so.4 k3d-0.7.11.0-1.fc11.i586 requires libboost_program_options-mt.so.4 k3d-0.7.11.0-1.fc11.i586 requires libboost_python-mt.so.4 k3d-devel-0.7.11.0-1.fc11.i586 requires libboost_python-mt.so.4 k3d-devel-0.7.11.0-1.fc11.i586 requires libboost_regex-mt.so.4 k3d-devel-0.7.11.0-1.fc11.i586 requires libboost_program_options-mt.so.4 kipi-plugins-0.2.0-2.fc11.i586 requires libcv.so.1 kipi-plugins-0.2.0-2.fc11.i586 requires libcxcore.so.1 kipi-plugins-0.2.0-2.fc11.i586 requires libhighgui.so.1 kipi-plugins-0.2.0-2.fc11.i586 requires libcvaux.so.1 libldb-devel-0.9.3-15.1.fc12.i586 requires libtdb-devel = 0:1.1.3-15.1.fc12 libprojectM-1.2.0-9.fc11.i586 requires libftgl.so.0 libyaz-3.0.41-2.fc11.i586 requires libicudata.so.40 libyaz-3.0.41-2.fc11.i586 requires libicui18n.so.40 libyaz-3.0.41-2.fc11.i586 requires libicuuc.so.40 mapnik-0.5.2-0.12.svn780.fc11.i586 requires libboost_program_options-mt.so.4 mapnik-0.5.2-0.12.svn780.fc11.i586 requires libboost_regex-mt.so.4 mapnik-0.5.2-0.12.svn780.fc11.i586 requires libicudata.so.40 mapnik-0.5.2-0.12.svn780.fc11.i586 requires libboost_filesystem-mt.so.4 mapnik-0.5.2-0.12.svn780.fc11.i586 requires libicuuc.so.40 mapnik-0.5.2-0.12.svn780.fc11.i586 requires libboost_iostreams-mt.so.4 mapnik-0.5.2-0.12.svn780.fc11.i586 requires libboost_thread-mt.so.4 mapnik-0.5.2-0.12.svn780.fc11.i586 requires libboost_system-mt.so.4 mapnik-python-0.5.2-0.12.svn780.fc11.i586 requires libboost_python-mt.so.4 mapnik-utils-0.5.2-0.12.svn780.fc11.i586 requires libboost_program_options-mt.so.4 mapnik-utils-0.5.2-0.12.svn780.fc11.i586 requires libboost_iostreams-mt.so.4 me-tv-0.8.12-5.fc12.i586 requires xine-ui mkvtoolnix-2.6.0-1.fc11.i586 requires libboost_regex-mt.so.4 mkvtoolnix-gui-2.6.0-1.fc11.i586 requires libboost_regex-mt.so.4 mrpt-apps-0.6.5-0.4.20090213svn807.fc11.i586 requires libboost_program_options-mt.so.4 mrpt-apps-0.6.5-0.4.20090213svn807.fc11.i586 requires libcv.so.1 mrpt-apps-0.6.5-0.4.20090213svn807.fc11.i586 requires libcxcore.so.1 mrpt-apps-0.6.5-0.4.20090213svn807.fc11.i586 requires libhighgui.so.1 mrpt-core-0.6.5-0.4.20090213svn807.fc11.i586 requires libcv.so.1 mrpt-core-0.6.5-0.4.20090213svn807.fc11.i586 requires libcxcore.so.1 mrpt-core-0.6.5-0.4.20090213svn807.fc11.i586 requires libhighgui.so.1 msort-8.46-3.fc11.i586 requires libicuuc.so.40 msort-8.46-3.fc11.i586 requires libicutu.so.40 ocaml-SDL-0.7.2-18.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-augeas-0.4-4.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-bisect-1.0-0.4.alpha.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-bisect-1.0-0.4.alpha.fc11.i586 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-bitstring-2.0.0-8.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-bitstring-2.0.0-8.fc11.i586 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-cairo-1.2.0.cvs20080301-8.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-calendar-2.0.4-4.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-camlidl-1.05-8.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-camlimages-3.0.1-7.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-camlp5-5.10-3.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-camomile-0.7.1-10.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-cil-1.3.6-11.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-cryptokit-1.3-8.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-csv-1.1.7-4.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-curl-0.5.0-4.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-curses-1.0.3-4.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-dbus-0.07-4.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-deriving-0.1.1a-7.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-expat-0.9.1-15.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-extlib-1.5.1-6.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-facile-1.1-8.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-fileutils-0.3.0-9.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-findlib-1.2.3-6.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-gettext-0.3.2-7.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-gettext-0.3.2-7.fc11.i586 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-gettext-camomile-0.3.2-7.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-gsl-0.6.0-7.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-json-static-0.9.6-8.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-json-static-0.9.6-8.fc11.i586 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-json-wheel-1.0.4-8.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-lablgl-1.03-7.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-lablgtk-2.12.0-2.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-lablgtk-devel-2.12.0-2.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-lacaml-4.7.6-1.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-libvirt-0.6.1.0-1.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-lwt-1.1.0-4.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-mikmatch-1.0.0-5.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-mikmatch-1.0.0-5.fc11.i586 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-mlgmpidl-1.1-1.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-mysql-1.0.4-8.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-newt-0.9-5.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-ocamlgraph-1.0-4.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-ocamlnet-2.2.9-12.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-ocamlnet-nethttpd-2.2.9-12.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-openin-20070524-7.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-openin-20070524-7.fc11.i586 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-ounit-1.0.3-4.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-p3l-2.03-2.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-pa-do-0.8.4-5.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-pa-do-0.8.4-5.fc11.i586 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-pa-monad-6.0-1.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-pa-monad-6.0-1.fc11.i586 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-pcre-5.15.0-4.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-perl4caml-0.9.5-8.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-pgocaml-1.1-8.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-pgocaml-1.1-8.fc11.i586 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-postgresql-1.10.3-1.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-preludeml-0.1-0.11.20090113.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-pxp-1.2.0test2-6.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-pxp-1.2.0test2-6.fc11.i586 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-reins-0.1a-4.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-res-3.1.1-1.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-sexplib-4.2.7-2.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-sexplib-4.2.7-2.fc11.i586 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-sqlite-1.2.0-5.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-ssl-0.4.3-2.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-type-conv-1.6.7-1.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-type-conv-1.6.7-1.fc11.i586 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-ulex-1.1-6.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-ulex-1.1-6.fc11.i586 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-xml-light-2.2.cvs20070817-11.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-xmlrpc-light-0.6.1-1.fc11.i586 requires ocaml(runtime) = 0:3.11.0 ocaml-zip-1.04-1.fc11.i586 requires ocaml(runtime) = 0:3.11.0 openvrml-0.17.12-1.fc11.i586 requires libboost_thread-mt.so.4 openvrml-xembed-0.17.12-1.fc11.i586 requires libboost_thread-mt.so.4 pdf2djvu-0.5.0-3.fc11.i586 requires libpoppler.so.4 pdfcube-0.0.3-3.fc11.i586 requires libpoppler.so.4 pdfcube-0.0.3-3.fc11.i586 requires libboost_program_options-mt.so.4 player-2.1.1-10.fc11.i586 requires libml.so.1 player-2.1.1-10.fc11.i586 requires libboost_signals.so.4 player-2.1.1-10.fc11.i586 requires libhighgui.so.1 player-2.1.1-10.fc11.i586 requires libcvaux.so.1 player-2.1.1-10.fc11.i586 requires libcv.so.1 player-2.1.1-10.fc11.i586 requires libcxcore.so.1 player-2.1.1-10.fc11.i586 requires libboost_thread-mt.so.4 player-examples-2.1.1-10.fc11.i586 requires libboost_signals.so.4 player-examples-2.1.1-10.fc11.i586 requires libboost_thread-mt.so.4 plplot-ocaml-5.9.3-2.fc12.i586 requires ocaml(runtime) = 0:3.11.0 pyexiv2-0.1.3-3.fc12.i586 requires libboost_python.so.4 python-cclib-0.91-4.fc10.noarch requires python(abi) = 0:2.5 python-kinterbasdb-3.3.0-0.fc10.i386 requires python(abi) = 0:2.5 python-kinterbasdb-3.3.0-0.fc10.i386 requires libpython2.5.so.1.0 python-paida-3.2.1_2.10.1-2.fc10.noarch requires python(abi) = 0:2.5 python-polybori-0.5-5.fc11.i586 requires libboost_python.so.4 python-tag-0.94.5-2.fc11.i586 requires libboost_python-mt.so.4 qbittorrent-1.4.0-0.1.20090429svn.fc12.i586 requires libboost_filesystem-mt.so.4 qbittorrent-1.4.0-0.1.20090429svn.fc12.i586 requires libboost_thread-mt.so.4 qbittorrent-1.4.0-0.1.20090429svn.fc12.i586 requires libboost_system-mt.so.4 qmf-0.5.752600-6.fc12.i586 requires libboost_filesystem.so.4 qmf-0.5.752600-6.fc12.i586 requires libboost_program_options.so.4 qmforge-2.1-4.fc10.noarch requires python(abi) = 0:2.5 qpidc-0.5.752600-6.fc12.i586 requires libboost_filesystem.so.4 qpidc-0.5.752600-6.fc12.i586 requires libboost_program_options.so.4 qpidc-perftest-0.5.752600-6.fc12.i586 requires libboost_filesystem.so.4 qpidc-perftest-0.5.752600-6.fc12.i586 requires libboost_program_options.so.4 qpidc-rdma-0.5.752600-6.fc12.i586 requires libboost_filesystem.so.4 qpidc-rdma-0.5.752600-6.fc12.i586 requires libboost_program_options.so.4 qpidc-ssl-0.5.752600-6.fc12.i586 requires libboost_filesystem.so.4 qpidc-ssl-0.5.752600-6.fc12.i586 requires libboost_program_options.so.4 qpidd-0.5.752600-6.fc12.i586 requires libboost_filesystem.so.4 qpidd-0.5.752600-6.fc12.i586 requires libboost_program_options.so.4 qpidd-acl-0.5.752600-6.fc12.i586 requires libboost_filesystem.so.4 qpidd-acl-0.5.752600-6.fc12.i586 requires libboost_program_options.so.4 qpidd-cluster-0.5.752600-6.fc12.i586 requires libboost_filesystem.so.4 qpidd-cluster-0.5.752600-6.fc12.i586 requires libboost_program_options.so.4 qpidd-rdma-0.5.752600-6.fc12.i586 requires libboost_filesystem.so.4 qpidd-rdma-0.5.752600-6.fc12.i586 requires libboost_program_options.so.4 qpidd-ssl-0.5.752600-6.fc12.i586 requires libboost_filesystem.so.4 qpidd-ssl-0.5.752600-6.fc12.i586 requires libboost_program_options.so.4 qpidd-xml-0.5.752600-6.fc12.i586 requires libboost_filesystem.so.4 qpidd-xml-0.5.752600-6.fc12.i586 requires libboost_program_options.so.4 rcsslogplayer-13.1.0-4.fc11.i586 requires libboost_program_options-mt.so.4 rcssserver-13.2.0-1.fc11.i586 requires libboost_filesystem-mt.so.4 rcssserver-13.2.0-1.fc11.i586 requires libboost_system-mt.so.4 referencer-1.1.5-6.fc11.i586 requires libboost_regex.so.4 showimg-pgsql-0.9.5-22.fc11.i586 requires libpqxx-2.6.8.so soci-3.0.0-10.fc10.i386 requires libboost_program_options.so.3 soci-3.0.0-10.fc10.i386 requires libboost_date_time.so.3 soci-mysql-3.0.0-10.fc10.i386 requires libboost_program_options.so.3 soci-mysql-3.0.0-10.fc10.i386 requires libboost_date_time.so.3 soci-postgresql-3.0.0-10.fc10.i386 requires libboost_program_options.so.3 soci-postgresql-3.0.0-10.fc10.i386 requires libboost_date_time.so.3 source-highlight-2.10-3.fc11.i586 requires libboost_regex.so.4 spring-0.78.2.1-9.fc11.i586 requires libboost_regex-mt.so.4 spring-0.78.2.1-9.fc11.i586 requires libboost_thread-mt.so.4 sword-1.5.11-4.fc11.i586 requires libicudata.so.40 sword-1.5.11-4.fc11.i586 requires libicui18n.so.40 sword-1.5.11-4.fc11.i586 requires libicuuc.so.40 sword-1.5.11-4.fc11.i586 requires libicuio.so.40 tellico-1.3.5-1.fc11.i586 requires libpoppler.so.4 twinkle-1.4.2-2.fc11.i586 requires libboost_regex.so.4 vegastrike-0.5.0-9.fc11.i586 requires libboost_python.so.4 vegastrike-0.5.0-9.fc11.i586 requires libOgreMain-1.6.1.so wp_tray-0.5.3-10.fc11.i586 requires libboost_regex.so.4 wp_tray-0.5.3-10.fc11.i586 requires libboost_filesystem.so.4 wp_tray-0.5.3-10.fc11.i586 requires libboost_system.so.4 xmms2-0.5-6.fc11.i586 requires libboost_signals.so.4 yafc-1.1.1-12.fc11.i586 requires libkrb4.so.2(krb4_2_MIT) yafc-1.1.1-12.fc11.i586 requires libkrb4.so.2 yaz-3.0.41-2.fc11.i586 requires libicudata.so.40 yaz-3.0.41-2.fc11.i586 requires libicui18n.so.40 yaz-3.0.41-2.fc11.i586 requires libicuuc.so.40 ====================================================================== Broken packages in dist-f12-build-current-ppc: 1:openoffice.org-core-3.1.0-11.2.fc11.ppc requires libicule.so.40 1:openoffice.org-core-3.1.0-11.2.fc11.ppc requires libicuuc.so.40 1:openoffice.org-core-3.1.0-11.2.fc11.ppc requires libicudata.so.40 1:openoffice.org-core-3.1.0-11.2.fc11.ppc requires libicui18n.so.40 1:openoffice.org-pdfimport-3.1.0-11.2.fc11.ppc requires libpoppler.so.4 1:openoffice.org-writer-core-3.1.0-11.2.fc11.ppc requires libicuuc.so.40 2:koffice-krita-1.9.99.0-1.fc12.ppc requires libpoppler.so.4 HippoDraw-python-1.21.1-9.fc11.ppc requires libboost_python.so.4 Miro-2.0.3-2.fc12.ppc requires libboost_python.so.4 QuantLib-test-0.9.7-5.fc11.ppc requires libboost_unit_test_framework.so.4 R-RScaLAPACK-0.5.1-19.fc11.ppc requires openmpi-libs adminutil-1.1.8-1.fc11.ppc requires libicuuc.so.40 adminutil-1.1.8-1.fc11.ppc requires libicui18n.so.40 adminutil-1.1.8-1.fc11.ppc requires libicudata.so.40 alsa-firmware-1.0.20-1.fc12.noarch requires alsa-tools-firmware >= 0:1.0.20 asc-2.2.0.0-3.fc11.ppc requires libboost_regex.so.4 barry-0.15-0.5.20090109git.fc11.ppc requires libboost_serialization.so.4 bmpx-0.40.14-8.fc11.ppc requires libboost_regex-mt.so.4 bmpx-0.40.14-8.fc11.ppc requires libboost_iostreams-mt.so.4 bzrtools-1.14.0-1.fc11.ppc requires bzr < 0:1.15 cas-0.14-10.fc12.noarch requires crash cduce-0.5.2.1-14.fc11.ppc requires ocaml(runtime) = 0:3.11.0 cduce-0.5.2.1-14.fc11.ppc requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 cduce-ocamlduce-0.5.2.1-14.fc11.ppc requires ocaml(runtime) = 0:3.11.0 chess-1.0-24.fc11.ppc requires libboost_thread-mt.so.4 chess-1.0-24.fc11.ppc requires libCEGUIOgreRenderer-1.6.1.so chess-1.0-24.fc11.ppc requires libOgreMain-1.6.1.so cinepaint-libs-0.22.1-12.fc11.2.ppc requires libftgl.so.0 conexus-gtkmm-devel-0.7.0-1.fc12.ppc requires sysfs-devel cyrus-imapd-2.3.14-1.fc11.ppc requires libkrb4.so.2 cyrus-imapd-2.3.14-1.fc11.ppc requires libkrb4.so.2(krb4_2_MIT) cyrus-imapd-utils-2.3.14-1.fc11.ppc requires libkrb4.so.2 dwdiff-1.5-3.fc11.ppc requires libicuuc.so.40 dwdiff-1.5-3.fc11.ppc requires libicudata.so.40 dwdiff-1.5-3.fc11.ppc requires libicui18n.so.40 esperanza-0.4.0-2.fc11.ppc requires libboost_signals.so.4 fedora-ds-admin-1.1.7-4.fc11.ppc requires libicudata.so.40 fedora-ds-admin-1.1.7-4.fc11.ppc requires libicui18n.so.40 fedora-ds-admin-1.1.7-4.fc11.ppc requires libicuuc.so.40 fedora-ds-dsgw-1.1.2-1.fc11.ppc requires libicudata.so.40 fedora-ds-dsgw-1.1.2-1.fc11.ppc requires libicui18n.so.40 fedora-ds-dsgw-1.1.2-1.fc11.ppc requires libicuuc.so.40 fetchmail-6.3.9-3.fc11.ppc requires libkrb4.so.2(krb4_2_MIT) fetchmail-6.3.9-3.fc11.ppc requires libkrb4.so.2 firebird-2.1.2.18118.0-7.fc10.ppc requires libicuuc.so.40 firebird-2.1.2.18118.0-7.fc10.ppc requires libicui18n.so.40 firebird-2.1.2.18118.0-7.fc10.ppc requires libicudata.so.40 firebird-libfbembed-2.1.2.18118.0-7.fc10.ppc requires libicuuc.so.40 firebird-libfbembed-2.1.2.18118.0-7.fc10.ppc requires libicui18n.so.40 firebird-libfbembed-2.1.2.18118.0-7.fc10.ppc requires libicudata.so.40 firebird-superserver-2.1.2.18118.0-7.fc10.ppc requires libicuuc.so.40 firebird-superserver-2.1.2.18118.0-7.fc10.ppc requires libicui18n.so.40 firebird-superserver-2.1.2.18118.0-7.fc10.ppc requires libicudata.so.40 firstaidkit-plugin-grub-0.2.2-9.fc11.noarch requires grub frei0r-plugins-1.1.22-1.fc11.ppc requires libml.so.1 frei0r-plugins-1.1.22-1.fc11.ppc requires libcv.so.1 frei0r-plugins-1.1.22-1.fc11.ppc requires libcxcore.so.1 frei0r-plugins-1.1.22-1.fc11.ppc requires libhighgui.so.1 frei0r-plugins-1.1.22-1.fc11.ppc requires libcvaux.so.1 fuse-encfs-1.5-6.fc11.ppc requires libboost_filesystem-mt.so.4 fuse-encfs-1.5-6.fc11.ppc requires libboost_serialization-mt.so.4 ghc-ghc-paths-devel-0.1.0.5-6.fc12.ppc requires ghc = 0:6.10.2 ghc-ghc-paths-doc-0.1.0.5-6.fc12.ppc requires ghc-doc = 0:6.10.2 ghc-ghc-paths-prof-0.1.0.5-6.fc12.ppc requires ghc-prof = 0:6.10.2 ghc-haddock-devel-2.4.2-2.fc12.ppc requires ghc = 0:6.10.2 ghc-haddock-doc-2.4.2-2.fc12.ppc requires ghc-doc = 0:6.10.2 ghc-haddock-prof-2.4.2-2.fc12.ppc requires ghc-prof = 0:6.10.2 ghc-haskell-src-exts-devel-0.4.8-5.fc12.ppc requires ghc = 0:6.10.2 ghc-haskell-src-exts-doc-0.4.8-5.fc12.ppc requires ghc-doc = 0:6.10.2 ghc-haskell-src-exts-prof-0.4.8-5.fc12.ppc requires ghc-prof = 0:6.10.2 ghc-hscolour-devel-1.12-3.fc12.ppc requires ghc = 0:6.10.2 ghc-hscolour-doc-1.12-3.fc12.ppc requires ghc-doc = 0:6.10.2 ghc-hscolour-prof-1.12-3.fc12.ppc requires ghc-prof = 0:6.10.2 ghc-uniplate-devel-1.2.0.3-3.fc11.ppc requires ghc = 0:6.10.1 ghc-uniplate-doc-1.2.0.3-3.fc11.ppc requires ghc-doc = 0:6.10.1 ghc-uniplate-prof-1.2.0.3-3.fc11.ppc requires ghc-prof = 0:6.10.1 glest-data-3.2.1-1.fc11.noarch requires glest = 0:3.2.1 glob2-0.9.3-2.fc11.ppc requires libboost_thread-mt.so.4 gnash-0.8.5-3.fc11.ppc requires libboost_date_time-mt.so.4 gnash-0.8.5-3.fc11.ppc requires libboost_thread-mt.so.4 gnash-cygnal-0.8.5-3.fc11.ppc requires libboost_thread-mt.so.4 gnome-commander-1.3-0.1.svn2532_13dev.fc12.ppc requires libpoppler.so.4 gnote-0.1.2-2.fc12.ppc requires libboost_regex-mt.so.4 gnote-0.1.2-2.fc12.ppc requires libboost_filesystem-mt.so.4 gnote-0.1.2-2.fc12.ppc requires libboost_system-mt.so.4 gnu-smalltalk-emacs-3.1-4.fc11.noarch requires gnu-smalltalk = 0:3.1 guimup-0.1.4-6.c.fc12.ppc requires mpd haddock-2.4.2-2.fc12.ppc requires ghc = 0:6.10.2 hugin-0.7.0-5.fc11.ppc requires libboost_thread-mt.so.4 hugin-base-0.7.0-5.fc11.ppc requires libboost_thread-mt.so.4 inkscape-0.47-0.9.20090518svn.fc12.ppc requires libpoppler.so.4 inkscape-view-0.47-0.9.20090518svn.fc12.ppc requires libpoppler.so.4 k3d-0.7.11.0-1.fc11.ppc requires libboost_regex-mt.so.4 k3d-0.7.11.0-1.fc11.ppc requires libboost_program_options-mt.so.4 k3d-0.7.11.0-1.fc11.ppc requires libboost_python-mt.so.4 k3d-devel-0.7.11.0-1.fc11.ppc requires libboost_python-mt.so.4 k3d-devel-0.7.11.0-1.fc11.ppc requires libboost_regex-mt.so.4 k3d-devel-0.7.11.0-1.fc11.ppc requires libboost_program_options-mt.so.4 kipi-plugins-0.2.0-2.fc11.ppc requires libcv.so.1 kipi-plugins-0.2.0-2.fc11.ppc requires libcxcore.so.1 kipi-plugins-0.2.0-2.fc11.ppc requires libhighgui.so.1 kipi-plugins-0.2.0-2.fc11.ppc requires libcvaux.so.1 libldb-devel-0.9.3-15.1.fc12.ppc requires libtdb-devel = 0:1.1.3-15.1.fc12 libprojectM-1.2.0-9.fc11.ppc requires libftgl.so.0 libyaz-3.0.41-2.fc11.ppc requires libicudata.so.40 libyaz-3.0.41-2.fc11.ppc requires libicui18n.so.40 libyaz-3.0.41-2.fc11.ppc requires libicuuc.so.40 liveusb-creator-3.6.5-3.fc12.noarch requires syslinux mapnik-0.5.2-0.12.svn780.fc11.ppc requires libicudata.so.40 mapnik-0.5.2-0.12.svn780.fc11.ppc requires libboost_program_options-mt.so.4 mapnik-0.5.2-0.12.svn780.fc11.ppc requires libboost_regex-mt.so.4 mapnik-0.5.2-0.12.svn780.fc11.ppc requires libboost_filesystem-mt.so.4 mapnik-0.5.2-0.12.svn780.fc11.ppc requires libicuuc.so.40 mapnik-0.5.2-0.12.svn780.fc11.ppc requires libboost_iostreams-mt.so.4 mapnik-0.5.2-0.12.svn780.fc11.ppc requires libboost_thread-mt.so.4 mapnik-0.5.2-0.12.svn780.fc11.ppc requires libboost_system-mt.so.4 mapnik-python-0.5.2-0.12.svn780.fc11.ppc requires libboost_python-mt.so.4 mapnik-utils-0.5.2-0.12.svn780.fc11.ppc requires libboost_program_options-mt.so.4 mapnik-utils-0.5.2-0.12.svn780.fc11.ppc requires libboost_iostreams-mt.so.4 me-tv-0.8.12-5.fc12.ppc requires xine-ui mkvtoolnix-2.6.0-1.fc11.ppc requires libboost_regex-mt.so.4 mkvtoolnix-gui-2.6.0-1.fc11.ppc requires libboost_regex-mt.so.4 mrpt-apps-0.6.5-0.4.20090213svn807.fc11.ppc requires libboost_program_options-mt.so.4 mrpt-apps-0.6.5-0.4.20090213svn807.fc11.ppc requires libcv.so.1 mrpt-apps-0.6.5-0.4.20090213svn807.fc11.ppc requires libcxcore.so.1 mrpt-apps-0.6.5-0.4.20090213svn807.fc11.ppc requires libhighgui.so.1 mrpt-core-0.6.5-0.4.20090213svn807.fc11.ppc requires libcv.so.1 mrpt-core-0.6.5-0.4.20090213svn807.fc11.ppc requires libcxcore.so.1 mrpt-core-0.6.5-0.4.20090213svn807.fc11.ppc requires libhighgui.so.1 msort-8.46-3.fc11.ppc requires libicuuc.so.40 msort-8.46-3.fc11.ppc requires libicutu.so.40 ocaml-SDL-0.7.2-18.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-augeas-0.4-4.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-bisect-1.0-0.4.alpha.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-bisect-1.0-0.4.alpha.fc11.ppc requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-bitstring-2.0.0-8.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-bitstring-2.0.0-8.fc11.ppc requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-cairo-1.2.0.cvs20080301-8.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-calendar-2.0.4-4.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-camlidl-1.05-8.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-camlimages-3.0.1-7.fc11.ppc requires ocaml(runtime) = 0:3.11.0 From mschwendt at gmail.com Fri May 22 18:57:05 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 22 May 2009 18:57:05 -0000 Subject: (2/3) Broken dependencies in Fedora 12 Development - 2009-05-22 Message-ID: <20090522185705.20074.59118@faldor.intranet> ocaml-camlp5-5.10-3.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-camomile-0.7.1-10.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-cryptokit-1.3-8.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-csv-1.1.7-4.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-curl-0.5.0-4.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-curses-1.0.3-4.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-dbus-0.07-4.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-deriving-0.1.1a-7.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-expat-0.9.1-15.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-extlib-1.5.1-6.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-facile-1.1-8.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-fileutils-0.3.0-9.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-findlib-1.2.3-6.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-gettext-0.3.2-7.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-gettext-0.3.2-7.fc11.ppc requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-gettext-camomile-0.3.2-7.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-gsl-0.6.0-7.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-json-static-0.9.6-8.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-json-static-0.9.6-8.fc11.ppc requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-json-wheel-1.0.4-8.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-lablgl-1.03-7.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-lablgtk-2.12.0-2.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-lablgtk-devel-2.12.0-2.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-lacaml-4.7.6-1.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-libvirt-0.6.1.0-1.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-lwt-1.1.0-4.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-mikmatch-1.0.0-5.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-mikmatch-1.0.0-5.fc11.ppc requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-mlgmpidl-1.1-1.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-mysql-1.0.4-8.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-newt-0.9-5.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-ocamlgraph-1.0-4.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-ocamlnet-2.2.9-12.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-ocamlnet-nethttpd-2.2.9-12.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-openin-20070524-7.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-openin-20070524-7.fc11.ppc requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-ounit-1.0.3-4.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-p3l-2.03-2.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-pa-do-0.8.4-5.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-pa-do-0.8.4-5.fc11.ppc requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-pa-monad-6.0-1.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-pa-monad-6.0-1.fc11.ppc requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-pcre-5.15.0-4.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-perl4caml-0.9.5-8.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-pgocaml-1.1-8.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-pgocaml-1.1-8.fc11.ppc requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-postgresql-1.10.3-1.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-preludeml-0.1-0.11.20090113.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-pxp-1.2.0test2-6.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-pxp-1.2.0test2-6.fc11.ppc requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-reins-0.1a-4.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-res-3.1.1-1.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-sexplib-4.2.7-2.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-sexplib-4.2.7-2.fc11.ppc requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-sqlite-1.2.0-5.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-ssl-0.4.3-2.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-type-conv-1.6.7-1.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-type-conv-1.6.7-1.fc11.ppc requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-ulex-1.1-6.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-ulex-1.1-6.fc11.ppc requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-xml-light-2.2.cvs20070817-11.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-xmlrpc-light-0.6.1-1.fc11.ppc requires ocaml(runtime) = 0:3.11.0 ocaml-zip-1.04-1.fc11.ppc requires ocaml(runtime) = 0:3.11.0 openvrml-0.17.12-1.fc11.ppc requires libboost_thread-mt.so.4 openvrml-xembed-0.17.12-1.fc11.ppc requires libboost_thread-mt.so.4 pdf2djvu-0.5.0-3.fc11.ppc requires libpoppler.so.4 pdfcube-0.0.3-3.fc11.ppc requires libpoppler.so.4 pdfcube-0.0.3-3.fc11.ppc requires libboost_program_options-mt.so.4 player-2.1.1-10.fc11.ppc requires libml.so.1 player-2.1.1-10.fc11.ppc requires libboost_signals.so.4 player-2.1.1-10.fc11.ppc requires libhighgui.so.1 player-2.1.1-10.fc11.ppc requires libcvaux.so.1 player-2.1.1-10.fc11.ppc requires libcv.so.1 player-2.1.1-10.fc11.ppc requires libcxcore.so.1 player-2.1.1-10.fc11.ppc requires libboost_thread-mt.so.4 player-examples-2.1.1-10.fc11.ppc requires libboost_signals.so.4 player-examples-2.1.1-10.fc11.ppc requires libboost_thread-mt.so.4 plplot-ocaml-5.9.3-2.fc12.ppc requires ocaml(runtime) = 0:3.11.0 pyexiv2-0.1.3-3.fc12.ppc requires libboost_python.so.4 python-cclib-0.91-4.fc10.noarch requires python(abi) = 0:2.5 python-kinterbasdb-3.3.0-0.fc10.ppc requires python(abi) = 0:2.5 python-kinterbasdb-3.3.0-0.fc10.ppc requires libpython2.5.so.1.0 python-paida-3.2.1_2.10.1-2.fc10.noarch requires python(abi) = 0:2.5 python-polybori-0.5-5.fc11.ppc requires libboost_python.so.4 python-tag-0.94.5-2.fc11.ppc requires libboost_python-mt.so.4 qbittorrent-1.4.0-0.1.20090429svn.fc12.ppc requires libboost_thread-mt.so.4 qbittorrent-1.4.0-0.1.20090429svn.fc12.ppc requires libboost_system-mt.so.4 qbittorrent-1.4.0-0.1.20090429svn.fc12.ppc requires libboost_filesystem-mt.so.4 qmf-0.5.752600-6.fc12.ppc requires libboost_filesystem.so.4 qmf-0.5.752600-6.fc12.ppc requires libboost_program_options.so.4 qmforge-2.1-4.fc10.noarch requires python(abi) = 0:2.5 qpidc-0.5.752600-6.fc12.ppc requires libboost_filesystem.so.4 qpidc-0.5.752600-6.fc12.ppc requires libboost_program_options.so.4 qpidc-perftest-0.5.752600-6.fc12.ppc requires libboost_filesystem.so.4 qpidc-perftest-0.5.752600-6.fc12.ppc requires libboost_program_options.so.4 qpidc-rdma-0.5.752600-6.fc12.ppc requires libboost_filesystem.so.4 qpidc-rdma-0.5.752600-6.fc12.ppc requires libboost_program_options.so.4 qpidc-ssl-0.5.752600-6.fc12.ppc requires libboost_filesystem.so.4 qpidc-ssl-0.5.752600-6.fc12.ppc requires libboost_program_options.so.4 qpidd-0.5.752600-6.fc12.ppc requires libboost_filesystem.so.4 qpidd-0.5.752600-6.fc12.ppc requires libboost_program_options.so.4 qpidd-acl-0.5.752600-6.fc12.ppc requires libboost_filesystem.so.4 qpidd-acl-0.5.752600-6.fc12.ppc requires libboost_program_options.so.4 qpidd-cluster-0.5.752600-6.fc12.ppc requires libboost_filesystem.so.4 qpidd-cluster-0.5.752600-6.fc12.ppc requires libboost_program_options.so.4 qpidd-rdma-0.5.752600-6.fc12.ppc requires libboost_filesystem.so.4 qpidd-rdma-0.5.752600-6.fc12.ppc requires libboost_program_options.so.4 qpidd-ssl-0.5.752600-6.fc12.ppc requires libboost_filesystem.so.4 qpidd-ssl-0.5.752600-6.fc12.ppc requires libboost_program_options.so.4 qpidd-xml-0.5.752600-6.fc12.ppc requires libboost_filesystem.so.4 qpidd-xml-0.5.752600-6.fc12.ppc requires libboost_program_options.so.4 rcsslogplayer-13.1.0-4.fc11.ppc requires libboost_program_options-mt.so.4 rcssserver-13.2.0-1.fc11.ppc requires libboost_filesystem-mt.so.4 rcssserver-13.2.0-1.fc11.ppc requires libboost_system-mt.so.4 referencer-1.1.5-6.fc11.ppc requires libboost_regex.so.4 showimg-pgsql-0.9.5-22.fc11.ppc requires libpqxx-2.6.8.so soci-3.0.0-10.fc10.ppc requires libboost_date_time.so.3 soci-3.0.0-10.fc10.ppc requires libboost_program_options.so.3 soci-mysql-3.0.0-10.fc10.ppc requires libboost_date_time.so.3 soci-mysql-3.0.0-10.fc10.ppc requires libboost_program_options.so.3 soci-postgresql-3.0.0-10.fc10.ppc requires libboost_date_time.so.3 soci-postgresql-3.0.0-10.fc10.ppc requires libboost_program_options.so.3 source-highlight-2.10-3.fc11.ppc requires libboost_regex.so.4 spring-maps-default-0.1-5.fc11.noarch requires spring sword-1.5.11-4.fc11.ppc requires libicudata.so.40 sword-1.5.11-4.fc11.ppc requires libicui18n.so.40 sword-1.5.11-4.fc11.ppc requires libicuuc.so.40 sword-1.5.11-4.fc11.ppc requires libicuio.so.40 tellico-1.3.5-1.fc11.ppc requires libpoppler.so.4 twinkle-1.4.2-2.fc11.ppc requires libboost_regex.so.4 vegastrike-0.5.0-9.fc11.ppc requires libboost_python.so.4 vegastrike-0.5.0-9.fc11.ppc requires libOgreMain-1.6.1.so wp_tray-0.5.3-10.fc11.ppc requires libboost_regex.so.4 wp_tray-0.5.3-10.fc11.ppc requires libboost_filesystem.so.4 wp_tray-0.5.3-10.fc11.ppc requires libboost_system.so.4 xmms2-0.5-6.fc11.ppc requires libboost_signals.so.4 yafc-1.1.1-12.fc11.ppc requires libkrb4.so.2(krb4_2_MIT) yafc-1.1.1-12.fc11.ppc requires libkrb4.so.2 yaz-3.0.41-2.fc11.ppc requires libicudata.so.40 yaz-3.0.41-2.fc11.ppc requires libicui18n.so.40 yaz-3.0.41-2.fc11.ppc requires libicuuc.so.40 ====================================================================== Broken packages in dist-f12-build-current-ppc64: 1:openoffice.org-core-3.1.0-11.2.fc11.ppc64 requires libicule.so.40()(64bit) 1:openoffice.org-core-3.1.0-11.2.fc11.ppc64 requires libicuuc.so.40()(64bit) 1:openoffice.org-core-3.1.0-11.2.fc11.ppc64 requires libicui18n.so.40()(64bit) 1:openoffice.org-core-3.1.0-11.2.fc11.ppc64 requires libicudata.so.40()(64bit) 1:openoffice.org-pdfimport-3.1.0-11.2.fc11.ppc64 requires libpoppler.so.4()(64bit) 1:openoffice.org-writer-core-3.1.0-11.2.fc11.ppc64 requires libicuuc.so.40()(64bit) 2:koffice-krita-1.9.99.0-1.fc12.ppc64 requires libpoppler.so.4()(64bit) HippoDraw-python-1.21.1-9.fc11.ppc64 requires libboost_python.so.4()(64bit) Miro-2.0.3-2.fc12.ppc64 requires libboost_python.so.4()(64bit) QuantLib-test-0.9.7-5.fc11.ppc64 requires libboost_unit_test_framework.so.4()(64bit) R-RScaLAPACK-0.5.1-19.fc11.ppc64 requires openmpi-libs adminutil-1.1.8-1.fc11.ppc64 requires libicuuc.so.40()(64bit) adminutil-1.1.8-1.fc11.ppc64 requires libicui18n.so.40()(64bit) adminutil-1.1.8-1.fc11.ppc64 requires libicudata.so.40()(64bit) alsa-firmware-1.0.20-1.fc12.noarch requires alsa-tools-firmware >= 0:1.0.20 asc-2.2.0.0-3.fc11.ppc64 requires libboost_regex.so.4()(64bit) barry-0.15-0.5.20090109git.fc11.ppc64 requires libboost_serialization.so.4()(64bit) bmpx-0.40.14-8.fc11.ppc64 requires libboost_iostreams.so.4()(64bit) bmpx-0.40.14-8.fc11.ppc64 requires libboost_regex.so.4()(64bit) bzrtools-1.14.0-1.fc11.ppc64 requires bzr < 0:1.15 ccsm-0.7.8-2.fc11.noarch requires compizconfig-python >= 0:0.7.8 chess-1.0-24.fc11.ppc64 requires libCEGUIOgreRenderer-1.6.1.so()(64bit) chess-1.0-24.fc11.ppc64 requires libboost_thread-mt.so.4()(64bit) chess-1.0-24.fc11.ppc64 requires libOgreMain-1.6.1.so()(64bit) cinepaint-libs-0.22.1-12.fc11.2.ppc64 requires libftgl.so.0()(64bit) conexus-gtkmm-devel-0.7.0-1.fc12.ppc64 requires sysfs-devel cyrus-imapd-2.3.14-1.fc11.ppc64 requires libkrb4.so.2()(64bit) cyrus-imapd-2.3.14-1.fc11.ppc64 requires libkrb4.so.2(krb4_2_MIT)(64bit) cyrus-imapd-utils-2.3.14-1.fc11.ppc64 requires libkrb4.so.2()(64bit) dwdiff-1.5-3.fc11.ppc64 requires libicuuc.so.40()(64bit) dwdiff-1.5-3.fc11.ppc64 requires libicui18n.so.40()(64bit) dwdiff-1.5-3.fc11.ppc64 requires libicudata.so.40()(64bit) esperanza-0.4.0-2.fc11.ppc64 requires libboost_signals.so.4()(64bit) fedora-ds-admin-1.1.7-4.fc11.ppc64 requires libicuuc.so.40()(64bit) fedora-ds-admin-1.1.7-4.fc11.ppc64 requires libicudata.so.40()(64bit) fedora-ds-admin-1.1.7-4.fc11.ppc64 requires libicui18n.so.40()(64bit) fedora-ds-dsgw-1.1.2-1.fc11.ppc64 requires libicuuc.so.40()(64bit) fedora-ds-dsgw-1.1.2-1.fc11.ppc64 requires libicudata.so.40()(64bit) fedora-ds-dsgw-1.1.2-1.fc11.ppc64 requires libicui18n.so.40()(64bit) fetchmail-6.3.9-3.fc11.ppc64 requires libkrb4.so.2(krb4_2_MIT)(64bit) fetchmail-6.3.9-3.fc11.ppc64 requires libkrb4.so.2()(64bit) firebird-2.1.2.18118.0-7.fc10.ppc64 requires libicuuc.so.40()(64bit) firebird-2.1.2.18118.0-7.fc10.ppc64 requires libicui18n.so.40()(64bit) firebird-2.1.2.18118.0-7.fc10.ppc64 requires libicudata.so.40()(64bit) firebird-libfbembed-2.1.2.18118.0-7.fc10.ppc64 requires libicuuc.so.40()(64bit) firebird-libfbembed-2.1.2.18118.0-7.fc10.ppc64 requires libicui18n.so.40()(64bit) firebird-libfbembed-2.1.2.18118.0-7.fc10.ppc64 requires libicudata.so.40()(64bit) firebird-superserver-2.1.2.18118.0-7.fc10.ppc64 requires libicuuc.so.40()(64bit) firebird-superserver-2.1.2.18118.0-7.fc10.ppc64 requires libicui18n.so.40()(64bit) firebird-superserver-2.1.2.18118.0-7.fc10.ppc64 requires libicudata.so.40()(64bit) firstaidkit-plugin-grub-0.2.2-9.fc11.noarch requires grub frei0r-plugins-1.1.22-1.fc11.ppc64 requires libhighgui.so.1()(64bit) frei0r-plugins-1.1.22-1.fc11.ppc64 requires libcvaux.so.1()(64bit) frei0r-plugins-1.1.22-1.fc11.ppc64 requires libml.so.1()(64bit) frei0r-plugins-1.1.22-1.fc11.ppc64 requires libcv.so.1()(64bit) frei0r-plugins-1.1.22-1.fc11.ppc64 requires libcxcore.so.1()(64bit) fuse-encfs-1.5-6.fc11.ppc64 requires libboost_serialization-mt.so.4()(64bit) fuse-encfs-1.5-6.fc11.ppc64 requires libboost_filesystem-mt.so.4()(64bit) gadget-0.0.3-3.fc11.noarch requires ejabberd gcl-emacs-2.6.8-0.3.20090303cvs.fc12.noarch requires gcl = 0:2.6.8-0.3.20090303cvs.fc12 gcl-xemacs-2.6.8-0.3.20090303cvs.fc12.noarch requires gcl = 0:2.6.8-0.3.20090303cvs.fc12 glest-data-3.2.1-1.fc11.noarch requires glest = 0:3.2.1 glob2-0.9.3-2.fc11.ppc64 requires libboost_thread-mt.so.4()(64bit) gnash-0.8.5-3.fc11.ppc64 requires libboost_thread-mt.so.4()(64bit) gnash-0.8.5-3.fc11.ppc64 requires libboost_date_time-mt.so.4()(64bit) gnash-cygnal-0.8.5-3.fc11.ppc64 requires libboost_thread-mt.so.4()(64bit) gnome-commander-1.3-0.1.svn2532_13dev.fc12.ppc64 requires libpoppler.so.4()(64bit) gnote-0.1.2-2.fc12.ppc64 requires libboost_regex-mt.so.4()(64bit) gnote-0.1.2-2.fc12.ppc64 requires libboost_system-mt.so.4()(64bit) gnote-0.1.2-2.fc12.ppc64 requires libboost_filesystem-mt.so.4()(64bit) gnu-smalltalk-emacs-3.1-4.fc11.noarch requires gnu-smalltalk = 0:3.1 gprolog-docs-1.3.1-3.fc11.noarch requires gprolog = 0:1.3.1-3.fc11 guimup-0.1.4-6.c.fc12.ppc64 requires mpd hugin-0.7.0-5.fc11.ppc64 requires libboost_thread-mt.so.4()(64bit) hugin-base-0.7.0-5.fc11.ppc64 requires libboost_thread-mt.so.4()(64bit) inkscape-0.47-0.9.20090518svn.fc12.ppc64 requires libpoppler.so.4()(64bit) inkscape-view-0.47-0.9.20090518svn.fc12.ppc64 requires libpoppler.so.4()(64bit) k3d-0.7.11.0-1.fc11.ppc64 requires libboost_program_options-mt.so.4()(64bit) k3d-0.7.11.0-1.fc11.ppc64 requires libboost_regex-mt.so.4()(64bit) k3d-0.7.11.0-1.fc11.ppc64 requires libboost_python-mt.so.4()(64bit) k3d-devel-0.7.11.0-1.fc11.ppc64 requires libboost_program_options-mt.so.4()(64bit) k3d-devel-0.7.11.0-1.fc11.ppc64 requires libboost_regex-mt.so.4()(64bit) k3d-devel-0.7.11.0-1.fc11.ppc64 requires libboost_python-mt.so.4()(64bit) kipi-plugins-0.2.0-2.fc11.ppc64 requires libcvaux.so.1()(64bit) kipi-plugins-0.2.0-2.fc11.ppc64 requires libcxcore.so.1()(64bit) kipi-plugins-0.2.0-2.fc11.ppc64 requires libhighgui.so.1()(64bit) kipi-plugins-0.2.0-2.fc11.ppc64 requires libcv.so.1()(64bit) libldb-devel-0.9.3-15.1.fc12.ppc64 requires libtdb-devel = 0:1.1.3-15.1.fc12 libprojectM-1.2.0-9.fc11.ppc64 requires libftgl.so.0()(64bit) libyaz-3.0.41-2.fc11.ppc64 requires libicuuc.so.40()(64bit) libyaz-3.0.41-2.fc11.ppc64 requires libicui18n.so.40()(64bit) libyaz-3.0.41-2.fc11.ppc64 requires libicudata.so.40()(64bit) liveusb-creator-3.6.5-3.fc12.noarch requires syslinux mapnik-0.5.2-0.12.svn780.fc11.ppc64 requires libboost_program_options-mt.so.4()(64bit) mapnik-0.5.2-0.12.svn780.fc11.ppc64 requires libboost_regex-mt.so.4()(64bit) mapnik-0.5.2-0.12.svn780.fc11.ppc64 requires libboost_iostreams-mt.so.4()(64bit) mapnik-0.5.2-0.12.svn780.fc11.ppc64 requires libboost_system-mt.so.4()(64bit) mapnik-0.5.2-0.12.svn780.fc11.ppc64 requires libboost_thread-mt.so.4()(64bit) mapnik-0.5.2-0.12.svn780.fc11.ppc64 requires libicuuc.so.40()(64bit) mapnik-0.5.2-0.12.svn780.fc11.ppc64 requires libicudata.so.40()(64bit) mapnik-0.5.2-0.12.svn780.fc11.ppc64 requires libboost_filesystem-mt.so.4()(64bit) mapnik-python-0.5.2-0.12.svn780.fc11.ppc64 requires libboost_python-mt.so.4()(64bit) mapnik-utils-0.5.2-0.12.svn780.fc11.ppc64 requires libboost_program_options-mt.so.4()(64bit) mapnik-utils-0.5.2-0.12.svn780.fc11.ppc64 requires libboost_iostreams-mt.so.4()(64bit) me-tv-0.8.12-5.fc12.ppc64 requires xine-ui mkvtoolnix-2.6.0-1.fc11.ppc64 requires libboost_regex-mt.so.4()(64bit) mkvtoolnix-gui-2.6.0-1.fc11.ppc64 requires libboost_regex-mt.so.4()(64bit) mrpt-apps-0.6.5-0.4.20090213svn807.fc11.ppc64 requires libboost_program_options-mt.so.4()(64bit) mrpt-apps-0.6.5-0.4.20090213svn807.fc11.ppc64 requires libhighgui.so.1()(64bit) mrpt-apps-0.6.5-0.4.20090213svn807.fc11.ppc64 requires libcv.so.1()(64bit) mrpt-apps-0.6.5-0.4.20090213svn807.fc11.ppc64 requires libcxcore.so.1()(64bit) mrpt-core-0.6.5-0.4.20090213svn807.fc11.ppc64 requires libhighgui.so.1()(64bit) mrpt-core-0.6.5-0.4.20090213svn807.fc11.ppc64 requires libcv.so.1()(64bit) mrpt-core-0.6.5-0.4.20090213svn807.fc11.ppc64 requires libcxcore.so.1()(64bit) msort-8.46-3.fc11.ppc64 requires libicuuc.so.40()(64bit) msort-8.46-3.fc11.ppc64 requires libicutu.so.40()(64bit) ocaml-SDL-0.7.2-18.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-augeas-0.4-4.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-bisect-1.0-0.4.alpha.fc11.ppc64 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-bisect-1.0-0.4.alpha.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-bitstring-2.0.0-8.fc11.ppc64 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-bitstring-2.0.0-8.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-cairo-1.2.0.cvs20080301-8.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-calendar-2.0.4-4.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-camlidl-1.05-8.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-camlimages-3.0.1-7.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-camlp5-5.10-3.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-cryptokit-1.3-8.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-csv-1.1.7-4.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-curl-0.5.0-4.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-curses-1.0.3-4.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-dbus-0.07-4.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-deriving-0.1.1a-7.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-expat-0.9.1-15.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-extlib-1.5.1-6.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-facile-1.1-8.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-fileutils-0.3.0-9.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-findlib-1.2.3-6.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-gettext-0.3.2-7.fc11.ppc64 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-gettext-0.3.2-7.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-gsl-0.6.0-7.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-json-static-0.9.6-8.fc11.ppc64 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-json-static-0.9.6-8.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-json-wheel-1.0.4-8.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-lablgl-1.03-7.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-lablgtk-2.12.0-2.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-lablgtk-devel-2.12.0-2.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-lacaml-4.7.6-1.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-libvirt-0.6.1.0-1.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-lwt-1.1.0-4.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-mikmatch-1.0.0-5.fc11.ppc64 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-mikmatch-1.0.0-5.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-mlgmpidl-1.1-1.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-mysql-1.0.4-8.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-newt-0.9-5.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-ocamlgraph-1.0-4.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-ocamlnet-2.2.9-12.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-ocamlnet-nethttpd-2.2.9-12.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-openin-20070524-7.fc11.ppc64 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-openin-20070524-7.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-ounit-1.0.3-4.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-p3l-2.03-2.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-pa-do-0.8.4-5.fc11.ppc64 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-pa-do-0.8.4-5.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-pa-monad-6.0-1.fc11.ppc64 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-pa-monad-6.0-1.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-pcre-5.15.0-4.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-perl4caml-0.9.5-8.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-pgocaml-1.1-8.fc11.ppc64 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-pgocaml-1.1-8.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-postgresql-1.10.3-1.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-preludeml-0.1-0.11.20090113.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-reins-0.1a-4.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-res-3.1.1-1.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-sexplib-4.2.7-2.fc11.ppc64 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-sexplib-4.2.7-2.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-sqlite-1.2.0-5.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-ssl-0.4.3-2.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-type-conv-1.6.7-1.fc11.ppc64 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-type-conv-1.6.7-1.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-ulex-1.1-6.fc11.ppc64 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-ulex-1.1-6.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-xml-light-2.2.cvs20070817-11.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-xmlrpc-light-0.6.1-1.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 ocaml-zip-1.04-1.fc11.ppc64 requires ocaml(runtime) = 0:3.11.0 openvrml-0.17.12-1.fc11.ppc64 requires libboost_thread-mt.so.4()(64bit) openvrml-xembed-0.17.12-1.fc11.ppc64 requires libboost_thread-mt.so.4()(64bit) pdf2djvu-0.5.0-3.fc11.ppc64 requires libpoppler.so.4()(64bit) player-2.1.1-10.fc11.ppc64 requires libboost_signals.so.4()(64bit) player-2.1.1-10.fc11.ppc64 requires libcvaux.so.1()(64bit) player-2.1.1-10.fc11.ppc64 requires libboost_thread-mt.so.4()(64bit) player-2.1.1-10.fc11.ppc64 requires libcxcore.so.1()(64bit) player-2.1.1-10.fc11.ppc64 requires libhighgui.so.1()(64bit) player-2.1.1-10.fc11.ppc64 requires libml.so.1()(64bit) player-2.1.1-10.fc11.ppc64 requires libcv.so.1()(64bit) player-examples-2.1.1-10.fc11.ppc64 requires libboost_signals.so.4()(64bit) player-examples-2.1.1-10.fc11.ppc64 requires libboost_thread-mt.so.4()(64bit) plplot-ocaml-5.9.3-2.fc12.ppc64 requires ocaml(runtime) = 0:3.11.0 pyexiv2-0.1.3-3.fc12.ppc64 requires libboost_python.so.4()(64bit) python-cclib-0.91-4.fc10.noarch requires python(abi) = 0:2.5 python-kinterbasdb-3.3.0-0.fc10.ppc64 requires python(abi) = 0:2.5 python-kinterbasdb-3.3.0-0.fc10.ppc64 requires libpython2.5.so.1.0()(64bit) python-mwlib-0.11.2-2.20090522hg2956.fc12.ppc64 requires LabPlot python-paida-3.2.1_2.10.1-2.fc10.noarch requires python(abi) = 0:2.5 python-polybori-0.5-5.fc11.ppc64 requires libboost_python.so.4()(64bit) python-tag-0.94.5-2.fc11.ppc64 requires libboost_python-mt.so.4()(64bit) qbittorrent-1.4.0-0.1.20090429svn.fc12.ppc64 requires libboost_system-mt.so.4()(64bit) qbittorrent-1.4.0-0.1.20090429svn.fc12.ppc64 requires libboost_thread-mt.so.4()(64bit) qbittorrent-1.4.0-0.1.20090429svn.fc12.ppc64 requires libboost_filesystem-mt.so.4()(64bit) qmf-0.5.752600-6.fc12.ppc64 requires libboost_filesystem.so.4()(64bit) qmf-0.5.752600-6.fc12.ppc64 requires libboost_program_options.so.4()(64bit) qmforge-2.1-4.fc10.noarch requires python(abi) = 0:2.5 qpidc-0.5.752600-6.fc12.ppc64 requires libboost_filesystem.so.4()(64bit) qpidc-0.5.752600-6.fc12.ppc64 requires libboost_program_options.so.4()(64bit) qpidc-perftest-0.5.752600-6.fc12.ppc64 requires libboost_filesystem.so.4()(64bit) qpidc-perftest-0.5.752600-6.fc12.ppc64 requires libboost_program_options.so.4()(64bit) qpidc-rdma-0.5.752600-6.fc12.ppc64 requires libboost_filesystem.so.4()(64bit) qpidc-rdma-0.5.752600-6.fc12.ppc64 requires libboost_program_options.so.4()(64bit) qpidc-ssl-0.5.752600-6.fc12.ppc64 requires libboost_filesystem.so.4()(64bit) qpidc-ssl-0.5.752600-6.fc12.ppc64 requires libboost_program_options.so.4()(64bit) qpidd-0.5.752600-6.fc12.ppc64 requires libboost_filesystem.so.4()(64bit) qpidd-0.5.752600-6.fc12.ppc64 requires libboost_program_options.so.4()(64bit) qpidd-acl-0.5.752600-6.fc12.ppc64 requires libboost_filesystem.so.4()(64bit) qpidd-acl-0.5.752600-6.fc12.ppc64 requires libboost_program_options.so.4()(64bit) qpidd-cluster-0.5.752600-6.fc12.ppc64 requires libboost_filesystem.so.4()(64bit) qpidd-cluster-0.5.752600-6.fc12.ppc64 requires libboost_program_options.so.4()(64bit) qpidd-rdma-0.5.752600-6.fc12.ppc64 requires libboost_filesystem.so.4()(64bit) qpidd-rdma-0.5.752600-6.fc12.ppc64 requires libboost_program_options.so.4()(64bit) qpidd-ssl-0.5.752600-6.fc12.ppc64 requires libboost_filesystem.so.4()(64bit) qpidd-ssl-0.5.752600-6.fc12.ppc64 requires libboost_program_options.so.4()(64bit) qpidd-xml-0.5.752600-6.fc12.ppc64 requires libboost_filesystem.so.4()(64bit) qpidd-xml-0.5.752600-6.fc12.ppc64 requires libboost_program_options.so.4()(64bit) rcsslogplayer-13.1.0-4.fc11.ppc64 requires libboost_program_options-mt.so.4()(64bit) rcssserver-13.2.0-1.fc11.ppc64 requires libboost_system-mt.so.4()(64bit) rcssserver-13.2.0-1.fc11.ppc64 requires libboost_filesystem-mt.so.4()(64bit) referencer-1.1.5-6.fc11.ppc64 requires libboost_regex.so.4()(64bit) showimg-pgsql-0.9.5-22.fc11.ppc64 requires libpqxx-2.6.8.so()(64bit) soci-3.0.0-10.fc10.ppc64 requires libboost_program_options.so.3()(64bit) soci-3.0.0-10.fc10.ppc64 requires libboost_date_time.so.3()(64bit) soci-mysql-3.0.0-10.fc10.ppc64 requires libboost_program_options.so.3()(64bit) soci-mysql-3.0.0-10.fc10.ppc64 requires libboost_date_time.so.3()(64bit) soci-postgresql-3.0.0-10.fc10.ppc64 requires libboost_program_options.so.3()(64bit) soci-postgresql-3.0.0-10.fc10.ppc64 requires libboost_date_time.so.3()(64bit) source-highlight-2.10-3.fc11.ppc64 requires libboost_regex.so.4()(64bit) spring-maps-default-0.1-5.fc11.noarch requires spring sword-1.5.11-4.fc11.ppc64 requires libicuio.so.40()(64bit) sword-1.5.11-4.fc11.ppc64 requires libicuuc.so.40()(64bit) sword-1.5.11-4.fc11.ppc64 requires libicui18n.so.40()(64bit) sword-1.5.11-4.fc11.ppc64 requires libicudata.so.40()(64bit) tellico-1.3.5-1.fc11.ppc64 requires libpoppler.so.4()(64bit) twinkle-1.4.2-2.fc11.ppc64 requires libboost_regex.so.4()(64bit) vegastrike-0.5.0-9.fc11.ppc64 requires libOgreMain-1.6.1.so()(64bit) vegastrike-0.5.0-9.fc11.ppc64 requires libboost_python.so.4()(64bit) wp_tray-0.5.3-10.fc11.ppc64 requires libboost_regex.so.4()(64bit) wp_tray-0.5.3-10.fc11.ppc64 requires libboost_system.so.4()(64bit) wp_tray-0.5.3-10.fc11.ppc64 requires libboost_filesystem.so.4()(64bit) xmms2-0.5-6.fc11.ppc64 requires libboost_signals.so.4()(64bit) yafc-1.1.1-12.fc11.ppc64 requires libkrb4.so.2(krb4_2_MIT)(64bit) yafc-1.1.1-12.fc11.ppc64 requires libkrb4.so.2()(64bit) yaz-3.0.41-2.fc11.ppc64 requires libicuuc.so.40()(64bit) yaz-3.0.41-2.fc11.ppc64 requires libicui18n.so.40()(64bit) yaz-3.0.41-2.fc11.ppc64 requires libicudata.so.40()(64bit) ====================================================================== Broken packages in dist-f12-build-current-x86_64: 1:openoffice.org-core-3.1.0-11.2.fc11.x86_64 requires libicudata.so.40()(64bit) 1:openoffice.org-core-3.1.0-11.2.fc11.x86_64 requires libicule.so.40()(64bit) 1:openoffice.org-core-3.1.0-11.2.fc11.x86_64 requires libicuuc.so.40()(64bit) 1:openoffice.org-core-3.1.0-11.2.fc11.x86_64 requires libicui18n.so.40()(64bit) 1:openoffice.org-pdfimport-3.1.0-11.2.fc11.x86_64 requires libpoppler.so.4()(64bit) 1:openoffice.org-writer-core-3.1.0-11.2.fc11.x86_64 requires libicuuc.so.40()(64bit) 2:koffice-krita-1.9.99.0-1.fc12.x86_64 requires libpoppler.so.4()(64bit) CodeAnalyst-gui-2.8.38-11.fc11.x86_64 requires libbfd-2.19.51.0.2-17.fc11.so()(64bit) HippoDraw-python-1.21.1-9.fc11.x86_64 requires libboost_python.so.4()(64bit) Miro-2.0.3-2.fc12.x86_64 requires libboost_python.so.4()(64bit) QuantLib-test-0.9.7-5.fc11.x86_64 requires libboost_unit_test_framework.so.4()(64bit) R-RScaLAPACK-0.5.1-19.fc11.x86_64 requires openmpi-libs adminutil-1.1.8-1.fc11.x86_64 requires libicuuc.so.40()(64bit) adminutil-1.1.8-1.fc11.x86_64 requires libicui18n.so.40()(64bit) adminutil-1.1.8-1.fc11.x86_64 requires libicudata.so.40()(64bit) alsa-firmware-1.0.20-1.fc12.noarch requires alsa-tools-firmware >= 0:1.0.20 asc-2.2.0.0-3.fc11.x86_64 requires libboost_regex.so.4()(64bit) barry-0.15-0.5.20090109git.fc11.x86_64 requires libboost_serialization.so.4()(64bit) bmpx-0.40.14-8.fc11.x86_64 requires libboost_iostreams.so.4()(64bit) bmpx-0.40.14-8.fc11.x86_64 requires libboost_regex.so.4()(64bit) bzrtools-1.14.0-1.fc11.x86_64 requires bzr < 0:1.15 cduce-0.5.2.1-14.fc11.x86_64 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 cduce-0.5.2.1-14.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 cduce-ocamlduce-0.5.2.1-14.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 chess-1.0-24.fc11.x86_64 requires libCEGUIOgreRenderer-1.6.1.so()(64bit) chess-1.0-24.fc11.x86_64 requires libboost_thread-mt.so.4()(64bit) chess-1.0-24.fc11.x86_64 requires libOgreMain-1.6.1.so()(64bit) cinepaint-libs-0.22.1-12.fc11.2.x86_64 requires libftgl.so.0()(64bit) conexus-gtkmm-devel-0.7.0-1.fc12.x86_64 requires sysfs-devel cyrus-imapd-2.3.14-1.fc11.x86_64 requires libkrb4.so.2(krb4_2_MIT)(64bit) cyrus-imapd-2.3.14-1.fc11.x86_64 requires libkrb4.so.2()(64bit) cyrus-imapd-utils-2.3.14-1.fc11.x86_64 requires libkrb4.so.2()(64bit) dwdiff-1.5-3.fc11.x86_64 requires libicuuc.so.40()(64bit) dwdiff-1.5-3.fc11.x86_64 requires libicui18n.so.40()(64bit) dwdiff-1.5-3.fc11.x86_64 requires libicudata.so.40()(64bit) esperanza-0.4.0-2.fc11.x86_64 requires libboost_signals.so.4()(64bit) fedora-ds-admin-1.1.7-4.fc11.x86_64 requires libicuuc.so.40()(64bit) fedora-ds-admin-1.1.7-4.fc11.x86_64 requires libicudata.so.40()(64bit) fedora-ds-admin-1.1.7-4.fc11.x86_64 requires libicui18n.so.40()(64bit) fedora-ds-dsgw-1.1.2-1.fc11.x86_64 requires libicuuc.so.40()(64bit) fedora-ds-dsgw-1.1.2-1.fc11.x86_64 requires libicudata.so.40()(64bit) fedora-ds-dsgw-1.1.2-1.fc11.x86_64 requires libicui18n.so.40()(64bit) fetchmail-6.3.9-3.fc11.x86_64 requires libkrb4.so.2(krb4_2_MIT)(64bit) fetchmail-6.3.9-3.fc11.x86_64 requires libkrb4.so.2()(64bit) firebird-2.1.2.18118.0-7.fc10.x86_64 requires libicuuc.so.40()(64bit) firebird-2.1.2.18118.0-7.fc10.x86_64 requires libicui18n.so.40()(64bit) firebird-2.1.2.18118.0-7.fc10.x86_64 requires libicudata.so.40()(64bit) firebird-libfbembed-2.1.2.18118.0-7.fc10.x86_64 requires libicuuc.so.40()(64bit) firebird-libfbembed-2.1.2.18118.0-7.fc10.x86_64 requires libicui18n.so.40()(64bit) firebird-libfbembed-2.1.2.18118.0-7.fc10.x86_64 requires libicudata.so.40()(64bit) firebird-superserver-2.1.2.18118.0-7.fc10.x86_64 requires libicuuc.so.40()(64bit) firebird-superserver-2.1.2.18118.0-7.fc10.x86_64 requires libicui18n.so.40()(64bit) firebird-superserver-2.1.2.18118.0-7.fc10.x86_64 requires libicudata.so.40()(64bit) frei0r-plugins-1.1.22-1.fc11.x86_64 requires libhighgui.so.1()(64bit) frei0r-plugins-1.1.22-1.fc11.x86_64 requires libml.so.1()(64bit) frei0r-plugins-1.1.22-1.fc11.x86_64 requires libcvaux.so.1()(64bit) frei0r-plugins-1.1.22-1.fc11.x86_64 requires libcv.so.1()(64bit) frei0r-plugins-1.1.22-1.fc11.x86_64 requires libcxcore.so.1()(64bit) fuse-encfs-1.5-6.fc11.x86_64 requires libboost_serialization-mt.so.4()(64bit) fuse-encfs-1.5-6.fc11.x86_64 requires libboost_filesystem-mt.so.4()(64bit) gambas2-gb-pdf-2.13.0-1.fc12.x86_64 requires libpoppler.so.4()(64bit) ghc-ghc-paths-devel-0.1.0.5-6.fc12.x86_64 requires ghc = 0:6.10.2 ghc-ghc-paths-doc-0.1.0.5-6.fc12.x86_64 requires ghc-doc = 0:6.10.2 ghc-ghc-paths-prof-0.1.0.5-6.fc12.x86_64 requires ghc-prof = 0:6.10.2 ghc-haddock-devel-2.4.2-2.fc12.x86_64 requires ghc = 0:6.10.2 ghc-haddock-doc-2.4.2-2.fc12.x86_64 requires ghc-doc = 0:6.10.2 ghc-haddock-prof-2.4.2-2.fc12.x86_64 requires ghc-prof = 0:6.10.2 ghc-haskell-src-exts-devel-0.4.8-5.fc12.x86_64 requires ghc = 0:6.10.2 ghc-haskell-src-exts-doc-0.4.8-5.fc12.x86_64 requires ghc-doc = 0:6.10.2 ghc-haskell-src-exts-prof-0.4.8-5.fc12.x86_64 requires ghc-prof = 0:6.10.2 ghc-hscolour-devel-1.12-3.fc12.x86_64 requires ghc = 0:6.10.2 ghc-hscolour-doc-1.12-3.fc12.x86_64 requires ghc-doc = 0:6.10.2 ghc-hscolour-prof-1.12-3.fc12.x86_64 requires ghc-prof = 0:6.10.2 ghc-uniplate-devel-1.2.0.3-3.fc11.x86_64 requires ghc = 0:6.10.1 ghc-uniplate-doc-1.2.0.3-3.fc11.x86_64 requires ghc-doc = 0:6.10.1 ghc-uniplate-prof-1.2.0.3-3.fc11.x86_64 requires ghc-prof = 0:6.10.1 glob2-0.9.3-2.fc11.x86_64 requires libboost_thread-mt.so.4()(64bit) gnash-0.8.5-3.fc11.x86_64 requires libboost_thread-mt.so.4()(64bit) gnash-0.8.5-3.fc11.x86_64 requires libboost_date_time-mt.so.4()(64bit) gnash-cygnal-0.8.5-3.fc11.x86_64 requires libboost_thread-mt.so.4()(64bit) gnome-commander-1.3-0.1.svn2532_13dev.fc12.x86_64 requires libpoppler.so.4()(64bit) gnote-0.1.2-2.fc12.x86_64 requires libboost_regex-mt.so.4()(64bit) gnote-0.1.2-2.fc12.x86_64 requires libboost_system-mt.so.4()(64bit) gnote-0.1.2-2.fc12.x86_64 requires libboost_filesystem-mt.so.4()(64bit) guimup-0.1.4-6.c.fc12.x86_64 requires mpd haddock-2.4.2-2.fc12.x86_64 requires ghc = 0:6.10.2 hugin-0.7.0-5.fc11.x86_64 requires libboost_thread-mt.so.4()(64bit) hugin-base-0.7.0-5.fc11.x86_64 requires libboost_thread-mt.so.4()(64bit) inkscape-0.47-0.9.20090518svn.fc12.x86_64 requires libpoppler.so.4()(64bit) inkscape-view-0.47-0.9.20090518svn.fc12.x86_64 requires libpoppler.so.4()(64bit) k3d-0.7.11.0-1.fc11.x86_64 requires libboost_program_options-mt.so.4()(64bit) k3d-0.7.11.0-1.fc11.x86_64 requires libboost_regex-mt.so.4()(64bit) k3d-0.7.11.0-1.fc11.x86_64 requires libboost_python-mt.so.4()(64bit) k3d-devel-0.7.11.0-1.fc11.x86_64 requires libboost_program_options-mt.so.4()(64bit) k3d-devel-0.7.11.0-1.fc11.x86_64 requires libboost_regex-mt.so.4()(64bit) k3d-devel-0.7.11.0-1.fc11.x86_64 requires libboost_python-mt.so.4()(64bit) kipi-plugins-0.2.0-2.fc11.x86_64 requires libcvaux.so.1()(64bit) kipi-plugins-0.2.0-2.fc11.x86_64 requires libcxcore.so.1()(64bit) kipi-plugins-0.2.0-2.fc11.x86_64 requires libhighgui.so.1()(64bit) kipi-plugins-0.2.0-2.fc11.x86_64 requires libcv.so.1()(64bit) libldb-devel-0.9.3-15.1.fc12.x86_64 requires libtdb-devel = 0:1.1.3-15.1.fc12 libprojectM-1.2.0-9.fc11.x86_64 requires libftgl.so.0()(64bit) libyaz-3.0.41-2.fc11.x86_64 requires libicuuc.so.40()(64bit) libyaz-3.0.41-2.fc11.x86_64 requires libicui18n.so.40()(64bit) libyaz-3.0.41-2.fc11.x86_64 requires libicudata.so.40()(64bit) lmms-0.4.4-1.fc12.x86_64 requires lmms-vst = 0:0.4.4-1.fc12 mapnik-0.5.2-0.12.svn780.fc11.x86_64 requires libboost_program_options-mt.so.4()(64bit) mapnik-0.5.2-0.12.svn780.fc11.x86_64 requires libboost_regex-mt.so.4()(64bit) mapnik-0.5.2-0.12.svn780.fc11.x86_64 requires libboost_iostreams-mt.so.4()(64bit) mapnik-0.5.2-0.12.svn780.fc11.x86_64 requires libboost_system-mt.so.4()(64bit) mapnik-0.5.2-0.12.svn780.fc11.x86_64 requires libboost_thread-mt.so.4()(64bit) mapnik-0.5.2-0.12.svn780.fc11.x86_64 requires libicuuc.so.40()(64bit) mapnik-0.5.2-0.12.svn780.fc11.x86_64 requires libicudata.so.40()(64bit) mapnik-0.5.2-0.12.svn780.fc11.x86_64 requires libboost_filesystem-mt.so.4()(64bit) mapnik-python-0.5.2-0.12.svn780.fc11.x86_64 requires libboost_python-mt.so.4()(64bit) mapnik-utils-0.5.2-0.12.svn780.fc11.x86_64 requires libboost_program_options-mt.so.4()(64bit) mapnik-utils-0.5.2-0.12.svn780.fc11.x86_64 requires libboost_iostreams-mt.so.4()(64bit) me-tv-0.8.12-5.fc12.x86_64 requires xine-ui mkvtoolnix-2.6.0-1.fc11.x86_64 requires libboost_regex-mt.so.4()(64bit) From mschwendt at gmail.com Fri May 22 18:57:08 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 22 May 2009 18:57:08 -0000 Subject: (3/3) Broken dependencies in Fedora 12 Development - 2009-05-22 Message-ID: <20090522185708.20074.94086@faldor.intranet> mkvtoolnix-gui-2.6.0-1.fc11.x86_64 requires libboost_regex-mt.so.4()(64bit) mrpt-apps-0.6.5-0.4.20090213svn807.fc11.x86_64 requires libboost_program_options-mt.so.4()(64bit) mrpt-apps-0.6.5-0.4.20090213svn807.fc11.x86_64 requires libhighgui.so.1()(64bit) mrpt-apps-0.6.5-0.4.20090213svn807.fc11.x86_64 requires libcv.so.1()(64bit) mrpt-apps-0.6.5-0.4.20090213svn807.fc11.x86_64 requires libcxcore.so.1()(64bit) mrpt-core-0.6.5-0.4.20090213svn807.fc11.x86_64 requires libhighgui.so.1()(64bit) mrpt-core-0.6.5-0.4.20090213svn807.fc11.x86_64 requires libcv.so.1()(64bit) mrpt-core-0.6.5-0.4.20090213svn807.fc11.x86_64 requires libcxcore.so.1()(64bit) msort-8.46-3.fc11.x86_64 requires libicuuc.so.40()(64bit) msort-8.46-3.fc11.x86_64 requires libicutu.so.40()(64bit) ocaml-SDL-0.7.2-18.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-augeas-0.4-4.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-bisect-1.0-0.4.alpha.fc11.x86_64 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-bisect-1.0-0.4.alpha.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-bitstring-2.0.0-8.fc11.x86_64 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-bitstring-2.0.0-8.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-cairo-1.2.0.cvs20080301-8.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-calendar-2.0.4-4.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-camlidl-1.05-8.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-camlimages-3.0.1-7.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-camlp5-5.10-3.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-camomile-0.7.1-10.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-cil-1.3.6-11.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-cryptokit-1.3-8.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-csv-1.1.7-4.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-curl-0.5.0-4.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-curses-1.0.3-4.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-dbus-0.07-4.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-deriving-0.1.1a-7.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-expat-0.9.1-15.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-extlib-1.5.1-6.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-facile-1.1-8.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-fileutils-0.3.0-9.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-findlib-1.2.3-6.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-gettext-0.3.2-7.fc11.x86_64 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-gettext-0.3.2-7.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-gettext-camomile-0.3.2-7.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-gsl-0.6.0-7.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-json-static-0.9.6-8.fc11.x86_64 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-json-static-0.9.6-8.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-json-wheel-1.0.4-8.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-lablgl-1.03-7.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-lablgtk-2.12.0-2.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-lablgtk-devel-2.12.0-2.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-lacaml-4.7.6-1.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-libvirt-0.6.1.0-1.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-lwt-1.1.0-4.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-mikmatch-1.0.0-5.fc11.x86_64 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-mikmatch-1.0.0-5.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-mlgmpidl-1.1-1.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-mysql-1.0.4-8.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-newt-0.9-5.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-ocamlgraph-1.0-4.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-ocamlnet-2.2.9-12.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-ocamlnet-nethttpd-2.2.9-12.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-openin-20070524-7.fc11.x86_64 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-openin-20070524-7.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-ounit-1.0.3-4.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-p3l-2.03-2.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-pa-do-0.8.4-5.fc11.x86_64 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-pa-do-0.8.4-5.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-pa-monad-6.0-1.fc11.x86_64 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-pa-monad-6.0-1.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-pcre-5.15.0-4.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-perl4caml-0.9.5-8.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-pgocaml-1.1-8.fc11.x86_64 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-pgocaml-1.1-8.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-postgresql-1.10.3-1.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-preludeml-0.1-0.11.20090113.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-pxp-1.2.0test2-6.fc11.x86_64 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-pxp-1.2.0test2-6.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-reins-0.1a-4.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-res-3.1.1-1.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-sexplib-4.2.7-2.fc11.x86_64 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-sexplib-4.2.7-2.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-sqlite-1.2.0-5.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-ssl-0.4.3-2.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-type-conv-1.6.7-1.fc11.x86_64 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-type-conv-1.6.7-1.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-ulex-1.1-6.fc11.x86_64 requires ocaml(Camlp4_import) = 0:901773aae9273de4d3a05d3a93dde334 ocaml-ulex-1.1-6.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-xml-light-2.2.cvs20070817-11.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-xmlrpc-light-0.6.1-1.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 ocaml-zip-1.04-1.fc11.x86_64 requires ocaml(runtime) = 0:3.11.0 openvrml-0.17.12-1.fc11.x86_64 requires libboost_thread-mt.so.4()(64bit) openvrml-xembed-0.17.12-1.fc11.x86_64 requires libboost_thread-mt.so.4()(64bit) pdf2djvu-0.5.0-3.fc11.x86_64 requires libpoppler.so.4()(64bit) player-2.1.1-10.fc11.x86_64 requires libboost_signals.so.4()(64bit) player-2.1.1-10.fc11.x86_64 requires libcvaux.so.1()(64bit) player-2.1.1-10.fc11.x86_64 requires libboost_thread-mt.so.4()(64bit) player-2.1.1-10.fc11.x86_64 requires libcxcore.so.1()(64bit) player-2.1.1-10.fc11.x86_64 requires libhighgui.so.1()(64bit) player-2.1.1-10.fc11.x86_64 requires libml.so.1()(64bit) player-2.1.1-10.fc11.x86_64 requires libcv.so.1()(64bit) player-examples-2.1.1-10.fc11.x86_64 requires libboost_signals.so.4()(64bit) player-examples-2.1.1-10.fc11.x86_64 requires libboost_thread-mt.so.4()(64bit) plplot-ocaml-5.9.3-2.fc12.x86_64 requires ocaml(runtime) = 0:3.11.0 pyexiv2-0.1.3-3.fc12.x86_64 requires libboost_python.so.4()(64bit) python-cclib-0.91-4.fc10.noarch requires python(abi) = 0:2.5 python-kinterbasdb-3.3.0-0.fc10.x86_64 requires python(abi) = 0:2.5 python-kinterbasdb-3.3.0-0.fc10.x86_64 requires libpython2.5.so.1.0()(64bit) python-paida-3.2.1_2.10.1-2.fc10.noarch requires python(abi) = 0:2.5 python-polybori-0.5-5.fc11.x86_64 requires libboost_python.so.4()(64bit) python-tag-0.94.5-2.fc11.x86_64 requires libboost_python-mt.so.4()(64bit) qbittorrent-1.4.0-0.1.20090429svn.fc12.x86_64 requires libboost_system-mt.so.4()(64bit) qbittorrent-1.4.0-0.1.20090429svn.fc12.x86_64 requires libboost_thread-mt.so.4()(64bit) qbittorrent-1.4.0-0.1.20090429svn.fc12.x86_64 requires libboost_filesystem-mt.so.4()(64bit) qmf-0.5.752600-6.fc12.x86_64 requires libboost_program_options.so.4()(64bit) qmf-0.5.752600-6.fc12.x86_64 requires libboost_filesystem.so.4()(64bit) qmforge-2.1-4.fc10.noarch requires python(abi) = 0:2.5 qpidc-0.5.752600-6.fc12.x86_64 requires libboost_program_options.so.4()(64bit) qpidc-0.5.752600-6.fc12.x86_64 requires libboost_filesystem.so.4()(64bit) qpidc-perftest-0.5.752600-6.fc12.x86_64 requires libboost_program_options.so.4()(64bit) qpidc-perftest-0.5.752600-6.fc12.x86_64 requires libboost_filesystem.so.4()(64bit) qpidc-rdma-0.5.752600-6.fc12.x86_64 requires libboost_program_options.so.4()(64bit) qpidc-rdma-0.5.752600-6.fc12.x86_64 requires libboost_filesystem.so.4()(64bit) qpidc-ssl-0.5.752600-6.fc12.x86_64 requires libboost_program_options.so.4()(64bit) qpidc-ssl-0.5.752600-6.fc12.x86_64 requires libboost_filesystem.so.4()(64bit) qpidd-0.5.752600-6.fc12.x86_64 requires libboost_program_options.so.4()(64bit) qpidd-0.5.752600-6.fc12.x86_64 requires libboost_filesystem.so.4()(64bit) qpidd-acl-0.5.752600-6.fc12.x86_64 requires libboost_program_options.so.4()(64bit) qpidd-acl-0.5.752600-6.fc12.x86_64 requires libboost_filesystem.so.4()(64bit) qpidd-cluster-0.5.752600-6.fc12.x86_64 requires libboost_program_options.so.4()(64bit) qpidd-cluster-0.5.752600-6.fc12.x86_64 requires libboost_filesystem.so.4()(64bit) qpidd-rdma-0.5.752600-6.fc12.x86_64 requires libboost_program_options.so.4()(64bit) qpidd-rdma-0.5.752600-6.fc12.x86_64 requires libboost_filesystem.so.4()(64bit) qpidd-ssl-0.5.752600-6.fc12.x86_64 requires libboost_program_options.so.4()(64bit) qpidd-ssl-0.5.752600-6.fc12.x86_64 requires libboost_filesystem.so.4()(64bit) qpidd-xml-0.5.752600-6.fc12.x86_64 requires libboost_program_options.so.4()(64bit) qpidd-xml-0.5.752600-6.fc12.x86_64 requires libboost_filesystem.so.4()(64bit) rcsslogplayer-13.1.0-4.fc11.x86_64 requires libboost_program_options-mt.so.4()(64bit) rcssserver-13.2.0-1.fc11.x86_64 requires libboost_system-mt.so.4()(64bit) rcssserver-13.2.0-1.fc11.x86_64 requires libboost_filesystem-mt.so.4()(64bit) referencer-1.1.5-6.fc11.x86_64 requires libboost_regex.so.4()(64bit) showimg-pgsql-0.9.5-22.fc11.x86_64 requires libpqxx-2.6.8.so()(64bit) soci-3.0.0-10.fc10.x86_64 requires libboost_date_time.so.3()(64bit) soci-3.0.0-10.fc10.x86_64 requires libboost_program_options.so.3()(64bit) soci-mysql-3.0.0-10.fc10.x86_64 requires libboost_date_time.so.3()(64bit) soci-mysql-3.0.0-10.fc10.x86_64 requires libboost_program_options.so.3()(64bit) soci-postgresql-3.0.0-10.fc10.x86_64 requires libboost_date_time.so.3()(64bit) soci-postgresql-3.0.0-10.fc10.x86_64 requires libboost_program_options.so.3()(64bit) source-highlight-2.10-3.fc11.x86_64 requires libboost_regex.so.4()(64bit) spring-0.78.2.1-9.fc11.x86_64 requires libboost_regex-mt.so.4()(64bit) spring-0.78.2.1-9.fc11.x86_64 requires libboost_thread-mt.so.4()(64bit) sword-1.5.11-4.fc11.x86_64 requires libicuio.so.40()(64bit) sword-1.5.11-4.fc11.x86_64 requires libicuuc.so.40()(64bit) sword-1.5.11-4.fc11.x86_64 requires libicui18n.so.40()(64bit) sword-1.5.11-4.fc11.x86_64 requires libicudata.so.40()(64bit) tellico-1.3.5-1.fc11.x86_64 requires libpoppler.so.4()(64bit) twinkle-1.4.2-2.fc11.x86_64 requires libboost_regex.so.4()(64bit) vegastrike-0.5.0-9.fc11.x86_64 requires libOgreMain-1.6.1.so()(64bit) vegastrike-0.5.0-9.fc11.x86_64 requires libboost_python.so.4()(64bit) wp_tray-0.5.3-10.fc11.x86_64 requires libboost_regex.so.4()(64bit) wp_tray-0.5.3-10.fc11.x86_64 requires libboost_system.so.4()(64bit) wp_tray-0.5.3-10.fc11.x86_64 requires libboost_filesystem.so.4()(64bit) xmms2-0.5-6.fc11.x86_64 requires libboost_signals.so.4()(64bit) yafc-1.1.1-12.fc11.x86_64 requires libkrb4.so.2(krb4_2_MIT)(64bit) yafc-1.1.1-12.fc11.x86_64 requires libkrb4.so.2()(64bit) yaz-3.0.41-2.fc11.x86_64 requires libicuuc.so.40()(64bit) yaz-3.0.41-2.fc11.x86_64 requires libicui18n.so.40()(64bit) yaz-3.0.41-2.fc11.x86_64 requires libicudata.so.40()(64bit) From notting at redhat.com Fri May 22 19:00:17 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 22 May 2009 15:00:17 -0400 Subject: FESCo Meeting Summary for 2009-05-22 Message-ID: <20090522190016.GB18436@nostromo.devel.redhat.com> == Members Present == * Jon Stanley (jds2001) * Kevin Fenzi (nirik) * Dan Horak (sharkcz) * Josh Boyer (jwb) * Brian Pepple (bpepple) * Bill Nottingham (notting) * David Woodhouse (dwmw2) * Jarod Wilson (j-rod) == Members Absent == * Dennis Gilmore (dgilmore) == provenpackager request - iarnell == Iain Arnell was approved for provenpackager by a 8-0 vote. == provenpackager request - hadess == Bastien Nocera was approved for provenpackager by a 8-0 vote. == Feature: OSGi Auto Dependencies - https://fedoraproject.org/wiki/Features/OSGiAutoDeps == FESCo voted 7-0 that OSGI be referred to the Fedora Packaging Committee as a packaging guideline, not as a Fedora 12 feature. == FESCo should allow non packagers to be committee members == FESCo voted 5-0 (with three abstentions) to not change the current requirement that FESCo nominees be part of the packager group. Discussion indicated that: * technical issues (FPC reports, features) are approved by FESCo * membership in packager is not a large hurdle * there have yet to be anyone who has expressed interest in running that * would need this exception, even in the mail thread that spawned this The issue is open for revisiting if conditions warrant and candidates arise that would require it. == Revert the recently published Flag policy == After a lot of discussion, FESCo voted 6-0 to: * revert/suspend the policy approved the prior week * have people look into the issues and gather data (requirements of * various locales, number of packages affected, etc.) * craft a policy based on further data, or decide that one is not * required at all Andreas Thienemann volunteered to gather data; Kevin Fenzi volunteered to assist as time permits. More volunteers welcome. == Meeting log == For more information, see the full meeting log at: http://bpepple.fedorapeople.org/fesco/FESCo-2009-05-22.html From rjones at redhat.com Fri May 22 19:04:46 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 22 May 2009 20:04:46 +0100 Subject: Broken dependencies in Fedora 12 Development - 2009-05-22 In-Reply-To: <20090522185628.20074.98140@faldor.intranet> References: <20090522185628.20074.98140@faldor.intranet> Message-ID: <20090522190446.GA4314@amd.home.annexia.org> On Fri, May 22, 2009 at 06:56:28PM -0000, Michael Schwendt wrote: > Your following packages in the repository suffer from broken dependencies: > > package: ocaml-lablgtk-2.12.0-2.fc11.i586 from dist-f12-build-current-i386 > unresolved deps: > ocaml(runtime) = 0:3.11.0 There's going to be quite a few of these until we get round to building the new packages. _If_ all goes well, it should happen over the weekend. If there are regressions in the OCaml compiler or bugs in other packages, we'll try our best, but can't promise anything. See earlier announcement about this: https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01691.html Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw From frankly3d at gmail.com Fri May 22 19:04:51 2009 From: frankly3d at gmail.com (Frank Murphy) Date: Fri, 22 May 2009 20:04:51 +0100 Subject: Package Maintainers Flags policy In-Reply-To: <870180fe0905180845j553c38d9k3865089ea9dc1505@mail.gmail.com> References: <20090518090953.5698908a@ohm.scrye.com> <870180fe0905180845j553c38d9k3865089ea9dc1505@mail.gmail.com> Message-ID: <4A16F753.9080808@gmail.com> Just some thoughts. I would ask people, take time for your answers. Go for a walk even. After Reading: https://www.redhat.com/archives/fedora-advisory-board/2009-May/msg00153.html 1: Has the flags policy, anything to do with RH becoming more prominent on the site? No problem with them becoming more prominent, they do sponsor a lot. If yes, say so, likewise no 2: Would our main Sponsor, suffer financially. As a result of inclusion of certain flags? 3: Would the fedora project survive, if there was no main sponsor? 4: What do our International Ambassadors feel on the ground? Does anyone outside the project give a toss. Frank From oget.fedora at gmail.com Fri May 22 19:15:40 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Fri, 22 May 2009 15:15:40 -0400 Subject: mono-2.4 and ppc64 status In-Reply-To: <49ECEACA.1060304@gmail.com> References: <49ECEACA.1060304@gmail.com> Message-ID: On Mon, Apr 20, 2009 at 5:36 PM, Toshio Kuratomi wrote: > Mono-2.4 has been built for ppc64 in F11 and devel. ?So people should be > able to start rebuilding packages to include ppc64 as well as the other > arches. ?There's a few wrinkles to watch out for: > > 1) Packages with dependencies will have to be built in dependency order. > ?For instance, a lot of packages depend on the gtk-sharp2 bindings and > those haven't been built yet. > > 2) Because of the imminent release of F11 we're in a freeze state. ?This > ?means getting dependencies into the Fedora11 buildroot will require > people to request tagging explicitly. ?This also means that if you > rebuild your package for F11 with ppc64 support and later you have to > get this package tagged into the release, all of the packages it depends > on will need to be tagged in as well (otherwise your ppc64 build will > have broken deps). > > With these in mind, I'd recommend people start rebuilding their mono > packages on ppc64 in the devel branch. ?Keep track of the dependency > chain you encounter. ?Then perform your builds in the Fedora 11 branch > as updates after the release. ?I'm not a mono-sig member, though, so if > you guys decide something else makes sense, just be sure to come up with > a plan so we don't release with a bunch of broken dependencies. > > -Toshio > > It has been a month. For some reason, gtk-sharp2 and gnome-sharp are not rebuilt with ppc64 support yet. We will only have a very limited time to rebuild all the depending packages for F-11. It would only take a few minutes to rebuild gtk-sharp2 and gnome-sharp for their maintainers. Why are these things left to the last minute? Orcan From notting at redhat.com Fri May 22 19:19:17 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 22 May 2009 15:19:17 -0400 Subject: I must be doing something seriously wrong... In-Reply-To: References: <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> <20090522143608.GC15667@nostromo.devel.redhat.com> Message-ID: <20090522191917.GC18436@nostromo.devel.redhat.com> Paul Wouters (paul at xelerance.com) said: >> I am not removing any choice from *you*. You are free to reference >> it as you see fit. > > But your crippling my tools. What tool is being crippled without flags? I'm interested to hear what we have that's using them in a good way. >>> /usr/lib64/openoffice.org/basis3.1/share/template/wizard/bitmap/taiwan.gif >>> /usr/share/texmf/omega/otp/otibet/tibadjusttsheg.otp >>> /usr/lib64/pango/1.6.0/modules/pango-tibetan-fc.so >>> >>> Today flags. tomorrow geography? Next week a language? Next year a culture? >> >> 1) The first is a picture of an island, it has no official designation > > In that sense, a flag is just "a mixture of colours", it has no official designation. If you're arguing that level of semantics, I'm not sure why we're bothering to continue to have discussions. > Funny how you did not comment to the part on DNSSEC keys of the Taiwan situation, > the one that actualy refers to me as a maintainer of dnssec-conf, and which > could be a real life scenario that goes beyond pictures of flags. As I said - it's a matter of trade-offs. I doubt that one would be worth it. Bill From inode0 at gmail.com Fri May 22 19:41:44 2009 From: inode0 at gmail.com (inode0) Date: Fri, 22 May 2009 14:41:44 -0500 Subject: FESCo Meeting Summary for 2009-05-22 In-Reply-To: <20090522190016.GB18436@nostromo.devel.redhat.com> References: <20090522190016.GB18436@nostromo.devel.redhat.com> Message-ID: On Fri, May 22, 2009 at 2:00 PM, Bill Nottingham wrote: > == FESCo should allow non packagers to be committee members == > > FESCo voted 5-0 (with three abstentions) to not change the current > requirement that FESCo nominees be part of the packager group. Discussion > indicated that: > > ? ?* technical issues (FPC reports, features) are approved by FESCo (1) To sit on FESCo good technical chops are important. > ? ?* membership in packager is not a large hurdle (2) The requirement of being in the packager group is not a large hurdle and proves little about a person's technical chops. > ? ?* there have yet to be anyone who has expressed interest in running that > ? ?* would need this exception, even in the mail thread that spawned this (3) No one has yet stepped up and attempted to run for an office he or she was not eligible to occupy. (1) + (2) + (3) = current policy makes sense to FESCo? John From notting at redhat.com Fri May 22 19:53:45 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 22 May 2009 15:53:45 -0400 Subject: FESCo Meeting Summary for 2009-05-22 In-Reply-To: References: <20090522190016.GB18436@nostromo.devel.redhat.com> Message-ID: <20090522195344.GA20448@nostromo.devel.redhat.com> inode0 (inode0 at gmail.com) said: > On Fri, May 22, 2009 at 2:00 PM, Bill Nottingham wrote: > > == FESCo should allow non packagers to be committee members == > > > > FESCo voted 5-0 (with three abstentions) to not change the current > > requirement that FESCo nominees be part of the packager group. Discussion > > indicated that: > > > > ? ?* technical issues (FPC reports, features) are approved by FESCo > > (1) To sit on FESCo good technical chops are important. > > > ? ?* membership in packager is not a large hurdle > > (2) The requirement of being in the packager group is not a large > hurdle and proves little about a person's technical chops. > > > ? ?* there have yet to be anyone who has expressed interest in running that > > ? ?* would need this exception, even in the mail thread that spawned this > > (3) No one has yet stepped up and attempted to run for an office he or > she was not eligible to occupy. > > (1) + (2) + (3) = current policy makes sense to FESCo? More that if you have the technical chops re (1) then (2) is not a significant additional hurdle. Bill From thomas.moschny at gmail.com Fri May 22 19:58:39 2009 From: thomas.moschny at gmail.com (Thomas Moschny) Date: Fri, 22 May 2009 21:58:39 +0200 Subject: (2/3) Broken dependencies in Fedora 12 Development - 2009-05-22 In-Reply-To: <20090522185705.20074.59118@faldor.intranet> References: <20090522185705.20074.59118@faldor.intranet> Message-ID: 2009/5/22 Michael Schwendt : > ? ?lmms-0.4.4-1.fc12.x86_64 ?requires ?lmms-vst = 0:0.4.4-1.fc12 This is false positive imho. lmms-vst can only be built on 32bit, and is thus explicitly named on the multilib whitelist. Guess you didn't take into account that list? - Thomas From mschwendt at gmail.com Fri May 22 20:13:24 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 22 May 2009 22:13:24 +0200 Subject: (2/3) Broken dependencies in Fedora 12 Development - 2009-05-22 In-Reply-To: References: <20090522185705.20074.59118@faldor.intranet> Message-ID: <20090522221324.5e1a67c1@faldor.intranet> On Fri, 22 May 2009 21:58:39 +0200, Thomas wrote: > 2009/5/22 Michael Schwendt: > > ? ?lmms-0.4.4-1.fc12.x86_64 ?requires ?lmms-vst = 0:0.4.4-1.fc12 > > This is false positive imho. lmms-vst can only be built on 32bit, and > is thus explicitly named on the multilib whitelist. > Guess you didn't take into account that list? > > - Thomas Yes, the repos inside koji are not mashed/multilib'ed, so if there are any strange reports, ignore them. Primarily I wanted to create early reports for packagers who just need to rebuild for changed SONAMEs, such as boost, icu, ... From awilliam at redhat.com Fri May 22 20:17:09 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 22 May 2009 13:17:09 -0700 Subject: Package Maintainers Flags policy In-Reply-To: <4A16F753.9080808@gmail.com> References: <20090518090953.5698908a@ohm.scrye.com> <870180fe0905180845j553c38d9k3865089ea9dc1505@mail.gmail.com> <4A16F753.9080808@gmail.com> Message-ID: <1243023429.16232.29.camel@adam.local.net> On Fri, 2009-05-22 at 20:04 +0100, Frank Murphy wrote: > 2: Would our main Sponsor, suffer financially. > As a result of inclusion of certain flags? As far as Red Hat is concerned, a complete "no flags" policy in Fedora would benefit Red Hat as it would save work removing flags from packages at the Red Hat stage. The policy previously approved by FESCo would not have helped Red Hat much, as Red Hat's policy is "no flags", and the previous FESCo policy was substantially different, so significant changes would still have been needed at the Red Hat level. However, Red Hat isn't going to take its ball and leave if Fedora doesn't approve a 'no flags' policy, it would just have to work a bit harder. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From inode0 at gmail.com Fri May 22 20:27:20 2009 From: inode0 at gmail.com (inode0) Date: Fri, 22 May 2009 15:27:20 -0500 Subject: FESCo election nominations now open In-Reply-To: References: <1242915966.4320.3.camel@localhost.localdomain> <4A157001.80107@fedoraproject.org> <1242919693.3029.83.camel@localhost.localdomain> <4A157592.9060704@fedoraproject.org> <20090521154403.GA10929@hansolo.jdub.homelinux.org> <20090521175153.GA11344@hansolo.jdub.homelinux.org> Message-ID: On Thu, May 21, 2009 at 4:23 PM, Andreas Thienemann wrote: > Fedora has always been (more or less) a meritocracy. Whoever does the > work, has the power to define the direction fedora is taking. This I believe is the hardest nut to crack with Fedora elections. The Fedora Board and FESCo and others think of themselves as being part of a meritocracy (at least that is my perception of what they think) but at the same time are trying to encourage more widespread democratic participation which naturally runs counter to perpetuating the meritocracy. Candidates actions historically speak volumes about them in Fedora elections as the few doing the electing know them. With wide open elections where voters do not know the candidates all sorts of new problems arise and the expectations and demands of naive voters seem to be a silly burden to the candidates. The same people are getting elected either way because the same people thus far self-nominate and voter participation remains low. I'm not sure what the perceived benefit was of making the election process more open, other than more open seems a good thing to us instinctively. John From andreas at bawue.net Fri May 22 20:27:48 2009 From: andreas at bawue.net (Andreas Thienemann) Date: Fri, 22 May 2009 22:27:48 +0200 (CEST) Subject: I must be doing something seriously wrong... In-Reply-To: References: <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> <1242934194.8848.202.camel@adam.local.net> <20090521203836.GB7210@nostromo.devel.redhat.com> <20090522145104.GA16138@nostromo.devel.redhat.com> Message-ID: Hi Kevin, On Fri, 22 May 2009, Kevin Kofler wrote: Du hattest doch eine schoene Liste von Programmen, die Flaggen enthalten. Hast Du die mal? Ich wuerde gerne mal zusammenstellen, wieviele Pakete denn betroffen sind? regards, andreas From paul at xelerance.com Fri May 22 20:31:59 2009 From: paul at xelerance.com (Paul Wouters) Date: Fri, 22 May 2009 16:31:59 -0400 (EDT) Subject: I must be doing something seriously wrong... In-Reply-To: <20090522191917.GC18436@nostromo.devel.redhat.com> References: <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> <20090522143608.GC15667@nostromo.devel.redhat.com> <20090522191917.GC18436@nostromo.devel.redhat.com> Message-ID: On Fri, 22 May 2009, Bill Nottingham wrote: >>> 1) The first is a picture of an island, it has no official designation >> >> In that sense, a flag is just "a mixture of colours", it has no official designation. > > If you're arguing that level of semantics, I'm not sure why we're bothering > to continue to have discussions. I am just refuting your arguments by using the same (imho flawed) reasoning. My point was that if you don't like my way of reasoning, you should not do it for your own arguments either. >> Funny how you did not comment to the part on DNSSEC keys of the Taiwan situation, >> the one that actualy refers to me as a maintainer of dnssec-conf, and which >> could be a real life scenario that goes beyond pictures of flags. > > As I said - it's a matter of trade-offs. I doubt that one would > be worth it. I am still not sure what you say here. "worth excluding their key" or "worth excluding from the no-taiwan/flags policy"? If the first, who is Fedora to overrule ICANN/IANA? Paul From sundaram at fedoraproject.org Fri May 22 20:33:26 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 23 May 2009 02:03:26 +0530 Subject: I must be doing something seriously wrong... In-Reply-To: References: <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> <1242934194.8848.202.camel@adam.local.net> <20090521203836.GB7210@nostromo.devel.redhat.com> <20090522145104.GA16138@nostromo.devel.redhat.com> Message-ID: <4A170C16.7070006@fedoraproject.org> On 05/23/2009 01:57 AM, Andreas Thienemann wrote: > Hi Kevin, > > On Fri, 22 May 2009, Kevin Kofler wrote: > > Du hattest doch eine schoene Liste von Programmen, die Flaggen enthalten. > > Hast Du die mal? Ich wuerde gerne mal zusammenstellen, wieviele Pakete > denn betroffen sind? Can you please stick to English? http://fedoraproject.org/wiki/Communicate/MailingListGuidelines#Use_the_common_language Rahul From awilliam at redhat.com Fri May 22 20:42:07 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 22 May 2009 13:42:07 -0700 Subject: I must be doing something seriously wrong... In-Reply-To: <4A170C16.7070006@fedoraproject.org> References: <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> <1242934194.8848.202.camel@adam.local.net> <20090521203836.GB7210@nostromo.devel.redhat.com> <20090522145104.GA16138@nostromo.devel.redhat.com> <4A170C16.7070006@fedoraproject.org> Message-ID: <1243024927.16232.30.camel@adam.local.net> On Sat, 2009-05-23 at 02:03 +0530, Rahul Sundaram wrote: > On 05/23/2009 01:57 AM, Andreas Thienemann wrote: > > Hi Kevin, > > > > On Fri, 22 May 2009, Kevin Kofler wrote: > > > > Du hattest doch eine schoene Liste von Programmen, die Flaggen enthalten. > > > > Hast Du die mal? Ich wuerde gerne mal zusammenstellen, wieviele Pakete > > denn betroffen sind? > > Can you please stick to English? > > http://fedoraproject.org/wiki/Communicate/MailingListGuidelines#Use_the_common_language I think he CC'ed the list unintentionally - note the personal salutation and the fact that both he and Kevin speak German. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From sanjay.ankur at gmail.com Fri May 22 20:48:50 2009 From: sanjay.ankur at gmail.com (Ankur Sinha) Date: Sat, 23 May 2009 02:18:50 +0530 Subject: FESCo election nominations now open In-Reply-To: References: <1242915966.4320.3.camel@localhost.localdomain> <4A157001.80107@fedoraproject.org> <1242919693.3029.83.camel@localhost.localdomain> <4A157592.9060704@fedoraproject.org> <20090521154403.GA10929@hansolo.jdub.homelinux.org> <20090521175153.GA11344@hansolo.jdub.homelinux.org> Message-ID: <1243025330.3304.17.camel@localhost.localdomain> On Fri, 2009-05-22 at 15:27 -0500, inode0 wrote: > On Thu, May 21, 2009 at 4:23 PM, Andreas Thienemann wrote: > > Fedora has always been (more or less) a meritocracy. Whoever does the > > work, has the power to define the direction fedora is taking. > > This I believe is the hardest nut to crack with Fedora elections. The > Fedora Board and FESCo and others think of themselves as being part of > a meritocracy (at least that is my perception of what they think) but > at the same time are trying to encourage more widespread democratic > participation which naturally runs counter to perpetuating the > meritocracy. > > Candidates actions historically speak volumes about them in Fedora > elections as the few doing the electing know them. With wide open > elections where voters do not know the candidates all sorts of new > problems arise and the expectations and demands of naive voters seem > to be a silly burden to the candidates. The same people are getting > elected either way because the same people thus far self-nominate and > voter participation remains low. > > I'm not sure what the perceived benefit was of making the election > process more open, other than more open seems a good thing to us > instinctively. > > John > +1 to that. Take me for example, I've been around for sometime and heave _HEARD_ all the candidates names somewhere or the other, and read their mails on the lists and maybe taken help from them sometime over the IRC etc. However, I agree with what John had written earlier.. "Well, letting a much broader segment of the Fedora community vote causes a disconnect with me. If they aren't "fit" to run for an open seat why are they "fit" to elect those who are?" I still don't think I'm fit to vote.. :| -- regards, Ankur From craftjml at gmail.com Fri May 22 20:48:53 2009 From: craftjml at gmail.com (Jud Craft) Date: Fri, 22 May 2009 15:48:53 -0500 Subject: FESCo election nominations now open In-Reply-To: References: <4A157001.80107@fedoraproject.org> <1242919693.3029.83.camel@localhost.localdomain> <4A157592.9060704@fedoraproject.org> <20090521154403.GA10929@hansolo.jdub.homelinux.org> <20090521175153.GA11344@hansolo.jdub.homelinux.org> Message-ID: <20d6441a0905221348g6ae613f4ka7fba9ac1bcf3521@mail.gmail.com> On Fri, May 22, 2009 at 3:27 PM, inode0 wrote: > On Thu, May 21, 2009 at 4:23 PM, Andreas Thienemann wrote: > > This I believe is the hardest nut to crack with Fedora elections. The > Fedora Board and FESCo and others think of themselves as being part of > a meritocracy (at least that is my perception of what they think) but > at the same time are trying to encourage more widespread democratic > participation which naturally runs counter to perpetuating the > meritocracy. > A meritocracy _is_, in a sense, a democracy, so voting limited to a meritocratic system is not "closed". Anyone has the right to participate and thus join the meritocracy -- unless you're implying that Fedora is preventing users from joining it (and I don't think you are). For those who do not have the knowledge, or do not have the time to contribute, by logical reasoning it follows that they deserve _less_ influence than those who do. I do not contribute to Fedora, so I do not expect to be given the same privileges of influence/decision making as someone who actually does -- e.g., a developer or contributor. To do otherwise would be presumptuous and audacious of me. Absolute democracy in society is based on the loose idea that everyone is a citizen -- therefore, everyone contributes to society and deserves a say. In this sense, you can limit Fedora voting to Fedora contributors, and the community is still a democracy. From adam.stokes at gmail.com Fri May 22 20:50:11 2009 From: adam.stokes at gmail.com (Adam Stokes) Date: Fri, 22 May 2009 16:50:11 -0400 Subject: Broken dependencies in Fedora 12 Development - 2009-05-22 In-Reply-To: <20090522185611.20074.98150@faldor.intranet> References: <20090522185611.20074.98150@faldor.intranet> Message-ID: On Fri, May 22, 2009 at 2:56 PM, Michael Schwendt wrote: > Your following packages in the repository suffer from broken dependencies: > > package: cas-0.14-10.fc12.noarch from dist-f12-build-current-ppc > ?unresolved deps: > ? ? crash > > Why is this happening? Last I checked there is crash available on ppc. -- ( adam stokes ) || ( adam.stokes at gmail.com ) From craftjml at gmail.com Fri May 22 20:51:50 2009 From: craftjml at gmail.com (Jud Craft) Date: Fri, 22 May 2009 15:51:50 -0500 Subject: FESCo election nominations now open In-Reply-To: <20d6441a0905221348g6ae613f4ka7fba9ac1bcf3521@mail.gmail.com> References: <1242919693.3029.83.camel@localhost.localdomain> <4A157592.9060704@fedoraproject.org> <20090521154403.GA10929@hansolo.jdub.homelinux.org> <20090521175153.GA11344@hansolo.jdub.homelinux.org> <20d6441a0905221348g6ae613f4ka7fba9ac1bcf3521@mail.gmail.com> Message-ID: <20d6441a0905221351t26db2c6dmb7e05c26a139694e@mail.gmail.com> Or, for a more concrete metaphor... All Americans have the right to vote. But Europeans who just pop in on vacation do not. Likewise, random internet denizens who just show up (even predictably and dedicatedly) and post mailing-list messages should have no special privilege to vote for Fedora's direction and leadership. A democracy is not open to everyone -- it merely defines equality _within_ a predefined group (of citizens, of community members, etc). From stickster at gmail.com Fri May 22 20:54:18 2009 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 22 May 2009 16:54:18 -0400 Subject: I must be doing something seriously wrong... In-Reply-To: <1243024927.16232.30.camel@adam.local.net> References: <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> <1242934194.8848.202.camel@adam.local.net> <20090521203836.GB7210@nostromo.devel.redhat.com> <20090522145104.GA16138@nostromo.devel.redhat.com> <4A170C16.7070006@fedoraproject.org> <1243024927.16232.30.camel@adam.local.net> Message-ID: <20090522205418.GB15605@localhost.localdomain> On Fri, May 22, 2009 at 01:42:07PM -0700, Adam Williamson wrote: > On Sat, 2009-05-23 at 02:03 +0530, Rahul Sundaram wrote: > > On 05/23/2009 01:57 AM, Andreas Thienemann wrote: > > > Hi Kevin, > > > > > > On Fri, 22 May 2009, Kevin Kofler wrote: > > > > > > Du hattest doch eine schoene Liste von Programmen, die Flaggen enthalten. > > > > > > Hast Du die mal? Ich wuerde gerne mal zusammenstellen, wieviele Pakete > > > denn betroffen sind? > > > > Can you please stick to English? > > > > http://fedoraproject.org/wiki/Communicate/MailingListGuidelines#Use_the_common_language > > I think he CC'ed the list unintentionally - note the personal salutation > and the fact that both he and Kevin speak German. Doing this without Google (pinky-swear), but I think Andreas noted that Kevin once had a list of programs that contained flags, asked if he still had it, and said he'd like to determine precisely how many packages were affected by the policy. How'd I do? /me gets in the only piece of studying German he's likely to fit in before LinuxTag, and apologizes once again to his German friends for mangling their native tongue -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From mschwendt at gmail.com Fri May 22 20:56:18 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 22 May 2009 22:56:18 +0200 Subject: Broken dependencies in Fedora 12 Development - 2009-05-22 In-Reply-To: References: <20090522185611.20074.98150@faldor.intranet> Message-ID: <20090522225618.54ed97a5@faldor.intranet> On Fri, 22 May 2009 16:50:11 -0400, Adam wrote: > On Fri, May 22, 2009 at 2:56 PM, Michael Schwendt wrote: > > Your following packages in the repository suffer from broken dependencies: > > > > package: cas-0.14-10.fc12.noarch from dist-f12-build-current-ppc > > ?unresolved deps: > > ? ? crash > > > > > Why is this happening? Last I checked there is crash available on ppc. Only the ppc64 build (via multilib). There is no ppc build of it directly in the un"mash"ed repo inside koji. http://koji.fedoraproject.org/koji/buildinfo?buildID=84905 From andreas at bawue.net Fri May 22 21:03:19 2009 From: andreas at bawue.net (Andreas Thienemann) Date: Fri, 22 May 2009 23:03:19 +0200 (CEST) Subject: I must be doing something seriously wrong... In-Reply-To: <20090522205418.GB15605@localhost.localdomain> References: <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> <1242934194.8848.202.camel@adam.local.net> <20090521203836.GB7210@nostromo.devel.redhat.com> <20090522145104.GA16138@nostromo.devel.redhat.com> <4A170C16.7070006@fedoraproject.org> <1243024927.16232.30.camel@adam.local.net> <20090522205418.GB15605@localhost.localdomain> Message-ID: On Fri, 22 May 2009, Paul W. Frields wrote: > Doing this without Google (pinky-swear), but I think Andreas noted > that Kevin once had a list of programs that contained flags, asked if > he still had it, and said he'd like to determine precisely how many > packages were affected by the policy. Yeah, sounds about right. After all, I'm just doing my Fesco homework. :D > How'd I do? You're doing great. And if anyone wonders, Reply-To is considered harmful. > /me gets in the only piece of studying German he's likely to fit in > before LinuxTag, and apologizes once again to his German friends for > mangling their native tongue Okay, for Linuxtag and FudCon we should be doing a language course like FudCon Brno offered. And I'll explain the "Beautiful thing at the beach" in person. :) regards, andreas From makowski.fedora at gmail.com Fri May 22 21:06:51 2009 From: makowski.fedora at gmail.com (philippe makowski) Date: Fri, 22 May 2009 23:06:51 +0200 Subject: (1/3) Broken dependencies in Fedora 12 Development - 2009-05-22 In-Reply-To: <20090522185703.20074.55314@faldor.intranet> References: <20090522185703.20074.55314@faldor.intranet> Message-ID: 2009/5/22 Michael Schwendt : > ? ?makowski.fedora AT gmail com > ? ? ? ?firebird > ? ? ? ?python-kinterbasdb for firebird, I'm working on a patch hope to find the solution From notting at redhat.com Fri May 22 21:35:52 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 22 May 2009 17:35:52 -0400 Subject: I must be doing somthing seriously wrong... In-Reply-To: <20090521113119.GA9316@hansolo.jdub.homelinux.org> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> Message-ID: <20090522213552.GB20448@nostromo.devel.redhat.com> Josh Boyer (jwboyer at gmail.com) said: > >meeting minutes? If 8 out of 21 summaries are missing, IMHO this is a > >fact worth mentioning. > > They are missing because the minutes are done by FESCo members themselves and > we are humans. That isn't to say that the minutes aren't important, but that > people make mistakes and are busy and at times, things get missed. The IRC > logs for almost all the meetings should be available though. > > Earlier in the year we tried a rotation of minutes takers to alleviate the > burden on one person, but that seems to have failed. If someone wanted to > volunteer to be the FESCo secretary, I'm sure we would welcome that. The missing summaries and logs should be corrected now. Bill From notting at redhat.com Fri May 22 21:37:14 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 22 May 2009 17:37:14 -0400 Subject: I must be doing something seriously wrong... In-Reply-To: References: <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> <20090522143608.GC15667@nostromo.devel.redhat.com> <20090522191917.GC18436@nostromo.devel.redhat.com> Message-ID: <20090522213713.GC20448@nostromo.devel.redhat.com> Paul Wouters (paul at xelerance.com) said: >>> Funny how you did not comment to the part on DNSSEC keys of the Taiwan situation, >>> the one that actualy refers to me as a maintainer of dnssec-conf, and which >>> could be a real life scenario that goes beyond pictures of flags. >> >> As I said - it's a matter of trade-offs. I doubt that one would >> be worth it. > > I am still not sure what you say here. "worth excluding their key" or "worth > excluding from the no-taiwan/flags policy"? I doubt it would be worth disabling DNSSEC because of a single country's actions (assuming no legal liability.) Bill From paul at xelerance.com Fri May 22 21:44:16 2009 From: paul at xelerance.com (Paul Wouters) Date: Fri, 22 May 2009 17:44:16 -0400 (EDT) Subject: I must be doing something seriously wrong... In-Reply-To: <20090522213713.GC20448@nostromo.devel.redhat.com> References: <1242921797.3029.84.camel@localhost.localdomain> <1242922308.8758.14.camel@localhost.localdomain> <1242924184.3029.96.camel@localhost.localdomain> <1242930985.8848.188.camel@adam.local.net> <20090521185342.GA6176@nostromo.devel.redhat.com> <20090522143608.GC15667@nostromo.devel.redhat.com> <20090522191917.GC18436@nostromo.devel.redhat.com> <20090522213713.GC20448@nostromo.devel.redhat.com> Message-ID: On Fri, 22 May 2009, Bill Nottingham wrote: >>> As I said - it's a matter of trade-offs. I doubt that one would >>> be worth it. >> >> I am still not sure what you say here. "worth excluding their key" or "worth >> excluding from the no-taiwan/flags policy"? > > I doubt it would be worth disabling DNSSEC because of a single country's > actions (assuming no legal liability.) I was talking about not shipping a TLD key for .tw. We would never disable DNSEC globally. Paul From kevin.kofler at chello.at Sat May 23 02:34:58 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 23 May 2009 04:34:58 +0200 Subject: List of packages including country flags Message-ID: OK, let's all collect the list. These have already come up: - kdebase-runtime (currently in a -flags subpackage, used at least 1. by the keyboard layout switcher to represent a keyboard layout and 2. when selecting the locale in System Settings to represent a country) - deluge (currently getting ripped out because that was requested in a bug) - gcompris - freeciv - xfce4-xkb-plugin - ktorrent (same use as deluge, for geolocation of peers) Icon themes, containing at least one flag (UN or other) to represent the locale preferences (and I didn't check if there are other icons containing flags): - gnome-icon-theme (UN) - bluecurve-icon-theme (3 countries, overlayed into a single icon) - oxygen-icon-theme (UN) - crystalsvg-icon-theme (2 countries, overlayed into a single icon) Other KDE packages (yes, KDE ships multiple copies of flags, in slightly different formats (PNG vs. SVG, sizes)): - kdeedu (kgeography, that's the "geography learning app" I alluded to, the flags are part of the information about countries it shows) - kdeedu-marble (flags are shown in the properties for a place) - kdegames (ksirk) (similar to FreeCiv in principle: the flags are used to represent players, who choose a given nation; note that this game is extra "fun" for the "politically correct" folks because it contains a map of Earth with territories not quite matching actual country borders, see the screenshot at http://www.kde-apps.org/content/preview.php?preview=1&id=21450&file1=21450-1.png&file2=21450-2.png&file3=&name=KsirK to get an idea) - kde-plasma-translatoid (currently getting ripped out because the flags were noticed and frowned upon during review, uses flags for languages) That's 14 packages, and I'm sure there are more (if you know of any others, feel free to reply). Kevin Kofler From kevin.kofler at chello.at Sat May 23 02:41:51 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 23 May 2009 04:41:51 +0200 Subject: List of packages including country flags References: Message-ID: Oh, and while not technically flags, freecol includes historical stems (decorated shields) of 4 European countries. Kevin Kofler From christoph.wickert at googlemail.com Sat May 23 02:48:24 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Sat, 23 May 2009 04:48:24 +0200 Subject: List of packages including country flags In-Reply-To: References: Message-ID: <1243046904.3033.1.camel@localhost.localdomain> Am Samstag, den 23.05.2009, 04:34 +0200 schrieb Kevin Kofler: > OK, let's all collect the list. > [..] > > That's 14 packages, and I'm sure there are more (if you know of any others, > feel free to reply). Openttd, currently under review: https://bugzilla.redhat.com/show_bug.cgi?id=491518 Christoph From gmaxwell at gmail.com Sat May 23 03:32:21 2009 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Fri, 22 May 2009 23:32:21 -0400 Subject: List of packages including country flags In-Reply-To: References: Message-ID: On Fri, May 22, 2009 at 10:34 PM, Kevin Kofler wrote: > OK, let's all collect the list. > > These have already come up: > - kdebase-runtime (currently in a -flags subpackage, used at least 1. by the > keyboard layout switcher to represent a keyboard layout The patch removing the flags from that should be sent upstream too? countries and languages/keymaps are not a bijection. From icon at fedoraproject.org Sat May 23 03:39:20 2009 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Fri, 22 May 2009 23:39:20 -0400 Subject: List of packages including country flags In-Reply-To: References: Message-ID: On Fri, May 22, 2009 at 10:34 PM, Kevin Kofler wrote: > - freeciv Oh, come on. Freeciv lists flags of countries that have actually existed but don't any more (Babylonians, Persians), never existed but might some day (Antarctica, Quebec), and never existed and never will (Martians). Removing the flags from the game will make the game pointless and unplayable. Come on, we can do better than police games. They are *supposed* to be fictitious! I can play for Soviets and invade the US, how's that for historical or political correctness? :) Regards, -- Konstantin Ryabitsev Montr?al, Qu?bec From a.badger at gmail.com Sat May 23 04:33:43 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 22 May 2009 21:33:43 -0700 Subject: List of packages including country flags In-Reply-To: References: Message-ID: <4A177CA7.9030309@gmail.com> On 05/22/2009 07:34 PM, Kevin Kofler wrote: > OK, let's all collect the list. > > These have already come up: > - kdebase-runtime (currently in a -flags subpackage, used at least 1. by the > keyboard layout switcher to represent a keyboard layout and 2. when > selecting the locale in System Settings to represent a country) > - deluge (currently getting ripped out because that was requested in a bug) > - gcompris > - freeciv > - xfce4-xkb-plugin > - ktorrent (same use as deluge, for geolocation of peers) > netpanzer (marks units as belonging to a player but no historical significance) Probably a better way to do this is to get a list of all the files in the distribution and look through that for image files that could be flags. -Toshio From kevin.kofler at chello.at Sat May 23 04:42:56 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 23 May 2009 06:42:56 +0200 Subject: List of packages including country flags References: Message-ID: Konstantin Ryabitsev wrote: > Oh, come on. Freeciv lists flags of countries that have actually > existed but don't any more (Babylonians, Persians), never existed but > might some day (Antarctica, Quebec), and never existed and never will > (Martians). Removing the flags from the game will make the game > pointless and unplayable. > > Come on, we can do better than police games. That's kinda (part of) my point. I'm not the one who wants to burn all flags, quite the opposite (I find even this subpackage idea to be too restrictive and completely pointless). Kevin Kofler From kevin.kofler at chello.at Sat May 23 04:46:11 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 23 May 2009 06:46:11 +0200 Subject: List of packages including country flags References: Message-ID: Gregory Maxwell wrote: > The patch removing the flags from [kdebase-runtime] should be sent > upstream too? It's not a patch, it's putting the flags into a subpackage (or before, running rm) so they are just not there. It's completely the wrong fix, entirely not upstreamable. It removes the common copy of flags which means they're also missing where they make more sense, e.g. for the locale selection (which is per country). Not to mention that I'm not convinced there's a problem to be fixed there at all. > countries and languages/keymaps are not a bijection. It's close enough. Many users expect country flags to be used in this place, just use a search engine to find the many complaints in forums, bugzilla etc. about those flags being missing in Fedora. (Also note that keymaps != languages, they're actually closer to being per country than per language.) And using flags there is already optional! We can easily tweak kde-settings so the default is to show only the 2-letter code for the layout by default. That doesn't require removing the flags altogether (which is highly confusing for the user because checking the box to show them has no effect, and it also means the flags are missing in other places). So no, removing the flags entirely is not upstreamable, and will also be rejected by upstream (they explicitly decided not to ban flags from KDE). At most, changing the default for the keyboard layout chooser from showing the flag (in addition to the name) to just showing the name may be upstreamable, but even there you have to expect some resistance. No matter how technically inaccurate they may be, users are asking for the flags in the keyboard chooser! Kevin Kofler From kevin.kofler at chello.at Sat May 23 05:02:35 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 23 May 2009 07:02:35 +0200 Subject: List of packages including country flags References: <4A177CA7.9030309@gmail.com> Message-ID: Christoph Wickert wrote: > Openttd, currently under review: > https://bugzilla.redhat.com/show_bug.cgi?id=491518 Toshio Kuratomi wrote: > netpanzer (marks units as belonging to a player but no historical > significance) With those 2, we're now at 16 packages including flags and 1 including historical stems/shields. This already exceeds the "4 or 5 packages" estimate by a factor of 3 to 4. And no systematic search was even done. Censoring flags means censoring a lot of packages and breaking some of them entirely. It is not a trivial issue at all. Note that I have yet to see an icon for preferences-desktop-locale which doesn't use one or more flags. Echo uses a "generic" all-blue flag, but this is fairly close to some real flags (e.g. the UN flag is blue with some logo on it, the Somali flag is blue with a white star on it, the city of Nitra in Slovakia uses a solid blue flag with a swallowtail form (flagid.org found that one for me)) and there are also plenty of possible political etc. interpretations for a solid blue flag. I don't think a "generic" flag is any less of a problem there than a UN flag. Kevin Kofler From Fedora at FamilleCollet.com Sat May 23 05:12:27 2009 From: Fedora at FamilleCollet.com (Remi Collet) Date: Sat, 23 May 2009 07:12:27 +0200 Subject: List of packages including country flags In-Reply-To: References: Message-ID: <4A1785BB.1000004@FamilleCollet.com> Le 23/05/2009 04:34, Kevin Kofler a ?crit : > OK, let's all collect the list. ocsinventory use flags for locale selection. Patch is ready, I'm just waiting for upstream feedback. + From james at fedoraproject.org Sat May 23 05:23:55 2009 From: james at fedoraproject.org (James Antill) Date: Sat, 23 May 2009 01:23:55 -0400 Subject: Multilib/multiarch debuginfo In-Reply-To: <20090417181901.611A1FC35F@magilla.sf.frob.com> References: <1239887581.23619.5.camel@politzer.theorphys.helsinki.fi> <20090416203646.4AC47FC3C6@magilla.sf.frob.com> <1239917677.9867.0.camel@localhost.localdomain> <20090416220032.D55B3FC3C6@magilla.sf.frob.com> <1239977430.9658.16.camel@code.and.org> <20090417181901.611A1FC35F@magilla.sf.frob.com> Message-ID: <1243056235.7264.2254.camel@code.and.org> On Fri, 2009-04-17 at 11:19 -0700, Roland McGrath wrote: > > A few of the yum-utils commands take a --archlist, repoquery and > > yumdownloader both do for instance. This is more for looking at data on > > ppc from an i386 box, as i386 is already in the archlist for x86_64. > ^^^ > > You meant x86_64 here, I think. I noticed that switch and noticed that it > didn't help for this case. No, I meant ppc. Normally yum would see ppc packages, when on an x86_64 machine and "know" that it can't use them ... so will auto exclude them. --archlist changes that. > > And that doesn't change what $basearch will be in the config. files > > because doing that is a really bad idea due to the fact that you'll have > > changed what /var/cache/yum/blah/ points to without the next run of yum > > knowing (it's a bad idea to have the same repoid point to more than one > > place). > > Right, I figured that would be the gotcha with what I had in mind. > Maybe it would make sense for yum to name its cache subdirs repo.basearch? > > > So what you probably want is to create a blah-i386 to go with your > > normal blah repo. ... which hardcodes i386 as the arch. Leave it > > disabled, and then whever you want to use it do: > > It seems like a simple enough change to use basearch in the cache dir > names. Then everyone could do this for all the repos without fiddling with > repo configs. Does that seem like something yum could do in the future? > (I'm not asking for any of this to be done next week or anything.) > > Maybe also --repoid et al could grok "reponame.arch" syntax (akin to the > package "name.arch" syntax you can use). Another way to state it is that > the full "repoid" would be "reponame.arch", and "reponame" alone turns into > "reponame.$basearch" implicitly. We've recently changed upstream yum so that the base cachedir can contain variables. Ie. instead of: cachedir = /var/cache/yum ...you can do: cachedir = /var/cache/yum/$basearch/$releasever ...this solves a couple of problems over using the repo.arch syntax. Having a command line option to change arch/releasever is another challenge, for a couple of reasons. Although x86_64 => i386 there is an easy way, as you can (after the above change) do: setarch i386 yum blah ...and it'll have it's own cachedir. -- James Antill Fedora From gmaxwell at gmail.com Sat May 23 05:28:30 2009 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Sat, 23 May 2009 01:28:30 -0400 Subject: List of packages including country flags In-Reply-To: References: Message-ID: On Sat, May 23, 2009 at 12:46 AM, Kevin Kofler wrote: >> countries and languages/keymaps are not a bijection. > > It's close enough. Many users expect country flags to be used in this place, > just use a search engine to find the many complaints in forums, bugzilla > etc. about those flags being missing in Fedora. (Also note that keymaps != > languages, they're actually closer to being per country than per language.) They aren't really per-country either. To be most accurate I would say are per-language with occasional national variants. There are quite a few cases where the implication that a language belongs to a particular country (or a country has a particular 'right' language) is highly offensive. It's simply not right, and it's highly insensitive to the social realities in some parts of the world. It smacks of the sort of multi-cultural ignorance that Americans are widely credited with? [snip] > So no, removing the flags entirely is not upstreamable, and will also be > rejected by upstream (they explicitly decided not to ban flags from KDE). Have a citation for that? Specifically for a refusal to stop conflating keymaps and languages with national flags? (An complete cessation of flag use is a more general issue, and I wouldn't be surprised to see KDE refuse to stop using flags to identify countries? laws and politics be-damned) [And yes, I follow now that this change itself isn't upstreamable; but there is nothing wrong with getting upstream to fix that part that is actually broken even if fedora has a need to go further] From mailings at x-tnd.be Sat May 23 06:47:03 2009 From: mailings at x-tnd.be (Johan Cwiklinski) Date: Sat, 23 May 2009 08:47:03 +0200 Subject: List of packages including country flags In-Reply-To: References: Message-ID: <4A179BE7.7010507@x-tnd.be> Le 23/05/2009 04:34, Kevin Kofler a ?crit : > [...] > - gcompris > [...] > For this one, flags are used to select current language (at least, I do not know all the proposed games, I'll have to ask upstream if flags are/will be used elsewhere). gcompris is an educationnal software, for 2 years old and more children. Flags usage to select language is not exactly part of the educational side the soft, but it's also part of it (think that a two years old child may "prefer" choosing his language according to the flag, not to the text). Considering this, I'm not sure simply removing flags for gcompris is the thing to do. Any thoughts ? At last, my question is quite simple : what should I do ? Remove flags, put them into a subpackage, or let them as it ? Regards, Johan From iarnell at gmail.com Sat May 23 06:55:30 2009 From: iarnell at gmail.com (Iain Arnell) Date: Sat, 23 May 2009 08:55:30 +0200 Subject: List of packages including country flags In-Reply-To: References: Message-ID: <81487f820905222355o71a58ea4o4a5460525ec89d1d@mail.gmail.com> On Sat, May 23, 2009 at 4:34 AM, Kevin Kofler wrote: [snip] > That's 14 packages, and I'm sure there are more (if you know of any others, > feel free to reply). perl-Lingua-Flags, currently up for review. https://bugzilla.redhat.com/show_bug.cgi?id=502054 But it doesn't actually use the flags - just makes them available for other modules to use - though they are both technically and substantively essential to this package. -- Iain. From atorkhov at gmail.com Sat May 23 07:53:31 2009 From: atorkhov at gmail.com (Alexey Torkhov) Date: Sat, 23 May 2009 11:53:31 +0400 Subject: List of packages including country flags In-Reply-To: References: Message-ID: <1243065211.19974.12.camel@localhost.localdomain> On Sat, 2009-05-23 at 04:34 +0200, Kevin Kofler wrote: > That's 14 packages, and I'm sure there are more (if you know of any others, > feel free to reply). Two more games that use flags: - bygfoot. For this one, flags are most certainly essential - I can?t imagine how to manage a football command without seeing, for example, Brazil flag. - springlobby. It shows user country/location with flag. Regards, Alexey From martin.sourada at gmail.com Sat May 23 08:35:37 2009 From: martin.sourada at gmail.com (Martin Sourada) Date: Sat, 23 May 2009 10:35:37 +0200 Subject: Long term Flags handling suggestion Message-ID: <1243067737.4197.9.camel@pc-notebook.kolej.mff.cuni.cz> Hi, I don't want to start another flame, but I thought that the proper way to handle flags - if we want to make them optional and not to ban them completely - would be to provide them via icon themes. They are mentioned in the icon-naming-specs [1]. Why long term solution? Because there are zillion country and other flags in the world and no icon theme I know of includes more than 3 flags... The basic idea behind this is that flag is an icon as well and as such should follow user selected icon theme's style. There's no point it 10 applications shipping their own sets of flags which each look different. Plus, having an icon theme -flags subpackages which would each Provide: icons-flags would make the installation for end user easier. Anyway, just my 2 cents, I don't understand the legal reasoning behind this guideline so my suggestion might be wrong as well... References: [1] http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From makowski.fedora at gmail.com Sat May 23 08:51:58 2009 From: makowski.fedora at gmail.com (philippe makowski) Date: Sat, 23 May 2009 10:51:58 +0200 Subject: (1/3) Broken dependencies in Fedora 12 Development - 2009-05-22 In-Reply-To: References: <20090522185703.20074.55314@faldor.intranet> Message-ID: 2009/5/22 philippe makowski : > 2009/5/22 Michael Schwendt : >> ? ?makowski.fedora AT gmail com >> ? ? ? ?firebird >> ? ? ? ?python-kinterbasdb > for firebird, I'm working on a patch > hope to find the solution > ok fixed for firebird Task Info: http://koji.fedoraproject.org/koji/taskinfo?taskID=1372064 Build Info: http://koji.fedoraproject.org/koji/buildinfo?buildID=103278 so it will be solved for python-kinterbasdb as soon as koji will take the new firebird package and not the old one From bochecha at fedoraproject.org Sat May 23 09:28:16 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Sat, 23 May 2009 11:28:16 +0200 Subject: Long term Flags handling suggestion In-Reply-To: <1243067737.4197.9.camel@pc-notebook.kolej.mff.cuni.cz> References: <1243067737.4197.9.camel@pc-notebook.kolej.mff.cuni.cz> Message-ID: <2d319b780905230228uc9a3d2ekb3c4a4e3f1076193@mail.gmail.com> On Sat, May 23, 2009 at 10:35, Martin Sourada wrote: > I don't want to start another flame, but I thought that the proper way > to handle flags - if we want to make them optional and not to ban them > completely - would be to provide them via icon themes. They are > mentioned in the icon-naming-specs [1]. > > Why long term solution? Because there are zillion country and other > flags in the world and no icon theme I know of includes more than 3 > flags... > > The basic idea behind this is that flag is an icon as well and as such > should follow user selected icon theme's style. There's no point it 10 > applications shipping their own sets of flags which each look different. > Plus, having an icon theme -flags subpackages which would each Provide: > icons-flags would make the installation for end user easier. Also, if you go to upstream and say ? flags are bad, I must remove them in Fedora, you should remove them too ?, they might not be very pleased. However, it could be far easier to ask them to stop bundling the flags and instead use them in an icon theme. So packagers would not have to patch upstream. Upstream would still have their flags. We could more easily make them optional. Sounds like a great idea to me :) Regards, ---------- Mathieu Bridon (bochecha) From rms at 1407.org Sat May 23 09:50:32 2009 From: rms at 1407.org (Rui Miguel Silva Seabra) Date: Sat, 23 May 2009 10:50:32 +0100 Subject: In which country should Fedora be legal? In-Reply-To: <20090519215536.GB4623@roque.1407.org> References: <20090519195838.GC4558@free.fr> <20090519215536.GB4623@roque.1407.org> Message-ID: <20090523095032.GC4757@roque.1407.org> On Tue, May 19, 2009 at 10:55:36PM +0100, Rui Miguel Silva Seabra wrote: > On Tue, May 19, 2009 at 09:58:38PM +0200, Patrice Dumas wrote: > > Hello, > > > > I think that the flag policy is the wrong way to look at a real issue. > > First, it tries to solve 2 issues > > 1. being legal in some countries > > It'll very likely become downright illegal in many countries in Europe > depending on Cibercrime implementations. I'm glad to report that the Portuguese law proposal[1] which was made by the Government (who holds absolute majority in the Parliament) is quite more sensible that it would be expected. There's a few problems with whether research is effectively forbidden in certain areas or not, but all things considered... it's not the disaster it could be (and was in some places). Rui From ewan at macmahon.me.uk Sat May 23 09:51:15 2009 From: ewan at macmahon.me.uk (Ewan Mac Mahon) Date: Sat, 23 May 2009 10:51:15 +0100 Subject: List of packages including country flags In-Reply-To: <4A179BE7.7010507@x-tnd.be> References: <4A179BE7.7010507@x-tnd.be> Message-ID: <20090523095114.GA29247@macmahon.me.uk> On Sat, May 23, 2009 at 08:47:03AM +0200, Johan Cwiklinski wrote: > Le 23/05/2009 04:34, Kevin Kofler a ?crit : > > [...] > > - gcompris > > [...] > > > > At last, my question is quite simple : what should I do ? Remove flags, > put them into a subpackage, or let them as it ? > For now you shouldn't need to do anything. Yesterday's FESCO meeting suspended the flags policy pending the collection of more data, and a review. It might be useful to consider what effect stipping the flags would have on the package, and posting that somewhere for FESCO's consideration. Possibly there should be a tracker ticket to collect this sort of data on? Ewan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jamatos at fc.up.pt Sat May 23 09:53:04 2009 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Sat, 23 May 2009 10:53:04 +0100 Subject: List of packages including country flags In-Reply-To: References: Message-ID: <200905231053.04847.jamatos@fc.up.pt> On Saturday 23 May 2009 04:39:20 Konstantin Ryabitsev wrote: > and never existed and never will (Martians) I find this remark highly questionable and even offensive. It seems that you have learn nothing from "Babylon 5". ;-) -- Jos? Ab?lio From laxathom at fedoraproject.org Sat May 23 10:06:35 2009 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Sat, 23 May 2009 12:06:35 +0200 Subject: mono-2.4 and ppc64 status In-Reply-To: <49ECEACA.1060304@gmail.com> References: <49ECEACA.1060304@gmail.com> Message-ID: <62bc09df0905230306wf18ad0fy1b82d70260ee673f@mail.gmail.com> On Mon, Apr 20, 2009 at 11:36 PM, Toshio Kuratomi wrote: > Mono-2.4 has been built for ppc64 in F11 and devel. ?So people should be > able to start rebuilding packages to include ppc64 as well as the other > arches. ?There's a few wrinkles to watch out for: > > 1) Packages with dependencies will have to be built in dependency order. > ?For instance, a lot of packages depend on the gtk-sharp2 bindings and > those haven't been built yet. > > 2) Because of the imminent release of F11 we're in a freeze state. ?This > ?means getting dependencies into the Fedora11 buildroot will require > people to request tagging explicitly. ?This also means that if you > rebuild your package for F11 with ppc64 support and later you have to > get this package tagged into the release, all of the packages it depends > on will need to be tagged in as well (otherwise your ppc64 build will > have broken deps). > > With these in mind, I'd recommend people start rebuilding their mono > packages on ppc64 in the devel branch. ?Keep track of the dependency > chain you encounter. ?Then perform your builds in the Fedora 11 branch > as updates after the release. ?I'm not a mono-sig member, though, so if > you guys decide something else makes sense, just be sure to come up with > a plan so we don't release with a bunch of broken dependencies. > > -Toshio > gtk-sharp2 has been built for ppc64 and tag has been requested. other packages will be rebuild once gtk-sharp2 tagged. -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB From mschwendt at gmail.com Sat May 23 10:37:35 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sat, 23 May 2009 12:37:35 +0200 Subject: Conflicts not being resolved Message-ID: <20090523123735.009ddf62@faldor.intranet> https://fedoraproject.org/wiki/Packaging/Conflicts https://fedoraproject.org/wiki/Packaging/Conflicts#Other_Uses_of_Conflicts: | As a general rule, Fedora packages must NOT contain any usage of the | Conflicts: field. | Keep in mind that implicit conflicts are NEVER acceptable. | If your package conflicts with another package, then you must either | resolve the conflict, or mark it with Conflicts:. What happens so far is that packagers simply ignore it. Again I see bz tickets from Nov 2008 which have not been responded to. The page doesn't point out that missing "Conflicts" tags are bad. Implicit conflicts are not detected prior to an RPM transaction check. Typically, implicit conflicts cause tools like Yum to fail, leaving it to the user to do the head-scratching and to remove packages manually. From rjones at redhat.com Sat May 23 12:06:41 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Sat, 23 May 2009 13:06:41 +0100 Subject: Broken dependencies in Fedora 12 Development - 2009-05-22 In-Reply-To: <20090522190446.GA4314@amd.home.annexia.org> References: <20090522185628.20074.98140@faldor.intranet> <20090522190446.GA4314@amd.home.annexia.org> Message-ID: <20090523120641.GA7635@amd.home.annexia.org> On Fri, May 22, 2009 at 08:04:46PM +0100, Richard W.M. Jones wrote: > On Fri, May 22, 2009 at 06:56:28PM -0000, Michael Schwendt wrote: > > Your following packages in the repository suffer from broken dependencies: > > > > package: ocaml-lablgtk-2.12.0-2.fc11.i586 from dist-f12-build-current-i386 > > unresolved deps: > > ocaml(runtime) = 0:3.11.0 > > There's going to be quite a few of these until we get round to > building the new packages. _If_ all goes well, it should happen over > the weekend. If there are regressions in the OCaml compiler or bugs > in other packages, we'll try our best, but can't promise anything. > > See earlier announcement about this: > > https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01691.html Update: I've built (roughly) 60 out of the (roughly) 75 packages. Three packages have upstream problems, one of which is now fixed, still waiting on the other two. The other packages are waiting for previous build requirements to settle down in dist-f12. In general there doesn't seem to be any major problem with the new OCaml compiler, so that's good news! Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html From nicolas.mailhot at laposte.net Sat May 23 12:28:15 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 23 May 2009 14:28:15 +0200 Subject: FESCo Meeting Summary for 2009-05-22 In-Reply-To: <20090522195344.GA20448@nostromo.devel.redhat.com> References: <20090522190016.GB18436@nostromo.devel.redhat.com> <20090522195344.GA20448@nostromo.devel.redhat.com> Message-ID: <1243081695.21508.4.camel@arekh.okg> Le vendredi 22 mai 2009 ? 15:53 -0400, Bill Nottingham a ?crit : > inode0 (inode0 at gmail.com) said: > > On Fri, May 22, 2009 at 2:00 PM, Bill Nottingham wrote: > > > * membership in packager is not a large hurdle > > > > (2) The requirement of being in the packager group is not a large > > hurdle and proves little about a person's technical chops. > More that if you have the technical chops re (1) then (2) is not > a significant additional hurdle. I have and will continue to sponsor anyone who packages two or three fonts. This is basically a "can read technical packaging guidelines" test (had to raise the bar from one package to several since it was getting too trivial with guideline simplifications) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jwboyer at gmail.com Sat May 23 13:52:49 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Sat, 23 May 2009 09:52:49 -0400 Subject: I must be doing something seriously wrong... In-Reply-To: <1242938158.2974.17.camel@localhost.localdomain> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <20090521124654.GB10004@hansolo.jdub.homelinux.org> <1242922282.8758.13.camel@localhost.localdomain> <20090521170723.GA11191@hansolo.jdub.homelinux.org> <1242938158.2974.17.camel@localhost.localdomain> Message-ID: <20090523135249.GA32053@hansolo.jdub.homelinux.org> On Thu, May 21, 2009 at 10:35:58PM +0200, Christoph Wickert wrote: >Am Donnerstag, den 21.05.2009, 13:07 -0400 schrieb Josh Boyer: >> On Thu, May 21, 2009 at 06:11:22PM +0200, Christoph Wickert wrote: >> >Am Donnerstag, den 21.05.2009, 08:46 -0400 schrieb Josh Boyer: >> >> On Thu, May 21, 2009 at 02:20:52PM +0200, Christoph Wickert wrote: >> >> [snipped] >> >> >> >> >privileges, so one should also pull his duties. If not, IMHO the person >> >> >is not qualified for FESCo, simple as that. (Sorry if this sounds harsh) >> >> >> >> It doesn't sound particularly harsh, but I wonder what privileges you think >> >> you get when you are in FESCo? >> > >> >As a FESCo member you are to decide over the direction that Fedora >> >takes, this is the biggest privilege I can think of inside a FOSS >> >project. >> >> 1) Yes, I do consider that a privilege. It is also a burden :) >> >> 2) Mostly we vote on policies and proposals and Features that the fedora >> contributors submit. So while FESCo approves those, the direction that Fedora >> takes is almost entirely driven by those submissions. > >Correct me if I'm wrong: A good number of proposals are made by people >who are also in FESCo, right? No. >Also I've got a notion that FESCo recently approves more and more >proposals without asking the community for opinions first and even in >opposition to the community. I can't recall that being the case. There certainly may have been some proposals that were opened during the week that were discussed on that Friday, but we aren't creating secret proposals and voting on them. All of them come directly from contributors (usually via fedora-devel discussions) and are logged in the open fesco trac instance for the meetings. > >> >I think Toshio already uttered similar concerns, so FESCo should have >> >dealt with them *before* ratifying the policy. Looking at the IRC log I >> >see there was *zero* discussion but only +1s. (This is how I'd expect a >> >vote in the Communist Party of China but not in Fedora - SCNR) >> >> Quite possibly, yes. >> >> >> >I do think it is relevant. The policy deals with religious flags, but it >> >> >does not deal with religions symbols. I could draw a square around >> >> >symbol and call it a flag. >> >> >> >> And I could remove a square from the flag and call it a symbol. Discussing >> >> theoreticals at this point is only going to lead us to more and more absurd >> >> cases. I don't think we're here to draft policies that cover every possible >> >> situation whether it will ever happen in real life or not. >> > >> >I know I'm just to negative sometimes. I think we always need to be >> >prepared for worst case scenarios, which also includes theoretical >> >questions. Others say that this or that will never happen because we are >> >all in the same boat, but I think history has proven different. >> >> It's a prudent approach. I find that preparing for the worst case scenario can >> often lead to an entirely sub-optimal normal case scenario though. A balance >> needs to be achieved. > >Agreed, but IMO this balance is missing in this case. Most likely we >have a different POV here. > >> >> The original question was about advertising to the users. So how do we >> >> advertise -docs packages to users, and why isn't that sufficient for -flags? >> > >> >I still think you put it wrong because IMO you are comparing apples and >> >oranges. >> > 1. In a perfect world (TM) there is no need for docs because >> > everything is self self-explanatory. >> >> In a perfect world, there is no need for flags because humanity is united and >> we have reached utopia. We don't live in a perfect world. > >Even in the Star Trek universe there are still flags ;) I'm done debating anything that starts with 'in a perfect world' because we don't live in a perfect world and I hardly think that the Star Trek universe would qualify as one either. >> > 2. At least users *should* not need docs at least none that are not >> > installed by default. Our -docs packages are mostly targeted at >> > developers and system administrators. >> >> And our flags packages would be targeted at whom? > >Users in free countries. > >> > 3. If someone really needs docs, he will realize this himself, >> > because he is missing knowledge. For flags he doesn't. How is a >> > deluge user supposed the realize the lack of a function? >> >> Deluge is clearly spelled out in the guideline as not needing flags for >> functionality. Is that statement incorrect? > >Please note the difference between "a function" and "functionality". Of >course the missing flags do not impact the basic function of deluge >which is sharing files, but there is certain functionality missing. >People can no longer see the location of their peers on a quick glance >and have to read instead. I don't find that concerning. Maybe it will help literacy. josh From rawhide at fedoraproject.org Sat May 23 14:19:54 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Sat, 23 May 2009 14:19:54 +0000 (UTC) Subject: rawhide report: 20090523 changes Message-ID: <20090523141954.2494F1F820F@releng2.fedora.phx.redhat.com> Compose started at Sat May 23 06:15:04 UTC 2009 Updated Packages: alsa-utils-1.0.20-3.fc11 ------------------------ * Fri May 15 2009 Jaroslav Kysela 1.0.20-3 - fixed Headphone Volume issue (bz#500956) * Mon May 11 2009 Jaroslav Kysela 1.0.20-1 - updated to 1.0.20 final - updated alsa-info.sh script to 0.4.56 * Mon May 11 2009 Jaroslav Kysela 1.0.20-2 - fix build (update sources file) coccinelle-0.1.8-1.fc11.3 ------------------------- * Fri May 22 2009 Richard W.M. Jones - 0.1.8-1.fc11.3 - New upstream version 0.1.8. - Include patch from Debian to fix CVE-2009-1753 (RHBZ#502174). - Segfaults on PPC64, so added to ExcludeArch. generic-release-11-1 -------------------- * Wed May 20 2009 Tom "spot" Callaway - 11-1 - resync with fedora-release package glibc-2.10.1-2 -------------- * Fri May 22 2009 Jakub Jelinek 2.10.1-2 - fix accept4 on architectures other than i?86/x86_64 - robustify nscd client code during server GC - fix up nscd segfaults during daemon shutdown - fix memchr on ia64 (BZ#10162) - replace the Sun RPC license with the BSD license, with the explicit permission of Sun Microsystems - fix up powerpc long double errno reporting ibus-chewing-1.0.10.20090523-2.fc11 ----------------------------------- * Fri May 22 2009 - Ding-Yi Chen - 1.0.10.20090522-1 - Now the 1st down key brings the longest possible phrases. The 2nd down key brings the 2nd longest possible phrases from the back, unlike the previous versions where the cursor stays in the head of longest phrase. - Add force lowercase in English mode option. - Fix double free issue when destroy ibus-chewing. - Hide ibus-chewing-panel when ibus-chewing is focus-out * Fri May 22 2009 Ding-Yi Chen - 1.0.10.20090523-1 - Applied Lubomir Rintel's patch * Fri May 22 2009 Ding-Yi Chen - 1.0.10.20090523-2 - Add back the export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` * Mon May 11 2009 Ding-Yi Chen - 1.0.9.20090508-1 Now commit is forced when switch of ibus-chewing or current application loses focus. - New ibus-chewing.png is contribute by WM. - input-keyboard.png is no longer needed and removed. - ibus-engine-chewing -v option now need an integer as verbose level. - ibus-chewing.schemas is now generated. - Fix some CMake modules bugs. * Tue Apr 28 2009 Ding-Yi Chen - 1.0.8.20090428-1 Fix the errors which Funda Wang as pointing out: - Move src/chewing.xml.in to data/ - Fixed some typo in next_version targets. - Remove GConf2 package requirement, while add gconftool-2 requirement. libchewing-0.3.2-10.fc11 ------------------------ * Wed May 20 2009 Ding-Yi Chen - 0.3.2-10 - Need autoreconf to make changes in Makefile.am effective. * Mon May 18 2009 Ding-Yi Chen - 0.3.2-9 - Possible Fix of Bug 501220 - RFE: edit last preedit character from end of line Chewing upstream does not handle if phrase choice rearward is enabled. libdrm-2.4.6-7.fc11 ------------------- * Tue May 19 2009 Kristian H??gsberg - 2.4.6-7 - Add patch to limit cachable object size (#498131). squirrelmail-1.4.19-1.fc11 -------------------------- * Fri May 22 2009 Michal Hlavinka - 1.4.19-1 - updated to 1.4.19 - fixes CVE-2009-1579, CVE-2009-1580, CVE-2009-1581 * Tue May 19 2009 Michal Hlavinka - 1.4.18-2 - fix undefined variable aSpamIds (#501260) * Tue May 12 2009 Michal Hlavinka - 1.4.18-1 - updated to 1.4.18 transmission-1.53-1.fc11 ------------------------ * Fri May 22 2009 Denis Leroy - 1.53-1 - Update to upstream 1.53 - Security fix CVE-2009-1757 (#500278) * Tue Apr 28 2009 Denis Leroy - 1.52-1 - Update to upstream 1.52 - XDG Download patch upstreamed - Added patch to make full allocation by default xorg-x11-drv-intel-2.7.0-6.fc11 ------------------------------- * Wed May 20 2009 - 2.7.0-6 - Add intel-2.7-dont-gtt-map-big-objects.patch to avoid mapping big gem objects through the GTT (#498131). * Thu May 07 2009 Adam Jackson 2.7.0-5 - Update intel-gpu-tools Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 10 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From braden at endoframe.com Sat May 23 15:03:47 2009 From: braden at endoframe.com (Braden McDaniel) Date: Sat, 23 May 2009 11:03:47 -0400 Subject: Breaking deps deliberately In-Reply-To: References: <20090513111343.4d79d48f@faldor.intranet> <20090513134744.GA19304@amd.home.annexia.org> <4A0AD15F.6040300@fedoraproject.org> <20090513135728.GA19428@amd.home.annexia.org> <20090513142048.GA19610@amd.home.annexia.org> <20090513142742.GB19610@amd.home.annexia.org> <20090513220839.GA22106@amd.home.annexia.org> <20090514114703.6ea61d2d@faldor.intranet> Message-ID: <1243091027.12703.6.camel@localhost.localdomain> On Thu, 2009-05-14 at 23:34 +0200, Kevin Kofler wrote: > Michael Schwendt wrote: > > Btw, the F-10 update would have had a higher %release than the F-11 > > update (1.0.21-4.fc10 > 1.0.21-3.fc11). > > Sigh, why do people keep doing this instead of using proper 3.fc10.1 > versioning? Deliberate breaking of upgrade paths also needs to be banned! I didn't know about this until this subthread... and I asked a rather senior packaging person about it some months ago and didn't get this information. So I think this is poorly publicized; and perhaps poorly positioned in the packaging guidelines. That said, is there a reason the update system shouldn't enforce this? That is, why allow an update to F-(n-1) that's greater than the current package in F-n (or devel)? -- Braden McDaniel From bjorn at xn--rombobjrn-67a.se Sat May 23 16:41:52 2009 From: bjorn at xn--rombobjrn-67a.se (=?iso-8859-1?q?Bj=F6rn_Persson?=) Date: Sat, 23 May 2009 18:41:52 +0200 Subject: List of packages including country flags In-Reply-To: <4A179BE7.7010507@x-tnd.be> References: <4A179BE7.7010507@x-tnd.be> Message-ID: <200905231841.52645.bjorn@xn--rombobjrn-67a.se> Johan Cwiklinski wrote: > gcompris is an educationnal software, for 2 years old and more children. > > Flags usage to select language is not exactly part of the educational > side the soft, but it's also part of it (think that a two years old > child may "prefer" choosing his language according to the flag, not to > the text). I think a two-year-old is more likely to click through the list to look at the pretty pictures until bored, and then all the texts in the program are in some random illegible language. Bj?rn Persson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From kevin.kofler at chello.at Sat May 23 17:26:13 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 23 May 2009 19:26:13 +0200 Subject: List of packages including country flags References: Message-ID: Gregory Maxwell wrote: > They aren't really per-country either. To be most accurate I would say are > per-language with occasional national variants. > > There are quite a few cases where the implication that a language belongs > to a particular country (or a country has a particular 'right' language) > is highly offensive. It's simply not right, and it's highly insensitive to > the social realities in some parts of the world. Then those users can just turn the darn checkbox off. Users in many other parts of the world are expecting and asking for those flags. See e.g. bug reports like these: https://bugzilla.redhat.com/show_bug.cgi?id=244578 https://bugzilla.redhat.com/show_bug.cgi?id=236332 (and several more) or forum threads like this: http://forums.fedoraforum.org/showthread.php?t=147863 > It smacks of the sort of multi-cultural ignorance that Americans are > widely credited with? Kinda ironic how you're accusing me of multi-cultural ignorance while at the same time assuming I'm American. :-/ I'm a European (Italian citizen, born and resident in Austria, went to a French school) who speaks 4 languages fluently (German, Italian, French, English). I know that countries and languages don't map 1:1 and that keyboard layouts don't map 1:1 to either. But if you look at the list of keyboard layouts, you'll see that 78 layouts out of 83 (checked on Fedora 9) are named after a country. I don't see how it would be inappropriate to match those up with a flag. If that's inappropriate, then the name needs fixing too! But then it's kinda hard to find a proper name and especially a proper 2-letter code to show in the switcher (so I don't see how 2-letter codes are any better than flags). (How do you fit "Germany and Austria" into 2 letters? "da" won't cut it, that's already Denmark. Even 3 letters are insufficient for some layouts used in multiple countries. And you can't fit more into a systray icon.) The remaining 5 layouts (Arabic, Braille, Esperanto, Latin America and Maori) are shown without a country flag, using just a 3-letter abbreviation (Maori could probably use a New Zealand flag, but it currently doesn't). I don't see how that interface is inappropriate. As for the multi-language countries which have been cited, both Switzerland and India have A SINGLE keyboard layout in that list (which is generated from xkb data)! Switzerland has variants for German and French (not sure which one the Italian speakers use) which you select AFTER you selected the main layout in the list (and the dialog allows you to pick 2 variants and to rename them, so if you want to switch between Swiss German and Swiss French layouts, you can make them show up as de and fr or something of your choice in the switcher). India has a default + 15 variants (and there too you can pick multiple ones and rename them). So if you think selecting layouts per country and considering the language variants variants of the same layout is broken, complain to the xkb folks, not to KDE! > Have a citation for that? Specifically for a refusal to stop > conflating keymaps and languages with national flags? See e.g.: http://marc.info/?l=kde-core-devel&m=108491020719046&w=2 (and the whole thread). Kevin Kofler From kevin.kofler at chello.at Sat May 23 17:28:51 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 23 May 2009 19:28:51 +0200 Subject: List of packages including country flags References: <4A1785BB.1000004@FamilleCollet.com> Message-ID: Remi Collet wrote: > ocsinventory use flags for locale selection. > > Patch is ready, I'm just waiting for upstream feedback. IMHO you shouldn't patch it. The policy has been suspended for now, we need to get it thrown out entirely. If upstream uses flags, we should ship them. Kevin Kofler From kevin.kofler at chello.at Sat May 23 17:37:13 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 23 May 2009 19:37:13 +0200 Subject: rawhide report: 20090523 changes References: <20090523141954.2494F1F820F@releng2.fedora.phx.redhat.com> Message-ID: Rawhide Report wrote: > - Include patch from Debian to fix CVE-2009-1753 (RHBZ#502174). Yet another insecure temporary file vulnerability. Why do we still not polyinstantiate /tmp by default? We're wasting lots of time on security measures which keep breaking apps such as SELinux, but simple things like polyinstantiation are still not used, why? This code would be perfectly safe if polyinstantiation was mandatory. Why are we stuck in the 1970s? Kevin Kofler From fedora at leemhuis.info Sat May 23 17:46:42 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 23 May 2009 19:46:42 +0200 Subject: unowned files and directories Message-ID: <4A183682.2000006@leemhuis.info> Hi! I now and then check which files on my systems are not owned by any RPM package. That often turns up a lot's of old and obsolete stuff that sometimes eats space I'd like to free. During those checks I often find lots of files and directories that obviously should be owned by some packages but aren't. So today I decided to track this a bit closer and do a fresh rawhide install with standard settings into a VM and check which files and directories were unowned using this command: find / | grep -v -e '^/selinux' -e '^/dev' -e '^/proc' -e '^/sys' -e '^/root' -e '^/home' -e '^/tmp' -e '^/var/cache/' -e '^/var/tmp/' | LC_ALL=C xargs -L 250 rpm -qf | grep "not owned" | awk '{print $2}' That resulted in round about 1800 unowned files and directories. You can find the full list at http://www.leemhuis.info/files/fedora/unowned Yes, maybe more stuff in /var should be filtered; same is true for things like "lost+found". But the list is interesting nevertheless as lot of things (random examples: "/etc/kde" or "/usr/lib64/gimp/2.0/plug-ins/xsane") afaics should definitely be owned by some package(?). But I'm a bit unsure what to do with the results. Filing bugs likely would be huge amount of work as well as and never-ending task for a small gain. Options? Just ignore? Or will the automatic test scripts QA iirc plans to set up check for things like that in the future? CU knurd (?) the list also leads to question like "why are there /.dbus and /.pulse?" and "why is there a /etc/hosts.rpmnew right after install and why does it look quite different" From chris.stone at gmail.com Sat May 23 19:45:26 2009 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 23 May 2009 12:45:26 -0700 Subject: Package Maintainers Flags policy In-Reply-To: <20090520135717.GA13882@nostromo.devel.redhat.com> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520135717.GA13882@nostromo.devel.redhat.com> Message-ID: On Wed, May 20, 2009 at 6:57 AM, Bill Nottingham wrote: > Is it catering to paranoia of a particular government? Yes. (So are > the T-6 restriction, FWIW.) ?Is it annoying? Yes. ?However, changing the > scope of various governments is fairly out of scope of Fedora; let's stick > to what we can change. What are the T-6 restrictions? A google search only came up with this thread. I'm trying to understand your logic, are you saying that if the Chinese government no longer recognized other languages as being valid, then we would have to remove all languages from Fedora? Is that not the exact same logic you are applying to flags? > > It comes down to a tradeoff; it's essentially a pragmatic decision. Are the > gains by making it acceptable in China (or similar locales) worth the effort in > changing/removing some small number of packages? Given the benefits in > opening up the community to 1/6 of the planet's population, and the fact > that in most all cases, the flags aren't a crucial portion of the > functionality *of the project* that is exposed to users, I think so. Why not make a China spin? There is a Russia spin in the works is there not? Why not a China spin? In the China spin we can make all flags the Chinese flag. From chris.stone at gmail.com Sat May 23 20:12:46 2009 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 23 May 2009 13:12:46 -0700 Subject: Youth Protection: Was Re: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <4A13C879.4080002@poolshark.org> <20090520102730.45a3b7d4@ohm.scrye.com> <4A143CDC.8040400@freenet.de> <4A143F64.5080002@redhat.com> <4A14C5BB.5050401@freenet.de> <7dd7ab490905202158sc923880ge50c81bceb580024@mail.gmail.com> <4A15A3A5.4090004@redhat.com> Message-ID: On Thu, May 21, 2009 at 12:30 PM, Seth Vidal wrote: > > > On Thu, 21 May 2009, Paul Wouters wrote: >> ps. The really interesting question is: If a Fedora DVD image contains a >> ? US flag, can you still burn it? :) >> > > I don't know where people have gotten the idea that burning a US flag is > illegal. It's not. It's been found to be protected speech repeatedly. The fact that they have to "re-find" this fact repeatedly is what is amusing about his statement. I did not get the impression that he was suggesting that burning a US flag is illegal. From chris.stone at gmail.com Sat May 23 20:28:17 2009 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 23 May 2009 13:28:17 -0700 Subject: FESCo Meeting Summary for 2009-05-22 In-Reply-To: <20090522190016.GB18436@nostromo.devel.redhat.com> References: <20090522190016.GB18436@nostromo.devel.redhat.com> Message-ID: On Fri, May 22, 2009 at 12:00 PM, Bill Nottingham wrote: > == Members Present == > > * Jon Stanley (jds2001) > * Kevin Fenzi (nirik) > * Dan Horak (sharkcz) > * Josh Boyer (jwb) > * Brian Pepple (bpepple) > * Bill Nottingham (notting) > * David Woodhouse (dwmw2) > * Jarod Wilson (j-rod) > > == Revert the recently published Flag policy == > > After a lot of discussion, FESCo voted 6-0 to: > > ? ?* revert/suspend the policy approved the prior week > ? ?* have people look into the issues and gather data (requirements of > ? ?* various locales, number of packages affected, etc.) > ? ?* craft a policy based on further data, or decide that one is not > ? ?* required at all Sounds rational. Thank you. From rdieter at math.unl.edu Sat May 23 21:57:43 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 23 May 2009 16:57:43 -0500 Subject: PolicyKit changes in F12 References: <1242262846.9432.9.camel@localhost.localdomain> <200905201730.51182.jreznik@redhat.com> Message-ID: Jaroslav Reznik wrote: > On Jueves 14 Mayo 2009 03:00:46 Matthias Clasen escribi?: >> Just a heads-up: >> >> We hope to land a new PolicyKit version (which will turn into 1.0, >> eventually) in F12 soon. The new version simplifies the API and will >> require PolicyKit-using application to be ported. For more information, >> have a look at the feature page: >> >> http://fedoraproject.org/wiki/Features/PolicyKitOne >> >> It also has pointers to api docs and a (terse) porting guide. We already >> have a collection of patches for quite a few PolicyKit-using apps, so >> the transitions should be relatively painless. > could you be more specific in porting guide with some more real world > examples etc. Patches are OK for quick overview what should be done but > it's not a good source if you don't know code for those apps. Seems frustrations are mounting: "On policykit and standards" http://lists.freedesktop.org/archives/polkit-devel/2009-May/000119.html -- Rex From kevin.kofler at chello.at Sat May 23 22:33:09 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 24 May 2009 00:33:09 +0200 Subject: PolicyKit changes in F12 References: <1242262846.9432.9.camel@localhost.localdomain> <200905201730.51182.jreznik@redhat.com> Message-ID: Jaroslav Reznik wrote: > How long old PK will be shipped in Fedora? Shipping old PolicyKit won't really help, as PackageKit etc. are all going to get ported to the new one. The only reasonable thing to do is to BLOCK the upgrade until it can be supported cross desktop. I'm really fed up of having to play catch up with supposedly "shared" technologies getting upgraded under us without anybody talking to KDE upstream or to us (Fedora's KDE SIG) about the schedule. The PolicyKit-kde developer even WANTS to support the new version, but he didn't get the documentation he needs for that (and asked for weeks ago)! (Lack of documentation is a real issue for this stuff. When I did the KDM ConsoleKit patch, I had to look at source code, both of ConsoleKit and of GDM, to figure out what the heck was going on.) Kevin Kofler From Curtis at GreenKey.net Sat May 23 23:49:31 2009 From: Curtis at GreenKey.net (Curtis Doty) Date: Sat, 23 May 2009 16:49:31 -0700 (PDT) Subject: unowned files and directories In-Reply-To: <4A183682.2000006@leemhuis.info> References: <4A183682.2000006@leemhuis.info> Message-ID: <20090523234932.5653D6F0B5@alopias.GreenKey.net> 7:46pm Thorsten Leemhuis said: > I now and then check which files on my systems are not owned by any RPM > package. That often turns up a lot's of old and obsolete stuff that > sometimes eats space I'd like to free. During those checks I often find > lots of files and directories that obviously should be owned by some > packages but aren't. Same here--compulsively--as part of a forhead-smackingly simple backup routine. > > But I'm a bit unsure what to do with the results. Filing bugs likely > would be huge amount of work as well as and never-ending task for a > small gain. > > Options? Just ignore? Or will the automatic test scripts QA iirc plans > to set up check for things like that in the future? We should start with /usr and pare that down first before /etc and /var grunge. However, some bugs about /usr grunge have languished awaiting upstream intervention. I.e. http://bugzilla.redhat.com/136013 ../C From xjakub at fi.muni.cz Sun May 24 01:35:04 2009 From: xjakub at fi.muni.cz (Milos Jakubicek) Date: Sun, 24 May 2009 03:35:04 +0200 Subject: unowned files and directories In-Reply-To: <4A183682.2000006@leemhuis.info> References: <4A183682.2000006@leemhuis.info> Message-ID: <4A18A448.8060003@fi.muni.cz> On 23.5.2009 19:46, Thorsten Leemhuis wrote: > Hi! > > I now and then check which files on my systems are not owned by any RPM > package. That often turns up a lot's of old and obsolete stuff that > sometimes eats space I'd like to free. During those checks I often find > lots of files and directories that obviously should be owned by some > packages but aren't. You should contact Michael Schwendt, he has done a lot of work in this -- and IIRC he is still doing periodic checks in this area. Regards, Milos From mclasen at redhat.com Sun May 24 02:26:10 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Sat, 23 May 2009 22:26:10 -0400 Subject: PolicyKit changes in F12 In-Reply-To: References: <1242262846.9432.9.camel@localhost.localdomain> <200905201730.51182.jreznik@redhat.com> Message-ID: <1243131970.3331.50.camel@localhost.localdomain> On Sun, 2009-05-24 at 00:33 +0200, Kevin Kofler wrote: > Jaroslav Reznik wrote: > > How long old PK will be shipped in Fedora? > > Shipping old PolicyKit won't really help, as PackageKit etc. are all going > to get ported to the new one. The only reasonable thing to do is to BLOCK > the upgrade until it can be supported cross desktop. I'm really fed up of > having to play catch up with supposedly "shared" technologies getting > upgraded under us without anybody talking to KDE upstream or to us > (Fedora's KDE SIG) about the schedule. The feature page has been out there for all to read for months. It took me a couple of evenings to write patches for the majority of polkit users in gnome, so I assume it should be possible to do the same for KDE. It is probably even easier, since you have those fabulous abstraction layers on top of all the 'shared' technologies... > The PolicyKit-kde developer even > WANTS to support the new version, but he didn't get the documentation he > needs for that (and asked for weeks ago)! I see a single mail by Dario on the PolicyKit mailing list before the one that you consider as 'mounting frustration'. Admittedly, it didn't get a reply, but it was a very general 'lets work together' mail, not asking concrete questions about missing documentation. As we all know, writing documentation is hard. The current 'porting guide' is the result of Richard and me writing patches to port a bunch of apps to the new PolicyKit, and is really just a collection of notes taken while hacking. I propose that the best way to improve the docs is to ask concrete questions on the mailing list. Matthias From kevin.kofler at chello.at Sun May 24 05:53:48 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 24 May 2009 07:53:48 +0200 Subject: PolicyKit changes in F12 References: <1242262846.9432.9.camel@localhost.localdomain> <200905201730.51182.jreznik@redhat.com> <1243131970.3331.50.camel@localhost.localdomain> Message-ID: Matthias Clasen wrote: > It took me a couple of evenings to write patches for the majority of > polkit users in gnome Several of your "porting patches" just drop PolicyKit support entirely (so it looks to me like either it's actually more work to port to the new PolicyKit than you claim or the new PolicyKit is just not powerful enough to support everything the old one did, both of which would be bad things). Kevin Kofler From kevin.kofler at chello.at Sun May 24 06:07:39 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 24 May 2009 08:07:39 +0200 Subject: PolicyKit changes in F12 References: <1242262846.9432.9.camel@localhost.localdomain> <200905201730.51182.jreznik@redhat.com> <1243131970.3331.50.camel@localhost.localdomain> Message-ID: Oh, and I should add: Matthias Clasen wrote: > It took me a couple of evenings to write patches for the majority of > polkit users in gnome, so I assume it should be possible to do the same > for KDE. It is probably even easier, since you have those fabulous > abstraction layers on top of all the 'shared' technologies... The only layer between PolicyKit and KDE at the moment is polkit-qt. Moreover, the affected software portions to port in KDE land are not simple applications like the ones you ported. They are: - polkit-qt: the binding, which needs changes for ALL the API changes, not just the ones affecting a particular application (which is also why Dario is asking for a complete list of API changes, which sadly doesn't seem to exist... rewriting everything without writing down what is being changed and then reconstructing the changes from notes taken when porting applications is a really bad way to document API changes), and changes to polkit-qt's own API may also be needed (and if so, need to be decided upstream, we can't just do random API changes locally in Fedora), - PolicyKit-kde: this has 2 parts: i. the authentication agent, which needs to be basically rewritten (because the way authentication is handled has changed) and ii. the polkit-kde-authorization tool which needs significant changes or a rewrite. The application layer may need porting too if polkit-qt needs API changes, but getting polkit-qt and PolicyKit-kde ported is the big effort (and a working PolicyKit-kde is important for things like PackageKit). Kevin Kofler From a.badger at gmail.com Sun May 24 15:07:01 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 24 May 2009 08:07:01 -0700 Subject: List of packages including country flags In-Reply-To: <200905231841.52645.bjorn@xn--rombobjrn-67a.se> References: <4A179BE7.7010507@x-tnd.be> <200905231841.52645.bjorn@xn--rombobjrn-67a.se> Message-ID: <4A196295.2010306@gmail.com> On 05/23/2009 09:41 AM, Bj?rn Persson wrote: > Johan Cwiklinski wrote: >> gcompris is an educationnal software, for 2 years old and more children. >> >> Flags usage to select language is not exactly part of the educational >> side the soft, but it's also part of it (think that a two years old >> child may "prefer" choosing his language according to the flag, not to >> the text). > > I think a two-year-old is more likely to click through the list to look at the > pretty pictures until bored, and then all the texts in the program are in > some random illegible language. > A two year old (through kindergartener or first grader) is certainly capable of choosing a symbol that they've been taught to use from a table of other symbols. The real question is whether there's a time in a child's development when they can pick out an image that gets them into a program but can't pick out a two letter abbreviation to do the same. BTW, gcompris, has audio in various languages for children to learn from. So it's not just text that's being translated by the language selection. -Toshio From rawhide at fedoraproject.org Sun May 24 15:34:33 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Sun, 24 May 2009 15:34:33 +0000 (UTC) Subject: rawhide report: 20090524 changes Message-ID: <20090524153433.BF2611F821D@releng2.fedora.phx.redhat.com> Compose started at Sun May 24 06:15:09 UTC 2009 Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 0 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From jreznik at redhat.com Sun May 24 16:06:27 2009 From: jreznik at redhat.com (Jaroslav Reznik) Date: Sun, 24 May 2009 18:06:27 +0200 Subject: PolicyKit changes in F12 In-Reply-To: <1243131970.3331.50.camel@localhost.localdomain> References: <1242262846.9432.9.camel@localhost.localdomain> <1243131970.3331.50.camel@localhost.localdomain> Message-ID: <200905241806.27669.jreznik@redhat.com> On Sunday 24 May 2009 04:26:10 Matthias Clasen wrote: > On Sun, 2009-05-24 at 00:33 +0200, Kevin Kofler wrote: > > Jaroslav Reznik wrote: > > > How long old PK will be shipped in Fedora? > > > > Shipping old PolicyKit won't really help, as PackageKit etc. are all > > going to get ported to the new one. The only reasonable thing to do is to > > BLOCK the upgrade until it can be supported cross desktop. I'm really fed > > up of having to play catch up with supposedly "shared" technologies > > getting upgraded under us without anybody talking to KDE upstream or to > > us (Fedora's KDE SIG) about the schedule. > > The feature page has been out there for all to read for months. Yes, it was - but this is first visible activity with actual results - existing code etc. as I know (sorry if it's not true). > It took me a couple of evenings to write patches for the majority of > polkit users in gnome, so I assume it should be possible to do the same > for KDE. It is probably even easier, since you have those fabulous > abstraction layers on top of all the 'shared' technologies... Currently it's using polkit-grant and that seems it's not ported to new API yet. Could you take a look to code and suggest us right way to port it? Every help/ideas are appreciate. I'll try to look into deeper and I hope we can do it until Fedora 12 is released. It lies in http://websvn.kde.org/trunk/kdesupport/polkit-qt/ and http://websvn.kde.org/trunk/KDE/kdebase/workspace/PolicyKit-kde/ Upstream is currently considering writing on pure DBUS implementation even own backend. I hope I can join it and try to help. Main problem is it took some time for PolKit to be accepted by KDE and it's 4.3 feature and it's now beta (and as KDE has very strict freezes). Now there are big API changes and it misses KDE release - it's a work for 4.4 - so next year :( > > The PolicyKit-kde developer even > > WANTS to support the new version, but he didn't get the documentation he > > needs for that (and asked for weeks ago)! > > I see a single mail by Dario on the PolicyKit mailing list before the > one that you consider as 'mounting frustration'. Admittedly, it didn't > get a reply, but it was a very general 'lets work together' mail, not > asking concrete questions about missing documentation. > > As we all know, writing documentation is hard. The current 'porting > guide' is the result of Richard and me writing patches to port a bunch > of apps to the new PolicyKit, and is really just a collection of notes > taken while hacking. > > I propose that the best way to improve the docs is to ask concrete > questions on the mailing list. I've pointed Dario to this thread. We're in close contact, so I can try to cooperate this efforts as it should be cross desktop one. Feel free to contact me. Complaining don't help - actual code yes ;-) > > > Matthias Thanks Jaroslav From jreznik at redhat.com Sun May 24 16:07:50 2009 From: jreznik at redhat.com (Jaroslav Reznik) Date: Sun, 24 May 2009 18:07:50 +0200 Subject: PolicyKit changes in F12 In-Reply-To: References: <1242262846.9432.9.camel@localhost.localdomain> <200905201730.51182.jreznik@redhat.com> Message-ID: <200905241807.51043.jreznik@redhat.com> On Sunday 24 May 2009 00:33:09 Kevin Kofler wrote: > Jaroslav Reznik wrote: > > How long old PK will be shipped in Fedora? > > Shipping old PolicyKit won't really help, as PackageKit etc. are all going > to get ported to the new one. The only reasonable thing to do is to BLOCK > the upgrade until it can be supported cross desktop. Kevin, I know but it can add some time for us. Jaroslav > I'm really fed up of > having to play catch up with supposedly "shared" technologies getting > upgraded under us without anybody talking to KDE upstream or to us > (Fedora's KDE SIG) about the schedule. The PolicyKit-kde developer even > WANTS to support the new version, but he didn't get the documentation he > needs for that (and asked for weeks ago)! (Lack of documentation is a real > issue for this stuff. When I did the KDM ConsoleKit patch, I had to look at > source code, both of ConsoleKit and of GDM, to figure out what the heck was > going on.) > > Kevin Kofler From bjorn at xn--rombobjrn-67a.se Sun May 24 23:01:58 2009 From: bjorn at xn--rombobjrn-67a.se (=?utf-8?q?Bj=C3=B6rn_Persson?=) Date: Mon, 25 May 2009 01:01:58 +0200 Subject: List of packages including country flags In-Reply-To: <4A196295.2010306@gmail.com> References: <200905231841.52645.bjorn@xn--rombobjrn-67a.se> <4A196295.2010306@gmail.com> Message-ID: <200905250102.23830.bjorn@xn--rombobjrn-67a.se> Toshio Kuratomi wrote: > A two year old (through kindergartener or first grader) is certainly > capable of choosing a symbol that they've been taught to use from a > table of other symbols. The real question is whether there's a time in > a child's development when they can pick out an image that gets them > into a program but can't pick out a two letter abbreviation to do the same. It's not really about getting into the program but rather configuring the program. Gcompris uses the locale from the environment by default, like all well-behaved programs do, but you can go to the configuration screen and choose another locale if you want to. Then you need to exit Gcompris and start it again before the change takes effect on the whole program, so I doubt that the intention is that children should choose their locale every time they start Gcompris. I haven't quite figured out why the developers felt a need to have a separate locale setting just for Gcompris, but in those cases where it's needed I think a parent or teacher will configure the program and then tell the children not to touch the settings. > BTW, gcompris, has audio in various languages for children to learn > from. So it's not just text that's being translated by the language > selection. In that case I would suggest a recorded voice that says "Should I speak English?" and the equivalent in each language ? if the intention really is that children who can't read should be able to choose their language. Bj?rn Persson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From mclasen at redhat.com Mon May 25 02:55:14 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Sun, 24 May 2009 22:55:14 -0400 Subject: PolicyKit changes in F12 In-Reply-To: References: <1242262846.9432.9.camel@localhost.localdomain> <200905201730.51182.jreznik@redhat.com> <1243131970.3331.50.camel@localhost.localdomain> Message-ID: <1243220114.2348.5.camel@localhost.localdomain> On Sun, 2009-05-24 at 07:53 +0200, Kevin Kofler wrote: > Matthias Clasen wrote: > > It took me a couple of evenings to write patches for the majority of > > polkit users in gnome > > Several of your "porting patches" just drop PolicyKit support entirely (so > it looks to me like either it's actually more work to port to the new > PolicyKit than you claim or the new PolicyKit is just not powerful enough > to support everything the old one did, both of which would be bad things). Look closer then. The big advantage of the new api is that the PolicyKit interaction is kept entirely on the mechanism side, with no need for clients do a complicated first-call-mechanism-then-polkit-then-mechanism-again dance. The consequence is that porting to the new api often just means dropping polkit-specific code from the clients. From dchen at redhat.com Mon May 25 05:21:05 2009 From: dchen at redhat.com (Ding-Yi Chen) Date: Mon, 25 May 2009 15:21:05 +1000 Subject: List of packages including country flags In-Reply-To: References: Message-ID: <1243228865.4642.70.camel@dhcp-0-207.bne.redhat.com> ? ??2009-05-23 ? 19:26 +0200?Kevin Kofler ??? > I know that countries and languages don't map 1:1 and that keyboard layouts > don't map 1:1 to either. But if you look at the list of keyboard layouts, > you'll see that 78 layouts out of 83 (checked on Fedora 9) are named after > a country. I don't see how it would be inappropriate to match those up with > a flag. If that's inappropriate, then the name needs fixing too! Unless there is a plan to complete the flags/icons for 83-78=5 layouts, it does not look consistent, does it? > But then > it's kinda hard to find a proper name and especially a proper 2-letter code > to show in the switcher (so I don't see how 2-letter codes are any better > than flags). (How do you fit "Germany and Austria" into 2 letters? "da" > won't cut it, that's already Denmark. Even 3 letters are insufficient for > some layouts used in multiple countries. And you can't fit more into a > systray icon.) The remaining 5 layouts (Arabic, Braille, Esperanto, Latin > America and Maori) are shown without a country flag, using just a 3-letter > abbreviation (Maori could probably use a New Zealand flag, but it currently > doesn't). I don't see how that interface is inappropriate. Technically, up to 6 alphabets can be actually squeeze in the systray icon. I already explained in my previous posts. See icon for SCIM of concrete example. > As for the multi-language countries which have been cited, both Switzerland > and India have A SINGLE keyboard layout in that list (which is generated > from xkb data)! I think there are some Dvorak keyboards in China and India, but Dvorak is not listed in either of them. > Switzerland has variants for German and French (not sure > which one the Italian speakers use) which you select AFTER you selected the > main layout in the list (and the dialog allows you to pick 2 variants and > to rename them, so if you want to switch between Swiss German and Swiss > French layouts, you can make them show up as de and fr or something of your > choice in the switcher). India has a default + 15 variants (and there too > you can pick multiple ones and rename them). So if you think selecting > layouts per country and considering the language variants variants of the > same layout is broken, complain to the xkb folks, not to KDE! It might be too late for xkb, but KDE/GNOME key layout selector on the other hand, can provide alternative UI to achieve the same effect. It is good that KDE can customize the layout label.However as a input method developer, I am more willing to see the key layouts which are categorized by ... layout themselves. Such as QWERTY-- Default +-ja_JP +-ko_KR, +-de_CH +-fr_CH +-it_CH +-en_UK +... DVORAK-- QWERTZ-- +-de_CH +-de_CH at SunDeadKey +-de_CH at NOSunDeadKey +-de_CH at Mac +-fr_CH +-it_CH +... AZERTY--fr_FR +-fr_BE .... The benefits of this category systems are: 1. Input method developers only need to deal with the keys that matter (i.e. 0-9 and a-z) instead of go through the whole country list. 2. End users need fewer scroll for the first level category. 3. Reduce the redundancy: Many countries use essentially the standard QWERTY layout, no need to show all of them. 4. Flags can be assigned to the second level, either from the listing locale string or the regional setting. So Aussies, Kiwi, Singaporean can use their own flags (instead of American flags), everybody is happy. :-) -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ From kevin.kofler at chello.at Mon May 25 06:54:43 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 25 May 2009 08:54:43 +0200 Subject: List of packages including country flags References: <1243228865.4642.70.camel@dhcp-0-207.bne.redhat.com> Message-ID: Ding-Yi Chen wrote: > Unless there is a plan to complete the flags/icons for 83-78=5 layouts, > it does not look consistent, does it? Those 5 layouts do not match a country, so it makes sense not to show any flags for them. This is neither a real issue, nor an argument for removing the remaining 78 flags. > It might be too late for xkb, but KDE/GNOME key layout selector on the > other hand, can provide alternative UI to achieve the same effect. > > It is good that KDE can customize the layout label.However > as a input method developer, I am more willing to see the key layouts > which are categorized by ... layout themselves. Such as > QWERTY-- Default > +-ja_JP > +-ko_KR, > +-de_CH > +-fr_CH > +-it_CH > +-en_UK > +... > DVORAK-- > QWERTZ-- > +-de_CH > +-de_CH at SunDeadKey > +-de_CH at NOSunDeadKey > +-de_CH at Mac > +-fr_CH > +-it_CH > +... > AZERTY--fr_FR > +-fr_BE > .... > > The benefits of this category systems are: > 1. Input method developers only need to deal with the keys that matter > (i.e. 0-9 and a-z) instead of go through the whole country list. > 2. End users need fewer scroll for the first level category. > 3. Reduce the redundancy: Many countries use essentially the standard > QWERTY layout, no need to show all of them. > 4. Flags can be assigned to the second level, either from the listing > locale string or the regional setting. So Aussies, Kiwi, Singaporean can > use their own flags (instead of American flags), everybody is happy. :-) Please propose these UI improvements to KDE upstream. They have nothing to do with Fedora's policy on flags in any case. (You write yourself that flags would still be useful, or even more useful, under that scheme.) Kevin Kofler From petersen at redhat.com Mon May 25 07:24:22 2009 From: petersen at redhat.com (Jens Petersen) Date: Mon, 25 May 2009 03:24:22 -0400 (EDT) Subject: Broken dependencies in Fedora 12 Development - 2009-05-22 In-Reply-To: <20090522185608.20074.34996@faldor.intranet> Message-ID: <1190975571.1388261243236262332.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Thanks - I think I have taken care of all these. -Jens ----- "Michael Schwendt" wrote: > Your following packages in the repository suffer from broken > dependencies: > > package: ghc-ghc-paths-devel-0.1.0.5-6.fc12.i586 from > dist-f12-build-current-i386 > unresolved deps: > ghc = 0:6.10.2 > > package: ghc-ghc-paths-devel-0.1.0.5-6.fc12.ppc from > dist-f12-build-current-ppc > unresolved deps: > ghc = 0:6.10.2 > > package: ghc-ghc-paths-devel-0.1.0.5-6.fc12.x86_64 from > dist-f12-build-current-x86_64 > unresolved deps: > ghc = 0:6.10.2 > > package: ghc-ghc-paths-doc-0.1.0.5-6.fc12.i586 from > dist-f12-build-current-i386 > unresolved deps: > ghc-doc = 0:6.10.2 > > package: ghc-ghc-paths-doc-0.1.0.5-6.fc12.ppc from > dist-f12-build-current-ppc > unresolved deps: > ghc-doc = 0:6.10.2 > > package: ghc-ghc-paths-doc-0.1.0.5-6.fc12.x86_64 from > dist-f12-build-current-x86_64 > unresolved deps: > ghc-doc = 0:6.10.2 > > package: ghc-ghc-paths-prof-0.1.0.5-6.fc12.i586 from > dist-f12-build-current-i386 > unresolved deps: > ghc-prof = 0:6.10.2 > > package: ghc-ghc-paths-prof-0.1.0.5-6.fc12.ppc from > dist-f12-build-current-ppc > unresolved deps: > ghc-prof = 0:6.10.2 > > package: ghc-ghc-paths-prof-0.1.0.5-6.fc12.x86_64 from > dist-f12-build-current-x86_64 > unresolved deps: > ghc-prof = 0:6.10.2 > > package: ghc-haddock-devel-2.4.2-2.fc12.i586 from > dist-f12-build-current-i386 > unresolved deps: > ghc = 0:6.10.2 > > package: ghc-haddock-devel-2.4.2-2.fc12.ppc from > dist-f12-build-current-ppc > unresolved deps: > ghc = 0:6.10.2 > > package: ghc-haddock-devel-2.4.2-2.fc12.x86_64 from > dist-f12-build-current-x86_64 > unresolved deps: > ghc = 0:6.10.2 > > package: ghc-haddock-doc-2.4.2-2.fc12.i586 from > dist-f12-build-current-i386 > unresolved deps: > ghc-doc = 0:6.10.2 > > package: ghc-haddock-doc-2.4.2-2.fc12.ppc from > dist-f12-build-current-ppc > unresolved deps: > ghc-doc = 0:6.10.2 > > package: ghc-haddock-doc-2.4.2-2.fc12.x86_64 from > dist-f12-build-current-x86_64 > unresolved deps: > ghc-doc = 0:6.10.2 > > package: ghc-haddock-prof-2.4.2-2.fc12.i586 from > dist-f12-build-current-i386 > unresolved deps: > ghc-prof = 0:6.10.2 > > package: ghc-haddock-prof-2.4.2-2.fc12.ppc from > dist-f12-build-current-ppc > unresolved deps: > ghc-prof = 0:6.10.2 > > package: ghc-haddock-prof-2.4.2-2.fc12.x86_64 from > dist-f12-build-current-x86_64 > unresolved deps: > ghc-prof = 0:6.10.2 > > package: ghc-hscolour-devel-1.12-3.fc12.i586 from > dist-f12-build-current-i386 > unresolved deps: > ghc = 0:6.10.2 > > package: ghc-hscolour-devel-1.12-3.fc12.ppc from > dist-f12-build-current-ppc > unresolved deps: > ghc = 0:6.10.2 > > package: ghc-hscolour-devel-1.12-3.fc12.x86_64 from > dist-f12-build-current-x86_64 > unresolved deps: > ghc = 0:6.10.2 > > package: ghc-hscolour-doc-1.12-3.fc12.i586 from > dist-f12-build-current-i386 > unresolved deps: > ghc-doc = 0:6.10.2 > > package: ghc-hscolour-doc-1.12-3.fc12.ppc from > dist-f12-build-current-ppc > unresolved deps: > ghc-doc = 0:6.10.2 > > package: ghc-hscolour-doc-1.12-3.fc12.x86_64 from > dist-f12-build-current-x86_64 > unresolved deps: > ghc-doc = 0:6.10.2 > > package: ghc-hscolour-prof-1.12-3.fc12.i586 from > dist-f12-build-current-i386 > unresolved deps: > ghc-prof = 0:6.10.2 > > package: ghc-hscolour-prof-1.12-3.fc12.ppc from > dist-f12-build-current-ppc > unresolved deps: > ghc-prof = 0:6.10.2 > > package: ghc-hscolour-prof-1.12-3.fc12.x86_64 from > dist-f12-build-current-x86_64 > unresolved deps: > ghc-prof = 0:6.10.2 > > package: haddock-2.4.2-2.fc12.i586 from dist-f12-build-current-i386 > unresolved deps: > ghc = 0:6.10.2 > > package: haddock-2.4.2-2.fc12.ppc from dist-f12-build-current-ppc > unresolved deps: > ghc = 0:6.10.2 > > package: haddock-2.4.2-2.fc12.x86_64 from > dist-f12-build-current-x86_64 > unresolved deps: > ghc = 0:6.10.2 From bochecha at fedoraproject.org Mon May 25 08:32:34 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Mon, 25 May 2009 10:32:34 +0200 Subject: List of packages including country flags In-Reply-To: <200905250102.23830.bjorn@xn--rombobjrn-67a.se> References: <200905231841.52645.bjorn@xn--rombobjrn-67a.se> <4A196295.2010306@gmail.com> <200905250102.23830.bjorn@xn--rombobjrn-67a.se> Message-ID: <2d319b780905250132r6e66ddacldba4e67d89712691@mail.gmail.com> 2009/5/25 Bj?rn Persson : > Toshio Kuratomi wrote: >> A two year old (through kindergartener or first grader) is certainly >> capable of choosing a symbol that they've been taught to use from a >> table of other symbols. ?The real question is whether there's a time in >> a child's development when they can pick out an image that gets them >> into a program but can't pick out a two letter abbreviation to do the same. > > It's not really about getting into the program but rather configuring the > program. Gcompris uses the locale from the environment by default, like all > well-behaved programs do, but you can go to the configuration screen and > choose another locale if you want to. Then you need to exit Gcompris and > start it again before the change takes effect on the whole program, so I > doubt that the intention is that children should choose their locale every > time they start Gcompris. > > I haven't quite figured out why the developers felt a need to have a separate > locale setting just for Gcompris, but in those cases where it's needed I > think a parent or teacher will configure the program and then tell the > children not to touch the settings. Remember this is a learning software. You can have your system configured for french and let your child both play sometimes in french and otherwise learn english with GCompris. ---------- Mathieu Bridon (bochecha) From mschwendt at gmail.com Mon May 25 08:35:01 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Mon, 25 May 2009 10:35:01 +0200 Subject: mimehandler automatic Provides? Message-ID: <20090525103501.0f1b7571@faldor.intranet> Are they related to http://fedoraproject.org/wiki/Features/AutoFontsAndMimeInstaller ? audacity = 1.3.7-0.6.beta.fc11 Build Time 2009-03-02 16:40:30 GMT mimehandler(application/ogg) mimehandler(application/x-audacity-project) mimehandler(audio/basic) mimehandler(audio/x-aifc) mimehandler(audio/x-aiff) mimehandler(audio/x-aiffc) mimehandler(audio/x-wav) And in a later build they are not added anymore. audacity = 1.3.7-0.7.beta.fc11 Build Time 2009-05-13 08:50:08 GMT Searching the Wiki for "mimehandler" yields no results. From mtasaka at ioa.s.u-tokyo.ac.jp Mon May 25 08:53:25 2009 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Mon, 25 May 2009 17:53:25 +0900 Subject: mimehandler automatic Provides? In-Reply-To: <20090525103501.0f1b7571@faldor.intranet> References: <20090525103501.0f1b7571@faldor.intranet> Message-ID: <4A1A5C85.6000508@ioa.s.u-tokyo.ac.jp> Michael Schwendt wrote, at 05/25/2009 05:35 PM +9:00: > Are they related to > http://fedoraproject.org/wiki/Features/AutoFontsAndMimeInstaller > ? Yes. > audacity = 1.3.7-0.6.beta.fc11 > Build Time 2009-03-02 16:40:30 GMT > > mimehandler(application/ogg) > mimehandler(application/x-audacity-project) > mimehandler(audio/basic) > mimehandler(audio/x-aifc) > mimehandler(audio/x-aiff) > mimehandler(audio/x-aiffc) > mimehandler(audio/x-wav) > > > And in a later build they are not added anymore. > > audacity = 1.3.7-0.7.beta.fc11 > Build Time 2009-05-13 08:50:08 GMT > > Searching the Wiki for "mimehandler" yields no results. I guess this is related to - https://bugzilla.redhat.com/show_bug.cgi?id=494817 - and "file" seems to have changed between these two days. Note that Panu said that the above bug was fixed in F-12 rpm and actually 1.3.7-0.7.beta.fc12 has some mimetype Provides. Regards, Mamoru From smohan at fedoraproject.org Mon May 25 13:33:41 2009 From: smohan at fedoraproject.org (Satish Mohan) Date: Mon, 25 May 2009 09:33:41 -0400 (EDT) Subject: Fedora and the moblin2 fork In-Reply-To: <8268247.601243257680000.JavaMail.smohan@dhcp1-117.pnq.redhat.com> Message-ID: <18204418.621243258415040.JavaMail.smohan@dhcp1-117.pnq.redhat.com> ----- Original Message ----- From: "Peter Robinson" To: "Development discussions related to Fedora" Sent: Friday, May 22, 2009 1:50:31 PM GMT +05:30 Chennai, Kolkata, Mumbai, New Delhi Subject: Re: Fedora and the moblin2 fork On Fri, May 22, 2009 at 5:25 AM, Adam Miller wrote: > In an attempt to get the ball rolling, I was hoping that we might be > able to get some direction on where bits need work and/or what parts > of Moblin we would like to include with Fedora. > > If this is already outlined somewhere and I might have simply missed > it, please post me the URL so that I can try and start working on bits > a pieces I am able as soon as I get some free time. Not yet, but its on my todo list. I might even get to it over the weekend. Got it working with rawhide. Looking for a place to host the rpms and srpms Not a clean build, but it works Satish -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list From tmraz at redhat.com Mon May 25 13:52:37 2009 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 25 May 2009 15:52:37 +0200 Subject: Anybody interested in vpnc Message-ID: <1243259557.2547.7.camel@vespa.frost.loc> Hi fellow packagers, is anybody interested in maintaining vpnc in Fedora and EPEL? I'd like to orphan it. I might stay as a comaintainer if you want. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From rawhide at fedoraproject.org Mon May 25 15:53:55 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Mon, 25 May 2009 15:53:55 +0000 (UTC) Subject: rawhide report: 20090525 changes Message-ID: <20090525155355.25BAB1B8003@releng2.fedora.phx.redhat.com> Compose started at Mon May 25 06:15:09 UTC 2009 Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 0 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From hugh at mimosa.com Mon May 25 18:22:02 2009 From: hugh at mimosa.com (D. Hugh Redelmeier) Date: Mon, 25 May 2009 14:22:02 -0400 (EDT) Subject: PolicyKit changes in F12 In-Reply-To: References: <1242262846.9432.9.camel@localhost.localdomain> <200905201730.51182.jreznik@redhat.com> Message-ID: | From: Rex Dieter | Seems frustrations are mounting: | "On policykit and standards" | http://lists.freedesktop.org/archives/polkit-devel/2009-May/000119.html [I'm an outsider. This thread is my introduction to the whole area. I'm not even a KDE user.] This certainly does not look like a healthy approach to standardization and cooperation. - the http://cgit.freedesktop.org/PolicyKit/tree/docs/PORTING-GUIDE appears clearly biased towards GNOME, even though its URL and title suggest universality: the first substantial line talks about polkit-gobject-1 (I *think* that gobject means GNOME object) - in a well-constituted standards process (not a de facto standard), stakeholders are consulted before changes are made. It looks as if KDE folks have been stakeholders and have not been allowed to even sign-off on the design, let alone participate in it. - for good reason, the normal output of a standardization process is a document, not code. There appears to be no complete documentation. - all stakeholders ought to be treated respectfully and equitably. That means, for example, KDE ought not the be second to GNOME. More particularly, the architectures should be open-ended, allowing for more than KDE and GNOME. See, for example, http://c2.com/cgi/wiki?ZeroOneInfinityRule I admit that my reactions may be ill-founded. Perhaps this is meant to be an example of "We reject: kings, presidents and voting. We believe in: rough consensus and running code" (The IETF approach, as phrased by http://en.wikipedia.org/wiki/David_D._Clark ) Even the IETF does have votes (but only of those in the room at the time). From rjones at redhat.com Mon May 25 21:07:26 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 25 May 2009 22:07:26 +0100 Subject: Anybody interested in vpnc In-Reply-To: <1243259557.2547.7.camel@vespa.frost.loc> References: <1243259557.2547.7.camel@vespa.frost.loc> Message-ID: <20090525210726.GA25677@amd.home.annexia.org> On Mon, May 25, 2009 at 03:52:37PM +0200, Tomas Mraz wrote: > is anybody interested in maintaining vpnc in Fedora and EPEL? I'd like > to orphan it. I might stay as a comaintainer if you want. It looks like Warren Togami has jumped in there to be co-maintainer. If you need someone else I can help. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From wtogami at redhat.com Mon May 25 21:29:32 2009 From: wtogami at redhat.com (Warren Togami) Date: Mon, 25 May 2009 17:29:32 -0400 Subject: Anybody interested in vpnc In-Reply-To: <20090525210726.GA25677@amd.home.annexia.org> References: <1243259557.2547.7.camel@vespa.frost.loc> <20090525210726.GA25677@amd.home.annexia.org> Message-ID: <4A1B0DBC.6070601@redhat.com> On 05/25/2009 05:07 PM, Richard W.M. Jones wrote: > On Mon, May 25, 2009 at 03:52:37PM +0200, Tomas Mraz wrote: >> is anybody interested in maintaining vpnc in Fedora and EPEL? I'd like >> to orphan it. I might stay as a comaintainer if you want. > > It looks like Warren Togami has jumped in there to be co-maintainer. > If you need someone else I can help. > > Rich. > wait what? Why are you volunteering me for something I know nothing about? Warren From jkeating at redhat.com Mon May 25 22:10:45 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 25 May 2009 15:10:45 -0700 Subject: Anybody interested in vpnc In-Reply-To: <20090525210726.GA25677@amd.home.annexia.org> References: <1243259557.2547.7.camel@vespa.frost.loc> <20090525210726.GA25677@amd.home.annexia.org> Message-ID: <1243289445.3144.12.camel@localhost.localdomain> On Mon, 2009-05-25 at 22:07 +0100, Richard W.M. Jones wrote: > > It looks like Warren Togami has jumped in there to be co-maintainer. > If you need someone else I can help. Warren is only there as watch commit and watch bugzilla. He doesn't have commit rights. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From laxathom at fedoraproject.org Tue May 26 00:42:51 2009 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Tue, 26 May 2009 02:42:51 +0200 Subject: mono-2.4 and ppc64 status In-Reply-To: <62bc09df0905230306wf18ad0fy1b82d70260ee673f@mail.gmail.com> References: <49ECEACA.1060304@gmail.com> <62bc09df0905230306wf18ad0fy1b82d70260ee673f@mail.gmail.com> Message-ID: <62bc09df0905251742w287777f2n74a43da20bca499d@mail.gmail.com> On Sat, May 23, 2009 at 12:06 PM, Xavier Lamien wrote: > On Mon, Apr 20, 2009 at 11:36 PM, Toshio Kuratomi wrote: >> Mono-2.4 has been built for ppc64 in F11 and devel. ?So people should be >> able to start rebuilding packages to include ppc64 as well as the other >> arches. ?There's a few wrinkles to watch out for: >> >> 1) Packages with dependencies will have to be built in dependency order. >> ?For instance, a lot of packages depend on the gtk-sharp2 bindings and >> those haven't been built yet. >> >> 2) Because of the imminent release of F11 we're in a freeze state. ?This >> ?means getting dependencies into the Fedora11 buildroot will require >> people to request tagging explicitly. ?This also means that if you >> rebuild your package for F11 with ppc64 support and later you have to >> get this package tagged into the release, all of the packages it depends >> on will need to be tagged in as well (otherwise your ppc64 build will >> have broken deps). >> >> With these in mind, I'd recommend people start rebuilding their mono >> packages on ppc64 in the devel branch. ?Keep track of the dependency >> chain you encounter. ?Then perform your builds in the Fedora 11 branch >> as updates after the release. ?I'm not a mono-sig member, though, so if >> you guys decide something else makes sense, just be sure to come up with >> a plan so we don't release with a bunch of broken dependencies. >> >> -Toshio >> > > gtk-sharp2 has been built for ppc64 and tag has been requested. > other packages will be rebuild once gtk-sharp2 tagged. > Heads up, gtk-sharp2 has been tagged and the following packages has been rebuilt for ppc64 availability. The list is a bit short for now as many of them need gnome-sharp (tag requested) ---------- gnome-sharp-2_24_0-4_fc11 gtksourceview2-sharp-1_0-5_svn89788_3_fc11 gecko-sharp2-0_13-3_fc11 webkit-sharp-0_2-2_fc11 monosim-1_3_0_2-3_fc11 avahi-0_6_25-2_fc11 (including sub-packages) mono-addins-0_4-7_20091702svn127062_1_fc11 gmime-2_4_3-5_fc11 bless-0_6_0-3_fc11 dbus-sharp-0_63-12_fc11 themonospot-0_7_1_1-3_fc11 -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB From wilmer at fedoraproject.org Tue May 26 01:37:00 2009 From: wilmer at fedoraproject.org (Wilmer Jaramillo M.) Date: Mon, 25 May 2009 21:07:00 -0430 Subject: Anybody interested in vpnc In-Reply-To: <1243259557.2547.7.camel@vespa.frost.loc> References: <1243259557.2547.7.camel@vespa.frost.loc> Message-ID: <2b26c4260905251837r1ee08656qcc1d1e90cbf25abf@mail.gmail.com> On Mon, May 25, 2009 at 9:22 AM, Tomas Mraz wrote: > Hi fellow packagers, > > is anybody interested in maintaining vpnc in Fedora and EPEL? I'd like > to orphan it. I might stay as a comaintainer if you want. I'm interesting in maintaing. -- Wilmer Jaramillo M., Fedora Project yum isn't useful for geeks, is just for lazy people irc.freenode.net: k0k @ #fedora-ve, #talug GPG Key Fingerprint = 0666 D0D3 24CE 8935 9C24 BBF1 87DD BEA2 A4B2 1E8A From dchen at redhat.com Tue May 26 02:27:20 2009 From: dchen at redhat.com (Ding-Yi Chen) Date: Tue, 26 May 2009 12:27:20 +1000 Subject: List of packages including country flags In-Reply-To: References: <1243228865.4642.70.camel@dhcp-0-207.bne.redhat.com> Message-ID: <1243304840.4784.17.camel@dhcp-0-207.bne.redhat.com> ? ??2009-05-25 ? 08:54 +0200?Kevin Kofler ??? > Ding-Yi Chen wrote: > > Unless there is a plan to complete the flags/icons for 83-78=5 layouts, > > it does not look consistent, does it? > > Those 5 layouts do not match a country, so it makes sense not to show any > flags for them. This is neither a real issue, nor an argument for removing > the remaining 78 flags. I prefer the consistence way. :-) > > QWERTY-- Default > > +-ja_JP > > +-ko_KR, > > +-de_CH > > +-fr_CH > > +-it_CH > > +-en_UK > > +... > > DVORAK-- > > QWERTZ-- > > +-de_CH > > +-de_CH at SunDeadKey > > +-de_CH at NOSunDeadKey > > +-de_CH at Mac > > +-fr_CH > > +-it_CH > > +... > > AZERTY--fr_FR > > +-fr_BE > > .... > > > > The benefits of this category systems are: > > 1. Input method developers only need to deal with the keys that matter > > (i.e. 0-9 and a-z) instead of go through the whole country list. > > 2. End users need fewer scroll for the first level category. > > 3. Reduce the redundancy: Many countries use essentially the standard > > QWERTY layout, no need to show all of them. > > 4. Flags can be assigned to the second level, either from the listing > > locale string or the regional setting. So Aussies, Kiwi, Singaporean can > > use their own flags (instead of American flags), everybody is happy. :-) > > Please propose these UI improvements to KDE upstream. They have nothing to > do with Fedora's policy on flags in any case. (You write yourself that > flags would still be useful, or even more useful, under that scheme.) > > Kevin Kofler I will bring up the key layout issue in i18n meeting first. Well, I myself did not against the flags, just want them to be informative and nobody should feel being left out. By the way, the keyboard icons should be customizable, so they can be flags, part of keyboards, pretty flowers or left blank for space/performance/political concerns. -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ From tibbs at math.uh.edu Tue May 26 04:20:17 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 25 May 2009 23:20:17 -0500 Subject: Agenda for the 2009-05-26 Packaging Committee meeting Message-ID: The Packaging Committee will meet Tuesday, 2009-05-26 at 17:00UTC in the #fedora-meeting channel on chat.freenode.net. FPC works from the agenda at https://fedoraproject.org/wiki/Packaging/GuidelinesTodo; there's just one item currently on the agenda: Phase out Buildroot - https://fedoraproject.org/wiki/Phase_out_buildroot_tag_%28draft%29 Users who wish to bring proposals before the committee are encouraged to read https://fedoraproject.org/wiki/Packaging/Committee#Guideline_Change_Procedure Anyone is welcome to create drafts under https://fedoraproject.org/wiki/PackagingDrafts and to update https://fedoraproject.org/wiki/PackagingDrafts/DraftsTodo; such updates will automatically appear on our agenda. - J< From zprikryl at redhat.com Tue May 26 05:47:35 2009 From: zprikryl at redhat.com (Zdenek Prikryl) Date: Tue, 26 May 2009 07:47:35 +0200 Subject: Abrt - should this be a feature? In-Reply-To: <1243007510.2617.3.camel@choeger6> References: <4A0DC949.7000601@fedoraproject.org> <4A116F78.3020607@redhat.com> <4A118A4C.3050909@fedoraproject.org> <4A1290AD.90205@redhat.com> <4A154D52.1000500@redhat.com> <4A16A449.1010602@redhat.com> <1243007510.2617.3.camel@choeger6> Message-ID: <4A1B8277.9010106@redhat.com> Christoph H?ger wrote: > Does abrt offer the installation of degubinfo for the just-crashed > application? Packagekit should make that a two click operation. > If an user wants to report a crash, abrt will install all needed debuginfos. For the installation abrt uses debuginfo-install, so all needed dependencies are installed too. -- Zdenek Prikryl From a.badger at gmail.com Tue May 26 05:57:00 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 25 May 2009 22:57:00 -0700 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: References: Message-ID: <4A1B84AC.8070804@gmail.com> On 05/25/2009 09:20 PM, Jason L Tibbitts III wrote: > The Packaging Committee will meet Tuesday, 2009-05-26 at 17:00UTC in > the #fedora-meeting channel on chat.freenode.net. > > FPC works from the agenda at > https://fedoraproject.org/wiki/Packaging/GuidelinesTodo; there's just > one item currently on the agenda: > > Phase out Buildroot - > https://fedoraproject.org/wiki/Phase_out_buildroot_tag_%28draft%29 > Unfortunately, a question of how safe this was with older rpms was raised and Panu hasn't gotten back to us yet. There's not much sense discussing this unless some rpm maintainer can take a look at the short thread here: https://www.redhat.com/archives/fedora-packaging/2009-May/msg00106.html Panu also asked for a clarification of the %define vs %global guideline. I wrote something up here but need more input from him or another rpm maintainer. https://www.redhat.com/archives/fedora-packaging/2009-May/msg00103.html Final note, I won't be present tomorrow but if anything comes up on the open discussion and needs another vote for quorum, I can vote via email. -Toshio From sundaram at fedoraproject.org Tue May 26 06:05:23 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 26 May 2009 11:35:23 +0530 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: References: Message-ID: <4A1B86A3.7040404@fedoraproject.org> On 05/26/2009 09:50 AM, Jason L Tibbitts III wrote: > The Packaging Committee will meet Tuesday, 2009-05-26 at 17:00UTC in > the #fedora-meeting channel on chat.freenode.net. > > FPC works from the agenda at > https://fedoraproject.org/wiki/Packaging/GuidelinesTodo; there's just > one item currently on the agenda: > > Phase out Buildroot - > https://fedoraproject.org/wiki/Phase_out_buildroot_tag_%28draft%29 How about phasing out Group tag as well? Rahul From rjones at redhat.com Tue May 26 08:06:13 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 26 May 2009 09:06:13 +0100 Subject: Anybody interested in vpnc In-Reply-To: <4A1B0DBC.6070601@redhat.com> References: <1243259557.2547.7.camel@vespa.frost.loc> <20090525210726.GA25677@amd.home.annexia.org> <4A1B0DBC.6070601@redhat.com> Message-ID: <20090526080407.GA27381@amd.home.annexia.org> On Mon, May 25, 2009 at 05:29:32PM -0400, Warren Togami wrote: > On 05/25/2009 05:07 PM, Richard W.M. Jones wrote: >> On Mon, May 25, 2009 at 03:52:37PM +0200, Tomas Mraz wrote: >>> is anybody interested in maintaining vpnc in Fedora and EPEL? I'd like >>> to orphan it. I might stay as a comaintainer if you want. >> >> It looks like Warren Togami has jumped in there to be co-maintainer. >> If you need someone else I can help. >> >> Rich. >> > > wait what? Why are you volunteering me for something I know nothing about? A simple misunderstanding - I looked at the ACLs and noticed that you were there already, so I assumed you'd already taken co-maint for the package. Tomas: If you still want me to co-maintain this package, let me know. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw From rjones at redhat.com Tue May 26 08:10:15 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 26 May 2009 09:10:15 +0100 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: <4A1B86A3.7040404@fedoraproject.org> References: <4A1B86A3.7040404@fedoraproject.org> Message-ID: <20090526081015.GB27381@amd.home.annexia.org> On Tue, May 26, 2009 at 11:35:23AM +0530, Rahul Sundaram wrote: > On 05/26/2009 09:50 AM, Jason L Tibbitts III wrote: > > The Packaging Committee will meet Tuesday, 2009-05-26 at 17:00UTC in > > the #fedora-meeting channel on chat.freenode.net. > > > > FPC works from the agenda at > > https://fedoraproject.org/wiki/Packaging/GuidelinesTodo; there's just > > one item currently on the agenda: > > > > Phase out Buildroot - > > https://fedoraproject.org/wiki/Phase_out_buildroot_tag_%28draft%29 > > How about phasing out Group tag as well? It seems like the Group tag is now optional in upstream RPM (since somewhere around F-11). I vote for also removing the %clean section. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 75 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From tmraz at redhat.com Tue May 26 08:19:45 2009 From: tmraz at redhat.com (Tomas Mraz) Date: Tue, 26 May 2009 10:19:45 +0200 Subject: Anybody interested in vpnc In-Reply-To: <20090526080407.GA27381@amd.home.annexia.org> References: <1243259557.2547.7.camel@vespa.frost.loc> <20090525210726.GA25677@amd.home.annexia.org> <4A1B0DBC.6070601@redhat.com> <20090526080407.GA27381@amd.home.annexia.org> Message-ID: <1243325985.2547.14.camel@vespa.frost.loc> On Tue, 2009-05-26 at 09:06 +0100, Richard W.M. Jones wrote: > On Mon, May 25, 2009 at 05:29:32PM -0400, Warren Togami wrote: > > On 05/25/2009 05:07 PM, Richard W.M. Jones wrote: > >> On Mon, May 25, 2009 at 03:52:37PM +0200, Tomas Mraz wrote: > >>> is anybody interested in maintaining vpnc in Fedora and EPEL? I'd like > >>> to orphan it. I might stay as a comaintainer if you want. > >> > >> It looks like Warren Togami has jumped in there to be co-maintainer. > >> If you need someone else I can help. > >> > >> Rich. > >> > > > > wait what? Why are you volunteering me for something I know nothing about? > > A simple misunderstanding - I looked at the ACLs and noticed that you > were there already, so I assumed you'd already taken co-maint for the > package. > > Tomas: If you still want me to co-maintain this package, let me know. I'll orphan it and you can be the primary maintainer. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From mschwendt at gmail.com Tue May 26 08:24:25 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 26 May 2009 10:24:25 +0200 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: <20090526081015.GB27381@amd.home.annexia.org> References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> Message-ID: <20090526102425.0e0a8616@faldor.intranet> On Tue, 26 May 2009 09:10:15 +0100, Richard wrote: > I vote for also removing the %clean section. Complete removal or only making "rm -rf %{buildroot}" the default? In case of the former, let's also add an implicit "rm -rf %{buildroot}" at start of %install. There are still packagers who don't empty the buildroot and who don't know rpmbuild's -bi --short-circuit options. From ml at kiewel-online.ch Tue May 26 08:39:27 2009 From: ml at kiewel-online.ch (Uwe Kiewel) Date: Tue, 26 May 2009 10:39:27 +0200 Subject: dependency errors while upgrading vom F10 to Rawhide (F11) Message-ID: <4A1BAABF.8050603@kiewel-online.ch> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I checked the ability to upgrade from F10 to F11 (Rawhide) directly using yum. A couple of weeks ago, there were dependency errors with python. These errors are not fixed until now. In my point of view, this issue should be fixed until GA of Leonidas. Thanks, Uwe ====================================================================== What I have done: [root at alberta ~]# yum --disablerepo=* --enablerepo=rawhide update I got: - --> Finished Dependency Resolution sos-1.8-11.fc10.noarch from installed has depsolving problems --> Missing Dependency: python(abi) = 2.5 is needed by package sos-1.8-11.fc10.noarch (installed) 7:kdegraphics-4.2.3-1.fc10.i386 from installed has depsolving problems --> Missing Dependency: libdjvulibre.so.15 is needed by package 7:kdegraphics-4.2.3-1.fc10.i386 (installed) PyQt4-4.4.4-6.fc10.i386 from installed has depsolving problems --> Missing Dependency: python(abi) = 2.5 is needed by package PyQt4-4.4.4-6.fc10.i386 (installed) PyQt4-4.4.4-6.fc10.i386 from installed has depsolving problems --> Missing Dependency: libpython2.5.so.1.0 is needed by package PyQt4-4.4.4-6.fc10.i386 (installed) kdeedu-marble-4.2.3-1.fc10.i386 from installed has depsolving problems --> Missing Dependency: libgps.so.17 is needed by package kdeedu-marble-4.2.3-1.fc10.i386 (installed) 7:kdegraphics-libs-4.2.3-1.fc10.i386 from installed has depsolving problems --> Missing Dependency: libexiv2.so.4 is needed by package 7:kdegraphics-libs-4.2.3-1.fc10.i386 (installed) 7:kdegraphics-4.2.3-1.fc10.i386 from installed has depsolving problems --> Missing Dependency: libpoppler.so.3 is needed by package 7:kdegraphics-4.2.3-1.fc10.i386 (installed) 6:kdelibs-4.2.3-2.fc10.i386 from installed has depsolving problems --> Missing Dependency: libssl.so.7 is needed by package 6:kdelibs-4.2.3-2.fc10.i386 (installed) Error: Missing Dependency: python(abi) = 2.5 is needed by package sos-1.8-11.fc10.noarch (installed) Error: Missing Dependency: libdjvulibre.so.15 is needed by package 7:kdegraphics-4.2.3-1.fc10.i386 (installed) Error: Missing Dependency: libpoppler.so.3 is needed by package 7:kdegraphics-4.2.3-1.fc10.i386 (installed) Error: Missing Dependency: libssl.so.7 is needed by package 6:kdelibs-4.2.3-2.fc10.i386 (installed) Error: Missing Dependency: libpython2.5.so.1.0 is needed by package PyQt4-4.4.4-6.fc10.i386 (installed) Error: Missing Dependency: libexiv2.so.4 is needed by package 7:kdegraphics-libs-4.2.3-1.fc10.i386 (installed) Error: Missing Dependency: libgps.so.17 is needed by package kdeedu-marble-4.2.3-1.fc10.i386 (installed) Error: Missing Dependency: python(abi) = 2.5 is needed by package PyQt4-4.4.4-6.fc10.i386 (installed) [root at alberta ~]# So, I tried to use updates-testing to fix, but more errors appeared: - --> Finished Dependency Resolution sos-1.8-11.fc10.noarch from installed has depsolving problems --> Missing Dependency: python(abi) = 2.5 is needed by package sos-1.8-11.fc10.noarch (installed) 7:kdegraphics-4.2.3-1.fc10.i386 from installed has depsolving problems --> Missing Dependency: libdjvulibre.so.15 is needed by package 7:kdegraphics-4.2.3-1.fc10.i386 (installed) PyQt4-4.4.4-6.fc10.i386 from installed has depsolving problems --> Missing Dependency: libpython2.5.so.1.0 is needed by package PyQt4-4.4.4-6.fc10.i386 (installed) PyQt4-4.4.4-6.fc10.i386 from installed has depsolving problems --> Missing Dependency: python(abi) = 2.5 is needed by package PyQt4-4.4.4-6.fc10.i386 (installed) createrepo-0.9.7-7.fc10.noarch from updates-testing has depsolving problems --> Missing Dependency: python(abi) = 2.5 is needed by package createrepo-0.9.7-7.fc10.noarch (updates-testing) kdeedu-marble-4.2.3-1.fc10.i386 from installed has depsolving problems --> Missing Dependency: libgps.so.17 is needed by package kdeedu-marble-4.2.3-1.fc10.i386 (installed) ntp-4.2.4p7-1.fc10.i386 from updates-testing has depsolving problems --> Missing Dependency: libcrypto.so.7 is needed by package ntp-4.2.4p7-1.fc10.i386 (updates-testing) 1:qt-4.5.1-10.fc10.i386 from updates-testing has depsolving problems --> Missing Dependency: libssl.so.7 is needed by package 1:qt-4.5.1-10.fc10.i386 (updates-testing) 1:qt-x11-4.5.1-10.fc10.i386 from updates-testing has depsolving problems --> Missing Dependency: libcrypto.so.7 is needed by package 1:qt-x11-4.5.1-10.fc10.i386 (updates-testing) 7:kdegraphics-libs-4.2.3-1.fc10.i386 from installed has depsolving problems --> Missing Dependency: libexiv2.so.4 is needed by package 7:kdegraphics-libs-4.2.3-1.fc10.i386 (installed) 7:kdegraphics-4.2.3-1.fc10.i386 from installed has depsolving problems --> Missing Dependency: libpoppler.so.3 is needed by package 7:kdegraphics-4.2.3-1.fc10.i386 (installed) 1:qt-x11-4.5.1-10.fc10.i386 from updates-testing has depsolving problems --> Missing Dependency: libssl.so.7 is needed by package 1:qt-x11-4.5.1-10.fc10.i386 (updates-testing) 6:kdelibs-4.2.3-3.fc10.i386 from updates-testing has depsolving problems --> Missing Dependency: libssl.so.7 is needed by package 6:kdelibs-4.2.3-3.fc10.i386 (updates-testing) preupgrade-1.1.0-1.fc10.noarch from updates-testing has depsolving problems --> Missing Dependency: python(abi) = 2.5 is needed by package preupgrade-1.1.0-1.fc10.noarch (updates-testing) 1:qt-4.5.1-10.fc10.i386 from updates-testing has depsolving problems --> Missing Dependency: libcrypto.so.7 is needed by package 1:qt-4.5.1-10.fc10.i386 (updates-testing) Error: Missing Dependency: python(abi) = 2.5 is needed by package sos-1.8-11.fc10.noarch (installed) Error: Missing Dependency: libdjvulibre.so.15 is needed by package 7:kdegraphics-4.2.3-1.fc10.i386 (installed) Error: Missing Dependency: libssl.so.7 is needed by package 1:qt-4.5.1-10.fc10.i386 (updates-testing) Error: Missing Dependency: libcrypto.so.7 is needed by package 1:qt-4.5.1-10.fc10.i386 (updates-testing) Error: Missing Dependency: libpoppler.so.3 is needed by package 7:kdegraphics-4.2.3-1.fc10.i386 (installed) Error: Missing Dependency: python(abi) = 2.5 is needed by package preupgrade-1.1.0-1.fc10.noarch (updates-testing) Error: Missing Dependency: libssl.so.7 is needed by package 1:qt-x11-4.5.1-10.fc10.i386 (updates-testing) Error: Missing Dependency: libpython2.5.so.1.0 is needed by package PyQt4-4.4.4-6.fc10.i386 (installed) Error: Missing Dependency: libexiv2.so.4 is needed by package 7:kdegraphics-libs-4.2.3-1.fc10.i386 (installed) Error: Missing Dependency: python(abi) = 2.5 is needed by package createrepo-0.9.7-7.fc10.noarch (updates-testing) Error: Missing Dependency: libcrypto.so.7 is needed by package ntp-4.2.4p7-1.fc10.i386 (updates-testing) Error: Missing Dependency: python(abi) = 2.5 is needed by package PyQt4-4.4.4-6.fc10.i386 (installed) Error: Missing Dependency: libgps.so.17 is needed by package kdeedu-marble-4.2.3-1.fc10.i386 (installed) Error: Missing Dependency: libssl.so.7 is needed by package 6:kdelibs-4.2.3-3.fc10.i386 (updates-testing) Error: Missing Dependency: libcrypto.so.7 is needed by package 1:qt-x11-4.5.1-10.fc10.i386 (updates-testing) [root at alberta ~]# -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBShuqvkJXG7BUuynnAQKxUA/+I1L2mLXzS72zK1LOQFtu6O0GX9HwuCFx PFJROClcq5aeeIBz7wJaqcxsbaRdIlTVwBziuvtSrkc2jCVOh2yftStv7Z0IGzHW PgN4YGu90+RbPH8w4W/98FKJyOhqPCBLDb0O6Y0i1u0LQDPlq9JBq+d+g0ycOqDt SBu2XdDzzcsbp5jOebMFjBye/MqBrXpkgeviWxQwFbvslXV7RMUyK/XoPEVWTOXw GzxuI6khw+rvK3DwMwBAVjEoxsGzzpk+PkqfggKnDn74QgWngrDBA52dJLYtHa3M INvXwoQH2U6cUtmQf2Gw/o5zwBEOCM1DYTy3k/KevasFixMUjCObrbWV98ojzcvq cOXMZvCZRTykwI0qh+gqB9A93TpLl8AJq9VmFSIogvHhEmFglJpeaBuCnpHtKlzr 5Q3B/oh1WYGWmdVp/kwc3CsbKS7hTHrnYn3FFbpwdqJ7Pju82y1pMXdoEnpVgdSU VJvX2sJRX5fPl1z5YnzrNOzJ5zzhUfn/qYk1e8tjFXMH5adoGZPSuoQYz90iInEu Ab0CxanzvY+pbIZ9dbvVA4TyB2ENFnqmEeqhdE0Fng9iGe5jblqMvMdq+vNvtl5z WrTyHy1cjclClL5ZH/a2WmJ8AfPx9ISKHZ53kD8vSAGBAphSWaxZaKbrxPEEWjr6 D3IZz8fJm1Q= =78wC -----END PGP SIGNATURE----- From sundaram at fedoraproject.org Tue May 26 08:43:31 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 26 May 2009 14:13:31 +0530 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: <20090526081015.GB27381@amd.home.annexia.org> References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> Message-ID: <4A1BABB3.6060306@fedoraproject.org> On 05/26/2009 01:40 PM, Richard W.M. Jones wrote: > On Tue, May 26, 2009 at 11:35:23AM +0530, Rahul Sundaram wrote: >> On 05/26/2009 09:50 AM, Jason L Tibbitts III wrote: >>> The Packaging Committee will meet Tuesday, 2009-05-26 at 17:00UTC in >>> the #fedora-meeting channel on chat.freenode.net. >>> >>> FPC works from the agenda at >>> https://fedoraproject.org/wiki/Packaging/GuidelinesTodo; there's just >>> one item currently on the agenda: >>> >>> Phase out Buildroot - >>> https://fedoraproject.org/wiki/Phase_out_buildroot_tag_%28draft%29 >> >> How about phasing out Group tag as well? > > It seems like the Group tag is now optional in upstream RPM (since > somewhere around F-11). Yes but there should be packaging guidelines adding a note that you can just drop it similar to built root. Does apt, smart and synaptic support comps though? do we care? Rahul From mschwendt at gmail.com Tue May 26 08:46:49 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 26 May 2009 10:46:49 +0200 Subject: unowned files and directories In-Reply-To: <4A183682.2000006@leemhuis.info> References: <4A183682.2000006@leemhuis.info> Message-ID: <20090526104649.4222c1ba@faldor.intranet> On Sat, 23 May 2009 19:46:42 +0200, Thorsten wrote: > But I'm a bit unsure what to do with the results. Filing bugs likely > would be huge amount of work as well as and never-ending task for a > small gain. http://mschwendt.fedorapeople.org/dircheck-remote.py Example usage: ./dircheck-remote.py -r rawhide -n ^vtk ./dircheck-remote.py -r rawhide > Options? Just ignore? Or will the automatic test scripts QA iirc plans > to set up check for things like that in the future? Different strategy. Also to raise awareness of the problem. Focus on those unowned directories - which bear a risk of breaking tarball compilation (e.g. old unowned empty versioned API directories which confuse tarball configure scripts, not limited to %_includedir), - which look like files might be misplaced (e.g. unowned directories in suspicious paths), - which look like missing subpackage dependencies (e.g. "yum install foo-something" doesn't lead to working software since "foo" is not installed automatically) - which pile up usability crap, such as empty versioned %docdirs. [1] [1] The latter is annoying. It breaks tab completion in /usr/share/doc (but also makes it harder to browse documentation with graphical file managers). Additionally, some packagers tend to use %doc in almost every subpackage, and I'm not sure they are aware of the consequences. From rjones at redhat.com Tue May 26 08:53:37 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 26 May 2009 09:53:37 +0100 Subject: Anybody interested in vpnc In-Reply-To: <1243325985.2547.14.camel@vespa.frost.loc> References: <1243259557.2547.7.camel@vespa.frost.loc> <20090525210726.GA25677@amd.home.annexia.org> <4A1B0DBC.6070601@redhat.com> <20090526080407.GA27381@amd.home.annexia.org> <1243325985.2547.14.camel@vespa.frost.loc> Message-ID: <20090526085337.GA27874@amd.home.annexia.org> On Tue, May 26, 2009 at 10:19:45AM +0200, Tomas Mraz wrote: > I'll orphan it and you can be the primary maintainer. Done. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html From mschwendt at gmail.com Tue May 26 08:57:29 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 26 May 2009 10:57:29 +0200 Subject: dependency errors while upgrading from F10 to Rawhide (F11) In-Reply-To: <4A1BAABF.8050603@kiewel-online.ch> References: <4A1BAABF.8050603@kiewel-online.ch> Message-ID: <20090526105729.7495bc12@faldor.intranet> On Tue, 26 May 2009 10:39:27 +0200, Uwe wrote: > I checked the ability to upgrade from F10 to F11 (Rawhide) directly > using yum. A couple of weeks ago, there were dependency errors with > python. These errors are not fixed until now. Nobody has posted the results of one of the upgradepathcheck scripts for a long time. :( > In my point of view, this issue should be fixed until GA of Leonidas. What set of repositories did you use when enabling updates-testing? In your quote I see lots of references to F10 updates-testing, but did you also enable F11 updates and F11 updates-testing? [Upgrading from an up-to-date F10 to F11 Rawhide is bound to fail. Not only because of packaging bugs (F10 packages having a higher EVR than F11 packages), but also because there is a growing number of updates and test-updates for F11 already.] From nicolas.mailhot at laposte.net Tue May 26 09:03:03 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 26 May 2009 11:03:03 +0200 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: <4A1BABB3.6060306@fedoraproject.org> References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> Message-ID: <2e0b0210933127a15f6cb510bf1f208a.squirrel@arekh.dyndns.org> Le Mar 26 mai 2009 10:43, Rahul Sundaram a ?crit : >> It seems like the Group tag is now optional in upstream RPM (since >> somewhere around F-11). > > Yes but there should be packaging guidelines adding a note that you > can > just drop it similar to built root. Does apt, smart and synaptic > support > comps though? do we care? I'd drop it from the font packaging spec templates at once if FPC & FESCO oked it. Each spurious line is pollution that frightens new packagers. -- Nicolas Mailhot From berrange at redhat.com Tue May 26 09:16:14 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 26 May 2009 10:16:14 +0100 Subject: PolicyKit changes in F12 In-Reply-To: References: <1242262846.9432.9.camel@localhost.localdomain> <200905201730.51182.jreznik@redhat.com> Message-ID: <20090526091614.GA31808@redhat.com> On Mon, May 25, 2009 at 02:22:02PM -0400, D. Hugh Redelmeier wrote: > | From: Rex Dieter > > | Seems frustrations are mounting: > | "On policykit and standards" > | http://lists.freedesktop.org/archives/polkit-devel/2009-May/000119.html > > [I'm an outsider. This thread is my introduction to the whole area. > I'm not even a KDE user.] > > This certainly does not look like a healthy approach to standardization > and cooperation. > > - the http://cgit.freedesktop.org/PolicyKit/tree/docs/PORTING-GUIDE > appears clearly biased towards GNOME, even though its URL and title > suggest universality: the first substantial line talks about > polkit-gobject-1 (I *think* that gobject means GNOME object) > > - in a well-constituted standards process (not a de facto standard), > stakeholders are consulted before changes are made. It looks > as if KDE folks have been stakeholders and have not been allowed to > even sign-off on the design, let alone participate in it. > > - for good reason, the normal output of a standardization process is a > document, not code. There appears to be no complete documentation. > > - all stakeholders ought to be treated respectfully and equitably. > That means, for example, KDE ought not the be second to GNOME. > More particularly, the architectures should be open-ended, allowing > for more than KDE and GNOME. See, for example, > http://c2.com/cgi/wiki?ZeroOneInfinityRule > > I admit that my reactions may be ill-founded. Perhaps this is meant You are attempting to create problems here which don't exist. David has already pointed out in another mail that if apps don't want to use the glib based library, they can talk to DBus directly. There are native QT bindings for DBus, and pretty much any other language can talk to DBus too with no deps on glib / gobject. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From ml at kiewel-online.ch Tue May 26 09:17:29 2009 From: ml at kiewel-online.ch (Uwe Kiewel) Date: Tue, 26 May 2009 11:17:29 +0200 Subject: dependency errors while upgrading from F10 to Rawhide (F11) In-Reply-To: <20090526105729.7495bc12@faldor.intranet> References: <4A1BAABF.8050603@kiewel-online.ch> <20090526105729.7495bc12@faldor.intranet> Message-ID: <4A1BB3A9.2020207@kiewel-online.ch> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt schrieb: > On Tue, 26 May 2009 10:39:27 +0200, Uwe wrote: > >> I checked the ability to upgrade from F10 to F11 (Rawhide) directly >> using yum. A couple of weeks ago, there were dependency errors with >> python. These errors are not fixed until now. > > Nobody has posted the results of one of the upgradepathcheck scripts > for a long time. :( > >> In my point of view, this issue should be fixed until GA of Leonidas. > > What set of repositories did you use when enabling updates-testing? > In your quote I see lots of references to F10 updates-testing, but > did you also enable F11 updates and F11 updates-testing? I think, yum only enables updates-testing for F10 if I type [root at alberta ~]# yum --disablerepo=* - --enablerepo=rawhide,updates-testing update How to enable the other update channels? > > [Upgrading from an up-to-date F10 to F11 Rawhide is bound to fail. > Not only because of packaging bugs (F10 packages having a higher > EVR than F11 packages), but also because there is a growing number > of updates and test-updates for F11 already.] > Does it meen an upgrade fron an Up-to-date F10 to F11 GA will also fail? Thanks, Uwe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBShuzqEJXG7BUuynnAQJYvQ/6AgRsZbYbIawgmunykKutdu278ODNsiHx l9KJlAibYbz00P0A7rm2CGlwqLVEUOGUM401jLB16AjNFEmDAIsE5GvjzFdeEQgR 0qrsfe4Thoek7RBRwdn1vr6YeYgqXy6WoYfeJ73OU34sS5eHMiyXtEnVNU8anVQq 2mGExPwZf5u2+S+uJPkZi73IV0PoZoD1Q3/lS5Z0qK7naim8gLyENjTVLlEtuUom RdF1TD1Z2PKN2ALTRSpciRSLJhVE4Ydhw/qhLQTIjkpKrBQLrt4+dZuECkbV7Pn0 aGpliuhGU+zv8ZihqduLykxR0uVi73am06vZ9ZfqyBWW/8N9e8TISD2zKvxZz8o+ 0O5eBUtHSBAtKr+kHcsn2rC8w7k3Zk6LBW6Ky2QEKLbKyyP1hp7N5pFFQO7knfQ9 K36AmL5/rJ1pXiXWUTURVlp/c6iRGBcxoNfDQX+UoDud6cin2G6nRO+GqgcUfV19 6UPh0q5jLfPh1h3cGPw1PKpAF0D9pwPk5giRs12wGPLyCdmD1sIpsl6oxLYrIWHJ ReVsl6jmdac/GLKbqFNZOyhpin0S7vZLioazvWQKDzmto6zj2kurJz5N74s8H9s3 e8K2zQ7O4iypSltlSOoP9P9k8LwqlkcYN5I5Zonwi3JASKD93be5F2MGd2awRkBf HNrdqxFuWS0= =hmb9 -----END PGP SIGNATURE----- From mschwendt at gmail.com Tue May 26 09:37:34 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 26 May 2009 11:37:34 +0200 Subject: dependency errors while upgrading from F10 to Rawhide (F11) In-Reply-To: <4A1BB3A9.2020207@kiewel-online.ch> References: <4A1BAABF.8050603@kiewel-online.ch> <20090526105729.7495bc12@faldor.intranet> <4A1BB3A9.2020207@kiewel-online.ch> Message-ID: <20090526113734.25fa0d23@faldor.intranet> On Tue, 26 May 2009 11:17:29 +0200, Uwe wrote: > > What set of repositories did you use when enabling updates-testing? > > In your quote I see lots of references to F10 updates-testing, but > > did you also enable F11 updates and F11 updates-testing? > > I think, yum only enables updates-testing for F10 if I type > > [root at alberta ~]# yum --disablerepo=* > - --enablerepo=rawhide,updates-testing update > > How to enable the other update channels? With a Yum-based distribution upgrade, you typically perform an upgrade in two steps. First you update to the right "fedora-release" package, so variables like $releasever used in your *.repo files expand to '11' instead of '10'. Then you run a plain "yum update", which automatically chooses the Fedora 11 repos. Alternatively, you hardcode the baseurls of the repos you want to upgrade to. [And as long as there is no F11 GA repo yet, you need to enable rawhide manually.] > > [Upgrading from an up-to-date F10 to F11 Rawhide is bound to fail. > > Not only because of packaging bugs (F10 packages having a higher > > EVR than F11 packages), but also because there is a growing number > > of updates and test-updates for F11 already.] > > > > Does it meen an upgrade fron an Up-to-date F10 to F11 GA will also fail? With Yum? Yes. The more packages in F11 Updates, the more likely you need them in order to replace your F10 Updates, which may be seen as newer than F11 GA. Same applies to Test Updates. From ml at kiewel-online.ch Tue May 26 09:43:54 2009 From: ml at kiewel-online.ch (Uwe Kiewel) Date: Tue, 26 May 2009 11:43:54 +0200 Subject: dependency errors while upgrading from F10 to Rawhide (F11) In-Reply-To: <20090526113734.25fa0d23@faldor.intranet> References: <4A1BAABF.8050603@kiewel-online.ch> <20090526105729.7495bc12@faldor.intranet> <4A1BB3A9.2020207@kiewel-online.ch> <20090526113734.25fa0d23@faldor.intranet> Message-ID: <4A1BB9DA.4030302@kiewel-online.ch> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt schrieb: > On Tue, 26 May 2009 11:17:29 +0200, Uwe wrote: > >>> What set of repositories did you use when enabling updates-testing? >>> In your quote I see lots of references to F10 updates-testing, but >>> did you also enable F11 updates and F11 updates-testing? >> I think, yum only enables updates-testing for F10 if I type >> >> [root at alberta ~]# yum --disablerepo=* >> - --enablerepo=rawhide,updates-testing update >> >> How to enable the other update channels? > > With a Yum-based distribution upgrade, you typically perform an upgrade in > two steps. First you update to the right "fedora-release" package, so > variables like $releasever used in your *.repo files expand to '11' > instead of '10'. Then you run a plain "yum update", which automatically > chooses the Fedora 11 repos. I know this procedure. Do we have the F11 repos yet? I don't think so, because F11 is not GA. > > Alternatively, you hardcode the baseurls of the repos you want to upgrade > to. > > [And as long as there is no F11 GA repo yet, you need to enable rawhide > manually.] > >>> [Upgrading from an up-to-date F10 to F11 Rawhide is bound to fail. >>> Not only because of packaging bugs (F10 packages having a higher >>> EVR than F11 packages), but also because there is a growing number >>> of updates and test-updates for F11 already.] >>> >> Does it meen an upgrade fron an Up-to-date F10 to F11 GA will also fail? > > With Yum? Yes. > > The more packages in F11 Updates, the more likely you need them in order > to replace your F10 Updates, which may be seen as newer than F11 GA. Same > applies to Test Updates. > That will be a brake a possible option from the past. :-( -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBShu52UJXG7BUuynnAQIBLg/7BGAQBNd6hANrgPhy+JQrF1+Cx173UTaz N0Eo6hkUap6uqEcgRUjvSW6WQrupfUtNMdpbRDqLYUKl+iUrTZrfJd2ml7m8IBUt 1CmntDuyIaijC/KnGdOsd0wsX9L9wCY9/N2jzl1RHDbptzu/6PwS/JdPGpnZGlu/ R+fM1JM0vdQlp6ngIHQckWe3Licv807gIHYtD3vb4m8/hjWe5fEKr1GvB9K2poze Bg40kyq5iv76w4CEoKO+y3m/Ss196d6kXfjWpEKsujj3NZtTGwe1uQg+kXpKE4ee WBd1ghu0QqVKaxF4xodIZsac5XYPgG4NGBwgKXHoXTc6V58QamCrs1uqcs1AKPg0 UiGWDeeYTZE8T1tf0pSAOS/tSsSUBE37FVwEULhdYswTDiq8t2CYuBeb2a4E7jUE dLqi7DgaGNKbAin2ycNHFBPwY3e1V9bNvjMrxswaEa7Rl36Jl9SltYdUbHg2IPxH tHjPKEpW8Mt0xVWeB00tIOfWYHvOPupLxw3zwOr63xFSPTSgLpMbgaIWJh5MOObe u2Gcd8lmfeFjAq/RdJF+5UPol7K+EPJywEXJmqeJFyIeS8o++K2ETnuBDH/kMy04 QkyhCeAKe5j+Gu71ZtSxYanCDMMwg6YcL0UpHcI3xW+Bi1UdcUzFnieR8dSeWyxT t/dgokC4WyQ= =xJF4 -----END PGP SIGNATURE----- From mschwendt at gmail.com Tue May 26 09:56:36 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 26 May 2009 11:56:36 +0200 Subject: dependency errors while upgrading from F10 to Rawhide (F11) In-Reply-To: <4A1BB9DA.4030302@kiewel-online.ch> References: <4A1BAABF.8050603@kiewel-online.ch> <20090526105729.7495bc12@faldor.intranet> <4A1BB3A9.2020207@kiewel-online.ch> <20090526113734.25fa0d23@faldor.intranet> <4A1BB9DA.4030302@kiewel-online.ch> Message-ID: <20090526115636.4e5ca9a3@faldor.intranet> On Tue, 26 May 2009 11:43:54 +0200, Uwe wrote: > > With a Yum-based distribution upgrade, you typically perform an upgrade in > > two steps. First you update to the right "fedora-release" package, so > > variables like $releasever used in your *.repo files expand to '11' > > instead of '10'. Then you run a plain "yum update", which automatically > > chooses the Fedora 11 repos. > > I know this procedure. Then use it. ;) > Do we have the F11 repos yet? I don't think so, > because F11 is not GA. F11 "updates" and F11 "updates-testing" _are_ available F11 release Everything, however, is still in "development" (Rawhide). > > The more packages in F11 Updates, the more likely you need them in order > > to replace your F10 Updates, which may be seen as newer than F11 GA. Same > > applies to Test Updates. > > > > That will be a brake a possible option from the past. :-( No. With Yum it has always been like that and the primary reason for creating the old upgradecheck.py script from the Fedora Extras era. From pmatilai at laiskiainen.org Tue May 26 10:08:50 2009 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Tue, 26 May 2009 13:08:50 +0300 (EEST) Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: <4A1BABB3.6060306@fedoraproject.org> References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> Message-ID: On Tue, 26 May 2009, Rahul Sundaram wrote: > On 05/26/2009 01:40 PM, Richard W.M. Jones wrote: >> On Tue, May 26, 2009 at 11:35:23AM +0530, Rahul Sundaram wrote: >>> On 05/26/2009 09:50 AM, Jason L Tibbitts III wrote: >>>> The Packaging Committee will meet Tuesday, 2009-05-26 at 17:00UTC in >>>> the #fedora-meeting channel on chat.freenode.net. >>>> >>>> FPC works from the agenda at >>>> https://fedoraproject.org/wiki/Packaging/GuidelinesTodo; there's just >>>> one item currently on the agenda: >>>> >>>> Phase out Buildroot - >>>> https://fedoraproject.org/wiki/Phase_out_buildroot_tag_%28draft%29 >>> >>> How about phasing out Group tag as well? >> >> It seems like the Group tag is now optional in upstream RPM (since >> somewhere around F-11). > > Yes but there should be packaging guidelines adding a note that you can > just drop it similar to built root. Does apt, smart and synaptic support > comps though? do we care? Smart in GUI-mode and Synaptic currently use the Group tag to, well, group the packages for viewing: http://laiskiainen.org/tmp/smartpm-groups.png. Apt (and smartpm in cli-mode) dont care. Without spec specified Group they all get lumped under "Unspecified" but as the group tags are already wildly inconsistent, full of typos etc... dunno if it's such a big loss. - Panu - From sundaram at fedoraproject.org Tue May 26 10:14:52 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 26 May 2009 15:44:52 +0530 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> Message-ID: <4A1BC11C.5080505@fedoraproject.org> On 05/26/2009 03:38 PM, Panu Matilainen wrote: > Smart in GUI-mode and Synaptic currently use the Group tag to, well, > group the packages for viewing: > http://laiskiainen.org/tmp/smartpm-groups.png. That's great. Apt (and smartpm in > cli-mode) dont care. > > Without spec specified Group they all get lumped under "Unspecified" but > as the group tags are already wildly inconsistent, full of typos etc... > dunno if it's such a big loss. Yes, the packaging/review guidelines only care about comps grouping and not the Group tag. So for many packages, it is pretty arbitrary. I guess, we can just lose both build root and group tag to reduce noise. Rahul From ml at kiewel-online.ch Tue May 26 10:16:13 2009 From: ml at kiewel-online.ch (Uwe Kiewel) Date: Tue, 26 May 2009 12:16:13 +0200 Subject: dependency errors while upgrading from F10 to Rawhide (F11) In-Reply-To: <20090526115636.4e5ca9a3@faldor.intranet> References: <4A1BAABF.8050603@kiewel-online.ch> <20090526105729.7495bc12@faldor.intranet> <4A1BB3A9.2020207@kiewel-online.ch> <20090526113734.25fa0d23@faldor.intranet> <4A1BB9DA.4030302@kiewel-online.ch> <20090526115636.4e5ca9a3@faldor.intranet> Message-ID: <4A1BC16D.6000707@kiewel-online.ch> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt schrieb: > On Tue, 26 May 2009 11:43:54 +0200, Uwe wrote: > >>> With a Yum-based distribution upgrade, you typically perform an upgrade in >>> two steps. First you update to the right "fedora-release" package, so >>> variables like $releasever used in your *.repo files expand to '11' >>> instead of '10'. Then you run a plain "yum update", which automatically >>> chooses the Fedora 11 repos. >> I know this procedure. > > Then use it. ;) That was not the right way: rpm -Uvh ftp://ftp.solnet.ch/mirror/fedora/linux/development/i386/os/Packages/fedora-release-notes-11.0.0-2.fc11.noarch.rpm rpm -Uvh ftp://ftp.solnet.ch/mirror/fedora/linux/development/i386/os/Packages/fedora-release-11-1.noarch.rpm [root at alberta ~]# yum clean all Loaded plugins: fastestmirror, refresh-packagekit Cleaning up Everything Cleaning up list of fastest mirrors [root at alberta ~]# yum update Loaded plugins: fastestmirror, refresh-packagekit Determining fastest mirrors YumRepo Error: All mirror URLs are not using ftp, http[s] or file. Eg. / removing mirrorlist with no valid mirrors: //var/cache/yum/fedora/mirrorlist.txt Error: Cannot find a valid baseurl for repo: fedora [root at alberta ~]# another try: [root at alberta ~]# yum --enablerepo=rawhide --disablerepo=fedora update Loaded plugins: fastestmirror, refresh-packagekit Loading mirror speeds from cached hostfile YumRepo Error: All mirror URLs are not using ftp, http[s] or file. Eg. / removing mirrorlist with no valid mirrors: //var/cache/yum/updates/mirrorlist.txt Cannot find a valid baseurl for repo: updates [root at alberta ~]# last try: yum --disablerepo=* --enablerepo=rawhide update and back to the errors of my very 1st posting... :-( -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBShvBbUJXG7BUuynnAQJMiQ//VR/88spZ1C4oDiZx+XrZ0bT/SdeMrTmp VNYwCHLKA8nttxucdMRU3EBvehs7goMHGw8Rbfv0f0ioSMiXrUSOMmf/qiZfqb8+ IGB12T3kYEZmxiYhk4zIFIDZKiUT715bChZ0F5eW2uWiVDD3pCeadWjWHSH+6JE8 smIySAH4GnbULOBkH/XW6+ge7JU5HKZkx//gcKS6qOja7T4/+BQ88VyP/qoiJOHG o2Zw3UKBN+KLJiHN+4EgiyPOr0Azg2ZD6GBIk3gKpFlTZW8zBscKyFU4EVfLan4r 8pjqVQxhO1o6Q7X08liu7/YNWj3ZAuImMTrHS7/NJPCdHfCO+LyiRIxJu65ozxjK jtQnAKLMCnPZjxLshWtDeeunEhV9ZrSQR1djYMUhnTW2tksJ/W6s7HhBk5h7sa++ N4G75yLOGycNWX7shrETuppAKuauhP34pG8RAZb0CXi539fZpPytdM5dRqwc1hde WhDw/ZZQj6kzUCjzR+4FVkV9hnMQxsCVkvFP9NLLUiFlSgdbhSeLsbcsNSg73SNn Owh6LfMgfoOmQPHzBCNuTxgRHwrguVt1zzUG47Zos8w6WfDgoA9XF8hQkYpelTox 2Ofu0pUNEUceUtMO+LYLPHXqxtXsC/fLQe7w7FmrimgDF50obHLqHlvzBsWKIVgh EG7EnsXf7ic= =i5oW -----END PGP SIGNATURE----- From mschwendt at gmail.com Tue May 26 10:35:19 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 26 May 2009 12:35:19 +0200 Subject: dependency errors while upgrading from F10 to Rawhide (F11) In-Reply-To: <4A1BC16D.6000707@kiewel-online.ch> References: <4A1BAABF.8050603@kiewel-online.ch> <20090526105729.7495bc12@faldor.intranet> <4A1BB3A9.2020207@kiewel-online.ch> <20090526113734.25fa0d23@faldor.intranet> <4A1BB9DA.4030302@kiewel-online.ch> <20090526115636.4e5ca9a3@faldor.intranet> <4A1BC16D.6000707@kiewel-online.ch> Message-ID: <20090526123519.764c4230@faldor.intranet> On Tue, 26 May 2009 12:16:13 +0200, Uwe wrote: > That was not the right way: It is. > Error: Cannot find a valid baseurl for repo: fedora *sigh* I told you there is no F11 release repo _yet_. Hence you need to disable "fedora" and enable "rawhide". > another try: > > [root at alberta ~]# yum --enablerepo=rawhide --disablerepo=fedora update > Loaded plugins: fastestmirror, refresh-packagekit > Loading mirror speeds from cached hostfile > YumRepo Error: All mirror URLs are not using ftp, http[s] or file. > Eg. / > removing mirrorlist with no valid mirrors: > //var/cache/yum/updates/mirrorlist.txt No idea what you get in there. Don't want to guess. Why didn't you do some minimal trouble-shooting? > Cannot find a valid baseurl for repo: updates wget 'http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f11&arch=i386' gives a list that looks good. From mschwendt at gmail.com Tue May 26 10:46:29 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 26 May 2009 12:46:29 +0200 Subject: dependency errors while upgrading from F10 to Rawhide (F11) In-Reply-To: <4A1BC16D.6000707@kiewel-online.ch> References: <4A1BAABF.8050603@kiewel-online.ch> <20090526105729.7495bc12@faldor.intranet> <4A1BB3A9.2020207@kiewel-online.ch> <20090526113734.25fa0d23@faldor.intranet> <4A1BB9DA.4030302@kiewel-online.ch> <20090526115636.4e5ca9a3@faldor.intranet> <4A1BC16D.6000707@kiewel-online.ch> Message-ID: <20090526124629.101d4d39@faldor.intranet> On Tue, 26 May 2009 12:16:13 +0200, Uwe wrote: > rpm -Uvh > ftp://ftp.solnet.ch/mirror/fedora/linux/development/i386/os/Packages/fedora-release-11-1.noarch.rpm > And to add some trouble-shooting myself, this new fedora-release package points to a mirrorlist URL that returns an XML file instead of the old plain-text list of baseurls. Perhaps upgrade tools like Yum are needed to handle it. But that doesn't prove that hardcoding the F11 repository baseurls would not work. Especially if above you choose a local mirror already anyway. From ml at kiewel-online.ch Tue May 26 11:03:17 2009 From: ml at kiewel-online.ch (Uwe Kiewel) Date: Tue, 26 May 2009 13:03:17 +0200 Subject: dependency errors while upgrading from F10 to Rawhide (F11) In-Reply-To: <20090526124629.101d4d39@faldor.intranet> References: <4A1BAABF.8050603@kiewel-online.ch> <20090526105729.7495bc12@faldor.intranet> <4A1BB3A9.2020207@kiewel-online.ch> <20090526113734.25fa0d23@faldor.intranet> <4A1BB9DA.4030302@kiewel-online.ch> <20090526115636.4e5ca9a3@faldor.intranet> <4A1BC16D.6000707@kiewel-online.ch> <20090526124629.101d4d39@faldor.intranet> Message-ID: <4A1BCC75.8060803@kiewel-online.ch> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt schrieb: > On Tue, 26 May 2009 12:16:13 +0200, Uwe wrote: > >> rpm -Uvh >> ftp://ftp.solnet.ch/mirror/fedora/linux/development/i386/os/Packages/fedora-release-11-1.noarch.rpm >> > > And to add some trouble-shooting myself, this new fedora-release package > points to a mirrorlist URL that returns an XML file instead of the old > plain-text list of baseurls. Perhaps upgrade tools like Yum are needed to > handle it. But that doesn't prove that hardcoding the F11 repository > baseurls would not work. Especially if above you choose a local mirror > already anyway. > I think, thats the point, why it would no be possible to go the way described in http://fedoraproject.org/wiki/YumUpgradeFaq (yet) I will try it again after Leonidas is GA - expecting it won't work. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBShvMdEJXG7BUuynnAQJ4pxAAjHKgNDOfDyh/8S0vUu9Gs75sZusJh+jW Y9Otp1EM7Kcwlo5HXLdqouBaL92mCumtmApU14a7emZ6e7IrnvhstDNHv4wAmXey 1JHnBCYh/8WygMkZRgoW6oWjsgNXBBbQNwJi64lfFxWfBKk+JUmcT1tiBcXLw57P OOaMN/IcERglmvvaJt5w2eaTd7rRIqf8ikn02bKvX4TTOWzCueE0Mp2y45rkgcRh OKINsulviRx8S8abzh7n2Ntg4GiIG60D5hOfT4OyCnBfQUP3uSm6ksPz72RBDyy6 FyAH0iMSwfzNTywEUmYcBvqjC9jLQNiRdZzQ7uAHKKliwGT9S+n/sSoHZCqyCn1f jWUvFmwQ3J3fTOUCavvVAo1PTakieNjwepriwIsvWdvGP4sRJD8pU5/RxCkqNkx2 DyMe5CFTdaaxdmkXKHQClRH+4pOPAQ7HvF4/RjHwM2UxB7D5TiA8tRA29Ok6WEJp EEhm0UrUZqD7JV1xPFuW8St6tM8olBcss0JZOu/NctDp/dzUQ5zq/Qu+P4lBs5PY Q9YMbc/1nkFZ+BRQ1B87D5BU7s/OYeH8viFbBYdlwD/IpnTJVy/0wxoxrRK9DGZH ghzx51t03iYPmGC9QHAV3eWTHK6xGYKKoIR2qoWtZKXgUEojxLwEIYgVRnp6IDcP bYHuAunh7B0= =z7ae -----END PGP SIGNATURE----- From j.w.r.degoede at hhs.nl Tue May 26 11:15:23 2009 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 26 May 2009 13:15:23 +0200 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: <4A1BC11C.5080505@fedoraproject.org> References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> Message-ID: <4A1BCF4B.8050802@hhs.nl> On 05/26/2009 12:14 PM, Rahul Sundaram wrote: > On 05/26/2009 03:38 PM, Panu Matilainen wrote: > >> Smart in GUI-mode and Synaptic currently use the Group tag to, well, >> group the packages for viewing: >> http://laiskiainen.org/tmp/smartpm-groups.png. > > That's great. > > Apt (and smartpm in >> cli-mode) dont care. >> >> Without spec specified Group they all get lumped under "Unspecified" but >> as the group tags are already wildly inconsistent, full of typos etc... >> dunno if it's such a big loss. > > Yes, the packaging/review guidelines only care about comps grouping and > not the Group tag. So for many packages, it is pretty arbitrary. I > guess, we can just lose both build root and group tag to reduce noise. > Can we please not remove the Group tag, it is actually quite usefull. What we need to remove / loose is comps. Having all this info in a centralized database is stupid. The spec files should tell which group(s) the package belongs in. So that when one adds a new package, this gets done right more or less automatically (and is part of the review). I actually use a script checking for rpms with the Amusements/Games group which are not in the comps games group, nor in a blacklist I keep. Each time I run this, this results in me adding a few games to comps which people forgot to add. comps is broken, really it is, this whole central database concept sucks. I'm not saying the rpm Group tag is the answer, but we should search for an answer which consists of putting the data inside the spec file. Regards, Hans From tcallawa at redhat.com Tue May 26 13:19:44 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 26 May 2009 09:19:44 -0400 Subject: Conflicts not being resolved In-Reply-To: <20090523123735.009ddf62@faldor.intranet> References: <20090523123735.009ddf62@faldor.intranet> Message-ID: <4A1BEC70.5090609@redhat.com> On 05/23/2009 06:37 AM, Michael Schwendt wrote: > https://fedoraproject.org/wiki/Packaging/Conflicts > https://fedoraproject.org/wiki/Packaging/Conflicts#Other_Uses_of_Conflicts: > > | As a general rule, Fedora packages must NOT contain any usage of the > | Conflicts: field. > > | Keep in mind that implicit conflicts are NEVER acceptable. > > | If your package conflicts with another package, then you must either > | resolve the conflict, or mark it with Conflicts:. > > What happens so far is that packagers simply ignore it. > Again I see bz tickets from Nov 2008 which have not been responded to. > > The page doesn't point out that missing "Conflicts" tags are bad. > Implicit conflicts are not detected prior to an RPM transaction check. > Typically, implicit conflicts cause tools like Yum to fail, leaving it > to the user to do the head-scratching and to remove packages manually. This seems like a great place for someone who is looking for a way to help out Fedora to work on, closing out these bugs. ~spot From tcallawa at redhat.com Tue May 26 13:22:37 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 26 May 2009 09:22:37 -0400 Subject: Breaking deps deliberately In-Reply-To: <1243091027.12703.6.camel@localhost.localdomain> References: <20090513111343.4d79d48f@faldor.intranet> <20090513134744.GA19304@amd.home.annexia.org> <4A0AD15F.6040300@fedoraproject.org> <20090513135728.GA19428@amd.home.annexia.org> <20090513142048.GA19610@amd.home.annexia.org> <20090513142742.GB19610@amd.home.annexia.org> <20090513220839.GA22106@amd.home.annexia.org> <20090514114703.6ea61d2d@faldor.intranet> <1243091027.12703.6.camel@localhost.localdomain> Message-ID: <4A1BED1D.3090508@redhat.com> On 05/23/2009 11:03 AM, Braden McDaniel wrote: > I didn't know about this until this subthread... and I asked a rather > senior packaging person about it some months ago and didn't get this > information. So I think this is poorly publicized; and perhaps poorly > positioned in the packaging guidelines. Always possible. I'm the first to admit that the packaging guidelines need a thorough reorganization. The information is documented here: https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Minor_release_bumps_for_old_branches Suggestions on improvements are always welcomed (as long as they are constructive). ~spot From tcallawa at redhat.com Tue May 26 13:26:07 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 26 May 2009 09:26:07 -0400 Subject: Package Maintainers Flags policy In-Reply-To: <4A16F753.9080808@gmail.com> References: <20090518090953.5698908a@ohm.scrye.com> <870180fe0905180845j553c38d9k3865089ea9dc1505@mail.gmail.com> <4A16F753.9080808@gmail.com> Message-ID: <4A1BEDEF.8080800@redhat.com> On 05/22/2009 03:04 PM, Frank Murphy wrote: > 1: Has the flags policy, anything to do with RH becoming more prominent > on the site? > No problem with them becoming more prominent, they do sponsor a lot. > If yes, say so, likewise no No. The fact that I authored the original flag policy had more to do with my awareness of the prior unwritten "no flags" policy, and nothing at all to do with Red Hat. Red Hat Legal did offer advice as to some of the wording, but they did not mandate it, nor did Red Hat instigate the creation of the flag policy. > 2: Would our main Sponsor, suffer financially. > As a result of inclusion of certain flags? No. As Adam said, having a "no flags" policy would make things slightly simpler for Red Hat to compose RHEL, but not enough to suffer any significant financial consequence. > 3: Would the fedora project survive, if there was no main sponsor? Thankfully, this is a problem we do not have to be concerned about for the time being. ~spot From tcallawa at redhat.com Tue May 26 13:31:01 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 26 May 2009 09:31:01 -0400 Subject: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520135717.GA13882@nostromo.devel.redhat.com> Message-ID: <4A1BEF15.70109@redhat.com> On 05/23/2009 03:45 PM, Christopher Stone wrote: > What are the T-6 restrictions? A google search only came up with this thread. There are 6 countries that Fedora cannot be legally exported to (as a result of US export restrictions): Cuba, Iran, Iraq, North Korea, Sudan and Syria These are known as the "T-6" countries. No individual associated with the Fedora project (or mirror site) should provide Fedora software to anyone in those countries, even if they are not in the US. Here's the full legal paragraph: "Because Fedora software contains encryption technology, Fedora software and technical information is subject to the U.S. Export Administration Regulations and other U.S. and foreign law, and may not be exported or re-exported to certain countries (currently Cuba, Iran, Iraq, North Korea, Sudan and Syria) or to persons or entities prohibited from receiving U.S. exports (including those (a) on the Bureau of Industry and Security Denied Parties List or Entity List, (b) on the Office of Foreign Assets Control list of Specially Designated Nationals and Blocked Persons, and (c) involved with missile technology or nuclear, chemical or biological weapons). You may not download Fedora software or technical information if you are located in one of these countries, or otherwise affected by these restrictions. You may not provide Fedora software or technical information to individuals or entities located in one of these countries or otherwise affected by these restrictions. You are also responsible for compliance with foreign law requirements applicable to the import and use of Fedora software and technical information." Tom "spot" Callaway, Fedora Legal From jreznik at redhat.com Tue May 26 13:37:22 2009 From: jreznik at redhat.com (Jaroslav Reznik) Date: Tue, 26 May 2009 15:37:22 +0200 Subject: PolicyKit changes in F12 In-Reply-To: <20090526091614.GA31808@redhat.com> References: <1242262846.9432.9.camel@localhost.localdomain> <20090526091614.GA31808@redhat.com> Message-ID: <200905261537.22667.jreznik@redhat.com> On Martes 26 Mayo 2009 11:16:14 Daniel P. Berrange escribi?: > On Mon, May 25, 2009 at 02:22:02PM -0400, D. Hugh Redelmeier wrote: > > | From: Rex Dieter > > | > > | Seems frustrations are mounting: > > | "On policykit and standards" > > | http://lists.freedesktop.org/archives/polkit-devel/2009-May/000119.html > > > > [I'm an outsider. This thread is my introduction to the whole area. > > I'm not even a KDE user.] > > > > This certainly does not look like a healthy approach to standardization > > and cooperation. > > > > - the http://cgit.freedesktop.org/PolicyKit/tree/docs/PORTING-GUIDE > > appears clearly biased towards GNOME, even though its URL and title > > suggest universality: the first substantial line talks about > > polkit-gobject-1 (I *think* that gobject means GNOME object) > > > > - in a well-constituted standards process (not a de facto standard), > > stakeholders are consulted before changes are made. It looks > > as if KDE folks have been stakeholders and have not been allowed to > > even sign-off on the design, let alone participate in it. > > > > - for good reason, the normal output of a standardization process is a > > document, not code. There appears to be no complete documentation. > > > > - all stakeholders ought to be treated respectfully and equitably. > > That means, for example, KDE ought not the be second to GNOME. > > More particularly, the architectures should be open-ended, allowing > > for more than KDE and GNOME. See, for example, > > http://c2.com/cgi/wiki?ZeroOneInfinityRule > > > > I admit that my reactions may be ill-founded. Perhaps this is meant > > You are attempting to create problems here which don't exist. David > has already pointed out in another mail that if apps don't want to use > the glib based library, they can talk to DBus directly. There are native > QT bindings for DBus, and pretty much any other language can talk to > DBus too with no deps on glib / gobject. Seems like direct DBus communication is the only way to do it from Qt/KDE apps as PolKit library requires gtk_init() somewhere in code... I've prepared patch for polkit-qt to the new PK1 Core API but... Or is there any other way to initialize glib without need for it? I'm not familiar with GTK app development... But library that expects gtk_init somewhere in application to be correctly intialized... PK1 should be split into parts - cross-desktop backends should be on freedesktop, gnome specific libraries should be in gnome repository. This should stop confusion. Jaroslav > Daniel > -- > > |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ > |: :| http://libvirt.org -o- http://virt-manager.org -o- > |: http://ovirt.org :| http://autobuild.org -o- > |: http://search.cpan.org/~danberr/ :| GnuPG: 7D3B9505 -o- F3C9 553F A1DA > |: 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Jaroslav ?ezn?k Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ From skvidal at fedoraproject.org Tue May 26 13:40:45 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 26 May 2009 09:40:45 -0400 (EDT) Subject: Conflicts not being resolved In-Reply-To: <4A1BEC70.5090609@redhat.com> References: <20090523123735.009ddf62@faldor.intranet> <4A1BEC70.5090609@redhat.com> Message-ID: On Tue, 26 May 2009, Tom \"spot\" Callaway wrote: > > This seems like a great place for someone who is looking for a way to > help out Fedora to work on, closing out these bugs. > I wrote a script to dump out "potential file conflicts". This needs to be dumped into the auto-qa work so we can look for file conflicts w/o explicit pkg conflicts automatically. -sv From mclasen at redhat.com Tue May 26 13:44:56 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 26 May 2009 09:44:56 -0400 Subject: PolicyKit changes in F12 In-Reply-To: <200905261537.22667.jreznik@redhat.com> References: <1242262846.9432.9.camel@localhost.localdomain> <20090526091614.GA31808@redhat.com> <200905261537.22667.jreznik@redhat.com> Message-ID: <1243345496.2357.8.camel@localhost.localdomain> On Tue, 2009-05-26 at 15:37 +0200, Jaroslav Reznik wrote: > > Seems like direct DBus communication is the only way to do it from Qt/KDE apps > as PolKit library requires gtk_init() somewhere in code... I've prepared > patch for polkit-qt to the new PK1 Core API but... Or is there any other way > to initialize glib without need for it? I'm not familiar with GTK app > development... But library that expects gtk_init somewhere in application to > be correctly intialized... Calling g_type_init() should be enough; there is no direct GTK+ dependency in polkit-gobject. Even g_type_init() may be too much for KDE apps to swallow though, so going directly to the bus is still a good idea. > PK1 should be split into parts - cross-desktop backends should be on > freedesktop, gnome specific libraries should be in gnome repository. This > should stop confusion. You mean like http://cgit.freedesktop.org/PolicyKit http://git.gnome.org/cgit/PolicyKit-gnome ? From pavel.lisy at gmail.com Tue May 26 13:14:29 2009 From: pavel.lisy at gmail.com (Pavel Lisy) Date: Tue, 26 May 2009 15:14:29 +0200 Subject: How to create header.info file Message-ID: <1243343669.17152.17.camel@pali-pc.hk.tmapy.cz> Hello I've made my repository for CentOS (3/4/5) with createrepo version 0.4.9. It makes these files repodata/filelists.xml.gz repodata/other.xml.gz repodata/primary.xml.gz repodata/repomd.xml Yum is working fine but on RHEL 4 I've got this error from up2date An HTTP error occurred: URL: http://ftp-hk.tmapy.cz/tmapy-twist/centos/4/os/i386/headers/header.info Status Code: 404 Error Message: Not Found How can I create this file and other files in headers directory? There is nothing in createrepo docs about these files. Can anybody help me? Pavel From rawhide at fedoraproject.org Tue May 26 13:53:29 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Tue, 26 May 2009 13:53:29 +0000 (UTC) Subject: rawhide report: 20090526 changes Message-ID: <20090526135329.857781F821C@releng2.fedora.phx.redhat.com> Compose started at Tue May 26 06:15:03 UTC 2009 Removed package CastPodder Summary: Added Packages: 0 Removed Packages: 1 Modified Packages: 0 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From skvidal at fedoraproject.org Tue May 26 13:51:49 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 26 May 2009 09:51:49 -0400 (EDT) Subject: How to create header.info file In-Reply-To: <1243343669.17152.17.camel@pali-pc.hk.tmapy.cz> References: <1243343669.17152.17.camel@pali-pc.hk.tmapy.cz> Message-ID: On Tue, 26 May 2009, Pavel Lisy wrote: > Hello > > I've made my repository for CentOS (3/4/5) with createrepo version > 0.4.9. > > It makes these files > > repodata/filelists.xml.gz > repodata/other.xml.gz > repodata/primary.xml.gz > repodata/repomd.xml > > Yum is working fine but on > > RHEL 4 I've got this error from up2date > > An HTTP error occurred: > URL: > http://ftp-hk.tmapy.cz/tmapy-twist/centos/4/os/i386/headers/header.info > Status Code: 404 > Error Message: Not Found > > How can I create this file and other files in headers directory? > There is nothing in createrepo docs about these files. 1. this is not a fedora-devel question. 2. You can ask on the centos lists about this but a short answer though is - look up about yum-arch I will not respond to any other questions about the above on this list. -sv From paul at xelerance.com Tue May 26 14:09:32 2009 From: paul at xelerance.com (Paul Wouters) Date: Tue, 26 May 2009 10:09:32 -0400 (EDT) Subject: export policy, was Re: Package Maintainers Flags policy In-Reply-To: <4A1BEF15.70109@redhat.com> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520135717.GA13882@nostromo.devel.redhat.com> <4A1BEF15.70109@redhat.com> Message-ID: On Tue, 26 May 2009, Tom "spot" Callaway wrote: Though I am also not a lawyer, I did look into things, being upstream for openswan and an author of a book containing crypto, a rather crypto heavy application and book... > There are 6 countries that Fedora cannot be legally exported to (as a > result of US export restrictions): > > Cuba, Iran, Iraq, North Korea, Sudan and Syria I think technically, this restriction only applies on the export of the software out of the US. For those outside the US, US law/doctrine does not apply (even though the US claims it does). Rather, for most Western countries, implementation of the Wassenaar Agreement in local law applies, where some countries have extended the export restrictios as set forth in the Wassenaar Agreement. In Europe, there is also the European Union Dual-Use Export laws. > These are known as the "T-6" countries. No individual associated with > the Fedora project (or mirror site) should provide Fedora software to > anyone in those countries, even if they are not in the US. This is again US doctrine. It becomes even stranger as in my case, Fedora imports openswan from The Netherlands, and then tells me I could not obtain my own GPL licensed code to do what is legal within my country? Though in this case, there is a large overlap of implementation of the Wassenaar Agreement. > "Because Fedora software contains encryption technology, Fedora software > and technical information is subject to the U.S. Export Administration > Regulations and other U.S. and foreign law, and may not be exported or > re-exported to certain countries (currently Cuba, Iran, Iraq, North > Korea, Sudan and Syria) See above. Note that the Wassenaar Agreement excludes software that is in the "public domain", eg free/open source software. > or to persons or entities prohibited from > receiving U.S. exports (including those (a) on the Bureau of Industry > and Security Denied Parties List or Entity List, (b) on the Office of > Foreign Assets Control list of Specially Designated Nationals and > Blocked Persons, and (c) involved with missile technology or nuclear, > chemical or biological weapons). This is technically a violation of GPL, and could mean that anyone distributing Fedora with those restrictions has lost their rights to use and/or distribute the GPL software contained within Fedora. > You may not download Fedora software or > technical information if you are located in one of these countries, or > otherwise affected by these restrictions. You may not provide Fedora > software or technical information to individuals or entities located in > one of these countries or otherwise affected by these restrictions. You > are also responsible for compliance with foreign law requirements > applicable to the import and use of Fedora software and technical > information." This is just boilerplate for more "US law applies to non-US citizens because we say so" doctrine. Though it does not apply to non-US citizens, there is a risk. I formulated it like this in the Openswan book: Unrecognised international claims Certain countries claim jurisdiction even outside their national borders. Most notably, France claims the right to ?regulate information on foreign servers?, Italy assumes jurisdiction over sites "directed to an Italian audience" and the US reserve the right to prosecute "offenses against American interests" according to US law, irrespective of where they take place. You may want to consider the possibility that you can be sued or prosecuted in another country. Additionally, if you are physically in a country other than the Netherlands when you download our software, you are probably subject to that country's jurisdiction anyway. And if your download happens to pass a router under US control (say in Guam), the US might make additional claims to rights for restriction of your packets or even your person. Note that this text was written a few years ago. For an updated situation, one should probably consult their local lawyer, please the updates from http://www.wassenaar.org/ Paul From jreznik at redhat.com Tue May 26 14:21:53 2009 From: jreznik at redhat.com (Jaroslav Reznik) Date: Tue, 26 May 2009 16:21:53 +0200 Subject: PolicyKit changes in F12 In-Reply-To: <1243345496.2357.8.camel@localhost.localdomain> References: <1242262846.9432.9.camel@localhost.localdomain> <200905261537.22667.jreznik@redhat.com> <1243345496.2357.8.camel@localhost.localdomain> Message-ID: <200905261621.53438.jreznik@redhat.com> On Martes 26 Mayo 2009 15:44:56 Matthias Clasen escribi?: > On Tue, 2009-05-26 at 15:37 +0200, Jaroslav Reznik wrote: > > Seems like direct DBus communication is the only way to do it from Qt/KDE > > apps as PolKit library requires gtk_init() somewhere in code... I've > > prepared patch for polkit-qt to the new PK1 Core API but... Or is there > > any other way to initialize glib without need for it? I'm not familiar > > with GTK app development... But library that expects gtk_init somewhere > > in application to be correctly intialized... > > Calling g_type_init() should be enough; there is no direct GTK+ > dependency in polkit-gobject. Even g_type_init() may be too much for KDE > apps to swallow though, so going directly to the bus is still a good > idea. Thanks, I'll try it. Shouldn't library do the proper initialization? Then it's OK for us and it's better for other nongtk projects (not only KDE) - I think once we have library it's useless to duplicate work. But we agreed with upstream that directly using dbus is best for us but first I tried to do port line by line according to your patches/docs/porting guide... > > PK1 should be split into parts - cross-desktop backends should be on > > freedesktop, gnome specific libraries should be in gnome repository. This > > should stop confusion. > > You mean like > > http://cgit.freedesktop.org/PolicyKit > http://git.gnome.org/cgit/PolicyKit-gnome > I thought polkit library which depends on glib initialization is not right cross desktop solution... Jaroslav -- Jaroslav ?ezn?k Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ From choeger at cs.tu-berlin.de Tue May 26 14:13:23 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Tue, 26 May 2009 16:13:23 +0200 Subject: thinkpad and acpi events Message-ID: <1243347203.2485.4.camel@choeger6> Hi all, I encounter a little weirdness with the recent (aka 2.6.29.3-155.fc11.i586) kernel on my R61 Thinkpad: Neither Suspend on lid-shut nor reaction on power button work. It seems to me that there a no events registered by the driver. Does anyone else see that? Is there a way to log that events? regards christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From bruno at wolff.to Tue May 26 13:24:13 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 26 May 2009 08:24:13 -0500 Subject: dependency errors while upgrading from F10 to Rawhide (F11) In-Reply-To: <4A1BB9DA.4030302@kiewel-online.ch> References: <4A1BAABF.8050603@kiewel-online.ch> <20090526105729.7495bc12@faldor.intranet> <4A1BB3A9.2020207@kiewel-online.ch> <20090526113734.25fa0d23@faldor.intranet> <4A1BB9DA.4030302@kiewel-online.ch> Message-ID: <20090526132413.GC29792@wolff.to> On Tue, May 26, 2009 at 11:43:54 +0200, Uwe Kiewel wrote: > > I know this procedure. Do we have the F11 repos yet? I don't think so, > because F11 is not GA. updates and updates-testing are normal and are at the mirrors. For Everything there is a fudge in the mirror list to point at f11 rawhide until GA. Rawhide should move to f12 very soon now, so you probably don't want to point to the rawhide repo unless you are careful. From nikolay at vladimiroff.com Tue May 26 14:49:25 2009 From: nikolay at vladimiroff.com (Nikolay Vladimirov) Date: Tue, 26 May 2009 17:49:25 +0300 Subject: thinkpad and acpi events In-Reply-To: <1243347203.2485.4.camel@choeger6> References: <1243347203.2485.4.camel@choeger6> Message-ID: 2009/5/26 Christoph H?ger : > Hi all, > > I encounter a little weirdness with the recent (aka > 2.6.29.3-155.fc11.i586) kernel on my R61 Thinkpad: Neither Suspend on > lid-shut nor reaction on power button work. It seems to me that there a > no events registered by the driver. Does anyone else see that? > Is there a way to log that events? > > regards > > christoph I noticed something similar on a T41, I think that the thinkpad_acpi(or whatever it's name was) module wasn't loaded. Didn't have the time to look in to it. Can you check the loaded modules? -- NV From sundaram at fedoraproject.org Tue May 26 14:54:41 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 26 May 2009 20:24:41 +0530 Subject: export policy, was Re: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520135717.GA13882@nostromo.devel.redhat.com> <4A1BEF15.70109@redhat.com> Message-ID: <4A1C02B1.8010509@fedoraproject.org> On 05/26/2009 07:39 PM, Paul Wouters wrote: > > This is technically a violation of GPL, and could mean that > anyone distributing Fedora with those restrictions has lost their rights > to use and/or distribute the GPL software contained within Fedora.here > they take place. FSF doesn't seem to think so http://fedoraproject.org/wiki/FreeSoftwareAnalysis/FSF Rahul From choeger at cs.tu-berlin.de Tue May 26 15:11:27 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Tue, 26 May 2009 17:11:27 +0200 Subject: compat c++ Message-ID: <1243350687.7214.19.camel@choeger5.umpa.netz> Hi, I was just wondering, if there is a compat c++ compiler package (or mode) available in fedora. The issue I encountered was that I got a lot of compiler errors because of strdup() malloc() etc. usages in c++ files without proper #include stuff. I am not a C++ expert, but I guess that there was a default behavior change between g++ 3 and 4. What I did was patching that package to get those #includes but as it contains a c++ code generator I also had to patch that. Although it seems to compile now, I still get zillions of "DO NOT CAST char* TO string YOU FOOL" warnings (wasn't there an option to get rid of them too?). Any kind of compat mode would make things alot easier (besides bringing the developers to write propert C++). regards christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From mschwendt at gmail.com Tue May 26 15:11:43 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 26 May 2009 17:11:43 +0200 Subject: dependency errors while upgrading from F10 to Rawhide (F11) In-Reply-To: <20090526132413.GC29792@wolff.to> References: <4A1BAABF.8050603@kiewel-online.ch> <20090526105729.7495bc12@faldor.intranet> <4A1BB3A9.2020207@kiewel-online.ch> <20090526113734.25fa0d23@faldor.intranet> <4A1BB9DA.4030302@kiewel-online.ch> <20090526132413.GC29792@wolff.to> Message-ID: <20090526171143.281ad0a7@faldor.intranet> On Tue, 26 May 2009 08:24:13 -0500, Bruno wrote: > updates and updates-testing are normal and are at the mirrors. For Everything > there is a fudge in the mirror list to point at f11 rawhide until GA. > Rawhide should move to f12 very soon now, so you probably don't want to > point to the rawhide repo unless you are careful. Is the Yum from F10 updates-testing needed to understand the XML mirrorlists? https://admin.fedoraproject.org/updates/F10/FEDORA-2009-5328 From walters at verbum.org Tue May 26 15:14:42 2009 From: walters at verbum.org (Colin Walters) Date: Tue, 26 May 2009 11:14:42 -0400 Subject: unowned files and directories In-Reply-To: <4A183682.2000006@leemhuis.info> References: <4A183682.2000006@leemhuis.info> Message-ID: On Sat, May 23, 2009 at 1:46 PM, Thorsten Leemhuis wrote: > > (?) the list also leads to question like "why are there /.dbus and > /.pulse?" My guess is some code in the installation process running as root with $HOME set to "/" is trying to connect to the DBus session bus. For compatibility with some unfortunate scenarios libdbus will attempt to auto-launch a bus using dbus-launch which will then create ~/.dbus. I assume pulse is similar (ideally pulse uses dbus, then we only have this bug once, but that's another discussion). Something trying to talk to the session bus sound familiar to anyone working on the installer? If we can set $HOME to /root that would sidestep most of the issues, alternatively in libdbus we could avoid autolaunching for root, since it should never be needed. From jussilehtola at fedoraproject.org Tue May 26 15:15:19 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Tue, 26 May 2009 18:15:19 +0300 Subject: compat c++ In-Reply-To: <1243350687.7214.19.camel@choeger5.umpa.netz> References: <1243350687.7214.19.camel@choeger5.umpa.netz> Message-ID: <1243350919.3877.5.camel@politzer.theorphys.helsinki.fi> On Tue, 2009-05-26 at 17:11 +0200, Christoph H?ger wrote: > Hi, > > I was just wondering, if there is a compat c++ compiler package (or > mode) available in fedora. The issue I encountered was that I got a lot > of compiler errors because of strdup() malloc() etc. usages in c++ files > without proper #include stuff. > I am not a C++ expert, but I guess that there was a default behavior > change between g++ 3 and 4. The best thing to do would of course be patching the code to respect the standards, but you can # yum -y install compat-gcc-34-c++ and use g++34 in the mean time. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From skvidal at fedoraproject.org Tue May 26 15:21:13 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 26 May 2009 11:21:13 -0400 (EDT) Subject: dependency errors while upgrading from F10 to Rawhide (F11) In-Reply-To: <20090526171143.281ad0a7@faldor.intranet> References: <4A1BAABF.8050603@kiewel-online.ch> <20090526105729.7495bc12@faldor.intranet> <4A1BB3A9.2020207@kiewel-online.ch> <20090526113734.25fa0d23@faldor.intranet> <4A1BB9DA.4030302@kiewel-online.ch> <20090526132413.GC29792@wolff.to> <20090526171143.281ad0a7@faldor.intranet> Message-ID: On Tue, 26 May 2009, Michael Schwendt wrote: > On Tue, 26 May 2009 08:24:13 -0500, Bruno wrote: > >> updates and updates-testing are normal and are at the mirrors. For Everything >> there is a fudge in the mirror list to point at f11 rawhide until GA. >> Rawhide should move to f12 very soon now, so you probably don't want to >> point to the rawhide repo unless you are careful. > > Is the Yum from F10 updates-testing needed to understand the XML > mirrorlists? > > https://admin.fedoraproject.org/updates/F10/FEDORA-2009-5328 yum 3.2.20 in f10-GA should work mostly fine. There have been some bug fixes since then but the majority of them are in the yum in updates released for F10. I know you don't need the version in updates-testing to read the metalinks. -sv From tcallawa at redhat.com Tue May 26 15:30:59 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 26 May 2009 11:30:59 -0400 Subject: export policy, was Re: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520135717.GA13882@nostromo.devel.redhat.com> <4A1BEF15.70109@redhat.com> Message-ID: <4A1C0B33.70804@redhat.com> On 05/26/2009 10:09 AM, Paul Wouters wrote: > See above. Note that the Wassenaar Agreement excludes software that is > in the "public domain", eg free/open source software. This is not correct. "Public Domain" has a very specific legal meaning, and 99% of FOSS does _not_ meet it. Public Domain is when the copyright holder has explicitly abandoned his/her/its copyright on the work and placed it into the Public Domain. (Note: In some countries, such as Germany, this is impossible) >> You may not download Fedora software or >> technical information if you are located in one of these countries, or >> otherwise affected by these restrictions. You may not provide Fedora >> software or technical information to individuals or entities located in >> one of these countries or otherwise affected by these restrictions. You >> are also responsible for compliance with foreign law requirements >> applicable to the import and use of Fedora software and technical >> information." > > This is just boilerplate for more "US law applies to non-US citizens > because we say so" doctrine. Keeping in mind the complexities of US export law are many, people who are directly affiliated with a US company are still required to follow US export law, or the US company can face serious legal risks (even if the non-US citizen who violates US export laws does not directly face any risk, or a minimized risk). In such a scenario, the individual could be perceived to have been acting as an agent of Fedora (Red Hat), making Red Hat liable. The penalties for export violation are steep and serious, which is why all Fedora contributors are required to abide by the export policies. ~spot From jkeating at j2solutions.net Tue May 26 15:38:55 2009 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 26 May 2009 08:38:55 -0700 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: <4A1BCF4B.8050802@hhs.nl> References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> Message-ID: <1243352335.3144.18.camel@localhost.localdomain> On Tue, 2009-05-26 at 13:15 +0200, Hans de Goede wrote: > > Can we please not remove the Group tag, it is actually quite usefull. > What we need to remove / loose is comps. Having all this info in a > centralized database is stupid. The spec files should tell which > group(s) the package belongs in. So that when one adds a new package, > this gets done right more or less automatically (and is part of the > review). Defining groups in the package is broken because different consumers of of the packages may wish to group those packages in different ways. When you define it in the package, you have to rebuild the package just to change how they're grouped. That's one of the big reasons why grouping should be done outside of the packages. -- Jesse Keating RHCE (http://jkeating.livejournal.com) Fedora Project (http://fedoraproject.org/wiki/JesseKeating) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) identi.ca (http://identi.ca/jkeating) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Tue May 26 16:11:40 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 26 May 2009 18:11:40 +0200 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: <1243352335.3144.18.camel@localhost.localdomain> References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <1243352335.3144.18.camel@localhost.localdomain> Message-ID: <4A1C14BC.7010508@freenet.de> Jesse Keating wrote: > On Tue, 2009-05-26 at 13:15 +0200, Hans de Goede wrote: >> Can we please not remove the Group tag, it is actually quite usefull. >> What we need to remove / loose is comps. Having all this info in a >> centralized database is stupid. The spec files should tell which >> group(s) the package belongs in. So that when one adds a new package, >> this gets done right more or less automatically (and is part of the >> review). ACK. Instead of abandoning rpm-Groups, it should be strengthened and comps be made strictly optional. > Defining groups in the package is broken because different consumers of > of the packages may wish to group those packages in different ways. > When you define it in the package, you have to rebuild the package just > to change how they're grouped. That's one of the big reasons why > grouping should be done outside of the packages. Comps and Groups are addressing completely different issues. From bochecha at fedoraproject.org Tue May 26 16:13:30 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Tue, 26 May 2009 18:13:30 +0200 Subject: export policy, was Re: Package Maintainers Flags policy In-Reply-To: <4A1C0B33.70804@redhat.com> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520135717.GA13882@nostromo.devel.redhat.com> <4A1BEF15.70109@redhat.com> <4A1C0B33.70804@redhat.com> Message-ID: <2d319b780905260913u6927bdadl634fe32741907132@mail.gmail.com> > The penalties for export violation are steep and > serious, which is why all Fedora contributors are required to abide by > the export policies. Maybe this should be mentioned in the CLA ? We (Fedora contributors) have to sign it. Specifying it there would make it more widely known, and could provide a way to make contributors respect it (as they agreed and signed the CLA). Unless I miss it, it is not mentioned: https://fedoraproject.org/wiki/Legal/Licenses/CLA Regards, ---------- Mathieu Bridon (bochecha) From tcallawa at redhat.com Tue May 26 16:35:15 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 26 May 2009 12:35:15 -0400 Subject: export policy, was Re: Package Maintainers Flags policy In-Reply-To: <2d319b780905260913u6927bdadl634fe32741907132@mail.gmail.com> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520135717.GA13882@nostromo.devel.redhat.com> <4A1BEF15.70109@redhat.com> <4A1C0B33.70804@redhat.com> <2d319b780905260913u6927bdadl634fe32741907132@mail.gmail.com> Message-ID: <4A1C1A43.1030908@redhat.com> On 05/26/2009 12:13 PM, Mathieu Bridon (bochecha) wrote: >> The penalties for export violation are steep and >> serious, which is why all Fedora contributors are required to abide by >> the export policies. > > Maybe this should be mentioned in the CLA ? We (Fedora contributors) > have to sign it. Specifying it there would make it more widely known, > and could provide a way to make contributors respect it (as they > agreed and signed the CLA). > > Unless I miss it, it is not mentioned: > https://fedoraproject.org/wiki/Legal/Licenses/CLA Nope. We'll definitely take that into consideration as we rework the CLA. Historically, we've only highlighted the export details onto people who are likely to redistribute Fedora as part of their normal activities (FreeMedia, Mirrors), but there is no reason we can't make it clear to everyone who signs the CLA. ~spot From notting at redhat.com Tue May 26 16:48:39 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 26 May 2009 12:48:39 -0400 Subject: rawhide report: 20090523 changes In-Reply-To: References: <20090523141954.2494F1F820F@releng2.fedora.phx.redhat.com> Message-ID: <20090526164839.GG9951@nostromo.devel.redhat.com> Kevin Kofler (kevin.kofler at chello.at) said: > Yet another insecure temporary file vulnerability. Why do we still not > polyinstantiate /tmp by default? We're wasting lots of time on security > measures which keep breaking apps such as SELinux, but simple things like > polyinstantiation are still not used, why? This code would be perfectly > safe if polyinstantiation was mandatory. Why are we stuck in the 1970s? ... send patches? It's techncially feasible, but no one's done the legwork to integrate it fully yet. (xguest goes a bit beyond what we'd want by default.) Bill From lemenkov at gmail.com Tue May 26 17:03:36 2009 From: lemenkov at gmail.com (Peter Lemenkov) Date: Tue, 26 May 2009 21:03:36 +0400 Subject: Why not to create Fedora-us and Fedora-non-us branches? Message-ID: Subj. As Debian folks did years ago. Such branching will be done very easy technically. -- With best regards! From notting at redhat.com Tue May 26 17:04:24 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 26 May 2009 13:04:24 -0400 Subject: List of packages including country flags In-Reply-To: <4A179BE7.7010507@x-tnd.be> References: <4A179BE7.7010507@x-tnd.be> Message-ID: <20090526170423.GI9951@nostromo.devel.redhat.com> Johan Cwiklinski (mailings at x-tnd.be) said: > Considering this, I'm not sure simply removing flags for gcompris is the > thing to do. > > Any thoughts ? It's the right thing from a UI standpoint. That dialog is horrible. Here's an example, when started in es_MX.UTF-8: http://notting.fedorapeople.org/gcompris.png 1) I started it in the locale of the largest Spanish-speaking population on the globe. So I get a (broken) flag image for an entirely different country? 2) Say I'm a child who can't read the language but is supposed to pick the language via flag. Not only is it not using a flag that I'd recognize in my locale, how am I even supposed to know that it's a language configuration area? There's no other information other than a name of the language (or 'your system default', which also isn't going to make a lot of sense to most kids) 3) There's also entries there to change the timing of the game, the skin, whether to have music or sound effects, etc. None of these have iconographic representations to make them usable by the pre-literate set. So yes, long term, the flags should be removed. Ideally, upstream would be convinced to do it. Bill From notting at redhat.com Tue May 26 17:06:12 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 26 May 2009 13:06:12 -0400 Subject: Why not to create Fedora-us and Fedora-non-us branches? In-Reply-To: References: Message-ID: <20090526170612.GJ9951@nostromo.devel.redhat.com> Peter Lemenkov (lemenkov at gmail.com) said: > Subj. As Debian folks did years ago. Such branching will be done very > easy technically. Because all the builds and composition is done in the US, and the trademarks are held by a US entity. Bill From lemenkov at gmail.com Tue May 26 17:10:00 2009 From: lemenkov at gmail.com (Peter Lemenkov) Date: Tue, 26 May 2009 21:10:00 +0400 Subject: Why not to create Fedora-us and Fedora-non-us branches? In-Reply-To: <20090526170612.GJ9951@nostromo.devel.redhat.com> References: <20090526170612.GJ9951@nostromo.devel.redhat.com> Message-ID: 2009/5/26 Bill Nottingham : >> Subj. As Debian folks did years ago. Such branching will be done very >> easy technically. > > Because all the builds and composition is done in the US, and the trademarks > are held by a US entity. Not a serious reason. Why not to relocate then in Europe? -- With best regards! From opensource at till.name Tue May 26 17:12:06 2009 From: opensource at till.name (Till Maas) Date: Tue, 26 May 2009 19:12:06 +0200 Subject: rawhide report: 20090523 changes In-Reply-To: <20090526164839.GG9951@nostromo.devel.redhat.com> References: <20090523141954.2494F1F820F@releng2.fedora.phx.redhat.com> <20090526164839.GG9951@nostromo.devel.redhat.com> Message-ID: <200905261912.12593.opensource@till.name> On Di Mai 26 2009, Bill Nottingham wrote: > Kevin Kofler (kevin.kofler at chello.at) said: > > Yet another insecure temporary file vulnerability. Why do we still not > > polyinstantiate /tmp by default? We're wasting lots of time on security > > measures which keep breaking apps such as SELinux, but simple things like > > polyinstantiation are still not used, why? This code would be perfectly > > safe if polyinstantiation was mandatory. Why are we stuck in the 1970s? > > ... send patches? It's techncially feasible, but no one's done the > legwork to integrate it fully yet. It is already done on the Fedorapeople server: https://fedoraproject.org/wiki/Infrastructure/FedoraPeopleConfig#polyinstantiated_tempdirs Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From jkeating at redhat.com Tue May 26 17:25:36 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 26 May 2009 10:25:36 -0700 Subject: Why not to create Fedora-us and Fedora-non-us branches? In-Reply-To: References: <20090526170612.GJ9951@nostromo.devel.redhat.com> Message-ID: <1243358736.3144.23.camel@localhost.localdomain> On Tue, 2009-05-26 at 21:10 +0400, Peter Lemenkov wrote: > 2009/5/26 Bill Nottingham : > > >> Subj. As Debian folks did years ago. Such branching will be done very > >> easy technically. > > > > Because all the builds and composition is done in the US, and the trademarks > > are held by a US entity. > > Not a serious reason. Why not to relocate then in Europe? > > > -- > With best regards! > Find us a Company in Europe that is not based in the US that is willing to fund with people and money as much as Red Hat is doing now. Oh, Europe won't help much, there are just as many silly laws there as there are in the US. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Tue May 26 17:29:46 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 26 May 2009 13:29:46 -0400 Subject: Why not to create Fedora-us and Fedora-non-us branches? In-Reply-To: References: <20090526170612.GJ9951@nostromo.devel.redhat.com> Message-ID: <20090526172946.GA12547@nostromo.devel.redhat.com> Peter Lemenkov (lemenkov at gmail.com) said: > >> Subj. As Debian folks did years ago. Such branching will be done very > >> easy technically. > > > > Because all the builds and composition is done in the US, and the trademarks > > are held by a US entity. > > Not a serious reason. Why not to relocate then in Europe? ... what exactly are you trying to accomplish? Make it legal to ship MP3 code? Sorry, those are patented in Europe as well. Make it so we can ship to various T-6 countries? I'm sure many European countries have their own lists as well. Bill From cweyl at alumni.drew.edu Tue May 26 17:31:37 2009 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Tue, 26 May 2009 10:31:37 -0700 Subject: Why not to create Fedora-us and Fedora-non-us branches? In-Reply-To: References: <20090526170612.GJ9951@nostromo.devel.redhat.com> Message-ID: <7dd7ab490905261031j18e8c39fw7175d9cc7828fdf7@mail.gmail.com> On Tue, May 26, 2009 at 10:10 AM, Peter Lemenkov wrote: > 2009/5/26 Bill Nottingham : > > >> Subj. As Debian folks did years ago. Such branching will be done very > >> easy technically. > > > > Because all the builds and composition is done in the US, and the > trademarks > > are held by a US entity. > > Not a serious reason. Why not to relocate then in Europe? > A US corporation is subject to US law no matter where it operates. Sounds serious to me :) -Chris -- Chris Weyl Ex astris, scientia -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.kofler at chello.at Tue May 26 17:32:31 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 26 May 2009 19:32:31 +0200 Subject: dependency errors while upgrading from F10 to Rawhide (F11) References: <4A1BAABF.8050603@kiewel-online.ch> <20090526105729.7495bc12@faldor.intranet> <4A1BB3A9.2020207@kiewel-online.ch> <20090526113734.25fa0d23@faldor.intranet> Message-ID: Michael Schwendt wrote: > [And as long as there is no F11 GA repo yet, you need to enable rawhide > manually.] Actually no, as the mirrorlists redirect you automatically. Kevin Kofler From sgallagh at redhat.com Tue May 26 17:39:45 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 26 May 2009 13:39:45 -0400 Subject: Why not to create Fedora-us and Fedora-non-us branches? In-Reply-To: <1243358736.3144.23.camel@localhost.localdomain> References: <20090526170612.GJ9951@nostromo.devel.redhat.com> <1243358736.3144.23.camel@localhost.localdomain> Message-ID: <4A1C2961.70703@redhat.com> On 05/26/2009 01:25 PM, Jesse Keating wrote: > On Tue, 2009-05-26 at 21:10 +0400, Peter Lemenkov wrote: >> 2009/5/26 Bill Nottingham : >> >>>> Subj. As Debian folks did years ago. Such branching will be done very >>>> easy technically. >>> Because all the builds and composition is done in the US, and the trademarks >>> are held by a US entity. >> Not a serious reason. Why not to relocate then in Europe? >> >> >> -- >> With best regards! >> > > Find us a Company in Europe that is not based in the US that is willing > to fund with people and money as much as Red Hat is doing now. > > Oh, Europe won't help much, there are just as many silly laws there as > there are in the US. > > Is there a reason that an interested party (in a locale where such export is legal) couldn't just create a custom spin on their own (and using their own build system) to create a Fedora-T6 spin (or for trademark reasons, rebrand it)? I can see this being a perfectly good premise for setting up a SIG... -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From notting at redhat.com Tue May 26 17:41:27 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 26 May 2009 13:41:27 -0400 Subject: Why not to create Fedora-us and Fedora-non-us branches? In-Reply-To: <4A1C2961.70703@redhat.com> References: <20090526170612.GJ9951@nostromo.devel.redhat.com> <1243358736.3144.23.camel@localhost.localdomain> <4A1C2961.70703@redhat.com> Message-ID: <20090526174126.GA13081@nostromo.devel.redhat.com> Stephen Gallagher (sgallagh at redhat.com) said: > Is there a reason that an interested party (in a locale where such > export is legal) couldn't just create a custom spin on their own (and > using their own build system) to create a Fedora-T6 spin (or for > trademark reasons, rebrand it)? I can see this being a perfectly good > premise for setting up a SIG... The SIG would be under the auspices of the Fedora project, return to step 1, do not pass go. Bill From tibbs at math.uh.edu Tue May 26 17:46:49 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 26 May 2009 12:46:49 -0500 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: (Jason L. Tibbitts, III's message of "Mon\, 25 May 2009 23\:20\:17 -0500") References: Message-ID: >>>>> "J" == Jason L Tibbitts writes: J> The Packaging Committee will meet Tuesday, 2009-05-26 at 17:00UTC J> in the #fedora-meeting channel on chat.freenode.net. Due to lack of quorum, this meeting is postponed to Tuesday, 2009-06-02. I will send an updated agenda as the meeting approaches. - J< From kevin.kofler at chello.at Tue May 26 17:46:49 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 26 May 2009 19:46:49 +0200 Subject: Why not to create Fedora-us and Fedora-non-us branches? References: <20090526170612.GJ9951@nostromo.devel.redhat.com> <7dd7ab490905261031j18e8c39fw7175d9cc7828fdf7@mail.gmail.com> Message-ID: Chris Weyl wrote: > A US corporation is subject to US law no matter where it operates. Sounds > serious to me :) I think the idea is to found a Fedora foundation outside of the US to own Fedora instead of RH. The reason given for not creating a foundation was that US tax laws are problematic, creating it outside of the US would mean favorable tax laws could be chosen as well. That said, RH may still get into trouble for contributory infringement, and with a non-US foundation, RH may even get accused of tax evasion, so I'm not that surprised they aren't thrilled by the idea. Kevin Kofler From mclasen at redhat.com Tue May 26 18:04:37 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 26 May 2009 14:04:37 -0400 Subject: rawhide report: 20090523 changes In-Reply-To: <200905261912.12593.opensource@till.name> References: <20090523141954.2494F1F820F@releng2.fedora.phx.redhat.com> <20090526164839.GG9951@nostromo.devel.redhat.com> <200905261912.12593.opensource@till.name> Message-ID: <1243361077.2324.0.camel@localhost.localdomain> On Tue, 2009-05-26 at 19:12 +0200, Till Maas wrote: > On Di Mai 26 2009, Bill Nottingham wrote: > > Kevin Kofler (kevin.kofler at chello.at) said: > > > Yet another insecure temporary file vulnerability. Why do we still not > > > polyinstantiate /tmp by default? We're wasting lots of time on security > > > measures which keep breaking apps such as SELinux, but simple things like > > > polyinstantiation are still not used, why? This code would be perfectly > > > safe if polyinstantiation was mandatory. Why are we stuck in the 1970s? > > > > ... send patches? It's techncially feasible, but no one's done the > > legwork to integrate it fully yet. > > It is already done on the Fedorapeople server: > https://fedoraproject.org/wiki/Infrastructure/FedoraPeopleConfig#polyinstantiated_tempdirs Hey, nice. That should really be an F12 feature. From awilliam at redhat.com Tue May 26 18:20:14 2009 From: awilliam at redhat.com (Adam Williamson) Date: Tue, 26 May 2009 11:20:14 -0700 Subject: dependency errors while upgrading vom F10 to Rawhide (F11) In-Reply-To: <4A1BAABF.8050603@kiewel-online.ch> References: <4A1BAABF.8050603@kiewel-online.ch> Message-ID: <1243362014.16232.92.camel@adam.local.net> On Tue, 2009-05-26 at 10:39 +0200, Uwe Kiewel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > I checked the ability to upgrade from F10 to F11 (Rawhide) directly > using yum. A couple of weeks ago, there were dependency errors with > python. These errors are not fixed until now. > > In my point of view, this issue should be fixed until GA of Leonidas. Others have explained what you should do to test this properly, but to address your final point: QA's stance on this is that the only supported upgrade methods are via the install images or preupgrade. Upgrade via yum has the status "not explicitly supported but may well work". We don't consider issues which would cause upgrading from release to release via yum to be blockers, but issues which would cause upgrading via preupgrade to fail usually would be. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From ville.skytta at iki.fi Tue May 26 18:30:28 2009 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Tue, 26 May 2009 21:30:28 +0300 Subject: compat c++ In-Reply-To: <1243350919.3877.5.camel@politzer.theorphys.helsinki.fi> References: <1243350687.7214.19.camel@choeger5.umpa.netz> <1243350919.3877.5.camel@politzer.theorphys.helsinki.fi> Message-ID: <200905262130.31278.ville.skytta@iki.fi> On Tuesday 26 May 2009, Jussi Lehtola wrote: > On Tue, 2009-05-26 at 17:11 +0200, Christoph H?ger wrote: > > Hi, > > > > I was just wondering, if there is a compat c++ compiler package (or > > mode) available in fedora. The issue I encountered was that I got a lot > > of compiler errors because of strdup() malloc() etc. usages in c++ files > > without proper #include stuff. > > I am not a C++ expert, but I guess that there was a default behavior > > change between g++ 3 and 4. > > The best thing to do would of course be patching the code to respect the > standards, but you can > > # yum -y install compat-gcc-34-c++ > > and use g++34 in the mean time. ...or try if -fpermissive (applied selectively where needed) helps with the newer one. From mschwendt at gmail.com Tue May 26 18:39:14 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 26 May 2009 20:39:14 +0200 Subject: dependency errors while upgrading from F10 to Rawhide (F11) In-Reply-To: References: <4A1BAABF.8050603@kiewel-online.ch> <20090526105729.7495bc12@faldor.intranet> <4A1BB3A9.2020207@kiewel-online.ch> <20090526113734.25fa0d23@faldor.intranet> Message-ID: <20090526203914.02e9023a@faldor.intranet> On Tue, 26 May 2009 19:32:31 +0200, Kevin wrote: > Michael Schwendt wrote: > > [And as long as there is no F11 GA repo yet, you need to enable rawhide > > manually.] > > Actually no, as the mirrorlists redirect you automatically. Well, great, but whatever very went wrong for Uwe (the OP), his Yum couldn't read the new XML mirrorlist and therefore couldn't construct a valid baseurl for "fedora" and other repos. > YumRepo Error: All mirror URLs are not using ftp, http[s] or file. > Eg. / > removing mirrorlist with no valid mirrors: > //var/cache/yum/fedora/mirrorlist.txt > Error: Cannot find a valid baseurl for repo: fedora From cmadams at hiwaay.net Tue May 26 18:39:49 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 26 May 2009 13:39:49 -0500 Subject: export policy, was Re: Package Maintainers Flags policy In-Reply-To: <4A1C1A43.1030908@redhat.com> References: <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520135717.GA13882@nostromo.devel.redhat.com> <4A1BEF15.70109@redhat.com> <4A1C0B33.70804@redhat.com> <2d319b780905260913u6927bdadl634fe32741907132@mail.gmail.com> <4A1C1A43.1030908@redhat.com> Message-ID: <20090526183949.GC1569132@hiwaay.net> Once upon a time, Tom spot Callaway said: > Historically, we've only highlighted the export details onto people who > are likely to redistribute Fedora as part of their normal activities > (FreeMedia, Mirrors), but there is no reason we can't make it clear to > everyone who signs the CLA. IIRC mirrors are not required to sign the CLA (I did, but that was because I was working towards being a packager as well). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From awilliam at redhat.com Tue May 26 18:42:21 2009 From: awilliam at redhat.com (Adam Williamson) Date: Tue, 26 May 2009 11:42:21 -0700 Subject: Why not to create Fedora-us and Fedora-non-us branches? In-Reply-To: <20090526172946.GA12547@nostromo.devel.redhat.com> References: <20090526170612.GJ9951@nostromo.devel.redhat.com> <20090526172946.GA12547@nostromo.devel.redhat.com> Message-ID: <1243363341.16232.97.camel@adam.local.net> On Tue, 2009-05-26 at 13:29 -0400, Bill Nottingham wrote: > Peter Lemenkov (lemenkov at gmail.com) said: > > >> Subj. As Debian folks did years ago. Such branching will be done very > > >> easy technically. > > > > > > Because all the builds and composition is done in the US, and the trademarks > > > are held by a US entity. > > > > Not a serious reason. Why not to relocate then in Europe? > > ... what exactly are you trying to accomplish? ...that isn't achieved, in practical terms, just as well by the existence of RPMFusion? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From skvidal at fedoraproject.org Tue May 26 18:42:22 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 26 May 2009 14:42:22 -0400 (EDT) Subject: dependency errors while upgrading from F10 to Rawhide (F11) In-Reply-To: <20090526203914.02e9023a@faldor.intranet> References: <4A1BAABF.8050603@kiewel-online.ch> <20090526105729.7495bc12@faldor.intranet> <4A1BB3A9.2020207@kiewel-online.ch> <20090526113734.25fa0d23@faldor.intranet> <20090526203914.02e9023a@faldor.intranet> Message-ID: On Tue, 26 May 2009, Michael Schwendt wrote: > On Tue, 26 May 2009 19:32:31 +0200, Kevin wrote: > >> Michael Schwendt wrote: >>> [And as long as there is no F11 GA repo yet, you need to enable rawhide >>> manually.] >> >> Actually no, as the mirrorlists redirect you automatically. > > Well, great, but whatever very went wrong for Uwe (the OP), his Yum > couldn't read the new XML mirrorlist and therefore couldn't construct a > valid baseurl for "fedora" and other repos. > >From f10's yum? Can I get a yum version number for what he's running? I think F10 GA had 3.2.20 in it.. -sv From paul at xelerance.com Tue May 26 18:50:09 2009 From: paul at xelerance.com (Paul Wouters) Date: Tue, 26 May 2009 14:50:09 -0400 (EDT) Subject: Why not to create Fedora-us and Fedora-non-us branches? In-Reply-To: <4A1C2961.70703@redhat.com> References: <20090526170612.GJ9951@nostromo.devel.redhat.com> <1243358736.3144.23.camel@localhost.localdomain> <4A1C2961.70703@redhat.com> Message-ID: On Tue, 26 May 2009, Stephen Gallagher wrote: >> Find us a Company in Europe that is not based in the US that is willing >> to fund with people and money as much as Red Hat is doing now. >> >> Oh, Europe won't help much, there are just as many silly laws there as >> there are in the US. 1) Your packets will still flow through the US anyway. 2) The US claim jurisdiction even outside their national borders and reserve the right to prosecute "offenses against American interests" according to US law, irrespective of where they take place. In other words, you could be extradited even if the offense would not actually be an offense in your country. For example, Dutch people have been extradited for selling drugs to US citizens in The Netherlands, even though marihuana is legal. (well, "its complicated") Also, you could never set foot in the US again without getting arrested, and most of us don't think those T-6 countries are worh that. > Is there a reason that an interested party (in a locale where such > export is legal) couldn't just create a custom spin on their own (and > using their own build system) to create a Fedora-T6 spin (or for > trademark reasons, rebrand it)? I can see this being a perfectly good > premise for setting up a SIG... respin what? remove the crypto? Try removing nss, openssl, gnutls and kerberos and see what's left of your system. Not much :P And who would want it? Surely not the T6 countries :P Paul From tcallawa at redhat.com Tue May 26 18:49:11 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 26 May 2009 14:49:11 -0400 Subject: export policy, was Re: Package Maintainers Flags policy In-Reply-To: <20090526183949.GC1569132@hiwaay.net> References: <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520135717.GA13882@nostromo.devel.redhat.com> <4A1BEF15.70109@redhat.com> <4A1C0B33.70804@redhat.com> <2d319b780905260913u6927bdadl634fe32741907132@mail.gmail.com> <4A1C1A43.1030908@redhat.com> <20090526183949.GC1569132@hiwaay.net> Message-ID: <4A1C39A7.6060502@redhat.com> On 05/26/2009 02:39 PM, Chris Adams wrote: > Once upon a time, Tom spot Callaway said: >> Historically, we've only highlighted the export details onto people who >> are likely to redistribute Fedora as part of their normal activities >> (FreeMedia, Mirrors), but there is no reason we can't make it clear to >> everyone who signs the CLA. > > IIRC mirrors are not required to sign the CLA (I did, but that was > because I was working towards being a packager as well). Yes, but they are presented with the export restrictions. ~spot From tcallawa at redhat.com Tue May 26 19:02:47 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 26 May 2009 15:02:47 -0400 Subject: Removing %clean (Was Re: Agenda for the 2009-05-26 Packaging Committee meeting) In-Reply-To: <20090526081015.GB27381@amd.home.annexia.org> References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> Message-ID: <4A1C3CD7.7040600@redhat.com> On 05/26/2009 04:10 AM, Richard W.M. Jones wrote: > I vote for also removing the %clean section. So, looking at this objectively, here are the technical problems: * We're defining a BuildRoot in the spec, but that definition is no longer used (Fedora 10 or higher), because rpm now automagically sets it for us. * We're typing rm -rf %{buildroot} multiple times in every single Fedora specfile. We want to invoke it twice: - As the very first operation of the %install scriptlet - As the very first operation of the %clean scriptlet The concerns around removing the BuildRoot from the spec is that if that spec is taken to an older system, the spec would either * Not work * Set the BuildRoot to / and cause massive system destruction The good news is that for all the Fedora targets that we care about, if BuildRoot is unset, it is just unset. It never gets set to / on anything we care about (including RHEL 4 and 5, I checked). And I really don't think we need to care about anything older than RHEL 4 (roughly equivalent to Fedora 6). A comment in the packaging guidelines should be sufficient, so simply dropping the unnecessary BuildRoot definition as soon as Fedora 9 is EOL seems like a sane course of action. The %install scriptlet case is reasonably simple to solve with redhat-rpm-config's customized macros file, simply add: %__spec_install_pre %{___build_pre}\ [ "$RPM_BUILD_ROOT" != "/" ] && rm -rf "${RPM_BUILD_ROOT}"\ mkdir -p `dirname "$RPM_BUILD_ROOT"`\ mkdir "$RPM_BUILD_ROOT"\ %{nil} This ensures that every time %install is invoked in a spec file, it checks that buildroot isn't / (which, it should never ever be, but given the past history, doesn't hurt to check), then deletes it. Next, it makes the basedir of $RPM_BUILD_ROOT, in case that doesn't exist, then makes the buildroot for us, saving additional pain in some Fedora spec files where the make install process is either too dumb to do this for us (or non-existant). The %clean scriptlet case is harder. Lets get the easy case out of the way, removing the obligatory rm -rf %{buildroot} invocation: %__spec_clean_pre %{___build_pre}\ [ "$RPM_BUILD_ROOT" != "/" ] && rm -rf "${RPM_BUILD_ROOT}"\ %{nil} With that, every time %clean is invoked in a spec file, it checks that buildroot isn't /, and then deletes it if it is not. However, that doesn't really resolve the deeper desire, which is as Richard points out, is to remove the need to explicitly state the %clean section at all. If we need to overload it beyond its defaults, we should be able to invoke it manually and append to it, but if it is not set, it should be invoked automagically. RPM doesn't act this way. For all scriptlets, their absence does not result in automatic invocation (there is no idea of "always executed" default scriptlets in a spec), but instead is how they are omitted. I can certainly see valid use cases where a package would not want %clean to be invoked. It might be possible to change RPM's behavior to introduce a disabler mechanism for default "always executed" scriptlets: %disable %check This would be a significant behavior change for RPM, and not something we could do with distribution specific macro tweaks. It would also break backwards compatibility with older RPM spec files, which has traditionally been avoided. ***** So, given those facts, and assuming that RPM isn't changing its behaviors anytime soon, we can make macro changes in redhat-rpm-config and change from this: BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) ... %install rm -rf %{buildroot} make DESTDIR=%{buildroot} install ... %clean rm -rf %{buildroot} ... TO: ... %install make DESTDIR=%{buildroot} install ... %clean ... Is anyone opposed to that? ~spot From rjones at redhat.com Tue May 26 19:13:48 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 26 May 2009 20:13:48 +0100 Subject: Removing %clean (Was Re: Agenda for the 2009-05-26 Packaging Committee meeting) In-Reply-To: <4A1C3CD7.7040600@redhat.com> References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1C3CD7.7040600@redhat.com> Message-ID: <20090526191348.GA32107@amd.home.annexia.org> On Tue, May 26, 2009 at 03:02:47PM -0400, Tom spot Callaway wrote: > Is anyone opposed to that? Sounds like a very reasonable proposal. I'll note that Debian packages include a minimum compatible standards (version) number. The RPM equivalent would I suppose be something like: Min-RPM: 4.4 RPM would check this and refuse to run if its version number was less than this, and of course older versions of RPM would fail completely when they see this header[1]. 'Course we'd have to educate people not to just remove the header or diddle around with the version number at random 'until it works'. Which maybe makes the proposal not completely idiot proof. Rich. [1] Or do they ..? I checked and they give this error: error: line 7: Unknown tag: Min-RPM: 1.1 -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From ml at kiewel-online.ch Tue May 26 19:17:54 2009 From: ml at kiewel-online.ch (Uwe Kiewel) Date: Tue, 26 May 2009 21:17:54 +0200 Subject: dependency errors while upgrading vom F10 to Rawhide (F11) In-Reply-To: <1243362014.16232.92.camel@adam.local.net> References: <4A1BAABF.8050603@kiewel-online.ch> <1243362014.16232.92.camel@adam.local.net> Message-ID: <4A1C4062.5090506@kiewel-online.ch> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam Williamson schrieb: > On Tue, 2009-05-26 at 10:39 +0200, Uwe Kiewel wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi, >> >> I checked the ability to upgrade from F10 to F11 (Rawhide) directly >> using yum. A couple of weeks ago, there were dependency errors with >> python. These errors are not fixed until now. >> >> In my point of view, this issue should be fixed until GA of Leonidas. > > Others have explained what you should do to test this properly, but to > address your final point: QA's stance on this is that the only supported > upgrade methods are via the install images or preupgrade. Upgrade via > yum has the status "not explicitly supported but may well work". I know, it is not explicitly supported. But, if you have a tool that worked four you in the past fine, you expect that behaviour for the future ;-) It's human thinking :-) > We don't consider issues which would cause upgrading from release to > release via yum to be blockers, but issues which would cause upgrading > via preupgrade to fail usually would be. So, I have to google about preupgrade. It's the first time I hear about. I did the upgrade via yum since F5 successfuly... Thanks, Uwe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBShxAYkJXG7BUuynnAQIN3RAAyssNfDr1wxvq2HeAIR2FzPiPB0Hjr6J/ 7G6CpQ4M4vQbU00cJZNDxh5NgOmbK2DTUIa0Ije/gVDSEjvs7RD31o5hUp8DsUkj u+21e+V/wI1YSXJvTrjBxzxqaELwAsoPsn18f26xxO8mFqWKufgoal6yFutL9vIO f6VD9DLA72lrhhSh43AbGtTgdbHYd49Me5rtdd3SgdlIfjGj0RnU+CNdVnUc9B59 HJ5knXMUhywrumZlGtAnXp3p2WBA3A5QNRHzScI82tossfuy6ios4NiCc3ONuIAn p7gTsJoVu2dsc2DzKLkc3n9P54l8b+eskB4jZpOQc4cm+x7SdqSePrzSKiFZ6sDg oXD86N12IBIUezSffBf5si6atMnLY+FJ+UO522SxKt1bKNLwGSIUBayMKn02Drbu hMJRlmfCFkSWIJHKc1cFMJEyZMDOKjJG/t+hWtoA/S9WzRws57zMtmpLsKy8vBAL lRiHY5NABsLPo/xXJAIoiO5oPSDy7tdWLaVVtTvQMm/wEQ7vcKJN8pXrlfssklBb LspMRMHvwYoHJijXofBGnqQ7/NnAZdmaE419fxZ0UGm68LmcY0/gGElewiRHUr1U VvNIOBXY8wng7yjQxFfBVCqSyca6kWMZsicIhBnAMDCN9sqLqAcWVICdyHHXnlSG +Z/7Q7kipuA= =koHu -----END PGP SIGNATURE----- From frankly3d at gmail.com Tue May 26 19:17:44 2009 From: frankly3d at gmail.com (Frank Murphy) Date: Tue, 26 May 2009 20:17:44 +0100 Subject: Why not to create Fedora-us and Fedora-non-us branches? In-Reply-To: <20090526172946.GA12547@nostromo.devel.redhat.com> References: <20090526170612.GJ9951@nostromo.devel.redhat.com> <20090526172946.GA12547@nostromo.devel.redhat.com> Message-ID: <4A1C4058.8090009@gmail.com> Bill Nottingham wrote: > Peter Lemenkov (lemenkov at gmail.com) said: > > ... what exactly are you trying to accomplish? > > Make it legal to ship MP3 code? Sorry, those are patented in Europe as well. > > Patents are *currently* illegal in Europe, (though they may be granted). The patents offices being self-funding and all that. http://en.wikipedia.org/wiki/Software_patents_under_the_European_Patent_Convention "Article 52" Frank From tibbs at math.uh.edu Tue May 26 19:28:55 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 26 May 2009 14:28:55 -0500 Subject: Removing %clean In-Reply-To: <4A1C3CD7.7040600@redhat.com> (Tom Callaway's message of "Tue\, 26 May 2009 15\:02\:47 -0400") References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1C3CD7.7040600@redhat.com> Message-ID: >>>>> "TC" == Tom \"spot\" Callaway writes: TC> Is anyone opposed to that? It's hard to oppose anything that frees us from carrying around all of this useless crap in every specfile. If we ever want our packaging to be considered sane, we have to make progress towards getting rid of stuff we don't really need and dumping the inexplicable random stuff that just gets included verbatim in every specfile without most folks understanding why it's there. - J< From bjorn at xn--rombobjrn-67a.se Tue May 26 19:45:22 2009 From: bjorn at xn--rombobjrn-67a.se (=?iso-8859-1?q?Bj=F6rn_Persson?=) Date: Tue, 26 May 2009 21:45:22 +0200 Subject: Removing %clean In-Reply-To: <4A1C3CD7.7040600@redhat.com> References: <20090526081015.GB27381@amd.home.annexia.org> <4A1C3CD7.7040600@redhat.com> Message-ID: <200905262145.34876.bjorn@xn--rombobjrn-67a.se> Tom "spot" Callaway wrote: > ? ? mkdir -p `dirname "$RPM_BUILD_ROOT"`\ > ? ? mkdir "$RPM_BUILD_ROOT"\ Is that somehow better than just ?mkdir -p "$RPM_BUILD_ROOT"?? Just curious. Bj?rn Persson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From awilliam at redhat.com Tue May 26 20:17:44 2009 From: awilliam at redhat.com (Adam Williamson) Date: Tue, 26 May 2009 13:17:44 -0700 Subject: dependency errors while upgrading vom F10 to Rawhide (F11) In-Reply-To: <4A1C4062.5090506@kiewel-online.ch> References: <4A1BAABF.8050603@kiewel-online.ch> <1243362014.16232.92.camel@adam.local.net> <4A1C4062.5090506@kiewel-online.ch> Message-ID: <1243369064.16232.100.camel@adam.local.net> On Tue, 2009-05-26 at 21:17 +0200, Uwe Kiewel wrote: > > We don't consider issues which would cause upgrading from release to > > release via yum to be blockers, but issues which would cause upgrading > > via preupgrade to fail usually would be. > > So, I have to google about preupgrade. It's the first time I hear about. > I did the upgrade via yum since F5 successfuly... Sure. As I said, practically speaking, it's likely to work in many cases. It's just that if you talk to the people most involved in implementing it (Seth) and testing it (Will) they will tell you that doing live upgrades via yum can't really ever be 100% safe for various reasons, but preupgrade can get very close and is useful in all the same cases. So their position is, we support preupgrade, we don't support yum. If yum works, great, if it doesn't, you can bug people to fix whatever it stopping it working, but it's not 'required' by any policy or guideline. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From ajax at redhat.com Tue May 26 20:19:20 2009 From: ajax at redhat.com (Adam Jackson) Date: Tue, 26 May 2009 16:19:20 -0400 Subject: Dead package notice: freetype1 Message-ID: <1243369160.2505.1.camel@atropine.boston.devel.redhat.com> freetype1 is gone from F12. Nobody's currently using it, and more importantly nobody ought to be, anywhere, ever. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Tue May 26 20:20:00 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 26 May 2009 16:20:00 -0400 (EDT) Subject: dependency errors while upgrading vom F10 to Rawhide (F11) In-Reply-To: <1243369064.16232.100.camel@adam.local.net> References: <4A1BAABF.8050603@kiewel-online.ch> <1243362014.16232.92.camel@adam.local.net> <4A1C4062.5090506@kiewel-online.ch> <1243369064.16232.100.camel@adam.local.net> Message-ID: On Tue, 26 May 2009, Adam Williamson wrote: > On Tue, 2009-05-26 at 21:17 +0200, Uwe Kiewel wrote: > >>> We don't consider issues which would cause upgrading from release to >>> release via yum to be blockers, but issues which would cause upgrading >>> via preupgrade to fail usually would be. >> >> So, I have to google about preupgrade. It's the first time I hear about. >> I did the upgrade via yum since F5 successfuly... > > Sure. As I said, practically speaking, it's likely to work in many > cases. It's just that if you talk to the people most involved in > implementing it (Seth) and testing it (Will) they will tell you that (Will has done most of the implementing in the last MANY releases of preupgrade) > doing live upgrades via yum can't really ever be 100% safe for various > reasons, but preupgrade can get very close and is useful in all the same > cases. So their position is, we support preupgrade, we don't support > yum. If yum works, great, if it doesn't, you can bug people to fix > whatever it stopping it working, but it's not 'required' by any policy > or guideline. The biggest problem you are likely to run into with a yum-based upgrade is situations where updating something takes out the foundation on which yum is running. The fontconfig bug comes to mind. If you want to run yum quasi-safely run it from a terminal, in screen. -sv From awilliam at redhat.com Tue May 26 20:32:50 2009 From: awilliam at redhat.com (Adam Williamson) Date: Tue, 26 May 2009 13:32:50 -0700 Subject: dependency errors while upgrading vom F10 to Rawhide (F11) In-Reply-To: References: <4A1BAABF.8050603@kiewel-online.ch> <1243362014.16232.92.camel@adam.local.net> <4A1C4062.5090506@kiewel-online.ch> <1243369064.16232.100.camel@adam.local.net> Message-ID: <1243369970.16232.101.camel@adam.local.net> On Tue, 2009-05-26 at 16:20 -0400, Seth Vidal wrote: > >> So, I have to google about preupgrade. It's the first time I hear about. > >> I did the upgrade via yum since F5 successfuly... > > > > Sure. As I said, practically speaking, it's likely to work in many > > cases. It's just that if you talk to the people most involved in > > implementing it (Seth) and testing it (Will) they will tell you that > > (Will has done most of the implementing in the last MANY releases of > preupgrade) Sorry, I wasn't clear - by "it" I was talking about yum. You're the guy who implements yum :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From skvidal at fedoraproject.org Tue May 26 20:35:38 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 26 May 2009 16:35:38 -0400 (EDT) Subject: dependency errors while upgrading vom F10 to Rawhide (F11) In-Reply-To: <1243369970.16232.101.camel@adam.local.net> References: <4A1BAABF.8050603@kiewel-online.ch> <1243362014.16232.92.camel@adam.local.net> <4A1C4062.5090506@kiewel-online.ch> <1243369064.16232.100.camel@adam.local.net> <1243369970.16232.101.camel@adam.local.net> Message-ID: On Tue, 26 May 2009, Adam Williamson wrote: > On Tue, 2009-05-26 at 16:20 -0400, Seth Vidal wrote: > >>>> So, I have to google about preupgrade. It's the first time I hear about. >>>> I did the upgrade via yum since F5 successfuly... >>> >>> Sure. As I said, practically speaking, it's likely to work in many >>> cases. It's just that if you talk to the people most involved in >>> implementing it (Seth) and testing it (Will) they will tell you that >> >> (Will has done most of the implementing in the last MANY releases of >> preupgrade) > > Sorry, I wasn't clear - by "it" I was talking about yum. You're the guy > who implements yum :) And a number of other people: James Antill and Tim Lauridisen to name just two important ones. -sv From opensource at till.name Tue May 26 20:44:30 2009 From: opensource at till.name (Till Maas) Date: Tue, 26 May 2009 22:44:30 +0200 Subject: Removing %clean In-Reply-To: <4A1C3CD7.7040600@redhat.com> References: <20090526081015.GB27381@amd.home.annexia.org> <4A1C3CD7.7040600@redhat.com> Message-ID: <200905262244.40505.opensource@till.name> On Di Mai 26 2009, Tom "spot" Callaway wrote: > On 05/26/2009 04:10 AM, Richard W.M. Jones wrote: > * Set the BuildRoot to / and cause massive system destruction What about setting BuildRoot to /home or /etc, this would case similiar massive system destruction? > %__spec_install_pre %{___build_pre}\ > [ "$RPM_BUILD_ROOT" != "/" ] && rm -rf "${RPM_BUILD_ROOT}"\ > mkdir -p `dirname "$RPM_BUILD_ROOT"`\ > mkdir "$RPM_BUILD_ROOT"\ > %{nil} > BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) > ... > > %install > rm -rf %{buildroot} > make DESTDIR=%{buildroot} install > ... > > %clean > rm -rf %{buildroot} > ... > > TO: > > ... > %install > make DESTDIR=%{buildroot} install > ... > %clean > ... > > Is anyone opposed to that? I am not, but it is a little strange to me that now that rpm is fixed that there is no race condition by default with "mkdir $RPM_BUILD_ROOT", why is it then possible to fix this for older versions of rpm in Fedora? This has already been discussed atleast in March 2007 on the Fedora packaging mailinglist. Nevertheless, please do this change. :-) Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From notting at redhat.com Tue May 26 20:51:01 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 26 May 2009 16:51:01 -0400 Subject: Removing %clean In-Reply-To: <200905262244.40505.opensource@till.name> References: <20090526081015.GB27381@amd.home.annexia.org> <4A1C3CD7.7040600@redhat.com> <200905262244.40505.opensource@till.name> Message-ID: <20090526205101.GA15575@nostromo.devel.redhat.com> Till Maas (opensource at till.name) said: > On Di Mai 26 2009, Tom "spot" Callaway wrote: > > On 05/26/2009 04:10 AM, Richard W.M. Jones wrote: > > > * Set the BuildRoot to / and cause massive system destruction > > What about setting BuildRoot to /home or /etc, this would case similiar > massive system destruction? Well, also only if you're building as root. Which you shouldn't do anyways. Bill From choeger at cs.tu-berlin.de Tue May 26 20:50:02 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Tue, 26 May 2009 22:50:02 +0200 Subject: thinkpad and acpi events In-Reply-To: References: <1243347203.2485.4.camel@choeger6> Message-ID: <1243371002.2485.5.camel@choeger6> [choeger at choeger6 ~]$ lsmod | grep think thinkpad_acpi 53944 0 hwmon 2148 1 thinkpad_acpi Seems like it's there. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From opensource at till.name Tue May 26 20:50:16 2009 From: opensource at till.name (Till Maas) Date: Tue, 26 May 2009 22:50:16 +0200 Subject: Removing %clean In-Reply-To: <200905262145.34876.bjorn@xn--rombobjrn-67a.se> References: <4A1C3CD7.7040600@redhat.com> <200905262145.34876.bjorn@xn--rombobjrn-67a.se> Message-ID: <200905262250.22543.opensource@till.name> On Di Mai 26 2009, Bj?rn Persson wrote: > Tom "spot" Callaway wrote: > > mkdir -p `dirname "$RPM_BUILD_ROOT"`\ > > mkdir "$RPM_BUILD_ROOT"\ > > Is that somehow better than just ?mkdir -p "$RPM_BUILD_ROOT"?? Just > curious. It prevents a race condition in case that $(dirname "$RPM_BUILD_ROOT") already exists or if all directories in the path to this directory are only writable by trustworthy users. In the default configuration, this was the /var/tmp directory, where every user could create a directory, make it writable for others and sneak content into the final rpm. Here is an explation, why 'mkdir -p "$RPM_BUILD_ROOT"' is vulnerable: http://lists.opensuse.org/opensuse-packaging/2007-02/msg00005.html Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From joe at nall.com Tue May 26 21:20:11 2009 From: joe at nall.com (Joe Nall) Date: Tue, 26 May 2009 16:20:11 -0500 Subject: Removing %clean In-Reply-To: <200905262250.22543.opensource@till.name> References: <4A1C3CD7.7040600@redhat.com> <200905262145.34876.bjorn@xn--rombobjrn-67a.se> <200905262250.22543.opensource@till.name> Message-ID: <8070303E-4A25-4067-95E3-94BBB1491A25@nall.com> On May 26, 2009, at 3:50 PM, Till Maas wrote: > On Di Mai 26 2009, Bj?rn Persson wrote: >> Tom "spot" Callaway wrote: >>> mkdir -p `dirname "$RPM_BUILD_ROOT"`\ >>> mkdir "$RPM_BUILD_ROOT"\ >> >> Is that somehow better than just ?mkdir -p "$RPM_BUILD_ROOT"?? Just >> curious. > > It prevents a race condition in case that $(dirname > "$RPM_BUILD_ROOT") already > exists or if all directories in the path to this directory are only > writable > by trustworthy users. In the default configuration, this was the / > var/tmp > directory, where every user could create a directory, make it > writable for > others and sneak content into the final rpm. Here is an explation, > why 'mkdir > -p "$RPM_BUILD_ROOT"' is vulnerable: > > http://lists.opensuse.org/opensuse-packaging/2007-02/msg00005.html Or polyinstantiate /var/tmp joe From opensource at till.name Tue May 26 21:25:49 2009 From: opensource at till.name (Till Maas) Date: Tue, 26 May 2009 23:25:49 +0200 Subject: Removing %clean In-Reply-To: <8070303E-4A25-4067-95E3-94BBB1491A25@nall.com> References: <200905262250.22543.opensource@till.name> <8070303E-4A25-4067-95E3-94BBB1491A25@nall.com> Message-ID: <200905262325.55205.opensource@till.name> On Di Mai 26 2009, Joe Nall wrote: > Or polyinstantiate /var/tmp This is something that one cannot change in rpm. Nevertheless rpm has fixed the problem in a similiar way, because instead of using a buildroot below /var/tmp, one below %{topir}/BUILDROOT is used, which is hopefully not in some world writable directory. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mcepl at redhat.com Tue May 26 21:29:31 2009 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 26 May 2009 21:29:31 +0000 (UTC) Subject: Agenda for the 2009-05-26 Packaging Committee meeting References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> Message-ID: Hans de Goede, Tue, 26 May 2009 13:15:23 +0200: > Can we please not remove the Group tag, it is actually quite usefull. > What we need to remove / loose is comps. Having all this info in a > centralized database is stupid. The spec files should tell which > group(s) the package belongs in. So that when one adds a new package, > this gets done right more or less automatically (and is part of the > review). Hear, hear!!! And add Suggests:/Recommends: (which is the other part of comps). +1000 From mcepl at redhat.com Tue May 26 21:25:35 2009 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 26 May 2009 21:25:35 +0000 (UTC) Subject: Why not to create Fedora-us and Fedora-non-us branches? References: <20090526170612.GJ9951@nostromo.devel.redhat.com> <1243358736.3144.23.camel@localhost.localdomain> Message-ID: Jesse Keating, Tue, 26 May 2009 10:25:36 -0700: > Oh, Europe won't help much, there are just as many silly laws there as > there are in the US. Better is some special place in Europe .... thinking ... what about Isle of Man, it has some exceptions from many laws ... err, we wouldn't be first Linux distro headquatered there :) Mat?j From rjones at redhat.com Tue May 26 21:34:10 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 26 May 2009 22:34:10 +0100 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> Message-ID: <20090526213410.GA32719@amd.home.annexia.org> On Tue, May 26, 2009 at 09:29:31PM +0000, Matej Cepl wrote: > Hans de Goede, Tue, 26 May 2009 13:15:23 +0200: > > Can we please not remove the Group tag, it is actually quite usefull. > > What we need to remove / loose is comps. Having all this info in a > > centralized database is stupid. The spec files should tell which > > group(s) the package belongs in. So that when one adds a new package, > > this gets done right more or less automatically (and is part of the > > review). > > Hear, hear!!! And add Suggests:/Recommends: (which is the other part of > comps). > > +1000 +1001 ... I've just been involved with submitting a package for febootstrap to Debian [yay, build Fedora images on Debian!], and I'm reminded yet again what a good idea 'Suggests/Recommends' are. I can Suggest packages like 'filelight' for measuring the effects of image minimization, without making it a proper dependency and consequently pulling in the whole of KDE. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From awilliam at redhat.com Tue May 26 21:50:33 2009 From: awilliam at redhat.com (Adam Williamson) Date: Tue, 26 May 2009 14:50:33 -0700 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: <20090526213410.GA32719@amd.home.annexia.org> References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> Message-ID: <1243374633.16232.103.camel@adam.local.net> On Tue, 2009-05-26 at 22:34 +0100, Richard W.M. Jones wrote: > On Tue, May 26, 2009 at 09:29:31PM +0000, Matej Cepl wrote: > > Hans de Goede, Tue, 26 May 2009 13:15:23 +0200: > > > Can we please not remove the Group tag, it is actually quite usefull. > > > What we need to remove / loose is comps. Having all this info in a > > > centralized database is stupid. The spec files should tell which > > > group(s) the package belongs in. So that when one adds a new package, > > > this gets done right more or less automatically (and is part of the > > > review). > > > > Hear, hear!!! And add Suggests:/Recommends: (which is the other part of > > comps). > > > > +1000 > > +1001 ... > > I've just been involved with submitting a package for febootstrap to > Debian [yay, build Fedora images on Debian!], and I'm reminded yet > again what a good idea 'Suggests/Recommends' are. I can Suggest > packages like 'filelight' for measuring the effects of image > minimization, without making it a proper dependency and consequently > pulling in the whole of KDE. Indeed - Mandriva's had Suggests for a year or two now, and I found it extremely convenient in several packages I maintain(ed). Isn't it going into upstream RPM soon, or in there already? I had this idea that it was. We'd likely still need comps in some form, though. MDV has Suggests and enforces Group tags, and still uses something similar to comps for fine-tuning ISO builds. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From belegdol at gmail.com Tue May 26 22:02:53 2009 From: belegdol at gmail.com (Julian Sikorski) Date: Wed, 27 May 2009 00:02:53 +0200 Subject: Why not to create Fedora-us and Fedora-non-us branches? In-Reply-To: References: <20090526170612.GJ9951@nostromo.devel.redhat.com> <1243358736.3144.23.camel@localhost.localdomain> <4A1C2961.70703@redhat.com> Message-ID: Paul Wouters pisze: > On Tue, 26 May 2009, Stephen Gallagher wrote: > >>> Find us a Company in Europe that is not based in the US that is willing >>> to fund with people and money as much as Red Hat is doing now. >>> >>> Oh, Europe won't help much, there are just as many silly laws there as >>> there are in the US. > > 1) Your packets will still flow through the US anyway. 2) The US claim > jurisdiction even outside their national borders and > reserve the right to prosecute "offenses against American interests" > according to US law, irrespective of where they take place. > > In other words, you could be extradited even if the offense would not > actually be an offense in your country. For example, Dutch people have > been extradited for selling drugs to US citizens in The Netherlands, > even though marihuana is legal. (well, "its complicated") Really? Big Brother is watching ;) > > Also, you could never set foot in the US again without getting arrested, > and most of us don't think those T-6 countries are worh that. > >> Is there a reason that an interested party (in a locale where such >> export is legal) couldn't just create a custom spin on their own (and >> using their own build system) to create a Fedora-T6 spin (or for >> trademark reasons, rebrand it)? I can see this being a perfectly good >> premise for setting up a SIG... > > respin what? remove the crypto? Try removing nss, openssl, gnutls and > kerberos and see what's left of your system. Not much :P > And who would want it? Surely not the T6 countries :P > > Paul > From tgl at redhat.com Tue May 26 23:00:19 2009 From: tgl at redhat.com (Tom Lane) Date: Tue, 26 May 2009 19:00:19 -0400 Subject: Why not to create Fedora-us and Fedora-non-us branches? In-Reply-To: References: <20090526170612.GJ9951@nostromo.devel.redhat.com> <1243358736.3144.23.camel@localhost.localdomain> Message-ID: <20992.1243378819@sss.pgh.pa.us> Matej Cepl writes: > Jesse Keating, Tue, 26 May 2009 10:25:36 -0700: >> Oh, Europe won't help much, there are just as many silly laws there as >> there are in the US. > Better is some special place in Europe .... thinking ... what about Isle > of Man, it has some exceptions from many laws ... err, we wouldn't be > first Linux distro headquatered there :) Unless everyone working on Fedora *moves* to the Isle of Man (and obtains citizenship there), I don't think this sort of maneuver keeps us out of trouble anyway. Realistically we all have to worry about the laws of wherever we live. So as long as a significant fraction of Fedora contributors are in $country, $country laws will matter for Fedora. (Repeat above statement for a rather long list of $country.) regards, tom lane From hugh at mimosa.com Wed May 27 01:19:41 2009 From: hugh at mimosa.com (D. Hugh Redelmeier) Date: Tue, 26 May 2009 21:19:41 -0400 (EDT) Subject: export policy, was Re: Package Maintainers Flags policy In-Reply-To: <4A1C0B33.70804@redhat.com> References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520135717.GA13882@nostromo.devel.redhat.com> <4A1BEF15.70109@redhat.com> <4A1C0B33.70804@redhat.com> Message-ID: | From: Tom "spot" Callaway | On 05/26/2009 10:09 AM, Paul Wouters wrote: | > See above. Note that the Wassenaar Agreement excludes software that is | > in the "public domain", eg free/open source software. | | This is not correct. "Public Domain" has a very specific legal meaning, | and 99% of FOSS does _not_ meet it. Public Domain is when the copyright | holder has explicitly abandoned his/her/its copyright on the work and | placed it into the Public Domain. (Note: In some countries, such as | Germany, this is impossible) Tom is right about the meaning of "public domain" in US law. This is not the meaning in the Wassenaar Agreement. From tim.lauridsen at googlemail.com Wed May 27 05:10:42 2009 From: tim.lauridsen at googlemail.com (Tim Lauridsen) Date: Wed, 27 May 2009 07:10:42 +0200 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: <20090526213410.GA32719@amd.home.annexia.org> References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> Message-ID: <4A1CCB52.4060103@googlemail.com> On 05/26/2009 11:34 PM, Richard W.M. Jones wrote: > On Tue, May 26, 2009 at 09:29:31PM +0000, Matej Cepl wrote: > >> Hans de Goede, Tue, 26 May 2009 13:15:23 +0200: >> >>> Can we please not remove the Group tag, it is actually quite usefull. >>> What we need to remove / loose is comps. Having all this info in a >>> centralized database is stupid. The spec files should tell which >>> group(s) the package belongs in. So that when one adds a new package, >>> this gets done right more or less automatically (and is part of the >>> review). >>> >> Hear, hear!!! And add Suggests:/Recommends: (which is the other part of >> comps). >> >> +1000 >> > +1001 ... > > I've just been involved with submitting a package for febootstrap to > Debian [yay, build Fedora images on Debian!], and I'm reminded yet > again what a good idea 'Suggests/Recommends' are. I can Suggest > packages like 'filelight' for measuring the effects of image > minimization, without making it a proper dependency and consequently > pulling in the whole of KDE. > > Rich. > > soft-deps (Suggests/Recommends) is really hard to handle at the depsolver level. A depsolver need to now the hard ones, not stuff like 'it would look very nice to have pink bracelet to my little pony'. It is hard to make good decisions based on that, a asking the user every time is not a good solution IMO. You will need to take a popquiz every time you what to install a package. I can see that the information can be useful at a high level gui or in some kind of appstore. People there have bought 'foo' have also bought 'bar'. But at the lowlevel like rpm/yum is not very useful, because we don't have the needed infomation to make a good decision. Tim From iarnell at gmail.com Wed May 27 05:27:55 2009 From: iarnell at gmail.com (Iain Arnell) Date: Wed, 27 May 2009 07:27:55 +0200 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: <4A1CCB52.4060103@googlemail.com> References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> Message-ID: <81487f820905262227u245c6e4es25daab7ab58901@mail.gmail.com> On Wed, May 27, 2009 at 7:10 AM, Tim Lauridsen wrote: > > soft-deps (Suggests/Recommends) is really hard to handle at the depsolver > level. A depsolver need to now the hard ones, not stuff like 'it would look > very nice to have pink bracelet to my little pony'. It is hard to make good > decisions based on that, a asking the user every time is not a good solution > IMO. You will need to take a popquiz every time you what to install a > package. > I can see that the information can be useful at a high level gui or in some > kind of appstore. People there have bought 'foo' have also bought 'bar'. But > at the lowlevel like rpm/yum is not very useful, because we don't have the > needed infomation to make a good decision. I wouldn't think it's that hard to implement. When installing a new package, simply treat Suggests as Requires; when removing a package just ignore Suggests completely. Only upgrading adds a little complexity - if new version Suggests something that the old version doesn't, treat it as Requires (so that I get new optional pony accessories automatically), otherwise ignore it (so that I can throw away that optional pink bracelet and not have it come back every time I update). -- Iain. From a.badger at gmail.com Wed May 27 06:00:07 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 26 May 2009 23:00:07 -0700 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: <81487f820905262227u245c6e4es25daab7ab58901@mail.gmail.com> References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <81487f820905262227u245c6e4es25daab7ab58901@mail.gmail.com> Message-ID: <4A1CD6E7.3080805@gmail.com> On 05/26/2009 10:27 PM, Iain Arnell wrote: > On Wed, May 27, 2009 at 7:10 AM, Tim Lauridsen > wrote: >> >> soft-deps (Suggests/Recommends) is really hard to handle at the depsolver >> level. A depsolver need to now the hard ones, not stuff like 'it would look >> very nice to have pink bracelet to my little pony'. It is hard to make good >> decisions based on that, a asking the user every time is not a good solution >> IMO. You will need to take a popquiz every time you what to install a >> package. >> I can see that the information can be useful at a high level gui or in some >> kind of appstore. People there have bought 'foo' have also bought 'bar'. But >> at the lowlevel like rpm/yum is not very useful, because we don't have the >> needed infomation to make a good decision. > > I wouldn't think it's that hard to implement. When installing a new > package, simply treat Suggests as Requires; when removing a package > just ignore Suggests completely. Only upgrading adds a little > complexity - if new version Suggests something that the old version > doesn't, treat it as Requires (so that I get new optional pony > accessories automatically), otherwise ignore it (so that I can throw > away that optional pink bracelet and not have it come back every time > I update). > Note that that would be horrible behaviour for also keeping a minimal packageset. -Toshio From awilliam at redhat.com Wed May 27 07:15:29 2009 From: awilliam at redhat.com (Adam Williamson) Date: Wed, 27 May 2009 00:15:29 -0700 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: <4A1CD6E7.3080805@gmail.com> References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <81487f820905262227u245c6e4es25daab7ab58901@mail.gmail.com> <4A1CD6E7.3080805@gmail.com> Message-ID: <1243408529.16232.108.camel@adam.local.net> On Tue, 2009-05-26 at 23:00 -0700, Toshio Kuratomi wrote: > On 05/26/2009 10:27 PM, Iain Arnell wrote: > > On Wed, May 27, 2009 at 7:10 AM, Tim Lauridsen > > wrote: > >> > >> soft-deps (Suggests/Recommends) is really hard to handle at the depsolver > >> level. A depsolver need to now the hard ones, not stuff like 'it would look > >> very nice to have pink bracelet to my little pony'. It is hard to make good > >> decisions based on that, a asking the user every time is not a good solution > >> IMO. You will need to take a popquiz every time you what to install a > >> package. > >> I can see that the information can be useful at a high level gui or in some > >> kind of appstore. People there have bought 'foo' have also bought 'bar'. But > >> at the lowlevel like rpm/yum is not very useful, because we don't have the > >> needed infomation to make a good decision. > > > > I wouldn't think it's that hard to implement. When installing a new > > package, simply treat Suggests as Requires; when removing a package > > just ignore Suggests completely. Only upgrading adds a little > > complexity - if new version Suggests something that the old version > > doesn't, treat it as Requires (so that I get new optional pony > > accessories automatically), otherwise ignore it (so that I can throw > > away that optional pink bracelet and not have it come back every time > > I update). > > > Note that that would be horrible behaviour for also keeping a minimal > packageset. Iain's suggestion is how it is handled in Mandriva. There is a parameter for urpmi (yum equivalent) - --no-suggests - which inverts the behaviour (suggested packages are not considered dependencies and not installed), and this can be set permanently in urpmi's global config file, for those who prefer to keep minimal package sets. this has worked well for two or three releases now, I haven't seen any complaints about it. when urpmi lists the packages that will be installed as dependencies in a transaction, those that are suggests rather than hard requires are tagged as such, so you can notice if a transaction is introducing a large number of suggested deps you may not necessarily want, and switch to --no-suggests. I believe Debian handles things in a similar way, although it has a more complex setup (there are also Recommends, and Enhances, which is sort of Suggests pointing in the other direction. I'm not sure how those are used.) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From rjones at redhat.com Wed May 27 07:25:31 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 27 May 2009 08:25:31 +0100 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: <4A1CCB52.4060103@googlemail.com> References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> Message-ID: <20090527072531.GA2413@amd.home.annexia.org> On Wed, May 27, 2009 at 07:10:42AM +0200, Tim Lauridsen wrote: > soft-deps (Suggests/Recommends) is really hard to handle at the > depsolver level. A depsolver need to now the hard ones, not stuff like > 'it would look very nice to have pink bracelet to my little pony'. It is > hard to make good decisions based on that, a asking the user every time > is not a good solution IMO. You will need to take a popquiz every time > you what to install a package. > I can see that the information can be useful at a high level gui or in > some kind of appstore. People there have bought 'foo' have also bought > 'bar'. But at the lowlevel like rpm/yum is not very useful, because we > don't have the needed infomation to make a good decision. There's no real difficulty here. The depsolver ignores 'suggests' for resolving dependencies. The UI needs to change to allow these to be selected, or in the case of command line tools like yum, to print them out at the end. "You may also be interested in packages A, B and C". Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From mcepl at redhat.com Wed May 27 07:37:37 2009 From: mcepl at redhat.com (Matej Cepl) Date: Wed, 27 May 2009 07:37:37 +0000 (UTC) Subject: Why not to create Fedora-us and Fedora-non-us branches? References: <20090526170612.GJ9951@nostromo.devel.redhat.com> <1243358736.3144.23.camel@localhost.localdomain> <20992.1243378819@sss.pgh.pa.us> Message-ID: Tom Lane, Tue, 26 May 2009 19:00:19 -0400: > Unless everyone working on Fedora *moves* to the Isle of Man (and > obtains citizenship there), I don't think this sort of maneuver keeps us > out of trouble anyway. Realistically we all have to worry about the > laws of wherever we live. So as long as a significant fraction of > Fedora contributors are in $country, $country laws will matter for > Fedora. (Repeat above statement for a rather long list of $country.) Of course, I was joking and I think that clicking on one link on The Site Which I Rather Won't Call By Its Name and confirming that I want to install new repository is not that big deal. Mat?j From pavel.lisy at gmail.com Wed May 27 07:42:55 2009 From: pavel.lisy at gmail.com (Pavel Lisy) Date: Wed, 27 May 2009 09:42:55 +0200 Subject: How to create header.info file In-Reply-To: References: <1243343669.17152.17.camel@pali-pc.hk.tmapy.cz> Message-ID: <1243410175.17152.74.camel@pali-pc.hk.tmapy.cz> Seth Vidal p??e v ?t 26. 05. 2009 v 09:51 -0400: > > On Tue, 26 May 2009, Pavel Lisy wrote: > > > Hello > > > > I've made my repository for CentOS (3/4/5) with createrepo version > > 0.4.9. > > > > It makes these files > > > > repodata/filelists.xml.gz > > repodata/other.xml.gz > > repodata/primary.xml.gz > > repodata/repomd.xml > > > > Yum is working fine but on > > > > RHEL 4 I've got this error from up2date > > > > An HTTP error occurred: > > URL: > > http://ftp-hk.tmapy.cz/tmapy-twist/centos/4/os/i386/headers/header.info > > Status Code: 404 > > Error Message: Not Found > > > > How can I create this file and other files in headers directory? > > There is nothing in createrepo docs about these files. > > > 1. this is not a fedora-devel question. I know but I am not member of centos list > 2. You can ask on the centos lists about this > > but a short answer though is - look up about yum-arch That's it. Now I see I used to use it but it was longtime ago and I forgot everything. Thank you very much, I wasn't able find this information other way (neither by Google). Pavel > I will not respond to any other questions about the above on this list. > > -sv > From mschwendt at gmail.com Wed May 27 08:01:52 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 27 May 2009 10:01:52 +0200 Subject: Removing %clean In-Reply-To: <20090526205101.GA15575@nostromo.devel.redhat.com> References: <20090526081015.GB27381@amd.home.annexia.org> <4A1C3CD7.7040600@redhat.com> <200905262244.40505.opensource@till.name> <20090526205101.GA15575@nostromo.devel.redhat.com> Message-ID: <20090527100152.0fdae95b@faldor.intranet> On Tue, 26 May 2009 16:51:01 -0400, Bill wrote: > Till Maas said: > > On Di Mai 26 2009, Tom "spot" Callaway wrote: > > > On 05/26/2009 04:10 AM, Richard W.M. Jones wrote: > > > > > * Set the BuildRoot to / and cause massive system destruction > > > > What about setting BuildRoot to /home or /etc, this would case similiar > > massive system destruction? > > Well, also only if you're building as root. Which you shouldn't do > anyways. "rm -rf /home" for a normal user would remove the user's home directory. The added risk for building as root user is due to bugs which may damage the system installation because the buildroot is not a chroot. The software that is built is not forced to install into the buildroot. It is asked to respect parameters like DESTDIR="$RPM_BUILD_ROOT" (provided that $DESTDIR is supported, which is not true in all cases), but that doesn't protect against bugs. It has happened before, for example, that unexpanded [or wrongly expanded] variables caused a build framework to remove wrong paths. From jamatos at fc.up.pt Wed May 27 08:58:45 2009 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Wed, 27 May 2009 09:58:45 +0100 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: <4A1CD6E7.3080805@gmail.com> References: <81487f820905262227u245c6e4es25daab7ab58901@mail.gmail.com> <4A1CD6E7.3080805@gmail.com> Message-ID: <200905270958.45819.jamatos@fc.up.pt> On Wednesday 27 May 2009 07:00:07 Toshio Kuratomi wrote: > > Note that that would be horrible behaviour for also keeping a minimal > packageset. It would be easy to add configuration options with the default being on. For keeping a minimum package set this configuration could be turned off. I don't like the proliferation of configuration options but this example seems to me that it deserves an exception to this rule. > -Toshio -- Jos? Ab?lio From benny+usenet at amorsen.dk Wed May 27 10:12:11 2009 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Wed, 27 May 2009 12:12:11 +0200 Subject: Removing %clean In-Reply-To: <200905262250.22543.opensource@till.name> (Till Maas's message of "Tue\, 26 May 2009 22\:50\:16 +0200") References: <4A1C3CD7.7040600@redhat.com> <200905262145.34876.bjorn@xn--rombobjrn-67a.se> <200905262250.22543.opensource@till.name> Message-ID: Till Maas writes: >> Tom "spot" Callaway wrote: >> > mkdir -p `dirname "$RPM_BUILD_ROOT"`\ >> > mkdir "$RPM_BUILD_ROOT"\ > It prevents a race condition in case that $(dirname "$RPM_BUILD_ROOT") already > exists or if all directories in the path to this directory are only writable > by trustworthy users. In the default configuration, this was the /var/tmp > directory, where every user could create a directory, make it writable for > others and sneak content into the final rpm. The two mkdirs are in reverse order though. Is that intentional? /Benny From thomas.moschny at gmail.com Wed May 27 10:21:31 2009 From: thomas.moschny at gmail.com (Thomas Moschny) Date: Wed, 27 May 2009 12:21:31 +0200 Subject: dependency errors while upgrading from F10 to Rawhide (F11) In-Reply-To: <4A1BC16D.6000707@kiewel-online.ch> References: <4A1BAABF.8050603@kiewel-online.ch> <20090526105729.7495bc12@faldor.intranet> <4A1BB3A9.2020207@kiewel-online.ch> <20090526113734.25fa0d23@faldor.intranet> <4A1BB9DA.4030302@kiewel-online.ch> <20090526115636.4e5ca9a3@faldor.intranet> <4A1BC16D.6000707@kiewel-online.ch> Message-ID: 2009/5/26 Uwe Kiewel : > [root at alberta ~]# yum --enablerepo=rawhide --disablerepo=fedora update > Loaded plugins: fastestmirror, refresh-packagekit > Loading mirror speeds from cached hostfile > YumRepo Error: All mirror URLs are not using ftp, http[s] or file. > ?Eg. / > removing mirrorlist with no valid mirrors: > //var/cache/yum/updates/mirrorlist.txt > > > Cannot find a valid baseurl for repo: updates > [root at alberta ~]# Same here. Updating fedora-release first (the normal procedure) did not work, showing the very same error. See also bz 494054. So from f10+updates (downgraded fedora-relase back to the f10 version), I used: % yum --enablerepo=rawhide upgrade yum fedora-release and afterwards simply % yum upgrade without manually changing any of the repos files. Maybe that two-step procedure is no longer necessary when yum 3.2.23 hits f10updates. The tickets says it is now in updates-testing. - Thomas From skvidal at fedoraproject.org Wed May 27 11:26:59 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 27 May 2009 07:26:59 -0400 (EDT) Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: <20090527072531.GA2413@amd.home.annexia.org> References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <20090527072531.GA2413@amd.home.annexia.org> Message-ID: On Wed, 27 May 2009, Richard W.M. Jones wrote: > On Wed, May 27, 2009 at 07:10:42AM +0200, Tim Lauridsen wrote: >> soft-deps (Suggests/Recommends) is really hard to handle at the >> depsolver level. A depsolver need to now the hard ones, not stuff like >> 'it would look very nice to have pink bracelet to my little pony'. It is >> hard to make good decisions based on that, a asking the user every time >> is not a good solution IMO. You will need to take a popquiz every time >> you what to install a package. >> I can see that the information can be useful at a high level gui or in >> some kind of appstore. People there have bought 'foo' have also bought >> 'bar'. But at the lowlevel like rpm/yum is not very useful, because we >> don't have the needed infomation to make a good decision. > > There's no real difficulty here. The depsolver ignores 'suggests' for > resolving dependencies. The UI needs to change to allow these to be > selected, or in the case of command line tools like yum, to print them > out at the end. "You may also be interested in packages A, B and C". > I think the number of disputing perspectives in this thread ALONE on how suggests would be handles proves that it is not obvious on its face how suggests should be handled. -sv From sundaram at fedoraproject.org Wed May 27 11:31:56 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 27 May 2009 17:01:56 +0530 Subject: Packaging Survey - May 2009 Message-ID: <4A1D24AC.4090802@fedoraproject.org> Hi I did a quick survey from Fedora on what software Fedora users are using that is not available in the repo. Here are the results. If you find anything interesting, feel free to pick it up. https://fedoraproject.org/wiki/Packaging_Survey_May_2009 Rahul From nils at redhat.com Wed May 27 12:16:10 2009 From: nils at redhat.com (Nils Philippsen) Date: Wed, 27 May 2009 14:16:10 +0200 Subject: Online Docs group was: I must be doing something seriously wrong... In-Reply-To: <1242921951.3029.86.camel@localhost.localdomain> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <20090521124654.GB10004@hansolo.jdub.homelinux.org> <1242911359.3356.13.camel@red.localdomain> <1242921951.3029.86.camel@localhost.localdomain> Message-ID: <1243426570.10598.223.camel@gibraltar.str.redhat.com> On Thu, 2009-05-21 at 09:05 -0700, Jesse Keating wrote: > On Thu, 2009-05-21 at 15:09 +0200, Pierre-Yves wrote: > > Maybe packageKit pointing out / highlighting package that have > > subpackage (such as -docs or -flags) might help this advertisement. > > There is an Online Docs group that has the -docs subpackage for many of > the system-config-* packages. It uses conditionals which are painful, > but would be a way for more -docs subpackages to be visible, and if the > user wishes to have local documentation, if available, for the packages > they've chosen, they can pick that group. > > The group name is a bit... wrong, but maybe a group of people that care > about documentation could help come up with a better name, and help to > ensure that all the available -docs packages get listed in this group. Sorry for chiming in late, but I'm just catching up with email after being on vacation. This particular group was my brain-fart, I just wanted to have a way to easily include/exclude online help documentation (mostly to make it easy for people doing live media to leave it out). Feel free to rename if you have a more suitable idea, though. If there is another means to achieve the same purpose, I'm all ears as well. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty nils at redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From nikolay at vladimiroff.com Wed May 27 12:38:17 2009 From: nikolay at vladimiroff.com (Nikolay Vladimirov) Date: Wed, 27 May 2009 15:38:17 +0300 Subject: Packaging Survey - May 2009 In-Reply-To: <4A1D24AC.4090802@fedoraproject.org> References: <4A1D24AC.4090802@fedoraproject.org> Message-ID: 2009/5/27 Rahul Sundaram : > Hi > > I did a quick survey from Fedora on what software Fedora users are using > that is not available in the repo. Here are the results. If you find > anything interesting, feel free to pick it up. > > https://fedoraproject.org/wiki/Packaging_Survey_May_2009 > > Rahul > Hi I looked at Unknown Horizons and it has Creative Commons Sampling Plus 1.0 license[1] on some[2] of the sounds. I noted this in the table also added the game to the forbidden games list until upstream can replace these sounds. [1] http://www.unknown-horizons.org/site/index.php?page=licence [2] http://trac.unknown-horizons.org/browser/trunk/content/audio/sounds/SOUND_LICENSE?rev=1961 -- NV From sundaram at fedoraproject.org Wed May 27 12:45:38 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 27 May 2009 18:15:38 +0530 Subject: Packaging Survey - May 2009 In-Reply-To: References: <4A1D24AC.4090802@fedoraproject.org> Message-ID: <4A1D35F2.7030401@fedoraproject.org> On 05/27/2009 06:08 PM, Nikolay Vladimirov wrote: > > I looked at Unknown Horizons and it has Creative Commons Sampling Plus > 1.0 license[1] on some[2] of the sounds. > I noted this in the table also added the game to the forbidden games > list until upstream can replace these sounds. > > [1] http://www.unknown-horizons.org/site/index.php?page=licence > [2] http://trac.unknown-horizons.org/browser/trunk/content/audio/sounds/SOUND_LICENSE?rev=1961 Thanks for looking into this. This is a small number. We have some folks interested in sound and can provide replacements. CC'ing. Rahul From opensource at till.name Wed May 27 12:49:57 2009 From: opensource at till.name (Till Maas) Date: Wed, 27 May 2009 14:49:57 +0200 Subject: Packaging Survey - May 2009 In-Reply-To: <4A1D24AC.4090802@fedoraproject.org> References: <4A1D24AC.4090802@fedoraproject.org> Message-ID: <200905271450.04746.opensource@till.name> On Wed May 27 2009, Rahul Sundaram wrote: > I did a quick survey from Fedora on what software Fedora users are using > that is not available in the repo. Here are the results. If you find > anything interesting, feel free to pick it up. > > https://fedoraproject.org/wiki/Packaging_Survey_May_2009 remind is already in Fedora since F6: https://admin.fedoraproject.org/pkgdb/packages/name/remind I removed it from the list, but the added it back. I am not sure why, but providing a editor note about your changes would make it a lot easier to cooperate, e.g. you can see in the history why I removed remind and in which revision thanks to the note. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From nikolay at vladimiroff.com Wed May 27 12:59:28 2009 From: nikolay at vladimiroff.com (Nikolay Vladimirov) Date: Wed, 27 May 2009 15:59:28 +0300 Subject: Packaging Survey - May 2009 In-Reply-To: <4A1D35F2.7030401@fedoraproject.org> References: <4A1D24AC.4090802@fedoraproject.org> <4A1D35F2.7030401@fedoraproject.org> Message-ID: 2009/5/27 Rahul Sundaram wrote: > On 05/27/2009 06:08 PM, Nikolay Vladimirov wrote: > >> >> I looked at Unknown Horizons and it has Creative Commons Sampling Plus >> 1.0 license[1] on some[2] of the sounds. >> I noted this in the table also added the game to the forbidden games >> list until upstream can replace these sounds. >> >> [1] http://www.unknown-horizons.org/site/index.php?page=licence >> [2] http://trac.unknown-horizons.org/browser/trunk/content/audio/sounds/SOUND_LICENSE?rev=1961 > > Thanks for looking into this. This is a small number. We have some folks > interested in sound and can provide replacements. CC'ing. > > Rahul > Upstream request for this -> http://trac.unknown-horizons.org/ticket/312 -- NV From jamatos at fc.up.pt Wed May 27 13:23:13 2009 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Wed, 27 May 2009 14:23:13 +0100 Subject: Packaging Survey - May 2009 In-Reply-To: <4A1D24AC.4090802@fedoraproject.org> References: <4A1D24AC.4090802@fedoraproject.org> Message-ID: <200905271423.14265.jamatos@fc.up.pt> On Wednesday 27 May 2009 12:31:56 Rahul Sundaram wrote: > Hi > > I did a quick survey from Fedora on what software Fedora users are using > that is not available in the repo. Here are the results. If you find > anything interesting, feel free to pick it up. > > https://fedoraproject.org/wiki/Packaging_Survey_May_2009 root is being reviewed (https://bugzilla.redhat.com/show_bug.cgi?id=451744) > Rahul -- Jos? Ab?lio From sundaram at fedoraproject.org Wed May 27 13:28:39 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 27 May 2009 18:58:39 +0530 Subject: Packaging Survey - May 2009 In-Reply-To: <200905271450.04746.opensource@till.name> References: <4A1D24AC.4090802@fedoraproject.org> <200905271450.04746.opensource@till.name> Message-ID: <4A1D4007.7000407@fedoraproject.org> On 05/27/2009 06:19 PM, Till Maas wrote: > On Wed May 27 2009, Rahul Sundaram wrote: > >> I did a quick survey from Fedora on what software Fedora users are using >> that is not available in the repo. Here are the results. If you find >> anything interesting, feel free to pick it up. >> >> https://fedoraproject.org/wiki/Packaging_Survey_May_2009 > > remind is already in Fedora since F6: > https://admin.fedoraproject.org/pkgdb/packages/name/remind > > I removed it from the list, but the added it back. My mistake. I thought I had accidentally deleted it and added it back I am not sure why, but > providing a editor note about your changes would make it a lot easier to > cooperate, e.g. you can see in the history why I removed remind and in which > revision thanks to the note. I added a comment instead. Thanks. Rahul From sundaram at fedoraproject.org Wed May 27 13:29:17 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 27 May 2009 18:59:17 +0530 Subject: Packaging Survey - May 2009 In-Reply-To: <200905271423.14265.jamatos@fc.up.pt> References: <4A1D24AC.4090802@fedoraproject.org> <200905271423.14265.jamatos@fc.up.pt> Message-ID: <4A1D402D.8040700@fedoraproject.org> On 05/27/2009 06:53 PM, Jos? Matos wrote: > On Wednesday 27 May 2009 12:31:56 Rahul Sundaram wrote: >> Hi >> >> I did a quick survey from Fedora on what software Fedora users are using >> that is not available in the repo. Here are the results. If you find >> anything interesting, feel free to pick it up. >> >> https://fedoraproject.org/wiki/Packaging_Survey_May_2009 > > root is being reviewed (https://bugzilla.redhat.com/show_bug.cgi?id=451744) Added the review request to the wiki to keep track of this. Thanks. Rahul From skvidal at fedoraproject.org Wed May 27 13:30:31 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 27 May 2009 09:30:31 -0400 (EDT) Subject: Packaging Survey - May 2009 In-Reply-To: <200905271423.14265.jamatos@fc.up.pt> References: <4A1D24AC.4090802@fedoraproject.org> <200905271423.14265.jamatos@fc.up.pt> Message-ID: On Wed, 27 May 2009, Jos? Matos wrote: > On Wednesday 27 May 2009 12:31:56 Rahul Sundaram wrote: >> Hi >> >> I did a quick survey from Fedora on what software Fedora users are using >> that is not available in the repo. Here are the results. If you find >> anything interesting, feel free to pick it up. >> >> https://fedoraproject.org/wiki/Packaging_Survey_May_2009 > > root is being reviewed (https://bugzilla.redhat.com/show_bug.cgi?id=451744) I have no problem with root being packaged, it used to be no small task to package root so if it is on its way I think that's great. I just want to relate my first exposure to 'root'. I was a sysadmin in the physics dept at duke university. I was told one of the workstations in the High Energy Physics dept was running slowly and asked if I could check it out. I login and discover a process running named 'rootd'. I suspend my desire to freak out a bit and eventually trace it back to a user's homedir where they've unzipped and built a local copy of cern's root. At this point I vow a silent oath to get even with whomever named the software 'root' and go about my day. That's my story. :) -sv From smohan at redhat.com Wed May 27 13:36:03 2009 From: smohan at redhat.com (smohan at redhat.com) Date: Wed, 27 May 2009 09:36:03 -0400 (EDT) Subject: Fedora and the moblin2 fork In-Reply-To: <8629962.2191243431294823.JavaMail.smohan@dhcp1-117.pnq.redhat.com> Message-ID: <6061983.2211243431360079.JavaMail.smohan@dhcp1-117.pnq.redhat.com> ----- "Satish Mohan" wrote: > ----- Original Message ----- > From: "Peter Robinson" > To: "Development discussions related to Fedora" > > Sent: Friday, May 22, 2009 1:50:31 PM GMT +05:30 Chennai, Kolkata, > Mumbai, New Delhi > Subject: Re: Fedora and the moblin2 fork > > On Fri, May 22, 2009 at 5:25 AM, Adam Miller > wrote: > > In an attempt to get the ball rolling, I was hoping that we might > be > > able to get some direction on where bits need work and/or what > parts > > of Moblin we would like to include with Fedora. > > > > If this is already outlined somewhere and I might have simply > missed > > it, please post me the URL so that I can try and start working on > bits > > a pieces I am able as soon as I get some free time. > > Not yet, but its on my todo list. I might even get to it over the > weekend. > > Got it working with rawhide. Looking for a place to host the rpms and > srpms > > Not a clean build, but it works Packages available at http://smohan.fedorapeople.org/moblin2/ This is just a rebuild of stock moblin2 rpms with minor tweaks. Satish From maxamillion at gmail.com Wed May 27 13:43:23 2009 From: maxamillion at gmail.com (Adam Miller) Date: Wed, 27 May 2009 08:43:23 -0500 Subject: Fedora and the moblin2 fork In-Reply-To: <6061983.2211243431360079.JavaMail.smohan@dhcp1-117.pnq.redhat.com> References: <8629962.2191243431294823.JavaMail.smohan@dhcp1-117.pnq.redhat.com> <6061983.2211243431360079.JavaMail.smohan@dhcp1-117.pnq.redhat.com> Message-ID: If you package and maintain all of those .... and wrote the kickstart for the spin, is there really anything else for the rest of us to do? -Adam -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From opensource at till.name Wed May 27 13:44:08 2009 From: opensource at till.name (Till Maas) Date: Wed, 27 May 2009 15:44:08 +0200 Subject: rawhide report: 20090523 changes In-Reply-To: <1243361077.2324.0.camel@localhost.localdomain> References: <20090523141954.2494F1F820F@releng2.fedora.phx.redhat.com> <200905261912.12593.opensource@till.name> <1243361077.2324.0.camel@localhost.localdomain> Message-ID: <200905271544.15053.opensource@till.name> On Tue May 26 2009, Matthias Clasen wrote: > On Tue, 2009-05-26 at 19:12 +0200, Till Maas wrote: > > It is already done on the Fedorapeople server: > > https://fedoraproject.org/wiki/Infrastructure/FedoraPeopleConfig#polyinst > >antiated_tempdirs > > Hey, nice. > > That should really be an F12 feature. Here is a draft feature page for this: https://fedoraproject.org/wiki/Features/Polyinstantiated_Temporary_Directories Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From sundaram at fedoraproject.org Wed May 27 13:48:29 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 27 May 2009 19:18:29 +0530 Subject: Fedora and the moblin2 fork In-Reply-To: References: <8629962.2191243431294823.JavaMail.smohan@dhcp1-117.pnq.redhat.com> <6061983.2211243431360079.JavaMail.smohan@dhcp1-117.pnq.redhat.com> Message-ID: <4A1D44AD.9030103@fedoraproject.org> On 05/27/2009 07:13 PM, Adam Miller wrote: > If you package and maintain all of those .... and wrote the kickstart > for the spin, is there really anything else for the rest of us to do? These packages are just hacks put up together to get a live cd up and running quickly. Interested people should go through them, submit them for review, push changes upstream etc. Rahul From loganjerry at gmail.com Wed May 27 14:11:57 2009 From: loganjerry at gmail.com (Jerry James) Date: Wed, 27 May 2009 08:11:57 -0600 Subject: Packaging Survey - May 2009 In-Reply-To: <4A1D24AC.4090802@fedoraproject.org> References: <4A1D24AC.4090802@fedoraproject.org> Message-ID: <870180fe0905270711r586d974dw1a39345c5b29a380@mail.gmail.com> On Wed, May 27, 2009 at 5:31 AM, Rahul Sundaram wrote: > Hi > > I did a quick survey from Fedora on what software Fedora users are using > that is not available in the repo. Here are the results. If you find > anything interesting, feel free to pick it up. > > https://fedoraproject.org/wiki/Packaging_Survey_May_2009 > > Rahul That's an interesting list! I wonder why CMU Common Lisp is on there, though. It's been in Fedora for a long time: https://admin.fedoraproject.org/pkgdb/packages/name/cmucl Perhaps it is because CMUCL is available on 32-bit systems only, so somebody with a 64-bit system noticed that it was "missing". -- Jerry James http://www.jamezone.org/ From sundaram at fedoraproject.org Wed May 27 14:17:30 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 27 May 2009 19:47:30 +0530 Subject: Packaging Survey - May 2009 In-Reply-To: <870180fe0905270711r586d974dw1a39345c5b29a380@mail.gmail.com> References: <4A1D24AC.4090802@fedoraproject.org> <870180fe0905270711r586d974dw1a39345c5b29a380@mail.gmail.com> Message-ID: <4A1D4B7A.2080808@fedoraproject.org> On 05/27/2009 07:41 PM, Jerry James wrote: > > https://admin.fedoraproject.org/pkgdb/packages/name/cmucl > > Perhaps it is because CMUCL is available on 32-bit systems only, so > somebody with a 64-bit system noticed that it was "missing". Very likely. This is all direct feedback from fedora-list and fedoraforum.org primarily. So I guess the user was using 64-bit. I will ask him. Why isn't CMUCL available for 64-bit systems? Rahul From tcallawa at redhat.com Wed May 27 14:19:05 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 27 May 2009 10:19:05 -0400 Subject: export policy, was Re: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520135717.GA13882@nostromo.devel.redhat.com> <4A1BEF15.70109@redhat.com> <4A1C0B33.70804@redhat.com> Message-ID: <4A1D4BD9.90302@redhat.com> On 05/26/2009 09:19 PM, D. Hugh Redelmeier wrote: > | From: Tom "spot" Callaway > > | On 05/26/2009 10:09 AM, Paul Wouters wrote: > | > See above. Note that the Wassenaar Agreement excludes software that is > | > in the "public domain", eg free/open source software. > | > | This is not correct. "Public Domain" has a very specific legal meaning, > | and 99% of FOSS does _not_ meet it. Public Domain is when the copyright > | holder has explicitly abandoned his/her/its copyright on the work and > | placed it into the Public Domain. (Note: In some countries, such as > | Germany, this is impossible) > > Tom is right about the meaning of "public domain" in US law. This is > not the meaning in the Wassenaar Agreement. Hmm, I dug this out of the WA, and Hugh is right: "In the public domain" This means "technology" or "software" which has been made available without restrictions upon its further dissemination. Note Copyright restrictions do not remove "technology" or "software" from being "in the public domain". A poor choice of words, especially since the terminology "public domain" has had a well defined and accepted international legal meaning long before the WA. This definition also seems contradictory, as redistribution is not a right automatically granted, it is only granted as an extension of copyright. However, it is noteworthy that Encryption software does not qualify for this exception in the WA, which is the main reason that Fedora has this export policy in the first place. ~spot From rjones at redhat.com Wed May 27 14:21:34 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 27 May 2009 15:21:34 +0100 Subject: Packaging Survey - May 2009 In-Reply-To: <4A1D4B7A.2080808@fedoraproject.org> References: <4A1D24AC.4090802@fedoraproject.org> <870180fe0905270711r586d974dw1a39345c5b29a380@mail.gmail.com> <4A1D4B7A.2080808@fedoraproject.org> Message-ID: <20090527142134.GA5104@amd.home.annexia.org> On Wed, May 27, 2009 at 07:47:30PM +0530, Rahul Sundaram wrote: > On 05/27/2009 07:41 PM, Jerry James wrote: > > > > > https://admin.fedoraproject.org/pkgdb/packages/name/cmucl > > > > Perhaps it is because CMUCL is available on 32-bit systems only, so > > somebody with a 64-bit system noticed that it was "missing". > > Very likely. This is all direct feedback from fedora-list and > fedoraforum.org primarily. So I guess the user was using 64-bit. I will > ask him. Why isn't CMUCL available for 64-bit systems? Because no one managed to write a code generator for x86-64 and PPC yet: https://bugzilla.redhat.com/show_bug.cgi?id=185085 Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From maxamillion at gmail.com Wed May 27 14:21:42 2009 From: maxamillion at gmail.com (Adam Miller) Date: Wed, 27 May 2009 09:21:42 -0500 Subject: The future of firestarter Message-ID: I recently picked up the firestarter package because it was orphaned and I know a few people who still use it. There were only a couple of small bugs opened against it so I figured I would hack at them as soon as I was able. But this morning there was a bug filed against it to port it to PolicyKit and I've run into two problems. 1) I know very little about PolicyKit other than a general overview of the purpose it serves and 2) I don't think it would really be worth doing all that work for a package that hasn't had any upstream activity in over 4 years. So my question is this, should I orphan this package such that someone else who feels the efforts wouldn't be wasted may take the time to perform the work or should I just retire the package? -Adam -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From rdieter at math.unl.edu Wed May 27 14:24:35 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 27 May 2009 09:24:35 -0500 Subject: Packaging Survey - May 2009 References: <4A1D24AC.4090802@fedoraproject.org> <870180fe0905270711r586d974dw1a39345c5b29a380@mail.gmail.com> <4A1D4B7A.2080808@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > Why isn't CMUCL available for 64-bit systems? Simply not supported (or bootstrapped) there. -- Rex From skvidal at fedoraproject.org Wed May 27 14:27:33 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 27 May 2009 10:27:33 -0400 (EDT) Subject: The future of firestarter In-Reply-To: References: Message-ID: On Wed, 27 May 2009, Adam Miller wrote: > I recently picked up the firestarter package because it was orphaned > and I know a few people who still use it. There were only a couple of > small bugs opened against it so I figured I would hack at them as soon > as I was able. But this morning there was a bug filed against it to > port it to PolicyKit and I've run into two problems. 1) I know very > little about PolicyKit other than a general overview of the purpose it > serves and 2) I don't think it would really be worth doing all that > work for a package that hasn't had any upstream activity in over 4 > years. So my question is this, should I orphan this package such that > someone else who feels the efforts wouldn't be wasted may take the > time to perform the work or should I just retire the package? > with no offense to the pkg itself - if it has not been maintained in that many years - then retire it. I think, in general, we need more people willing to put out to pasture unmaintained pkgs that are in need of new development/maintainance. -sv From sundaram at fedoraproject.org Wed May 27 14:29:23 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 27 May 2009 19:59:23 +0530 Subject: The future of firestarter In-Reply-To: References: Message-ID: <4A1D4E43.2050700@fedoraproject.org> On 05/27/2009 07:51 PM, Adam Miller wrote: > I recently picked up the firestarter package because it was orphaned > and I know a few people who still use it. There were only a couple of > small bugs opened against it so I figured I would hack at them as soon > as I was able. But this morning there was a bug filed against it to > port it to PolicyKit and I've run into two problems. 1) I know very > little about PolicyKit other than a general overview of the purpose it > serves and 2) I don't think it would really be worth doing all that > work for a package that hasn't had any upstream activity in over 4 > years. So my question is this, should I orphan this package such that > someone else who feels the efforts wouldn't be wasted may take the > time to perform the work or should I just retire the package? If upstream is dead and you are not going to do the work, just close the bug as WONTFIX. Yes, I filed the RFE in the first place but I wasn't aware that upstream is dead. So don't let that scare you from continuing to be the maintainer of it. Of course, if anyone is willing to do the work, that would be nice but probably not worth the effort if it is going to be a big patch. Rahul From loganjerry at gmail.com Wed May 27 14:24:33 2009 From: loganjerry at gmail.com (Jerry James) Date: Wed, 27 May 2009 08:24:33 -0600 Subject: Packaging Survey - May 2009 In-Reply-To: <20090527142134.GA5104@amd.home.annexia.org> References: <4A1D24AC.4090802@fedoraproject.org> <870180fe0905270711r586d974dw1a39345c5b29a380@mail.gmail.com> <4A1D4B7A.2080808@fedoraproject.org> <20090527142134.GA5104@amd.home.annexia.org> Message-ID: <870180fe0905270724g6100aa0cp9d15602b78a0deb9@mail.gmail.com> On Wed, May 27, 2009 at 8:21 AM, Richard W.M. Jones wrote: > Because no one managed to write a code generator for x86-64 > and PPC yet: > > https://bugzilla.redhat.com/show_bug.cgi?id=185085 > > Rich. > > -- > Richard Jones, Emerging Technologies, Red Hat ?http://et.redhat.com/~rjones > virt-df lists disk usage of guests without needing to install any > software inside the virtual machine. ?Supports Linux and Windows. > http://et.redhat.com/~rjones/virt-df/ Also, there are a number of places in the code where it is assumed that sizeof(void *) == sizeof(int). Note that SBCL, which is also in Fedora, is a fork of CMUCL. SBCL does work on 64-bit systems. The two are not entirely compatible, though. -- Jerry James http://www.jamezone.org/ From maxamillion at gmail.com Wed May 27 14:33:20 2009 From: maxamillion at gmail.com (Adam Miller) Date: Wed, 27 May 2009 09:33:20 -0500 Subject: The future of firestarter In-Reply-To: <4A1D4E43.2050700@fedoraproject.org> References: <4A1D4E43.2050700@fedoraproject.org> Message-ID: > If upstream is dead and you are not going to do the work, just close the > bug as WONTFIX. Yes, I filed the RFE in the first place but I wasn't > aware that upstream is dead. So don't let that scare you from continuing > to be the maintainer of it. Of course, if anyone is willing to do the > work, that would be nice but probably not worth the effort if it is > going to be a big patch. > > Rahul > I would honestly rather retire the package than do a WONTFIX, if the project as a whole is going the direction of PolicyKit and upstream is dead then I don't want to keep old and busted cruft around the repositories as Fedora continues to look towards the future. -Adam -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From drago01 at gmail.com Wed May 27 14:59:58 2009 From: drago01 at gmail.com (drago01) Date: Wed, 27 May 2009 16:59:58 +0200 Subject: Orphaning some packages (gdhcpd, wxdfast, beagle) Message-ID: Hi, I am looking for new maintainers for those packages: gdhcpd: I do not really use it, upstream has released a new version a while ago but the fedora package still is at the old version. Bugs: https://admin.fedoraproject.org/pkgdb/packages/bugs/gdhcpd wxdfast: Upstream is pretty much dead (no activity for years). Bugs: https://admin.fedoraproject.org/pkgdb/packages/bugs/wxdfast beagle: Package needs a lot of work and I don't really have time for it (upstream is also quite busy so there is little activity there too). Bugs: https://admin.fedoraproject.org/pkgdb/packages/bugs/beagle If someone wants to take (one of) them please reply to this mail. From pertusus at free.fr Wed May 27 15:08:00 2009 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 27 May 2009 17:08:00 +0200 Subject: uread is orphaned Message-ID: <20090527150800.GA6583@free.fr> Hello, Most of my packages found a new maintainer, but I just noticed that uread is still orphaned. It is a very easy to maintain software that detects what is in fortran formatted files. https://admin.fedoraproject.org/pkgdb/packages/name/uread I just filled a bug because there is a new version. Last one was in... 1998! https://bugzilla.redhat.com/show_bug.cgi?id=502842 -- Pat From jkeating at redhat.com Wed May 27 15:10:38 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 27 May 2009 08:10:38 -0700 Subject: Online Docs group was: I must be doing something seriously wrong... In-Reply-To: <1243426570.10598.223.camel@gibraltar.str.redhat.com> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <20090521124654.GB10004@hansolo.jdub.homelinux.org> <1242911359.3356.13.camel@red.localdomain> <1242921951.3029.86.camel@localhost.localdomain> <1243426570.10598.223.camel@gibraltar.str.redhat.com> Message-ID: <1243437038.3144.72.camel@localhost.localdomain> On Wed, 2009-05-27 at 14:16 +0200, Nils Philippsen wrote: > Sorry for chiming in late, but I'm just catching up with email after > being on vacation. This particular group was my brain-fart, I just > wanted to have a way to easily include/exclude online help documentation > (mostly to make it easy for people doing live media to leave it out). > Feel free to rename if you have a more suitable idea, though. If there > is another means to achieve the same purpose, I'm all ears as well. The existence of the group is fine, and it should probably grow. The problem is the name. "Online" at least here in the states means on the internet, so "Online Docs" would mean documents that your read via the Internet. "Offline Docs" is almost more correct but still a bit awkward. Anyway, I don't really have good suggestions. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From rawhide at fedoraproject.org Wed May 27 15:12:13 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Wed, 27 May 2009 15:12:13 +0000 (UTC) Subject: rawhide report: 20090527 changes Message-ID: <20090527151213.C4FF81F821C@releng2.fedora.phx.redhat.com> Compose started at Wed May 27 06:15:04 UTC 2009 Updated Packages: anaconda-11.5.0.56-1.fc11 ------------------------- * Tue May 26 2009 Chris Lumens - 11.5.0.55-1 - Fix blank network device descriptions in the loader. (#501757) (notting) - Make sure the right _isMigratable gets used for Ext3FS (#501585). (clumens) * Tue May 26 2009 Chris Lumens - 11.5.0.56-1 - Ensure matching rootfs type to live type with autopart (#501876) (katzj) eggdrop-1.6.19-4.fc11 --------------------- * Tue May 26 2009 Robert Scheck 1.6.19-4 - Added upstream ctcpfix to solve CVE-2009-1789 (#502650) kernel-2.6.29.4-162.fc11 ------------------------ * Mon May 25 2009 Kyle McMartin 2.6.29.3-160 - kvm fixes destined for 2.6.30, rhbz#492838: kvm-Fix-PDPTR-reloading-on-CR4-writes.patch kvm-Make-paravirt-tlb-flush-also-reload-the-PAE-PDP.patch * Mon May 25 2009 Kyle McMartin 2.6.29.4-161 - Linux 2.6.29.4 - dropped patches: linux-2.6-i2c-fix-bit-algorithm-timeout.patch linux-2.6-ftdi-oops.patch linux-2.6-btrfs-fix-page-mkwrite.patch - rebased patches: linux-2.6-btrfs-unstable-update.patch, page_mkwrite fixes. * Mon May 25 2009 Kyle McMartin 2.6.29.4-162 - keys-Handle-there-being-no-fallback-destination-key.patch: fix oops at boot with autofs/krb/cifs rhbz#501588. * Fri May 22 2009 John W. Linville - 2.6.29.3-158 - back-port "iwl3945: use cancel_delayed_work_sync to cancel rfkill_poll" - modify changelog entry from Apr 13 2009 to reference correct patch * Fri May 22 2009 Kyle McMartin 2.6.29.3-159 - drm-copyback-ioctl-data-to-userspace-regardless-of-retcode.patch: Fix possible hang in drmWaitVblank. upstream 9b6fe313bfce27d4a261257da70196be0ac2bef5. * Thu May 21 2009 Kyle McMartin - 2.6.29.3-157 - mac80211-don-t-drop-nullfunc-frames-during-software.patch: upstream a9a6ffffd05f97e6acbdeafc595e269855829751. mdadm-3.0-0.devel3.7.fc11 ------------------------- * Tue May 19 2009 Doug Ledford - 3.0-0.devel3.7 - Only check raid devices on weekly scrubbing, don't attempt to repair them mkinitrd-6.0.86-1.fc11 ---------------------- * Thu May 21 2009 Bill Nottingham - 6.0.86-1 - Reorder font initialization to properly handle KMS openoffice.org-3.1.0-11.3.fc11 ------------------------------ * Mon May 25 2009 Caol??n McNamara - 1:3.1.0-11.3 - add in the ia64 and arm fixes for the secondary arch people - Resolves(partially): rhbz#495901 No default font-width for wmf export - ooo#101567 add Maithili locale data (some dodgy negative value and listseperator though) - Resolves: rhbz#499474 soffice and .recently-used.xbel - Resolves: ooo#102194 crash export on .doc with unused style in .toc policycoreutils-2.0.62-12.6.fc11 -------------------------------- * Fri May 22 2009 Dan Walsh 2.0.62-12.6 - Add sandbox script * Tue May 12 2009 Dan Walsh 2.0.62-12.4 - Fix portspage and generation of init_script_file in templates * Tue May 12 2009 Dan Walsh 2.0.62-12.5 - More portspage fixes rhpl-0.221-1 ------------ * Tue May 26 2009 Jeremy Katz 0.222-1 - Fix leaking fd for loadkeys with a big hammer (#501368) - Fix Russian keyboard (#492544) Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 8 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From limb at jcomserv.net Wed May 27 15:16:02 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 27 May 2009 10:16:02 -0500 Subject: uread is orphaned In-Reply-To: <20090527150800.GA6583@free.fr> References: <20090527150800.GA6583@free.fr> Message-ID: <4A1D5932.5070206@jcomserv.net> Patrice Dumas wrote: > Hello, > > Most of my packages found a new maintainer, but I just noticed that > uread is still orphaned. It is a very easy to maintain software that > detects what is in fortran formatted files. > > https://admin.fedoraproject.org/pkgdb/packages/name/uread > > I just filled a bug because there is a new version. Last one was > in... 1998! > > https://bugzilla.redhat.com/show_bug.cgi?id=502842 > > -- > Pat > > I picked it up. -- in your fear, speak only peace in your fear, seek only love -d. bowie From paul at xelerance.com Wed May 27 15:16:22 2009 From: paul at xelerance.com (Paul Wouters) Date: Wed, 27 May 2009 11:16:22 -0400 (EDT) Subject: export policy, was Re: Package Maintainers Flags policy In-Reply-To: References: <20090518090953.5698908a@ohm.scrye.com> <4A13AF44.6040406@poolshark.org> <20090520083257.GG32139@macmahon.me.uk> <4A13C879.4080002@poolshark.org> <20090520135717.GA13882@nostromo.devel.redhat.com> <4A1BEF15.70109@redhat.com> <4A1C0B33.70804@redhat.com> Message-ID: On Tue, 26 May 2009, D. Hugh Redelmeier wrote: > | On 05/26/2009 10:09 AM, Paul Wouters wrote: > | > See above. Note that the Wassenaar Agreement excludes software that is > | > in the "public domain", eg free/open source software. > | > | This is not correct. "Public Domain" has a very specific legal meaning, > | and 99% of FOSS does _not_ meet it. Public Domain is when the copyright > | holder has explicitly abandoned his/her/its copyright on the work and > | placed it into the Public Domain. (Note: In some countries, such as > | Germany, this is impossible) > > Tom is right about the meaning of "public domain" in US law. This is > not the meaning in the Wassenaar Agreement. That's right, in the Wassenaar context it is (http://jya.com/wass-au.htm): "in the public domain" (GTN NTN GSN), as it applies herein, means "technology" or "software" which has been made available without restrictions upon its further dissemination (copyright restrictions do not remove "technology" or "software" from being "in the public domain") Note that the US has various restrictions on top of the Wassenaar Agreement, but those do not apply to me (as upstream) Paul From mw_triad at users.sourceforge.net Wed May 27 16:04:16 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 27 May 2009 11:04:16 -0500 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: <1243408529.16232.108.camel@adam.local.net> References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <81487f820905262227u245c6e4es25daab7ab58901@mail.gmail.com> <4A1CD6E7.3080805@gmail.com> <1243408529.16232.108.camel@adam.local.net> Message-ID: Adam Williamson wrote: > when urpmi lists the packages that will be installed as dependencies in > a transaction, those that are suggests rather than hard requires are > tagged as such, so you can notice if a transaction is introducing a > large number of suggested deps you may not necessarily want, and switch > to --no-suggests. ...so long as 'yum update' would tell me: updating ... installing for dependencies ... installing for suggestions ... :-) (Which I suppose it would have to, because I'm not thinking of another way to do it that wouldn't be wrong.) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Sorry, but I can't look into that right now. I'm running low on sacrificial chickens. From awilliam at redhat.com Wed May 27 16:23:33 2009 From: awilliam at redhat.com (Adam Williamson) Date: Wed, 27 May 2009 09:23:33 -0700 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <81487f820905262227u245c6e4es25daab7ab58901@mail.gmail.com> <4A1CD6E7.3080805@gmail.com> <1243408529.16232.108.camel@adam.local.net> Message-ID: <1243441413.2937.2.camel@adam.local.net> On Wed, 2009-05-27 at 11:04 -0500, Matthew Woehlke wrote: > Adam Williamson wrote: > > when urpmi lists the packages that will be installed as dependencies in > > a transaction, those that are suggests rather than hard requires are > > tagged as such, so you can notice if a transaction is introducing a > > large number of suggested deps you may not necessarily want, and switch > > to --no-suggests. > > ...so long as 'yum update' would tell me: > > updating > ... > installing for dependencies > ... > installing for suggestions > ... > > :-) > > (Which I suppose it would have to, because I'm not thinking of another > way to do it that wouldn't be wrong.) Well, yeah, I actually noted in my email that MDV's tool does exactly that (well, it doesn't show them as separate sets, it shows them in one long list with "(suggests)" to note the suggested ones. But doing it in sets would, I imagine, be trivial). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From jamatos at fc.up.pt Wed May 27 16:31:00 2009 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Wed, 27 May 2009 17:31:00 +0100 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: <1243441413.2937.2.camel@adam.local.net> References: <1243441413.2937.2.camel@adam.local.net> Message-ID: <200905271731.00909.jamatos@fc.up.pt> On Wednesday 27 May 2009 17:23:33 Adam Williamson wrote: > Well, yeah, I actually noted in my email that MDV's tool does exactly > that (well, it doesn't show them as separate sets, it shows them in one > long list with "(suggests)" to note the suggested ones. But doing it in > sets would, I imagine, be trivial). Wishful thinking. :-) It is easy to come with an example where those sets overlap, i.e. there is one package that only shows as (suggests) in more than one package. So I am not sure if it is worth the trouble to show all the separate sets. -- Jos? Ab?lio From cry_regarder at yahoo.com Wed May 27 16:39:15 2009 From: cry_regarder at yahoo.com (Cry) Date: Wed, 27 May 2009 16:39:15 +0000 (UTC) Subject: The future of firestarter References: <4A1D4E43.2050700@fedoraproject.org> Message-ID: Adam Miller gmail.com> writes: > > > If upstream is dead and you are not going to do the work, just close the > > bug as WONTFIX. Yes, I filed the RFE in the first place but I wasn't > > aware that upstream is dead. So don't let that scare you from continuing > dead then I don't want to keep old and busted cruft around the > repositories as Fedora continues to look towards the future. > > -Adam Any chance of filing a set of RFEs against system-config-firewall for the features that firestarter has that system-config-firewall is still missing? From mw_triad at users.sourceforge.net Wed May 27 16:47:27 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 27 May 2009 11:47:27 -0500 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: <200905271731.00909.jamatos@fc.up.pt> References: <1243441413.2937.2.camel@adam.local.net> <200905271731.00909.jamatos@fc.up.pt> Message-ID: Jos? Matos wrote: > On Wednesday 27 May 2009 17:23:33 Adam Williamson wrote: >> Well, yeah, I actually noted in my email that MDV's tool does exactly >> that (well, it doesn't show them as separate sets, it shows them in one >> long list with "(suggests)" to note the suggested ones. But doing it in >> sets would, I imagine, be trivial). ...and consistent with how yum currently works. > Wishful thinking. :-) Why? > It is easy to come with an example where those sets overlap, i.e. there is one > package that only shows as (suggests) in more than one package. Sure. Why does that matter? > So I am not sure if it is worth the trouble to show all the separate sets. How else are you going to display things? Specifically how are you going to display things that isn't /broken/? We have two groups right now, 'updating' and 'installing for dependencies'. Putting packages pulled in (only; directly or indirectly) by suggests: into either of those is clearly wrong. I don't see why this is hard. I do 'yum update'. It wants (with suggests: feature) to install packages for any combination of three reasons: - package is installed and is being updated - package is required by some package in transaction - package is suggested by some package in transaction (Without suggests: feature you only have first two.) Any package may belong to all three states, true. However it is placed in the group with the "strongest" reason for it being in the transaction. (The above are listed from strongest to weakest.) If it's installed already, set "required" flag and "update" flag. If it was required by something, set "required" flag iff what required it has "required" flag. Packages with "update" go in 'updating' group, with "required" but not "update" in 'installing for dependencies', everything else in 'installing for suggestions'. How hard is that, really? -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Sorry, but I can't look into that right now. I'm running low on sacrificial chickens. From tcallawa at redhat.com Wed May 27 16:49:33 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 27 May 2009 12:49:33 -0400 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: References: <1243441413.2937.2.camel@adam.local.net> <200905271731.00909.jamatos@fc.up.pt> Message-ID: <4A1D6F1D.8070300@redhat.com> On 05/27/2009 12:47 PM, Matthew Woehlke wrote: > How hard is that, really? Whenever someone says this on the -devel list, they are automatically required to write the patch. ~spot From kevin.kofler at chello.at Wed May 27 17:11:23 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 27 May 2009 19:11:23 +0200 Subject: Agenda for the 2009-05-26 Packaging Committee meeting References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <20090527072531.GA2413@amd.home.annexia.org> Message-ID: Seth Vidal wrote: > I think the number of disputing perspectives in this thread ALONE on how > suggests would be handles proves that it is not obvious on its face how > suggests should be handled. Well, people are proposing 2 behaviors: 1. treat as hard dependencies by default or 2. ignore by default. Why not have both? In fact that's what Debian is doing: Recommends is 1., Suggests is 2., and of course the default can be changed (you can choose to drag everything in or to ignore even Recommends). So why don't we do the same in RPM and Yum? Kevin Kofler From christoph.wickert at googlemail.com Wed May 27 17:14:49 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Wed, 27 May 2009 19:14:49 +0200 Subject: I must be doing something seriously wrong... In-Reply-To: <20090523135249.GA32053@hansolo.jdub.homelinux.org> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <20090521124654.GB10004@hansolo.jdub.homelinux.org> <1242922282.8758.13.camel@localhost.localdomain> <20090521170723.GA11191@hansolo.jdub.homelinux.org> <1242938158.2974.17.camel@localhost.localdomain> <20090523135249.GA32053@hansolo.jdub.homelinux.org> Message-ID: <1243444489.8668.17.camel@localhost.localdomain> Am Samstag, den 23.05.2009, 09:52 -0400 schrieb Josh Boyer: > On Thu, May 21, 2009 at 10:35:58PM +0200, Christoph Wickert wrote: > > >Also I've got a notion that FESCo recently approves more and more > >proposals without asking the community for opinions first and even in > >opposition to the community. > > I can't recall that being the case. There certainly may have been some > proposals that were opened during the week that were discussed on that Friday, > but we aren't creating secret proposals and voting on them. All of them come > directly from contributors (usually via fedora-devel discussions) and are > logged in the open fesco trac instance for the meetings. When the flags proposal was announced to fedora-devel, so so a public decision-making could take place *before* making a policy? The proposal was not announced, it's ratification nether and the policy was active for months without anybody getting informed. This is what I'd call a secret. > > > >> > 3. If someone really needs docs, he will realize this himself, > >> > because he is missing knowledge. For flags he doesn't. How is a > >> > deluge user supposed the realize the lack of a function? > >> > >> Deluge is clearly spelled out in the guideline as not needing flags for > >> functionality. Is that statement incorrect? > > > >Please note the difference between "a function" and "functionality". Of > >course the missing flags do not impact the basic function of deluge > >which is sharing files, but there is certain functionality missing. > >People can no longer see the location of their peers on a quick glance > >and have to read instead. > > > I don't find that concerning. Maybe it will help literacy. Hopefully, but the original question is still unanswered then: How is a deluge user supposed the realize the lack of single a function? > josh Christoph From kevin.kofler at chello.at Wed May 27 17:14:12 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 27 May 2009 19:14:12 +0200 Subject: How to create header.info file References: <1243343669.17152.17.camel@pali-pc.hk.tmapy.cz> <1243410175.17152.74.camel@pali-pc.hk.tmapy.cz> Message-ID: Pavel Lisy wrote: > I know but I am not member of centos list Then subscribe there. That was a really lame excuse for posting CentOS questions to a Fedora development list. Kevin Kofler From Jochen at herr-schmitt.de Wed May 27 17:20:11 2009 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 27 May 2009 19:20:11 +0200 Subject: I must be doing something seriously wrong... In-Reply-To: <1243444489.8668.17.camel@localhost.localdomain> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <20090521124654.GB10004@hansolo.jdub.homelinux.org> <1242922282.8758.13.camel@localhost.localdomain> <20090521170723.GA11191@hansolo.jdub.homelinux.org> <1242938158.2974.17.camel@localhost.localdomain> <20090523135249.GA32053@hansolo.jdub.homelinux.org> <1243444489.8668.17.camel@localhost.localdomain> Message-ID: <4A1D764B.4060202@herr-schmitt.de> Christoph Wickert schrieb: > When the flags proposal was announced to fedora-devel, so so a public > decision-making could take place *before* making a policy? > The proposal was not announced, it's ratification nether and the policy > was active for months without anybody getting informed. This is what I'd > call a secret. > > Even the title of thei policy was a bad chosen, because you may thought, the the usage of compiler flags may be the topic of this policy. > Hopefully, but the original question is still unanswered then: How is a > deluge user supposed the realize the lack of single a function? > > My opinion is to drop the flag policy entirely, so the flags should be integrated into the application as planed by the upstream. Best Regards: Jochen Schmitt From notting at redhat.com Wed May 27 17:21:40 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 27 May 2009 13:21:40 -0400 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: References: <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <20090527072531.GA2413@amd.home.annexia.org> Message-ID: <20090527172140.GA27455@nostromo.devel.redhat.com> Kevin Kofler (kevin.kofler at chello.at) said: > > I think the number of disputing perspectives in this thread ALONE on how > > suggests would be handles proves that it is not obvious on its face how > > suggests should be handled. > > Well, people are proposing 2 behaviors: 1. treat as hard dependencies by > default or 2. ignore by default. Why not have both? No, there are also the "ask the user always" proponents. Of course... they're wrong. :) Bill From awilliam at redhat.com Wed May 27 18:02:47 2009 From: awilliam at redhat.com (Adam Williamson) Date: Wed, 27 May 2009 11:02:47 -0700 Subject: Packaging Survey - May 2009 In-Reply-To: <4A1D24AC.4090802@fedoraproject.org> References: <4A1D24AC.4090802@fedoraproject.org> Message-ID: <1243447367.2937.8.camel@adam.local.net> On Wed, 2009-05-27 at 17:01 +0530, Rahul Sundaram wrote: > Hi > > I did a quick survey from Fedora on what software Fedora users are using > that is not available in the repo. Here are the results. If you find > anything interesting, feel free to pick it up. > > https://fedoraproject.org/wiki/Packaging_Survey_May_2009 as noted on the survey, I intend to package sk1 once things get a little less crazy around the f11 release :). I already maintain it for MDV, and it'd be fairly trivial to convert the spec. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From skvidal at fedoraproject.org Wed May 27 19:07:38 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 27 May 2009 15:07:38 -0400 (EDT) Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <20090527072531.GA2413@amd.home.annexia.org> Message-ID: On Wed, 27 May 2009, Kevin Kofler wrote: > Seth Vidal wrote: >> I think the number of disputing perspectives in this thread ALONE on how >> suggests would be handles proves that it is not obvious on its face how >> suggests should be handled. > > Well, people are proposing 2 behaviors: 1. treat as hard dependencies by > default or 2. ignore by default. Why not have both? In fact that's what > Debian is doing: Recommends is 1., Suggests is 2., and of course the > default can be changed (you can choose to drag everything in or to ignore > even Recommends). So why don't we do the same in RPM and Yum? I can't wait to see how we depsolve through: yum update: - foo is updated and recommends bar - bar conflicts with baz which is also in the update but I'm sure we'll muddle through - provided this is included in upstream rpm. -sv From tcallawa at redhat.com Wed May 27 19:17:40 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 27 May 2009 15:17:40 -0400 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <20090527072531.GA2413@amd.home.annexia.org> Message-ID: <4A1D91D4.4080909@redhat.com> On 05/27/2009 03:07 PM, Seth Vidal wrote: > but I'm sure we'll muddle through - provided this is included in > upstream rpm. I think the key here is that we're waiting to deal with this particular dilemma when upstream rpm has this functionality set. ~spot From skvidal at fedoraproject.org Wed May 27 19:47:47 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 27 May 2009 15:47:47 -0400 (EDT) Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: <4A1D91D4.4080909@redhat.com> References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <20090527072531.GA2413@amd.home.annexia.org> <4A1D91D4.4080909@redhat.com> Message-ID: On Wed, 27 May 2009, Tom \"spot\" Callaway wrote: > On 05/27/2009 03:07 PM, Seth Vidal wrote: >> but I'm sure we'll muddle through - provided this is included in >> upstream rpm. > > I think the key here is that we're waiting to deal with this particular > dilemma when upstream rpm has this functionality set. > and the last time I asked - the current patches for this feature for rpm were from suse's rpm and they were not liked, at all, by other rpm.org devs. -sv From christoph.wickert at googlemail.com Wed May 27 19:59:01 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Wed, 27 May 2009 21:59:01 +0200 Subject: I must be doing something seriously wrong... In-Reply-To: <4A1D764B.4060202@herr-schmitt.de> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <20090521124654.GB10004@hansolo.jdub.homelinux.org> <1242922282.8758.13.camel@localhost.localdomain> <20090521170723.GA11191@hansolo.jdub.homelinux.org> <1242938158.2974.17.camel@localhost.localdomain> <20090523135249.GA32053@hansolo.jdub.homelinux.org> <1243444489.8668.17.camel@localhost.localdomain> <4A1D764B.4060202@herr-schmitt.de> Message-ID: <1243454341.8668.19.camel@localhost.localdomain> Am Mittwoch, den 27.05.2009, 19:20 +0200 schrieb Jochen Schmitt: > Christoph Wickert schrieb: > > When the flags proposal was announced to fedora-devel, so so a public > > decision-making could take place *before* making a policy? > > The proposal was not announced, it's ratification nether and the policy > > was active for months without anybody getting informed. This is what I'd > > call a secret. > > > > > Even the title of thei policy was a bad chosen, because you may thought, > the the > usage of compiler flags may be the topic of this policy. > > Hopefully, but the original question is still unanswered then: How is a > > deluge user supposed the realize the lack of single a function? > > > > > My opinion is to drop the flag policy entirely, so the flags should be > integrated > into the application as planed by the upstream. Let's not start this discussion again. ;) I'm glad FESCo did the right thing by withdrawing the policy (at least for now). > Best Regards: > > Jochen Schmitt Regards, Christoph From cmadams at hiwaay.net Wed May 27 19:59:54 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 27 May 2009 14:59:54 -0500 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: References: <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <81487f820905262227u245c6e4es25daab7ab58901@mail.gmail.com> <4A1CD6E7.3080805@gmail.com> <1243408529.16232.108.camel@adam.local.net> Message-ID: <20090527195954.GC530933@hiwaay.net> Once upon a time, Matthew Woehlke said: > ...so long as 'yum update' would tell me: > > updating > ... > installing for dependencies > ... > installing for suggestions > ... > > :-) > > (Which I suppose it would have to, because I'm not thinking of another > way to do it that wouldn't be wrong.) Don't forget: installing for dependencies for suggestions ... installing for suggestions for dependencies for suggestions ... :-) (yes it is meant as a joke, but it is a serious point that dependencies for suggestions should be kept separate from "normal" dependencies) -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From awilliam at redhat.com Wed May 27 20:21:54 2009 From: awilliam at redhat.com (Adam Williamson) Date: Wed, 27 May 2009 13:21:54 -0700 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <20090527072531.GA2413@amd.home.annexia.org> Message-ID: <1243455714.2937.141.camel@adam.local.net> On Wed, 2009-05-27 at 19:11 +0200, Kevin Kofler wrote: > Seth Vidal wrote: > > I think the number of disputing perspectives in this thread ALONE on how > > suggests would be handles proves that it is not obvious on its face how > > suggests should be handled. > > Well, people are proposing 2 behaviors: 1. treat as hard dependencies by > default or 2. ignore by default. Why not have both? In fact that's what > Debian is doing: Recommends is 1., Suggests is 2., and of course the > default can be changed (you can choose to drag everything in or to ignore > even Recommends). So why don't we do the same in RPM and Yum? that sounds reasonable to me. honestly, I'd see any one of the three options as an improvement on the current situation, we shouldn't let uncertainty over which to choose hold us back from making any progress at all. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From awilliam at redhat.com Wed May 27 20:24:47 2009 From: awilliam at redhat.com (Adam Williamson) Date: Wed, 27 May 2009 13:24:47 -0700 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <20090527072531.GA2413@amd.home.annexia.org> Message-ID: <1243455887.2937.143.camel@adam.local.net> On Wed, 2009-05-27 at 15:07 -0400, Seth Vidal wrote: > I can't wait to see how we depsolve through: > > yum update: > > - foo is updated and recommends bar > - bar conflicts with baz which is also in the update > > > but I'm sure we'll muddle through - provided this is included in upstream > rpm. seems obvious to me that, in that case, bar should simply not be installed (possibly yum could print a note of what happened). btw, afaik, in both MDV's and SUSE's implementations of this, rpm-the-command ignores Suggests: dependencies entirely. only the distribution's own tools interpret them. as long as the hard Requires: dependencies are met, rpm is happy. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From Jochen at herr-schmitt.de Wed May 27 20:25:04 2009 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 27 May 2009 22:25:04 +0200 Subject: I must be doing something seriously wrong... In-Reply-To: <1243454341.8668.19.camel@localhost.localdomain> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <20090521124654.GB10004@hansolo.jdub.homelinux.org> <1242922282.8758.13.camel@localhost.localdomain> <20090521170723.GA11191@hansolo.jdub.homelinux.org> <1242938158.2974.17.camel@localhost.localdomain> <20090523135249.GA32053@hansolo.jdub.homelinux.org> <1243444489.8668.17.camel@localhost.localdomain> <4A1D764B.4060202@herr-schmitt.de> <1243454341.8668.19.camel@localhost.localdomain> Message-ID: <4A1DA1A0.5020306@herr-schmitt.de> Christoph Wickert schrieb: > Let's not start this discussion again. ;) I'm glad FESCo did the right > thing by withdrawing the policy (at least for now). > You know, that the flag policy was revert on the last FESCo meeting to take futher examination about it. Best Regards: Jochen Schmitt From gmaxwell at gmail.com Wed May 27 20:17:48 2009 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Wed, 27 May 2009 16:17:48 -0400 Subject: Why not to create Fedora-us and Fedora-non-us branches? In-Reply-To: <4A1C4058.8090009@gmail.com> References: <20090526170612.GJ9951@nostromo.devel.redhat.com> <20090526172946.GA12547@nostromo.devel.redhat.com> <4A1C4058.8090009@gmail.com> Message-ID: On Tue, May 26, 2009 at 3:17 PM, Frank Murphy wrote: > Bill Nottingham wrote: >> >> Peter Lemenkov (lemenkov at gmail.com) said: ?... what exactly are you trying >> to accomplish? >> >> Make it legal to ship MP3 code? Sorry, those are patented in Europe as >> well. >> >> > > Patents are *currently* illegal in Europe, (though they may be granted). > The patents offices being self-funding and all that. > > http://en.wikipedia.org/wiki/Software_patents_under_the_European_Patent_Convention > "Article 52" Codec patents are generally not 'software patents' in the common patent-speak meaning of the words. A typical (well written) codec patent will make little or no mention of computer software. Instead they speak of specific useful transformations of information in mechanical terms as well as machine embodiments. This puts them largely outside of the domain of what is normally discussed in the content of "software patents" (which, have recently been written abstractly without any real reference to any machine or mechanical process). The bulk of codec patent holders are European companies (I.e. Fraunhofer, Nokia, etc). The collection of royalties for codecs is a multi-billion dollar a year industry. There are many well funded companies spending considerable amounts of money licensing codecs, even on products which they only intend to market in Europe. On that basis, I think it's safe to conclude that there is more to the situation than you are suggesting. From maxamillion at gmail.com Wed May 27 20:54:24 2009 From: maxamillion at gmail.com (Adam Miller) Date: Wed, 27 May 2009 15:54:24 -0500 Subject: The future of firestarter In-Reply-To: References: <4A1D4E43.2050700@fedoraproject.org> Message-ID: On Wed, May 27, 2009 at 11:39 AM, Cry wrote: > > Any chance of filing a set of RFEs against system-config-firewall for the > features that firestarter has that system-config-firewall is still missing? > I like that idea, I've retired firestarter and will begin to file RFEs once I outline some features as well as pull the git repo and help with the development. -Adam -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From kevin.kofler at chello.at Wed May 27 22:17:29 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 28 May 2009 00:17:29 +0200 Subject: Why not to create Fedora-us and Fedora-non-us branches? References: <20090526170612.GJ9951@nostromo.devel.redhat.com> <20090526172946.GA12547@nostromo.devel.redhat.com> <4A1C4058.8090009@gmail.com> Message-ID: Gregory Maxwell wrote: > Codec patents are generally not 'software patents' in the common > patent-speak meaning of the words. But they most likely cannot be enforced against pure software. However, in some European countries (e.g. Germany), you can get in trouble for shipping things like hardware MP3 players without a license (even if the MP3 codec is implemented in software), some devices got confiscated at CeBit. Kevin Kofler From jkeating at redhat.com Wed May 27 22:35:16 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 27 May 2009 15:35:16 -0700 Subject: Why not to create Fedora-us and Fedora-non-us branches? In-Reply-To: References: <20090526170612.GJ9951@nostromo.devel.redhat.com> <20090526172946.GA12547@nostromo.devel.redhat.com> <4A1C4058.8090009@gmail.com> Message-ID: <1243463716.3144.82.camel@localhost.localdomain> On Thu, 2009-05-28 at 00:17 +0200, Kevin Kofler wrote: > Gregory Maxwell wrote: > > Codec patents are generally not 'software patents' in the common > > patent-speak meaning of the words. > > But they most likely cannot be enforced against pure software. However, in > some European countries (e.g. Germany), you can get in trouble for shipping > things like hardware MP3 players without a license (even if the MP3 codec > is implemented in software), some devices got confiscated at CeBit. > > Kevin Kofler > Which leads to some fuzzyness, like what about a computer vendor selling PCs with Fedora preloaded? Does that constitute a "hardware device"? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From ricky at fedoraproject.org Wed May 27 23:07:45 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Wed, 27 May 2009 19:07:45 -0400 Subject: smlnj package Message-ID: <20090527230745.GA31564@alpha.rzhou.org> Hey, would anybody be interested in helping to maintain a package for smlnj (http://www.smlnj.org/)? I recently made a package for it (http://ricky.fedorapeople.org/pkgs/smlnj/), but I'm not quite brave enough to take on maintaining this all by myself (especially since I haven't even started learning SML yet). Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From bjorn at xn--rombobjrn-67a.se Wed May 27 23:04:36 2009 From: bjorn at xn--rombobjrn-67a.se (=?utf-8?q?Bj=C3=B6rn_Persson?=) Date: Thu, 28 May 2009 01:04:36 +0200 Subject: Why not to create Fedora-us and Fedora-non-us branches? In-Reply-To: References: <4A1C4058.8090009@gmail.com> Message-ID: <200905280104.58585.bjorn@xn--rombobjrn-67a.se> Gregory Maxwell wrote: > On Tue, May 26, 2009 at 3:17 PM, Frank Murphy wrote: > > Patents are *currently* illegal in Europe, (though they may be granted). > > The patents offices being self-funding and all that. > > Codec patents are generally not 'software patents' in the common > patent-speak meaning of the words. Not if you ask the patent lawyers, no. > The bulk of codec patent holders are European companies (I.e. > Fraunhofer, Nokia, etc). The collection of royalties for codecs is a > multi-billion dollar a year industry. There are many well funded > companies spending considerable amounts of money licensing codecs, > even on products which they only intend to market in Europe. On that > basis, I think it's safe to conclude that there is more to the > situation than you are suggesting. That's certainly true. None the less, Frank is right. These patents *are* illegal, if you read what the convention and the national laws actually say, and yet they are granted by routine. Whether they would hold up in court doesn't matter much apparently. They are effective anyway. Bj?rn Persson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From mfleming at thatfleminggent.com Thu May 28 01:09:35 2009 From: mfleming at thatfleminggent.com (Michael Fleming) Date: Thu, 28 May 2009 11:09:35 +1000 Subject: Packaging Survey - May 2009 In-Reply-To: <4A1D24AC.4090802@fedoraproject.org> References: <4A1D24AC.4090802@fedoraproject.org> Message-ID: <20090528110935.30688d83@defender> On Wed, 27 May 2009 17:01:56 +0530 Rahul Sundaram wrote: > Hi > > I did a quick survey from Fedora on what software Fedora users are > using that is not available in the repo. Here are the results. If you > find anything interesting, feel free to pick it up. > > https://fedoraproject.org/wiki/Packaging_Survey_May_2009 > > Rahul > I can put my courier-authlib packages up for review - rpmlint only has fairly minor complaints which are easily fixed - which will in turn allow maildrop (which is already here) to build against it. Courier-imap has it's own peculiar way of self-upgrading (via sysconftool, another one of Sam's tools) which is extremely convenient for the end-user but is definitely not the Fedora way of doing things. The spec file is like a rougelike for RPM - once you go in you may never come back alive The configuration files under /usr/libexec can be moved around with symlinks but getting it in good enough shape to pass review would require some major surgery. However I'm on holidays from work at the moment so I have some spare time, I might give it a shot anyway. :-) Michael. -- Michael Fleming - (EMail/XMPP/Jabber) WWW: http://www.thatfleminggent.com Fedora / Red Hat Packages: http://www.thatfleminggent.com/rpm-packages Twitter: http://twitter.com/thatfleminggent From sundaram at fedoraproject.org Thu May 28 02:29:35 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 28 May 2009 07:59:35 +0530 Subject: The future of firestarter In-Reply-To: References: <4A1D4E43.2050700@fedoraproject.org> Message-ID: <4A1DF70F.4010102@fedoraproject.org> On 05/28/2009 02:24 AM, Adam Miller wrote: > On Wed, May 27, 2009 at 11:39 AM, Cry wrote: >> >> Any chance of filing a set of RFEs against system-config-firewall for the >> features that firestarter has that system-config-firewall is still missing? >> > > I like that idea, I've retired firestarter and will begin to file RFEs > once I outline some features as well as pull the git repo and help > with the development. Thanks Adam. Rahul From bouncingcats at gmail.com Thu May 28 02:58:44 2009 From: bouncingcats at gmail.com (David) Date: Thu, 28 May 2009 12:58:44 +1000 Subject: Online Docs group was: I must be doing something seriously wrong... In-Reply-To: <1243437038.3144.72.camel@localhost.localdomain> References: <1242900843.3685.26.camel@localhost.localdomain> <20090521113119.GA9316@hansolo.jdub.homelinux.org> <1242908453.6300.44.camel@localhost.localdomain> <20090521124654.GB10004@hansolo.jdub.homelinux.org> <1242911359.3356.13.camel@red.localdomain> <1242921951.3029.86.camel@localhost.localdomain> <1243426570.10598.223.camel@gibraltar.str.redhat.com> <1243437038.3144.72.camel@localhost.localdomain> Message-ID: <974cfff50905271958n5eeb5010j14a8697c529275cf@mail.gmail.com> On Thu, 2009-05-21 at 09:05 -0700, Jesse Keating wrote: > On Thu, 2009-05-21 at 15:09 +0200, Pierre-Yves wrote: > > There is an Online Docs group that has the -docs subpackage for many of > the system-config-* packages. It uses conditionals which are painful, > but would be a way for more -docs subpackages to be visible, and if the > user wishes to have local documentation, if available, for the packages > they've chosen, they can pick that group. > > The group name is a bit... wrong, but maybe a group of people that care > about documentation could help come up with a better name, and help to > ensure that all the available -docs packages get listed in this group. On Thu, May 28, 2009 at 1:10 AM, Jesse Keating wrote: > On Wed, 2009-05-27 at 14:16 +0200, Nils Philippsen wrote: >> Feel free to rename if you have a more suitable idea, though. If there >> is another means to achieve the same purpose, I'm all ears as well. > > The existence of the group is fine, and it should probably grow. ?The > problem is the name. ?"Online" at least here in the states means on the > internet, so "Online Docs" would mean documents that your read via the > Internet. ?"Offline Docs" is almost more correct but still a bit > awkward. ?Anyway, I don't really have good suggestions. Suggestions: "Local Documentation" "Local Help Documents" From adam at spicenitz.org Thu May 28 03:19:05 2009 From: adam at spicenitz.org (Adam Goode) Date: Wed, 27 May 2009 23:19:05 -0400 Subject: smlnj package In-Reply-To: <20090527230745.GA31564@alpha.rzhou.org> References: <20090527230745.GA31564@alpha.rzhou.org> Message-ID: <4A1E02A9.2080707@spicenitz.org> On 05/27/2009 07:07 PM, Ricky Zhou wrote: > Hey, would anybody be interested in helping to maintain a package for > smlnj (http://www.smlnj.org/)? I recently made a package for it > (http://ricky.fedorapeople.org/pkgs/smlnj/), but I'm not quite brave > enough to take on maintaining this all by myself (especially since I > haven't even started learning SML yet). Hi, I can help maintain smlnj. I'm the maintainer of mlton, an SML compiler. Once you get it into Fedora, I'll request co-maintainership. You'll want to bootstrap your package, so that you don't rely on binaries in the SRPM. I'm not exactly sure how to do it for smlnj, but it will be something like this: 1. Build with binaries in SRPM. 2. Get it into koji rawhide 3. Rebuild with BuildRequires: smlnj and with source only. Thanks, Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From skvidal at fedoraproject.org Thu May 28 04:23:06 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 28 May 2009 00:23:06 -0400 (EDT) Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: <1243455714.2937.141.camel@adam.local.net> References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <20090527072531.GA2413@amd.home.annexia.org> <1243455714.2937.141.camel@adam.local.net> Message-ID: On Wed, 27 May 2009, Adam Williamson wrote: > > that sounds reasonable to me. honestly, I'd see any one of the three > options as an improvement on the current situation, we shouldn't let > uncertainty over which to choose hold us back from making any progress > at all. the assumption you're making, of course, is that adding these items is progress. :) -sv From awilliam at redhat.com Thu May 28 05:20:57 2009 From: awilliam at redhat.com (Adam Williamson) Date: Wed, 27 May 2009 22:20:57 -0700 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <20090527072531.GA2413@amd.home.annexia.org> <1243455714.2937.141.camel@adam.local.net> Message-ID: <1243488057.2937.147.camel@adam.local.net> On Thu, 2009-05-28 at 00:23 -0400, Seth Vidal wrote: > > > > that sounds reasonable to me. honestly, I'd see any one of the three > > options as an improvement on the current situation, we shouldn't let > > uncertainty over which to choose hold us back from making any progress > > at all. > > the assumption you're making, of course, is that adding these items is > progress. Case. Not assumption. ;) It just seemed to me that if the _only_ problem were which of the three options was the best way forward, that would be a silly reason not to pick one. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From mcepl at redhat.com Thu May 28 06:09:24 2009 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 28 May 2009 06:09:24 +0000 (UTC) Subject: Agenda for the 2009-05-26 Packaging Committee meeting References: <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <20090527072531.GA2413@amd.home.annexia.org> <20090527172140.GA27455@nostromo.devel.redhat.com> Message-ID: Bill Nottingham, Wed, 27 May 2009 13:21:40 -0400: > No, there are also the "ask the user always" proponents. Of course... > they're wrong. :) Are they? Of course, I need to qualify that ?always?. For Red Hat customers with hundreds of servers managed by RHN/Satellite/something- even-more-weird it is out of the question, but I wouldn't mind if I was asked politely on my notebook whether I wouldn't like this nice package providing this functionality as well. Meaning, that this could be configurable (default switched off). Mat?j From sundaram at fedoraproject.org Thu May 28 08:12:00 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 28 May 2009 13:42:00 +0530 Subject: Broken dependencies in Fedora 12 Development - 2009-05-22 In-Reply-To: <20090522185613.20074.84609@faldor.intranet> References: <20090522185613.20074.84609@faldor.intranet> Message-ID: <4A1E4750.2090903@fedoraproject.org> On 05/23/2009 12:26 AM, Michael Schwendt wrote: > Your following packages in the repository suffer from broken dependencies: > > package: gnote-0.1.2-2.fc12.i586 from dist-f12-build-current-i386 Fixed by building a new upstream release - gnote 0.4.0 Rahul From mefoster at gmail.com Thu May 28 08:50:03 2009 From: mefoster at gmail.com (Mary Ellen Foster) Date: Thu, 28 May 2009 09:50:03 +0100 Subject: rawhide report: 20090527 changes In-Reply-To: <20090527151213.C4FF81F821C@releng2.fedora.phx.redhat.com> References: <20090527151213.C4FF81F821C@releng2.fedora.phx.redhat.com> Message-ID: 2009/5/27 Rawhide Report : > openoffice.org-3.1.0-11.3.fc11 > ------------------------------ > * Mon May 25 2009 Caol?n McNamara - 1:3.1.0-11.3 > - add in the ia64 and arm fixes for the secondary arch people > - Resolves(partially): rhbz#495901 No default font-width for wmf export > - ooo#101567 add Maithili locale data (some dodgy negative value and > ?listseperator though) > - Resolves: rhbz#499474 soffice and .recently-used.xbel > - Resolves: ooo#102194 crash export on .doc with unused style in .toc When I do this update, I see the following warning: grep: /usr/lib64/openoffice.org/extensions/ogltrans.oxt/description.xml: No such file or directory Updating : 1:openoffice.org-ogltrans-3.1.0-11.3.fc11.x86_64 29/72 I assume this is from the preinstall script ... Bugzilla here: https://bugzilla.redhat.com/show_bug.cgi?id=503003 MEF -- Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ ICCS, School of Informatics, University of Edinburgh The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From sundaram at fedoraproject.org Thu May 28 09:43:32 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 28 May 2009 15:13:32 +0530 Subject: gnaughty is a hot babe Message-ID: <4A1E5CC4.2060506@fedoraproject.org> Hi My packaging survey turned up a interesting suggestion https://www.redhat.com/archives/fedora-list/2009-May/msg01809.html We don't currently have any guidelines covering this but considering the Debian action to hot babe http://lwn.net/Articles/113644/ I wanted to asked first, is this allowed in Fedora? Rahul From caolanm at redhat.com Thu May 28 10:05:26 2009 From: caolanm at redhat.com (=?ISO-8859-1?Q?Caol=E1n?= McNamara) Date: Thu, 28 May 2009 11:05:26 +0100 Subject: rawhide report: 20090527 changes In-Reply-To: References: <20090527151213.C4FF81F821C@releng2.fedora.phx.redhat.com> Message-ID: <1243505126.19290.0.camel@Vain> On Thu, 2009-05-28 at 09:50 +0100, Mary Ellen Foster wrote: > I assume this is from the preinstall script ... > > Bugzilla here: https://bugzilla.redhat.com/show_bug.cgi?id=503003 Minor issue, not specific to this particular rpm, just no-one mentioned it before. C. From mail at robertoragusa.it Thu May 28 10:05:53 2009 From: mail at robertoragusa.it (Roberto Ragusa) Date: Thu, 28 May 2009 12:05:53 +0200 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: <20090527072531.GA2413@amd.home.annexia.org> References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <20090527072531.GA2413@amd.home.annexia.org> Message-ID: <4A1E6201.5030306@robertoragusa.it> Richard W.M. Jones wrote: > There's no real difficulty here. The depsolver ignores 'suggests' for > resolving dependencies. The UI needs to change to allow these to be > selected, or in the case of command line tools like yum, to print them > out at the end. "You may also be interested in packages A, B and C". There are a lot of interpretations about how exactly a suggestion should work. I'm wondering (just to make everything more complex), how to cope with suggestions which depend on the presence of two or more packages. For example: - webbrowser - pdfviewer - pdfviewerplugin4webbrowser : Requires webbrowser,pdfviewer I install webbrowser. Should the plugin be suggested? Reasonably, no. Then, I install pdfviewer. Should the plugin be suggested? Reasonably, yes. How do you handle this? Maybe a sort of "Enhances:" tag. - pdfviewerplugin4webbrowser : Requires webbrowser,pdfviewer, Enhances webbrowser This means, if you have the webbrowser, the plugin could be useful, but it requires something else (pdfviewer), so you (user or rpm/yum) have to decide, but, at least, you have all the necessary info. Having a "yum list suggestions" would be great for all this kind of "x4y-plugin" things, but it is certainly quite complicated to agree on the implementation (and then default policies). Just my two (euro)cents. -- Roberto Ragusa mail at robertoragusa.it From kushaldas at gmail.com Thu May 28 10:44:41 2009 From: kushaldas at gmail.com (Kushal Das) Date: Thu, 28 May 2009 16:14:41 +0530 Subject: Who wants a pony ? Message-ID: Hi all, If you want one, review https://bugzilla.redhat.com/show_bug.cgi?id=503021 Kushal -- http://fedoraproject.org http://kushaldas.in From mfleming at thatfleminggent.com Thu May 28 10:51:36 2009 From: mfleming at thatfleminggent.com (Michael Fleming) Date: Thu, 28 May 2009 20:51:36 +1000 Subject: gnaughty is a hot babe In-Reply-To: <4A1E5CC4.2060506@fedoraproject.org> References: <4A1E5CC4.2060506@fedoraproject.org> Message-ID: <20090528205136.023d31ac@defender> On Thu, 28 May 2009 15:13:32 +0530 Rahul Sundaram wrote: > > Hi > > My packaging survey turned up a interesting suggestion > > https://www.redhat.com/archives/fedora-list/2009-May/msg01809.html > > We don't currently have any guidelines covering this but considering > the Debian action to hot babe > > http://lwn.net/Articles/113644/ > > I wanted to asked first, is this allowed in Fedora? > Hm. interesting case. I've got no problem with it. Unlike hot-babe there's nothing even remotely resembling depiction here. It's essentially a download tool a la aria2/d4x/gwget with a particular focus/niche and in my opinion fairly innocuous. The author is pretty up-front about what it is and what it's for - if that's reflected in the %description then the odds on it being installed "accidentally" would be fairly low. > Rahul > Michael "It's only kinky the first time you rpm -i it" Fleming -- Michael Fleming - (EMail/XMPP/Jabber) WWW: http://www.thatfleminggent.com Fedora / Red Hat Packages: http://www.thatfleminggent.com/rpm-packages Twitter: http://twitter.com/thatfleminggent From mmaslano at redhat.com Thu May 28 11:01:05 2009 From: mmaslano at redhat.com (Marcela Maslanova) Date: Thu, 28 May 2009 13:01:05 +0200 Subject: Who wants a pony ? In-Reply-To: References: Message-ID: <4A1E6EF1.80106@redhat.com> On 05/28/2009 12:44 PM, Kushal Das wrote: > Hi all, > > If you want one, review https://bugzilla.redhat.com/show_bug.cgi?id=503021 > > Kushal It hope in different kind of pony but I'll take the review. -- Marcela Ma?l??ov? BaseOS team Brno From cassmodiah at fedoraproject.org Thu May 28 11:06:43 2009 From: cassmodiah at fedoraproject.org (Simon Wesp) Date: Thu, 28 May 2009 13:06:43 +0200 Subject: gnaughty is a hot babe In-Reply-To: <20090528205136.023d31ac@defender> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> Message-ID: <20090528130643.50677d14@schafwiese> Michael Fleming wrotes: MF> Hm. interesting case. MF> I've got no problem with it. Unlike hot-babe there's nothing even MF> remotely resembling depiction here. personally I am torn between 'go' and 'no-go' the guidelines says: "Content must not be pornographic, or contain nudity, whether animated, simulated, or photographed. There are better places on the Internet to get porn." my pro: this package is free of pornographic content. hotbabe isn't free of this content. my contra: it helps you to get this stuff. An instigator for a murder is guilty like the murderer himself! I created a review with the FE-LEGAL blocker, because I didn't see this email. -- Mit freundlichen Gr??en aus dem sch?nen Hainzell Simon Wesp The G in GNU stands for GNU http://fedoraproject.org/wiki/SimonWesp -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From frankly3d at gmail.com Thu May 28 09:53:50 2009 From: frankly3d at gmail.com (Frank Murphy (Frankly3d)) Date: Thu, 28 May 2009 10:53:50 +0100 Subject: gnaughty is a hot babe In-Reply-To: <4A1E5CC4.2060506@fedoraproject.org> References: <4A1E5CC4.2060506@fedoraproject.org> Message-ID: <4A1E5F2E.2040809@gmail.com> Rahul Sundaram wrote: > Hi > > My packaging survey turned up a interesting suggestion > > https://www.redhat.com/archives/fedora-list/2009-May/msg01809.html > > We don't currently have any guidelines covering this but considering the > Debian action to hot babe > > http://lwn.net/Articles/113644/ > > I wanted to asked first, is this allowed in Fedora? > > Rahul > Would a cc to legal be in order? As a just in case. Frank -- msn: frankly3d skype: frankly3d Mailing-List Reply to: Mailing-List Still Learning, Unicode where possible From bochecha at fedoraproject.org Thu May 28 11:21:43 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Thu, 28 May 2009 13:21:43 +0200 Subject: gnaughty is a hot babe In-Reply-To: <20090528205136.023d31ac@defender> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> Message-ID: <2d319b780905280421i510a7870x2a6b33e943f0851e@mail.gmail.com> > I've got no problem with it. Unlike hot-babe there's nothing even > remotely resembling depiction here. > > It's essentially a download tool a la aria2/d4x/gwget with a particular > focus/niche and in my opinion fairly innocuous. The author is pretty > up-front about what it is and what it's for - if that's reflected in > the %description then the odds on it being installed "accidentally" > would be fairly low. And it looks like we have a precedent... https://admin.fedoraproject.org/pkgdb/packages/name/p0rn-comfort ---------- Mathieu Bridon (bochecha) From ewan at macmahon.me.uk Thu May 28 11:31:57 2009 From: ewan at macmahon.me.uk (Ewan Mac Mahon) Date: Thu, 28 May 2009 12:31:57 +0100 Subject: gnaughty is a hot babe In-Reply-To: <4A1E5CC4.2060506@fedoraproject.org> References: <4A1E5CC4.2060506@fedoraproject.org> Message-ID: <20090528113156.GC29247@macmahon.me.uk> On Thu, May 28, 2009 at 03:13:32PM +0530, Rahul Sundaram wrote: > > Hi > > My packaging survey turned up a interesting suggestion > > https://www.redhat.com/archives/fedora-list/2009-May/msg01809.html > > We don't currently have any guidelines covering this but considering the > Debian action to hot babe > > http://lwn.net/Articles/113644/ > > I wanted to asked first, is this allowed in Fedora? > It seems pretty clear-cut based on the existing guidelines and practice. The guidelines say: "code is permitted (assuming, of course, that it has an open source compatible license, is not legally questionable, etc.), only some kinds of content are permissable" which seems to imply that /all/ code is permitted provided that it's open source and not legally questionable (and there doesn't seem to be any suggestion that this fails either of those tests). Further, one of the categories of banned content other than porn is "Religious texts", but Fedora includes SWORD, which is code (but with no content) designed to handle the bible, so it would appear that packages that are intended to handle, but do not include, banned content, are OK. Besides which, there's always the possibility that someone could use the gnaughty code as a base for a downloader for different content - free software isn't limited by its original author's intentions, and shouldn't be tainted by them either. Ewan From kristapsvecgr at gmail.com Thu May 28 11:18:56 2009 From: kristapsvecgr at gmail.com (Kristaps Viesalgs) Date: Thu, 28 May 2009 11:18:56 +0000 Subject: Make Fedora 11 use vx800 chipset correctly Message-ID: <51e1c70f0905280418w25423226wdfcce5132b837e84@mail.gmail.com> Hi! Here is my problem: I am trying to Fedora LIVE USB boot properly X on vx800 chipset/Chrome9 integrated GPU on VED8900 netbook (VIA OpenBook reference design). Default driver \"openchrome\" because of unsupported vx800 can\'t do that. Only some snv version of this driver can boot X correctly. But it is only one part of prolem: using boot option video=vesafb vga=791, mouse cursor goes invisible. Is there any brutal option how to properly boot X with vesa driver, install Fedora, then make openchrome svn installation? Is Fedora planning to make for VIA graphic chipset autoconfiguration utility? It would be very very useful. Kinds, Kristaps From cassmodiah at fedoraproject.org Thu May 28 11:57:20 2009 From: cassmodiah at fedoraproject.org (Simon Wesp) Date: Thu, 28 May 2009 13:57:20 +0200 Subject: gnaughty is a hot babe In-Reply-To: <2d319b780905280421i510a7870x2a6b33e943f0851e@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <2d319b780905280421i510a7870x2a6b33e943f0851e@mail.gmail.com> Message-ID: <20090528135720.71efa74e@schafwiese> "Mathieu Bridon (bochecha)" wrotes: MB> And it looks like we have a precedent... MB> https://admin.fedoraproject.org/pkgdb/packages/name/p0rn-comfort mh, cool! ;-) -- Mit freundlichen Gr??en aus dem sch?nen Hainzell Simon Wesp The G in GNU stands for GNU http://fedoraproject.org/wiki/SimonWesp -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From u0103a at gmail.com Thu May 28 12:35:31 2009 From: u0103a at gmail.com (jude ui) Date: Thu, 28 May 2009 08:35:31 -0400 Subject: Who wants a pony ? In-Reply-To: <4A1E6EF1.80106@redhat.com> References: <4A1E6EF1.80106@redhat.com> Message-ID: <91157db90905280535j61535404i3ed0f921cdabf572@mail.gmail.com> On 5/28/09, Marcela Maslanova wrote: > > On 05/28/2009 12:44 PM, Kushal Das wrote: > >> Hi all, >> >> If you want one, review >> https://bugzilla.redhat.com/show_bug.cgi?id=503021 >> >> Kushal >> > It hope in different kind of pony but I'll take the review. > > -- > Marcela Ma?l??ov? > BaseOS team Brno What do ponies have to do with this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at fedoraproject.org Thu May 28 12:37:19 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 28 May 2009 18:07:19 +0530 Subject: Who wants a pony ? In-Reply-To: <91157db90905280535j61535404i3ed0f921cdabf572@mail.gmail.com> References: <4A1E6EF1.80106@redhat.com> <91157db90905280535j61535404i3ed0f921cdabf572@mail.gmail.com> Message-ID: <4A1E857F.6040603@fedoraproject.org> On 05/28/2009 06:05 PM, jude ui wrote: > > > On 5/28/09, *Marcela Maslanova* > wrote: > > On 05/28/2009 12:44 PM, Kushal Das wrote: > > Hi all, > > If you want one, review > https://bugzilla.redhat.com/show_bug.cgi?id=503021 > > Kushal > > It hope in different kind of pony but I'll take the review. > > -- > Marcela Ma?l??ov? > BaseOS team Brno > > > > What do ponies have to do with this? I suppose you have to actually click on the link to find out. Rahul From sundaram at fedoraproject.org Thu May 28 12:40:10 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 28 May 2009 18:10:10 +0530 Subject: gnaughty is a hot babe In-Reply-To: <4A1E5F2E.2040809@gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <4A1E5F2E.2040809@gmail.com> Message-ID: <4A1E862A.7090006@fedoraproject.org> On 05/28/2009 03:23 PM, Frank Murphy (Frankly3d) wrote: > Would a cc to legal be in order? > As a just in case. It is blocking FE-Legal already. https://bugzilla.redhat.com/show_bug.cgi?id=503013 Rahul From stickster at gmail.com Thu May 28 13:06:49 2009 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 28 May 2009 09:06:49 -0400 Subject: Who wants a pony ? In-Reply-To: <4A1E857F.6040603@fedoraproject.org> References: <4A1E6EF1.80106@redhat.com> <91157db90905280535j61535404i3ed0f921cdabf572@mail.gmail.com> <4A1E857F.6040603@fedoraproject.org> Message-ID: <20090528130649.GI8860@localhost.localdomain> On Thu, May 28, 2009 at 06:07:19PM +0530, Rahul Sundaram wrote: > On 05/28/2009 06:05 PM, jude ui wrote: > > On 5/28/09, *Marcela Maslanova* > > wrote: > > > > On 05/28/2009 12:44 PM, Kushal Das wrote: > > > > Hi all, > > > > If you want one, review > > https://bugzilla.redhat.com/show_bug.cgi?id=503021 > > > > Kushal > > > > It hope in different kind of pony but I'll take the review. > > > > What do ponies have to do with this? > > I suppose you have to actually click on the link to find out. With Fedora, life apparently *could* be a pony farm. Who knew?!? -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From rawhide at fedoraproject.org Thu May 28 14:05:01 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Thu, 28 May 2009 14:05:01 +0000 (UTC) Subject: rawhide report: 20090528 changes Message-ID: <20090528140501.4121D1F8217@releng2.fedora.phx.redhat.com> Compose started at Thu May 28 06:15:03 UTC 2009 Updated Packages: kernel-2.6.29.4-167.fc11 ------------------------ * Wed May 27 2009 Kyle McMartin 2.6.29.4-164 - drm-intel-disable-kms-i8xx.patch: disable KMS by default on 845, 855, and 865. It can be forced on with i915.modeset=1 boot parameter. * Wed May 27 2009 Kyle McMartin 2.6.29.4-165 - Enable KMS/gem on I865. - drm-no-gem-on-i8xx.patch: Remove I865 so GEM will be enabled. - drm-intel-disable-kms-i8xx.patch: Enable KMS on I865. - Two fixes from Eric Anholt to fix i8x5: drm-i915-apply-a-big-hammer-to-865-gem-object.patch drm-i915-fix-tiling-pitch.patch * Wed May 27 2009 Kristian H??gsberg - 2.6.29.4-166 - Add drm-intel-set-domain-on-fault.patch to fix random gem object corruption when swapping (495323 and probably others). - Enable kms on 845 and 855 as well, Erics tiling patch should fix those too. * Wed May 27 2009 Kristian H??gsberg - 2.6.4.167 - Actually disable drm-intel-disable-kms-i8xx.patch. * Tue May 26 2009 Ben Skeggs 2.6.29.4-163 - drm-nouveau.patch: fix sor dpms (rh#501877) Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 1 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From ajax at redhat.com Thu May 28 14:48:29 2009 From: ajax at redhat.com (Adam Jackson) Date: Thu, 28 May 2009 10:48:29 -0400 Subject: Make Fedora 11 use vx800 chipset correctly In-Reply-To: <51e1c70f0905280418w25423226wdfcce5132b837e84@mail.gmail.com> References: <51e1c70f0905280418w25423226wdfcce5132b837e84@mail.gmail.com> Message-ID: <1243522109.2505.52.camel@atropine.boston.devel.redhat.com> On Thu, 2009-05-28 at 11:18 +0000, Kristaps Viesalgs wrote: > Hi! > > Here is my problem: I am trying to Fedora LIVE USB boot properly X on > vx800 chipset/Chrome9 integrated GPU on VED8900 netbook (VIA OpenBook > reference design). Default driver \"openchrome\" because of > unsupported vx800 can\'t do that. Only some snv version of this driver > can boot X correctly. Assuming "snv" means svn, I defer to the opinion of the openchrome maintainer on this point. We regularly ship svn snapshots of the openchrome driver, but we seem to be on one from March 21. Don't know why it hasn't been updated yet. > But it is only one part of prolem: using boot > option video=vesafb vga=791, mouse cursor goes invisible. Is there any > brutal option how to properly boot X with vesa driver, install Fedora, > then make openchrome svn installation? vesafb is garbage. Don't use it. If you install with 'xdriver=vesa', the installer will write out a minimal config file setting the X driver to vesa. > Is Fedora planning to make for > VIA graphic chipset autoconfiguration utility? It would be very very > useful. Why would we do that when we could just package a version of the driver that just works? - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From ajax at redhat.com Thu May 28 14:53:37 2009 From: ajax at redhat.com (Adam Jackson) Date: Thu, 28 May 2009 10:53:37 -0400 Subject: Make Fedora 11 use vx800 chipset correctly In-Reply-To: <1243522109.2505.52.camel@atropine.boston.devel.redhat.com> References: <51e1c70f0905280418w25423226wdfcce5132b837e84@mail.gmail.com> <1243522109.2505.52.camel@atropine.boston.devel.redhat.com> Message-ID: <1243522417.2505.54.camel@atropine.boston.devel.redhat.com> On Thu, 2009-05-28 at 10:48 -0400, Adam Jackson wrote: > On Thu, 2009-05-28 at 11:18 +0000, Kristaps Viesalgs wrote: > > Hi! > > > > Here is my problem: I am trying to Fedora LIVE USB boot properly X on > > vx800 chipset/Chrome9 integrated GPU on VED8900 netbook (VIA OpenBook > > reference design). Default driver \"openchrome\" because of > > unsupported vx800 can\'t do that. Only some snv version of this driver > > can boot X correctly. > > Assuming "snv" means svn, I defer to the opinion of the openchrome > maintainer on this point. We regularly ship svn snapshots of the > openchrome driver, but we seem to be on one from March 21. Don't know > why it hasn't been updated yet. Actually, having looked closer at the package, I see: # 1106:1122 - VX800 (PCI_CHIP_VT3353) alias pcivideo:v00001106d00001122sv*sd*bc*sc*i* openchrome Which would seem to indicate that it _does_ support this chip. Perhaps you could explain what goes wrong when trying to run X on it? The /var/log/Xorg.0.log file from trying to run it would be informative. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Thu May 28 14:54:38 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 28 May 2009 07:54:38 -0700 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: <1243455887.2937.143.camel@adam.local.net> References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <20090527072531.GA2413@amd.home.annexia.org> <1243455887.2937.143.camel@adam.local.net> Message-ID: <4A1EA5AE.8000201@gmail.com> On 05/27/2009 01:24 PM, Adam Williamson wrote: > On Wed, 2009-05-27 at 15:07 -0400, Seth Vidal wrote: > >> I can't wait to see how we depsolve through: >> >> yum update: >> >> - foo is updated and recommends bar >> - bar conflicts with baz which is also in the update >> >> >> but I'm sure we'll muddle through - provided this is included in upstream >> rpm. > > seems obvious to me that, in that case, bar should simply not be > installed (possibly yum could print a note of what happened). > That may be obvious but I think it makes a lot more work. Instead of simply having a possible dependency where the suggestion is either used or not depending on a config file option, you have a dependency that must be kept separate from the normal dependencies so that you know you can get rid of it (and it's dependencies) if a conflict arises. -Toshio From awilliam at redhat.com Thu May 28 16:06:37 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 28 May 2009 09:06:37 -0700 Subject: Make Fedora 11 use vx800 chipset correctly In-Reply-To: <1243522109.2505.52.camel@atropine.boston.devel.redhat.com> References: <51e1c70f0905280418w25423226wdfcce5132b837e84@mail.gmail.com> <1243522109.2505.52.camel@atropine.boston.devel.redhat.com> Message-ID: <1243526797.2937.151.camel@adam.local.net> On Thu, 2009-05-28 at 10:48 -0400, Adam Jackson wrote: > > Is Fedora planning to make for > > VIA graphic chipset autoconfiguration utility? It would be very very > > useful. > > Why would we do that when we could just package a version of the driver > that just works? Or to put it a different way, we already have a VIA graphic chipset autoconfiguration utility - it's the driver detection code in the X server. As an added bonus, it works for lots of other chipsets too! :) As Adam implied, the openchrome maintainer for Fedora, Xavier Bachelot, is actually also the main upstream developer of openchrome too, so he would presumably be aware of this issue - perhaps you could email him (his email address is in the package info) and see what his take is? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From awilliam at redhat.com Thu May 28 16:09:15 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 28 May 2009 09:09:15 -0700 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: <4A1EA5AE.8000201@gmail.com> References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <20090527072531.GA2413@amd.home.annexia.org> <1243455887.2937.143.camel@adam.local.net> <4A1EA5AE.8000201@gmail.com> Message-ID: <1243526955.2937.153.camel@adam.local.net> On Thu, 2009-05-28 at 07:54 -0700, Toshio Kuratomi wrote: > On 05/27/2009 01:24 PM, Adam Williamson wrote: > > On Wed, 2009-05-27 at 15:07 -0400, Seth Vidal wrote: > > > >> I can't wait to see how we depsolve through: > >> > >> yum update: > >> > >> - foo is updated and recommends bar > >> - bar conflicts with baz which is also in the update > >> > >> > >> but I'm sure we'll muddle through - provided this is included in upstream > >> rpm. > > > > seems obvious to me that, in that case, bar should simply not be > > installed (possibly yum could print a note of what happened). > > > That may be obvious but I think it makes a lot more work. Instead of > simply having a possible dependency where the suggestion is either used > or not depending on a config file option, you have a dependency that > must be kept separate from the normal dependencies so that you know you > can get rid of it (and it's dependencies) if a conflict arises. ah, I see what you mean - you're not saying the problem is deciding what yum should do, but in the actual implementation. Gotcha. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From fedora at leemhuis.info Thu May 28 17:04:46 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 28 May 2009 19:04:46 +0200 Subject: What questions would you like to ask the Fedora Board or FESCo Candidates? In-Reply-To: <4A12CB16.4050104@leemhuis.info> References: <4A12CB16.4050104@leemhuis.info> Message-ID: <4A1EC42E.2050400@leemhuis.info> Hi! This mail serves as a reminder: Go and add your questions to below mentioned wiki page over the next 36 hours, otherwise it might be to late for this election cycle. For details see quoted text below. Hint: Go and read the questions that were suggested up to now, maybe they'll help you to come up with an even better questions: https://fedoraproject.org/wiki/Elections/Questionnaire CU thl On 19.05.2009 17:07, Thorsten Leemhuis wrote: > Several seats of the Fedora Board and FESCo are up for election soon(?). > Right now we are in the nomination period, which will be followed by a > "Candidate Questionnaire." That means we give candidates a list of > questions to answer by mail before the Town Hall meetings on IRC happen. > > Candidates may choose to answer (or not) those questions as they see > fit. Voters can use the answers to get an impression of what the > candidate think or plan to do while serving for the Board or FESCo. > That should help to get a interesting discussion running during the IRC > Town Hall meetings. Furthermore, those people that can't or don't want > to participate in the IRC meetings can use the answers to make a more > informed vote. > > Hence we need to prepare a few good questions that we can send to the > candidates once the nomination period ends. And that's where I need > *your help*: If you have one or more questions you'd like to send to the > candidates simply go and add them to: > > https://fedoraproject.org/wiki/Elections/Questionnaire > > It just takes a minute or two, so best to do it right now -- otherwise > you might get distracted and forget about it. ;-) > > I'll take care of the remaining work to review, sort, and clean up the > questions(?), and send them to the candidates after the nomination > period ends. Hence, I need them by around the 27th of May. I'll later > collect the answers from the candidates and put them up for pubic > consumption to give people enough time to read them before the town hall > meetings start. > > So go to the wiki and add at least one hard question! The answer will > help Fedora contributors to chose whom to vote for! > > Thanks in advance. CU > knurd > > (?) If you haven't read about it yet see > https://fedoraproject.org/wiki/Elections for details. > > (?) If you want to get involved or review the question before I send > them please drop me a line and I'll get that arranged From jkeating at redhat.com Thu May 28 17:36:18 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 28 May 2009 10:36:18 -0700 Subject: One (more) week slip of Fedora 11 Release Message-ID: <1243532178.3037.27.camel@localhost.localdomain> A late discovered and just potentially fixed anaconda storage bug[1] has necessitated another week slip of our schedule. The change is important but invasive enough to require re-validating our storage tests. We were already late in producing the Release Candidate and there is not enough time to produce another one and validate it in time for next Tuesday's release date. Therefor we have decided to enact another week long slip of the release. This gives us time to create a second release candidate and fully validate it and hand it off to the mirrors in plenty of time to sync up for the new release date of June 9th. As much as we regret slipping, we also wish to avoid easily trigger-able bugs in our release, particularly in software that cannot be fixed with a 0-day update. At this time we would only accept tag requests for critical issues. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=500808 -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From dennisml at conversis.de Thu May 28 19:02:05 2009 From: dennisml at conversis.de (Dennis J.) Date: Thu, 28 May 2009 21:02:05 +0200 Subject: gnaughty is a hot babe In-Reply-To: <20090528130643.50677d14@schafwiese> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> Message-ID: <4A1EDFAD.4090803@conversis.de> On 05/28/2009 01:06 PM, Simon Wesp wrote: > Michael Fleming wrotes: > MF> Hm. interesting case. > > MF> I've got no problem with it. Unlike hot-babe there's nothing even > MF> remotely resembling depiction here. > > personally I am torn between 'go' and 'no-go' > > the guidelines says: > "Content must not be pornographic, or contain nudity, whether animated, > simulated, or photographed. There are better places on the Internet to > get porn." > > my pro: > this package is free of pornographic content. hotbabe isn't free of > this content. Why quote the guidline if it clearly doesn't apply in this case? > my contra: > it helps you to get this stuff. > An instigator for a murder is guilty like the murderer himself! Murder is a crime, pornography isn't so this comparison doesn't make much sense. Also Firefox helps you to "get this stuff" too so if that's a reason for banning this package then you'd have to ban a lot of other software from Fedora too. I don't see much of a controversy here. The package doesn't try to deceive anyone about it's intentions and doesn't contain any objectionable material itself. Regards, Dennis From jonstanley at gmail.com Thu May 28 21:20:36 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Thu, 28 May 2009 17:20:36 -0400 Subject: Plans for tomorrow's (20090529) FESCo meeting Message-ID: Well, I have nothing on the agenda for tomorrow's meeting at this point. Thus, the entire meeting taking place at 17:00UTC in #fedora-meeting will be an open floor, unless someone comes up with something to discuss between now and then :). From xavier at bachelot.org Thu May 28 22:55:44 2009 From: xavier at bachelot.org (Xavier Bachelot) Date: Fri, 29 May 2009 00:55:44 +0200 Subject: Make Fedora 11 use vx800 chipset correctly In-Reply-To: <1243522109.2505.52.camel@atropine.boston.devel.redhat.com> References: <51e1c70f0905280418w25423226wdfcce5132b837e84@mail.gmail.com> <1243522109.2505.52.camel@atropine.boston.devel.redhat.com> Message-ID: <4A1F1670.9040208@bachelot.org> Hi Ajax, Kristaps, Adam Jackson wrote: > On Thu, 2009-05-28 at 11:18 +0000, Kristaps Viesalgs wrote: >> Hi! >> >> Here is my problem: I am trying to Fedora LIVE USB boot properly X on >> vx800 chipset/Chrome9 integrated GPU on VED8900 netbook (VIA OpenBook >> reference design). Default driver \"openchrome\" because of >> unsupported vx800 can\'t do that. Only some snv version of this driver >> can boot X correctly. > > Assuming "snv" means svn, I defer to the opinion of the openchrome > maintainer on this point. We regularly ship svn snapshots of the > openchrome driver, but we seem to be on one from March 21. Don't know > why it hasn't been updated yet. > The current F10 and F11 packages should work just fine with a VX800. They are more or less what's in openchrome svn trunk. Fwiw, I do have a Quanta IL-1 working quite nicely. If your own machine is not working, please file a bug and attach the xorg conf and xorg log, I'll take a look asap. Make sure you're running the latest updates though. >> But it is only one part of prolem: using boot >> option video=vesafb vga=791, mouse cursor goes invisible. Is there any >> brutal option how to properly boot X with vesa driver, install Fedora, >> then make openchrome svn installation? > > vesafb is garbage. Don't use it. > > If you install with 'xdriver=vesa', the installer will write out a > minimal config file setting the X driver to vesa. > >> Is Fedora planning to make for >> VIA graphic chipset autoconfiguration utility? It would be very very >> useful. > > Why would we do that when we could just package a version of the driver > that just works? > > - ajax Regards, Xavier From xavier at bachelot.org Thu May 28 23:12:48 2009 From: xavier at bachelot.org (Xavier Bachelot) Date: Fri, 29 May 2009 01:12:48 +0200 Subject: Make Fedora 11 use vx800 chipset correctly In-Reply-To: <1243526797.2937.151.camel@adam.local.net> References: <51e1c70f0905280418w25423226wdfcce5132b837e84@mail.gmail.com> <1243522109.2505.52.camel@atropine.boston.devel.redhat.com> <1243526797.2937.151.camel@adam.local.net> Message-ID: <4A1F1A70.6060908@bachelot.org> Adam Williamson wrote: > On Thu, 2009-05-28 at 10:48 -0400, Adam Jackson wrote: > >>> Is Fedora planning to make for >>> VIA graphic chipset autoconfiguration utility? It would be very very >>> useful. >> Why would we do that when we could just package a version of the driver >> that just works? > > Or to put it a different way, we already have a VIA graphic chipset > autoconfiguration utility - it's the driver detection code in the X > server. As an added bonus, it works for lots of other chipsets too! :) > > As Adam implied, the openchrome maintainer for Fedora, Xavier Bachelot, > is actually also the main upstream developer of openchrome too, so he > would presumably be aware of this issue - perhaps you could email him > (his email address is in the package info) and see what his take is? It's true I'm involved with the openchrome project, but I'm not really a developer, and certainly not the main one, I'm unfortunately not skilled enough. I'll take this opportunity to outline that the openchrome project is severely understaffed, and if anyone is looking into getting involved with an X driver development, there is plenty to do to help us, either on the 2D driver, but also on the 3D driver (Chrome9 chips are not supported at all, it would be nice to work on a Gallium3D driver someday) and on the kernel (Chrome9 DRM needs to be reviewed and integrated). Especially, if you have interested in the OLPC project, the X0-1.5 will be based on a VIA chip soon to be supported by openchrome, so anyone willing to lend a hand is welcome. Regards, Xavier From awilliam at redhat.com Fri May 29 00:15:41 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 28 May 2009 17:15:41 -0700 Subject: Make Fedora 11 use vx800 chipset correctly In-Reply-To: <4A1F1A70.6060908@bachelot.org> References: <51e1c70f0905280418w25423226wdfcce5132b837e84@mail.gmail.com> <1243522109.2505.52.camel@atropine.boston.devel.redhat.com> <1243526797.2937.151.camel@adam.local.net> <4A1F1A70.6060908@bachelot.org> Message-ID: <1243556141.2937.179.camel@adam.local.net> On Fri, 2009-05-29 at 01:12 +0200, Xavier Bachelot wrote: > > As Adam implied, the openchrome maintainer for Fedora, Xavier Bachelot, > > is actually also the main upstream developer of openchrome too, so he > > would presumably be aware of this issue - perhaps you could email him > > (his email address is in the package info) and see what his take is? > > It's true I'm involved with the openchrome project, but I'm not really a > developer, and certainly not the main one, I'm unfortunately not skilled > enough. Sorry, from the fact you're the one who seemed to be on the other end of the line all the time, I figured you were! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From oget.fedora at gmail.com Fri May 29 05:20:15 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Fri, 29 May 2009 01:20:15 -0400 Subject: Plans for tomorrow's (20090529) FESCo meeting In-Reply-To: References: Message-ID: On Thu, May 28, 2009 at 5:20 PM, Jon Stanley wrote: > Well, I have nothing on the agenda for tomorrow's meeting at this > point. ?Thus, the entire meeting taking place at 17:00UTC in > #fedora-meeting will be an open floor, unless someone comes up with > something to discuss between now and then :). > I would like to have a pre-review on this proposal before we work on it more: http://fedoraproject.org/wiki/Features/FedoraStudio The initial idea was to classify the Audio Creation applications. But classifying just the Audio Creation applications and leaving the Audio/Video players, Video Creation applications, etc untouched was not going be good design. So we tried to come up with a unified solution, which might still need some polish. This has been discussed in the fedora-music list this month: https://www.redhat.com/archives/fedora-music-list/2009-May/msg00020.html Please express your opinions about this little project. Thanks, Orcan From sundaram at fedoraproject.org Fri May 29 05:23:24 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 29 May 2009 10:53:24 +0530 Subject: rawhide report: 20090528 changes In-Reply-To: <20090528140501.4121D1F8217@releng2.fedora.phx.redhat.com> References: <20090528140501.4121D1F8217@releng2.fedora.phx.redhat.com> Message-ID: <4A1F714C.80905@fedoraproject.org> On 05/28/2009 07:35 PM, Rawhide Report wrote: > Compose started at Thu May 28 06:15:03 UTC 2009 > > Updated Packages: > > kernel-2.6.29.4-167.fc11 > ------------------------ > * Wed May 27 2009 Kyle McMartin 2.6.29.4-164 > - drm-intel-disable-kms-i8xx.patch: disable KMS by default on 845, 855, > and 865. It can be forced on with i915.modeset=1 boot parameter. > > * Wed May 27 2009 Kyle McMartin 2.6.29.4-165 > - Enable KMS/gem on I865. > - drm-no-gem-on-i8xx.patch: Remove I865 so GEM will be enabled. > - drm-intel-disable-kms-i8xx.patch: Enable KMS on I865. > - Two fixes from Eric Anholt to fix i8x5: > drm-i915-apply-a-big-hammer-to-865-gem-object.patch > drm-i915-fix-tiling-pitch.patch > > * Wed May 27 2009 Kristian H?gsberg - 2.6.29.4-166 > - Add drm-intel-set-domain-on-fault.patch to fix random gem object > corruption when swapping (495323 and probably others). > - Enable kms on 845 and 855 as well, Erics tiling patch should fix > those too. > > * Wed May 27 2009 Kristian H?gsberg - 2.6.4.167 > - Actually disable drm-intel-disable-kms-i8xx.patch. Seems a lot of back and forth. What's going on? Can someone tell me the final state of expected behaviour is various cards? It would be useful to point users to this. Rahul From alsadi at gmail.com Fri May 29 08:05:01 2009 From: alsadi at gmail.com (Muayyad AlSadi) Date: Fri, 29 May 2009 11:05:01 +0300 Subject: gnaughty is a hot babe In-Reply-To: <4A1EDFAD.4090803@conversis.de> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> Message-ID: <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> in case you have accepted to put such packages in the repo please maintain a wiki page listing all of them so that we can add exclude for all of them in fedora .repo files sorry, but our users trust us [in ojuba.org spin] to provide packages that respect our family values and moralities From sundaram at fedoraproject.org Fri May 29 08:15:06 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 29 May 2009 13:45:06 +0530 Subject: gnaughty is a hot babe In-Reply-To: <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> Message-ID: <4A1F998A.9010807@fedoraproject.org> On 05/29/2009 01:35 PM, Muayyad AlSadi wrote: > in case you have accepted to put such packages in the repo > > please maintain a wiki page listing all of them so that we can add > exclude for all of them in > fedora .repo files > > sorry, but our users trust us [in ojuba.org spin] to provide packages > that respect our family values and moralities I suspect a list in the wiki would quickly become outdated. Might be worth adding a comps group if enough of them add up. Note this isn't really the first time. Other than some xscreensavers with fairly suggestive imageries, you also have things like these: ---- # yum search p0rn Loaded plugins: fastestmirror, presto, refresh-packagekit, remove-with-leaves =================== Matched: p0rn ================================= p0rn-comfort.noarch : Support programs for browsing image-gallery sites Rahul From opensource at till.name Fri May 29 08:33:19 2009 From: opensource at till.name (Till Maas) Date: Fri, 29 May 2009 10:33:19 +0200 Subject: Plans for tomorrow's (20090529) FESCo meeting In-Reply-To: References: Message-ID: <200905291033.20518.opensource@till.name> On Thu May 28 2009, Jon Stanley wrote: > Well, I have nothing on the agenda for tomorrow's meeting at this > point. Thus, the entire meeting taking place at 17:00UTC in > #fedora-meeting will be an open floor, unless someone comes up with > something to discuss between now and then :). There is a proposed Feature that connot be completed because kernel module packages are prohibited in Fedora: https://fedoraproject.org/wiki/Features/VirtualBox The Feature Wrangler told me, that the current feature process[0] cannot handle this situation, because feature pages hang around until they are excepted. But I guess that infiltrating FESCo to get kernel module packages back into Fedora is not was is expected to finish the feature. ;-) So if only FESCo can adjust the feature process, please update it to include the case of unfinishable features. Regards Till [0] https://fedoraproject.org/wiki/Features/Policy/Process -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From alsadi at gmail.com Fri May 29 08:39:42 2009 From: alsadi at gmail.com (Muayyad AlSadi) Date: Fri, 29 May 2009 11:39:42 +0300 Subject: gnaughty is a hot babe In-Reply-To: <4A1F998A.9010807@fedoraproject.org> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1F998A.9010807@fedoraproject.org> Message-ID: <385866f0905290139y6a740260sc374211679213d21@mail.gmail.com> comps group or force some %group in spec files or modify pkgdb to have tags or any thing, I just need to know all such packages them regarding the output of yum search, yes I expected that from the post of Mathieu Bridon (bochecha), and I was shocked it was there!! anyway, I really need a list of packages like the above p0rn-comfort, hot-babe, gnaughty is there anything else ? some how FLOSS projects lost their attitude, for example open arena start putting a note: it may not be suitable for children under 17. and their page contains a very offensive statement "If you want a game for kids you will want to play SDL Sopwith but **it is just as fun** and contains no objectionable materials!" and when I heard about world of padman as a game in which you shoot with paints instead of violent weapons I expected something moral and decent but it wasn't maybe if we wait a few years such projects will put explicit materials I guess someone should point to http://tldp.org/HOWTO/Encourage-Women-Linux-HOWTO/x168.html From bochecha at fedoraproject.org Fri May 29 08:51:27 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Fri, 29 May 2009 10:51:27 +0200 Subject: gnaughty is a hot babe In-Reply-To: <4A1F998A.9010807@fedoraproject.org> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1F998A.9010807@fedoraproject.org> Message-ID: <2d319b780905290151i517bd8b7u832e536645db6eb0@mail.gmail.com> > I suspect a list in the wiki would quickly become outdated. Might be > worth adding a comps group if enough of them add up. The problem with a comps group is that it will lead to having a group in graphical installers saying "Adult packages" (or something like that). Some might think of it as advertisement... Regards, ---------- Mathieu Bridon (bochecha) From alsadi at gmail.com Fri May 29 09:10:44 2009 From: alsadi at gmail.com (Muayyad AlSadi) Date: Fri, 29 May 2009 12:10:44 +0300 Subject: gnaughty is a hot babe In-Reply-To: <2d319b780905290151i517bd8b7u832e536645db6eb0@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1F998A.9010807@fedoraproject.org> <2d319b780905290151i517bd8b7u832e536645db6eb0@mail.gmail.com> Message-ID: <385866f0905290210h155da287k145e37d8a76f50d2@mail.gmail.com> > The problem with a comps group is that it will lead to having a group > in graphical installers although in ojuba we use ourown comps files, but this is a catastrophe because they are merged! I guess there is an option for hidden groups On Fri, May 29, 2009 at 11:51 AM, Mathieu Bridon (bochecha) wrote: >> I suspect a list in the wiki would quickly become outdated. Might be >> worth adding a comps group if enough of them add up. > > The problem with a comps group is that it will lead to having a group > in graphical installers saying "Adult packages" (or something like > that). > > Some might think of it as advertisement... > > Regards, > > > ---------- > > Mathieu Bridon (bochecha) > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From sundaram at fedoraproject.org Fri May 29 09:18:52 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 29 May 2009 14:48:52 +0530 Subject: gnaughty is a hot babe In-Reply-To: <385866f0905290210h155da287k145e37d8a76f50d2@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1F998A.9010807@fedoraproject.org> <2d319b780905290151i517bd8b7u832e536645db6eb0@mail.gmail.com> <385866f0905290210h155da287k145e37d8a76f50d2@mail.gmail.com> Message-ID: <4A1FA87C.9040009@fedoraproject.org> On 05/29/2009 02:40 PM, Muayyad AlSadi wrote: >> The problem with a comps group is that it will lead to having a group >> in graphical installers > > although in ojuba we use ourown comps files, but this is a catastrophe > because they are merged! > I guess there is an option for hidden groups If you are talking about comps groups with the same name getting merged in the yum grouplist, you can control that via overwrite_groups=0. Since you run a derivative, you don't have to use the Fedora comps file at all but create your own. Rahul From berrange at redhat.com Fri May 29 09:20:40 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 29 May 2009 10:20:40 +0100 Subject: gnaughty is a hot babe In-Reply-To: <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> Message-ID: <20090529092040.GA29375@redhat.com> On Fri, May 29, 2009 at 11:05:01AM +0300, Muayyad AlSadi wrote: > in case you have accepted to put such packages in the repo > > please maintain a wiki page listing all of them so that we can add > exclude for all of them in > fedora .repo files > > sorry, but our users trust us [in ojuba.org spin] to provide packages > that respect our family values and moralities IMHO it is not Fedora's job to define family values & moralities. Such morals/values will vary all around the world, such that no single list Fedora makes would be satisfactory. If a derived spin wants to define a set of morals & values then the burden should be on them to maintain the list of packages that don't comply, not Fedora. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From alsadi at gmail.com Fri May 29 09:30:45 2009 From: alsadi at gmail.com (Muayyad AlSadi) Date: Fri, 29 May 2009 12:30:45 +0300 Subject: gnaughty is a hot babe In-Reply-To: <20090529092040.GA29375@redhat.com> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <20090529092040.GA29375@redhat.com> Message-ID: <385866f0905290230n1170470cq31dc26c6dda35b6d@mail.gmail.com> > IMHO it is not Fedora's job to define family values & moralities. Such morals/values will vary all around the world I don't want fedora to define such things, we have our own values predefined. it should not make my job finding suck packages difficult we have more than 10,000 packages in the repos so don't expect me to test them all the package maintainers already classify their packages using Group: in the spec file and they already classify them in yum comps files I demand a systematic way, a policy that tells a package maintainer how to categories their packages in a unified proper way to warn people like us from their packages. From sundaram at fedoraproject.org Fri May 29 09:38:21 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 29 May 2009 15:08:21 +0530 Subject: gnaughty is a hot babe In-Reply-To: <385866f0905290230n1170470cq31dc26c6dda35b6d@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <20090529092040.GA29375@redhat.com> <385866f0905290230n1170470cq31dc26c6dda35b6d@mail.gmail.com> Message-ID: <4A1FAD0D.4030608@fedoraproject.org> On 05/29/2009 03:00 PM, Muayyad AlSadi wrote: >> IMHO it is not Fedora's job to define family values & moralities. Such morals/values will vary all around the world > I don't want fedora to define such things, we have our own values predefined. > > it should not make my job finding suck packages difficult > we have more than 10,000 packages in the repos so don't expect me to > test them all > > the package maintainers already classify their packages using Group: > in the spec file > > and they already classify them in yum comps files > > I demand a systematic way, a policy that tells a package maintainer > how to categories their packages in a unified proper way to warn > people like us from their packages. The problem, how do we determine what is offensive to any particular group? Some people consider 3D shooter games offensive. This is slippery slope. Unless there is a legal issue, I believe Fedora is going to end up with that package. For a derivative, you have to pick and choose what you want. Rahul From frankly3d at gmail.com Fri May 29 09:50:27 2009 From: frankly3d at gmail.com (Frank Murphy (Frankly3d)) Date: Fri, 29 May 2009 10:50:27 +0100 Subject: gnaughty is a hot babe In-Reply-To: <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> Message-ID: <4A1FAFE3.80302@gmail.com> Muayyad AlSadi wrote: > in case you have accepted to put such packages in the repo > > please maintain a wiki page listing all of them so that we can add > exclude for all of them in > fedora .repo files > > sorry, but our users trust us [in ojuba.org spin] to provide packages > that respect our family values and moralities > As long as they are not installed by default, I don't see the problem. If they do get installed, it would probably not be an accident. Whatever the moral\cultural situation Frank -- msn: frankly3d skype: frankly3d Mailing-List Reply to: Mailing-List Still Learning, Unicode where possible From dr.diesel at gmail.com Fri May 29 09:59:37 2009 From: dr.diesel at gmail.com (Dr. Diesel) Date: Fri, 29 May 2009 04:59:37 -0500 Subject: gnaughty is a hot babe In-Reply-To: <4A1FAFE3.80302@gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1FAFE3.80302@gmail.com> Message-ID: <2a28d2ab0905290259g8103cb7p9856559a611ed465@mail.gmail.com> On Fri, May 29, 2009 at 4:50 AM, Frank Murphy (Frankly3d) < frankly3d at gmail.com> wrote: > Muayyad AlSadi wrote: > >> in case you have accepted to put such packages in the repo >> >> please maintain a wiki page listing all of them so that we can add >> exclude for all of them in >> fedora .repo files >> >> sorry, but our users trust us [in ojuba.org spin] to provide packages >> that respect our family values and moralities >> >> > > As long as they are not installed by default, > I don't see the problem. > > If they do get installed, it would probably not be an accident. > Whatever the moral\cultural situation > > Frank Yes! Use Firefox for example where you can end up on a "questionable site" by accident! Any web browser/ftp/p2p/etc can be used to download images/movies, gnaughty is no different. -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jreznik at redhat.com Fri May 29 10:00:35 2009 From: jreznik at redhat.com (Jaroslav Reznik) Date: Fri, 29 May 2009 12:00:35 +0200 Subject: gnaughty is a hot babe In-Reply-To: <4A1FAD0D.4030608@fedoraproject.org> References: <4A1E5CC4.2060506@fedoraproject.org> <385866f0905290230n1170470cq31dc26c6dda35b6d@mail.gmail.com> <4A1FAD0D.4030608@fedoraproject.org> Message-ID: <200905291200.35953.jreznik@redhat.com> On Viernes 29 Mayo 2009 11:38:21 Rahul Sundaram escribi?: > On 05/29/2009 03:00 PM, Muayyad AlSadi wrote: > >> IMHO it is not Fedora's job to define family values & moralities. Such > >> morals/values will vary all around the world > > > > I don't want fedora to define such things, we have our own values > > predefined. > > > > it should not make my job finding suck packages difficult > > we have more than 10,000 packages in the repos so don't expect me to > > test them all > > > > the package maintainers already classify their packages using Group: > > in the spec file > > > > and they already classify them in yum comps files > > > > I demand a systematic way, a policy that tells a package maintainer > > how to categories their packages in a unified proper way to warn > > people like us from their packages. > > The problem, how do we determine what is offensive to any particular > group? Some people consider 3D shooter games offensive. This is slippery > slope. Unless there is a legal issue, I believe Fedora is going to end > up with that package. For a derivative, you have to pick and choose what > you want. +1 I don't like people who wants regulate everything because they think they are gods and they know what's good/bad for people. You, as administrator with root priviliges, you're the one who should say - this package is OK for my family, this is not... Same for TV regulations - you have remote, you're the best regulator!!! When I was young, my parents locked living room if they thought I have enough TV or there's something wrong they don't want to let me see. One month ago I've read interview with Czech broadcast regulation office boss and it was wonderful - he said - Internet never was intended as free/open medium, we have to regulate it (we is Europe Union) as companies broadcasting over Internet have advantage over that regulated. Isn't better to not regulate them instead of regulating Internet??? So please, prepare these packages, put them to the repository (not default in comps) - if there's good summary/description, it's admin/parent responsibility! Jaroslav > Rahul -- Jaroslav ?ezn?k Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ From frankly3d at gmail.com Fri May 29 10:15:40 2009 From: frankly3d at gmail.com (Frank Murphy (Frankly3d)) Date: Fri, 29 May 2009 11:15:40 +0100 Subject: gnaughty is a hot babe In-Reply-To: <2a28d2ab0905290259g8103cb7p9856559a611ed465@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1FAFE3.80302@gmail.com> <2a28d2ab0905290259g8103cb7p9856559a611ed465@mail.gmail.com> Message-ID: <4A1FB5CC.1060204@gmail.com> Dr. Diesel wrote: > > > > If they do get installed, it would probably not be an accident. > Whatever the moral\cultural situation > > Frank > > > Yes! Use Firefox for example where you can end up on a "questionable > site" by accident! That is true, but would not something like DansGuardian, be more suitable for people\cultures\countries that do have legitimate concerns. Block it at ISP level. > > Any web browser/ftp/p2p/etc can be used to download images/movies, > gnaughty is no different. > Agreed, in those cases it is usually no accident ;) But I think morality it is delving away from fedora, unless it is global socially objectionable, maybe Child-Porn. Frank -- msn: frankly3d skype: frankly3d Mailing-List Reply to: Mailing-List Still Learning, Unicode where possible From berrange at redhat.com Fri May 29 10:17:39 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 29 May 2009 11:17:39 +0100 Subject: gnaughty is a hot babe In-Reply-To: <385866f0905290230n1170470cq31dc26c6dda35b6d@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <20090529092040.GA29375@redhat.com> <385866f0905290230n1170470cq31dc26c6dda35b6d@mail.gmail.com> Message-ID: <20090529101739.GE29375@redhat.com> On Fri, May 29, 2009 at 12:30:45PM +0300, Muayyad AlSadi wrote: > > IMHO it is not Fedora's job to define family values & moralities. Such morals/values will vary all around the world > I don't want fedora to define such things, we have our own values predefined. > > it should not make my job finding suck packages difficult > we have more than 10,000 packages in the repos so don't expect me to > test them all Surely that is the very reason for existance of your derived distro project. If a derived distro wants todo a spin of Fedora with a package set that meets some particular criteria, it is the job of that derived distro to analyse the packages. If we have to maintain a list of packages for you, then what is to stop every other derived distro asking us to maintain lists of packages for their criteria too. It is your choice to build a distro with certain restrictions, ergo, it is your job to analyse the packages to comply with your restrictions. If you don't want to analyse all 10,000, then take a whitelist approach, instead of a blacklist, and build up your package set from a small trusted base. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From mschwendt at gmail.com Fri May 29 10:42:29 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 29 May 2009 12:42:29 +0200 Subject: gnaughty is a hot babe In-Reply-To: <4A1F998A.9010807@fedoraproject.org> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1F998A.9010807@fedoraproject.org> Message-ID: <20090529124229.0e577d0c@faldor.intranet> On Fri, 29 May 2009 13:45:06 +0530, Rahul wrote: > On 05/29/2009 01:35 PM, Muayyad AlSadi wrote: > > in case you have accepted to put such packages in the repo > > > > please maintain a wiki page listing all of them so that we can add > > exclude for all of them in > > fedora .repo files > > > > sorry, but our users trust us [in ojuba.org spin] to provide packages > > that respect our family values and moralities > > I suspect a list in the wiki would quickly become outdated. Might be > worth adding a comps group if enough of them add up. Note this isn't > really the first time. Other than some xscreensavers with fairly > suggestive imageries, you also have things like these: > > ---- > > # yum search p0rn > > Loaded plugins: fastestmirror, presto, refresh-packagekit, > remove-with-leaves > =================== Matched: p0rn ================================= > p0rn-comfort.noarch : Support programs for browsing image-gallery sites What are you trying to point out? It doesn't become clear to me. The name of the package you refer to might be a pun or a tongue-in-cheek reference, but other than that it's a set of tools (a proxy and tools) that can be used together with arbitrary image gallery web-sites [1]. Is the package name considered a problem already? [1] It suffered from Perl run-time failures here, however, when trying it on F10, so it's likely that currently it doesn't work as intended. From chitlesh.goorah at gmail.com Fri May 29 11:01:36 2009 From: chitlesh.goorah at gmail.com (Chitlesh GOORAH) Date: Fri, 29 May 2009 13:01:36 +0200 Subject: gnaughty is a hot babe In-Reply-To: <4A1E5CC4.2060506@fedoraproject.org> References: <4A1E5CC4.2060506@fedoraproject.org> Message-ID: <50baabb30905290401y3f2bef33se5b00040ddce608b@mail.gmail.com> On Thu, May 28, 2009 at 11:43 AM, Rahul Sundaram wrote: > > Hi > > My packaging survey turned up a interesting suggestion > > https://www.redhat.com/archives/fedora-list/2009-May/msg01809.html > > We don't currently have any guidelines covering this but considering the > Debian action to hot babe > > http://lwn.net/Articles/113644/ > > I wanted to asked first, ?is this allowed in Fedora? Well it depends on the content. If the content can't be read with software under the fedora umbrella, then it can't enter. Those videos are they under the ogg format or other opensource equivalent? Chitlesh From nicu_fedora at nicubunu.ro Fri May 29 11:05:01 2009 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Fri, 29 May 2009 14:05:01 +0300 Subject: gnaughty is a hot babe In-Reply-To: <50baabb30905290401y3f2bef33se5b00040ddce608b@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <50baabb30905290401y3f2bef33se5b00040ddce608b@mail.gmail.com> Message-ID: <4A1FC15D.9030003@nicubunu.ro> On 05/29/2009 02:01 PM, Chitlesh GOORAH wrote: > On Thu, May 28, 2009 at 11:43 AM, Rahul Sundaram wrote: >> My packaging survey turned up a interesting suggestion >> >> https://www.redhat.com/archives/fedora-list/2009-May/msg01809.html >> >> We don't currently have any guidelines covering this but considering the >> Debian action to hot babe >> >> http://lwn.net/Articles/113644/ >> >> I wanted to asked first, is this allowed in Fedora? > > Well it depends on the content. If the content can't be read with > software under the fedora umbrella, then it can't enter. > > Those videos are they under the ogg format or other opensource equivalent? There is no video, only a few harmless static drawings in PNG format. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/ photography: http://photoblog.nicubunu.ro/ my Fedora stuff: http://fedora.nicubunu.ro/ From chitlesh.goorah at gmail.com Fri May 29 11:07:53 2009 From: chitlesh.goorah at gmail.com (Chitlesh GOORAH) Date: Fri, 29 May 2009 13:07:53 +0200 Subject: gnaughty is a hot babe In-Reply-To: <4A1FC15D.9030003@nicubunu.ro> References: <4A1E5CC4.2060506@fedoraproject.org> <50baabb30905290401y3f2bef33se5b00040ddce608b@mail.gmail.com> <4A1FC15D.9030003@nicubunu.ro> Message-ID: <50baabb30905290407h352be372tb3a77ae1da0359e1@mail.gmail.com> On Fri, May 29, 2009 at 1:05 PM, Nicu Buculei wrote: > There is no video, only a few harmless static drawings in PNG format. > from : http://sourceforge.net/projects/gnaughty """Gnaughty is an utility to automatically download adult sex content, i.e. porn movies and pictures,....""" It seems movies can be downloaded. Chitlesh From kushaldas at gmail.com Fri May 29 11:12:41 2009 From: kushaldas at gmail.com (Kushal Das) Date: Fri, 29 May 2009 16:42:41 +0530 Subject: gnaughty is a hot babe In-Reply-To: <50baabb30905290407h352be372tb3a77ae1da0359e1@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <50baabb30905290401y3f2bef33se5b00040ddce608b@mail.gmail.com> <4A1FC15D.9030003@nicubunu.ro> <50baabb30905290407h352be372tb3a77ae1da0359e1@mail.gmail.com> Message-ID: On Fri, May 29, 2009 at 4:37 PM, Chitlesh GOORAH wrote: > > from : http://sourceforge.net/projects/gnaughty > > """Gnaughty is an utility to automatically download adult sex content, > i.e. porn movies and pictures,....""" > > It seems movies can be downloaded. > Yes that is true , but it does not provide any support to view that content, we have many other packages in Fedora which allows to download content and they download whatever format the site is providing, how the users watch it, it depends on their choice. Kushal -- http://fedoraproject.org http://kushaldas.in From valent.turkovic at gmail.com Fri May 29 11:13:24 2009 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Fri, 29 May 2009 13:13:24 +0200 Subject: welcome to fedora Message-ID: <64b14b300905290413m222c25b1v4ab68cff9481d75b@mail.gmail.com> http://images.howtoforge.com/images/the_perfect_desktop_linux_mint_7_gloria/15.jpg I saw this and thought that it would also be a nice idea to have in fedora, like a welcome screen "Wellcome to Fedora" or something similar... What are your thoughts on this? -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From jussilehtola at fedoraproject.org Fri May 29 11:23:23 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Fri, 29 May 2009 14:23:23 +0300 Subject: Plans for tomorrow's (20090529) FESCo meeting In-Reply-To: <200905291033.20518.opensource@till.name> References: <200905291033.20518.opensource@till.name> Message-ID: <1243596203.2559.10.camel@localhost.localdomain> On Fri, 2009-05-29 at 10:33 +0200, Till Maas wrote: > There is a proposed Feature that connot be completed because kernel module > packages are prohibited in Fedora: > https://fedoraproject.org/wiki/Features/VirtualBox Maybe the necessary bits can be included in the Fedora kernel package itself? -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From chitlesh.goorah at gmail.com Fri May 29 11:24:14 2009 From: chitlesh.goorah at gmail.com (Chitlesh GOORAH) Date: Fri, 29 May 2009 13:24:14 +0200 Subject: gnaughty is a hot babe In-Reply-To: References: <4A1E5CC4.2060506@fedoraproject.org> <50baabb30905290401y3f2bef33se5b00040ddce608b@mail.gmail.com> <4A1FC15D.9030003@nicubunu.ro> <50baabb30905290407h352be372tb3a77ae1da0359e1@mail.gmail.com> Message-ID: <50baabb30905290424m1a51813ckab95c777de9717d6@mail.gmail.com> On Fri, May 29, 2009 at 1:12 PM, Kushal Das wrote: > Yes that is true , but it does not provide any support to view that > content, we have many other packages in Fedora which allows to > download content and they download whatever format the site is > providing, how the users watch it, it depends on their choice. No, it doesn't (not till it is approved) not depend on the user's choice. My package OVM was blocked by FESCo because there was no opensource simulator. So if the downloaded videos aren't under an opensource compatible format, FESCo must rule out its package review. Chitlesh From sundaram at fedoraproject.org Fri May 29 11:24:32 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 29 May 2009 16:54:32 +0530 Subject: gnaughty is a hot babe In-Reply-To: <20090529124229.0e577d0c@faldor.intranet> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1F998A.9010807@fedoraproject.org> <20090529124229.0e577d0c@faldor.intranet> Message-ID: <4A1FC5F0.6070305@fedoraproject.org> On 05/29/2009 04:12 PM, Michael Schwendt wrote: > What are you trying to point out? It doesn't become clear to me. The name > of the package you refer to might be a pun or a tongue-in-cheek reference, > but other than that it's a set of tools (a proxy and tools) that can be > used together with arbitrary image gallery web-sites [1]. Is the package > name considered a problem already I don't personally consider it as a problem but I don't know whether others would. The point is that there is no rigid line that applies to everyone if we want to argue exclusion of a package based on morals. The legal line - we trust Red Hat Legal on that. So there is less debate based on that. Rahul From thomasj at fedoraproject.org Fri May 29 11:28:07 2009 From: thomasj at fedoraproject.org (Thomas Janssen) Date: Fri, 29 May 2009 13:28:07 +0200 Subject: welcome to fedora In-Reply-To: <64b14b300905290413m222c25b1v4ab68cff9481d75b@mail.gmail.com> References: <64b14b300905290413m222c25b1v4ab68cff9481d75b@mail.gmail.com> Message-ID: 2009/5/29 Valent Turkovic : > http://images.howtoforge.com/images/the_perfect_desktop_linux_mint_7_gloria/15.jpg > > I saw this and thought that it would also be a nice idea to have in > fedora, like a welcome screen "Wellcome to Fedora" or something > similar... > What are your thoughts on this? That Mint is more ugly than i thought ;) j/k Not a bad idea. -- LG Thomas Dubium sapientiae initium From jwboyer at gmail.com Fri May 29 11:28:15 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 29 May 2009 07:28:15 -0400 Subject: gnaughty is a hot babe In-Reply-To: <385866f0905290230n1170470cq31dc26c6dda35b6d@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <20090529092040.GA29375@redhat.com> <385866f0905290230n1170470cq31dc26c6dda35b6d@mail.gmail.com> Message-ID: <20090529112815.GC3095@hansolo.jdub.homelinux.org> On Fri, May 29, 2009 at 12:30:45PM +0300, Muayyad AlSadi wrote: >> IMHO it is not Fedora's job to define family values & moralities. Such morals/values will vary all around the world >I don't want fedora to define such things, we have our own values predefined. > >it should not make my job finding suck packages difficult >we have more than 10,000 packages in the repos so don't expect me to >test them all > >the package maintainers already classify their packages using Group: >in the spec file > >and they already classify them in yum comps files > >I demand a systematic way, a policy that tells a package maintainer >how to categories their packages in a unified proper way to warn >people like us from their packages. You can demand whatever you want, but that doesn't mean you will get it. If you want that, draft a proposal for the packaging guidelines and submit it. Honestly, I agree with the view that it is not Fedora's place to classify packages in such a manner. josh From kushaldas at gmail.com Fri May 29 11:29:03 2009 From: kushaldas at gmail.com (Kushal Das) Date: Fri, 29 May 2009 16:59:03 +0530 Subject: gnaughty is a hot babe In-Reply-To: <50baabb30905290424m1a51813ckab95c777de9717d6@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <50baabb30905290401y3f2bef33se5b00040ddce608b@mail.gmail.com> <4A1FC15D.9030003@nicubunu.ro> <50baabb30905290407h352be372tb3a77ae1da0359e1@mail.gmail.com> <50baabb30905290424m1a51813ckab95c777de9717d6@mail.gmail.com> Message-ID: On Fri, May 29, 2009 at 4:54 PM, Chitlesh GOORAH wrote: > > No, it doesn't (not till it is approved) not depend on the user's > choice. My package OVM was blocked by FESCo because there was no > opensource simulator. So if the downloaded videos aren't under an > opensource compatible format, FESCo must rule out its package review. As you said, no opensource simulator, but we have opensource viewer :) Kushal -- http://fedoraproject.org http://kushaldas.in From mjg at redhat.com Fri May 29 11:29:21 2009 From: mjg at redhat.com (Matthew Garrett) Date: Fri, 29 May 2009 12:29:21 +0100 Subject: Plans for tomorrow's (20090529) FESCo meeting In-Reply-To: <1243596203.2559.10.camel@localhost.localdomain> References: <200905291033.20518.opensource@till.name> <1243596203.2559.10.camel@localhost.localdomain> Message-ID: <20090529112918.GA28196@srcf.ucam.org> On Fri, May 29, 2009 at 02:23:23PM +0300, Jussi Lehtola wrote: > On Fri, 2009-05-29 at 10:33 +0200, Till Maas wrote: > > There is a proposed Feature that connot be completed because kernel module > > packages are prohibited in Fedora: > > https://fedoraproject.org/wiki/Features/VirtualBox > > Maybe the necessary bits can be included in the Fedora kernel package > itself? That's only likely to happen if the virtualbox code gets included in the upstream kernel. -- Matthew Garrett | mjg59 at srcf.ucam.org From nicu_fedora at nicubunu.ro Fri May 29 11:30:32 2009 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Fri, 29 May 2009 14:30:32 +0300 Subject: gnaughty is a hot babe In-Reply-To: <50baabb30905290407h352be372tb3a77ae1da0359e1@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <50baabb30905290401y3f2bef33se5b00040ddce608b@mail.gmail.com> <4A1FC15D.9030003@nicubunu.ro> <50baabb30905290407h352be372tb3a77ae1da0359e1@mail.gmail.com> Message-ID: <4A1FC758.5070803@nicubunu.ro> On 05/29/2009 02:07 PM, Chitlesh GOORAH wrote: > On Fri, May 29, 2009 at 1:05 PM, Nicu Buculei wrote: >> There is no video, only a few harmless static drawings in PNG format. >> > > from : http://sourceforge.net/projects/gnaughty > > """Gnaughty is an utility to automatically download adult sex content, > i.e. porn movies and pictures,....""" That was the "hot-babe" application. > It seems movies can be downloaded. Movies in proprietary formats can be downloaded also with Firefox, Transmission, wget, etc. From the description of gnaughty I understand it can also download images, which are in free formats, so the content is in both free and proprietary formats. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/ photography: http://photoblog.nicubunu.ro/ my Fedora stuff: http://fedora.nicubunu.ro/ From drago01 at gmail.com Fri May 29 11:29:48 2009 From: drago01 at gmail.com (drago01) Date: Fri, 29 May 2009 13:29:48 +0200 Subject: Plans for tomorrow's (20090529) FESCo meeting In-Reply-To: <1243596203.2559.10.camel@localhost.localdomain> References: <200905291033.20518.opensource@till.name> <1243596203.2559.10.camel@localhost.localdomain> Message-ID: On Fri, May 29, 2009 at 1:23 PM, Jussi Lehtola wrote: > On Fri, 2009-05-29 at 10:33 +0200, Till Maas wrote: >> There is a proposed Feature that connot be completed because kernel module >> packages are prohibited in Fedora: >> https://fedoraproject.org/wiki/Features/VirtualBox > > Maybe the necessary bits can be included in the Fedora kernel package > itself? For this they have to be upstream or atleast heading for upstream inclusion. From drago01 at gmail.com Fri May 29 11:35:46 2009 From: drago01 at gmail.com (drago01) Date: Fri, 29 May 2009 13:35:46 +0200 Subject: gnaughty is a hot babe In-Reply-To: <50baabb30905290424m1a51813ckab95c777de9717d6@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <50baabb30905290401y3f2bef33se5b00040ddce608b@mail.gmail.com> <4A1FC15D.9030003@nicubunu.ro> <50baabb30905290407h352be372tb3a77ae1da0359e1@mail.gmail.com> <50baabb30905290424m1a51813ckab95c777de9717d6@mail.gmail.com> Message-ID: On Fri, May 29, 2009 at 1:24 PM, Chitlesh GOORAH wrote: > On Fri, May 29, 2009 at 1:12 PM, Kushal Das wrote: >> Yes that is true , but it does not provide any support to view that >> content, we have many other packages in Fedora which allows to >> download content and they download whatever format the site is >> providing, how the users watch it, it depends on their choice. > > No, it doesn't (not till it is approved) not depend on the user's > choice. My package OVM was blocked by FESCo because there was no > opensource simulator. So if the downloaded videos aren't under an > opensource compatible format, FESCo must rule out its package review. Sorry but this is just bullshit with this logic we should ban everything which can download files. In case of OVM you wanted to add the "unviewable" content into fedora, while this packages do not add the movies to fedora they just provide a way to download them. Nobody is proposing to add a mp3 file or a h264 encoded video to fedora, so you are comparing apples and oranges. From jwboyer at gmail.com Fri May 29 11:36:07 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 29 May 2009 07:36:07 -0400 Subject: Plans for tomorrow's (20090529) FESCo meeting In-Reply-To: <200905291033.20518.opensource@till.name> References: <200905291033.20518.opensource@till.name> Message-ID: <20090529113607.GD3095@hansolo.jdub.homelinux.org> On Fri, May 29, 2009 at 10:33:19AM +0200, Till Maas wrote: >On Thu May 28 2009, Jon Stanley wrote: >> Well, I have nothing on the agenda for tomorrow's meeting at this >> point. Thus, the entire meeting taking place at 17:00UTC in >> #fedora-meeting will be an open floor, unless someone comes up with >> something to discuss between now and then :). > >There is a proposed Feature that connot be completed because kernel module >packages are prohibited in Fedora: >https://fedoraproject.org/wiki/Features/VirtualBox > >The Feature Wrangler told me, that the current feature process[0] cannot >handle this situation, because feature pages hang around until they are >excepted. But I guess that infiltrating FESCo to get kernel module packages >back into Fedora is not was is expected to finish the feature. ;-) > >So if only FESCo can adjust the feature process, please update it to include >the case of unfinishable features. I don't see a problem. If the Feature owner cares enough to keep proposing it, then FESCo will keep reviewing it. Technical items change over time. Perhaps the VirtualBox module will make it into the upstream kernel and the Feature will be viable. Or perhaps a future FESCo will revist kmods. If the Feature owner doesn't care, then they can delete the page. Either way, I don't see what the problem is with having it sit in the FeaturePageIncomplete category. josh From chitlesh.goorah at gmail.com Fri May 29 11:40:36 2009 From: chitlesh.goorah at gmail.com (Chitlesh GOORAH) Date: Fri, 29 May 2009 13:40:36 +0200 Subject: gnaughty is a hot babe In-Reply-To: <4A1FC758.5070803@nicubunu.ro> References: <4A1E5CC4.2060506@fedoraproject.org> <50baabb30905290401y3f2bef33se5b00040ddce608b@mail.gmail.com> <4A1FC15D.9030003@nicubunu.ro> <50baabb30905290407h352be372tb3a77ae1da0359e1@mail.gmail.com> <4A1FC758.5070803@nicubunu.ro> Message-ID: <50baabb30905290440l1490d87dg2c21f2226604cdb1@mail.gmail.com> On Fri, May 29, 2009 at 1:30 PM, Nicu Buculei wrote: > Movies in proprietary formats can be downloaded also with Firefox, > Transmission, wget, etc. > From the description of gnaughty I understand it can also download images, > which are in free formats, so the content is in both free and proprietary > formats. Here is the purpose of the application is important. A browser is not only intended for free and proprietary formats downloader. It serves other purposes as well. But gNaughty serves only purpose is "download porn". If we allow this package, in other words it says Fedora tolerates proprietary formats. It is not something we are comfortable with. On Fri, May 29, 2009 at 1:35 PM, drago01 wrote: > Sorry but this is just bullshit with this logic we should ban > everything which can download files. > In case of OVM you wanted to add the "unviewable" content into fedora, > while this packages do not add the movies to fedora they just provide > a way to download them. OVM is just a bunch for text files, viewable with any editor. I didn't say "unviewable" content. Chitlesh From chitlesh.goorah at gmail.com Fri May 29 11:45:24 2009 From: chitlesh.goorah at gmail.com (Chitlesh GOORAH) Date: Fri, 29 May 2009 13:45:24 +0200 Subject: gnaughty is a hot babe In-Reply-To: References: <4A1E5CC4.2060506@fedoraproject.org> <50baabb30905290401y3f2bef33se5b00040ddce608b@mail.gmail.com> <4A1FC15D.9030003@nicubunu.ro> <50baabb30905290407h352be372tb3a77ae1da0359e1@mail.gmail.com> <50baabb30905290424m1a51813ckab95c777de9717d6@mail.gmail.com> Message-ID: <50baabb30905290445l3a1b1c40qdba0872ef0215498@mail.gmail.com> On Fri, May 29, 2009 at 1:29 PM, Kushal Das wrote: > As you said, no opensource simulator, but we have opensource viewer :) Fedora doesn't ship a video viewer which supports proprietary formats out of the box. For me this package goes to rpmfusion. Chitlesh From ralph+fedora at strg-alt-entf.org Fri May 29 11:49:14 2009 From: ralph+fedora at strg-alt-entf.org (Ralph Angenendt) Date: Fri, 29 May 2009 13:49:14 +0200 Subject: gnaughty is a hot babe In-Reply-To: <50baabb30905290424m1a51813ckab95c777de9717d6@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <50baabb30905290401y3f2bef33se5b00040ddce608b@mail.gmail.com> <4A1FC15D.9030003@nicubunu.ro> <50baabb30905290407h352be372tb3a77ae1da0359e1@mail.gmail.com> <50baabb30905290424m1a51813ckab95c777de9717d6@mail.gmail.com> Message-ID: <20090529114914.GF12010@br-online.de> Chitlesh GOORAH wrote: > On Fri, May 29, 2009 at 1:12 PM, Kushal Das wrote: > > Yes that is true , but it does not provide any support to view that > > content, we have many other packages in Fedora which allows to > > download content and they download whatever format the site is > > providing, how the users watch it, it depends on their choice. > > No, it doesn't (not till it is approved) not depend on the user's > choice. My package OVM was blocked by FESCo because there was no > opensource simulator. So if the downloaded videos aren't under an > opensource compatible format, FESCo must rule out its package review. So Fedora should remove slrn, mutt, wget, links, curl, firefox, whatever now, because I can download or save Microsoft ASF files with them and have no fedora included program to use them with? Ummmm. Ralph -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From berrange at redhat.com Fri May 29 11:50:19 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 29 May 2009 12:50:19 +0100 Subject: gnaughty is a hot babe In-Reply-To: <50baabb30905290440l1490d87dg2c21f2226604cdb1@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <50baabb30905290401y3f2bef33se5b00040ddce608b@mail.gmail.com> <4A1FC15D.9030003@nicubunu.ro> <50baabb30905290407h352be372tb3a77ae1da0359e1@mail.gmail.com> <4A1FC758.5070803@nicubunu.ro> <50baabb30905290440l1490d87dg2c21f2226604cdb1@mail.gmail.com> Message-ID: <20090529115019.GH29375@redhat.com> On Fri, May 29, 2009 at 01:40:36PM +0200, Chitlesh GOORAH wrote: > On Fri, May 29, 2009 at 1:30 PM, Nicu Buculei wrote: > > Movies in proprietary formats can be downloaded also with Firefox, > > Transmission, wget, etc. > > From the description of gnaughty I understand it can also download images, > > which are in free formats, so the content is in both free and proprietary > > formats. > > Here is the purpose of the application is important. A browser is not > only intended for free and proprietary > formats downloader. It serves other purposes as well. > > But gNaughty serves only purpose is "download porn". If we allow this > package, in other words it says Fedora tolerates proprietary formats. > It is not something we are comfortable with. It is not Fedora's place to police *usage* of apps, only whether the app or package has a compliant license and follows the defined packaging & legal rules. If the tool were directly containing support for decoding such prorietry formats that would be a different matter, because the codecs would not pass the legal rules. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From jreznik at redhat.com Fri May 29 11:51:51 2009 From: jreznik at redhat.com (Jaroslav Reznik) Date: Fri, 29 May 2009 13:51:51 +0200 Subject: gnaughty is a hot babe In-Reply-To: <50baabb30905290440l1490d87dg2c21f2226604cdb1@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <4A1FC758.5070803@nicubunu.ro> <50baabb30905290440l1490d87dg2c21f2226604cdb1@mail.gmail.com> Message-ID: <200905291351.52188.jreznik@redhat.com> On Viernes 29 Mayo 2009 13:40:36 Chitlesh GOORAH escribi?: > On Fri, May 29, 2009 at 1:30 PM, Nicu Buculei wrote: > > Movies in proprietary formats can be downloaded also with Firefox, > > Transmission, wget, etc. > > From the description of gnaughty I understand it can also download > > images, which are in free formats, so the content is in both free and > > proprietary formats. > > Here is the purpose of the application is important. A browser is not > only intended for free and proprietary > formats downloader. It serves other purposes as well. > > But gNaughty serves only purpose is "download porn". If we allow this > package, in other words it says Fedora tolerates proprietary formats. > It is not something we are comfortable with. Internet is for porn... Sorry I don't know this software but as someone already pointed - it's opensource, it can be used to download other content. It's same like Adobe banned rtmpdump as it can be used to download restricted content but Flash Player is used everyday to watch unlegal content! One interesting thing - does it download free content? Are there some porn sites under CC licence? Free culture, by community for community... Jaroslav > On Fri, May 29, 2009 at 1:35 PM, drago01 wrote: > > Sorry but this is just bullshit with this logic we should ban > > everything which can download files. > > In case of OVM you wanted to add the "unviewable" content into fedora, > > while this packages do not add the movies to fedora they just provide > > a way to download them. > > OVM is just a bunch for text files, viewable with any editor. I didn't > say "unviewable" content. > > > Chitlesh From chitlesh.goorah at gmail.com Fri May 29 11:55:30 2009 From: chitlesh.goorah at gmail.com (Chitlesh GOORAH) Date: Fri, 29 May 2009 13:55:30 +0200 Subject: gnaughty is a hot babe In-Reply-To: <20090529115019.GH29375@redhat.com> References: <4A1E5CC4.2060506@fedoraproject.org> <50baabb30905290401y3f2bef33se5b00040ddce608b@mail.gmail.com> <4A1FC15D.9030003@nicubunu.ro> <50baabb30905290407h352be372tb3a77ae1da0359e1@mail.gmail.com> <4A1FC758.5070803@nicubunu.ro> <50baabb30905290440l1490d87dg2c21f2226604cdb1@mail.gmail.com> <20090529115019.GH29375@redhat.com> Message-ID: <50baabb30905290455y16806bf8r212f23abaa2ac3c0@mail.gmail.com> On Fri, May 29, 2009 at 1:50 PM, Daniel P. Berrange wrote: > If the tool were directly containing support for decoding > such prorietry formats that would be a different matter, because the > codecs would not pass the legal rules. OVM doesn't directly include any fedora forbidden items as well. It was refused because there was not enough opensource tools to use it. It is the same situation here. Chitlesh From sundaram at fedoraproject.org Fri May 29 11:57:02 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 29 May 2009 17:27:02 +0530 Subject: gnaughty is a hot babe In-Reply-To: <200905291351.52188.jreznik@redhat.com> References: <4A1E5CC4.2060506@fedoraproject.org> <4A1FC758.5070803@nicubunu.ro> <50baabb30905290440l1490d87dg2c21f2226604cdb1@mail.gmail.com> <200905291351.52188.jreznik@redhat.com> Message-ID: <4A1FCD8E.6080508@fedoraproject.org> On 05/29/2009 05:21 PM, Jaroslav Reznik wrote: ! > > One interesting thing - does it download free content? Are there some porn > sites under CC licence? Free culture, by community for community... There is and no, I am not linking to them, here. Rahul From kushaldas at gmail.com Fri May 29 11:58:11 2009 From: kushaldas at gmail.com (Kushal Das) Date: Fri, 29 May 2009 17:28:11 +0530 Subject: gnaughty is a hot babe In-Reply-To: <50baabb30905290455y16806bf8r212f23abaa2ac3c0@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <50baabb30905290401y3f2bef33se5b00040ddce608b@mail.gmail.com> <4A1FC15D.9030003@nicubunu.ro> <50baabb30905290407h352be372tb3a77ae1da0359e1@mail.gmail.com> <4A1FC758.5070803@nicubunu.ro> <50baabb30905290440l1490d87dg2c21f2226604cdb1@mail.gmail.com> <20090529115019.GH29375@redhat.com> <50baabb30905290455y16806bf8r212f23abaa2ac3c0@mail.gmail.com> Message-ID: On Fri, May 29, 2009 at 5:25 PM, Chitlesh GOORAH wrote: > > OVM doesn't directly include any fedora forbidden items as well. It > was refused because there was not enough opensource tools to use it. > It is the same situation here. > We have totem. Kushal -- http://fedoraproject.org http://kushaldas.in From mjg at redhat.com Fri May 29 11:59:21 2009 From: mjg at redhat.com (Matthew Garrett) Date: Fri, 29 May 2009 12:59:21 +0100 Subject: gnaughty is a hot babe In-Reply-To: <50baabb30905290455y16806bf8r212f23abaa2ac3c0@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <50baabb30905290401y3f2bef33se5b00040ddce608b@mail.gmail.com> <4A1FC15D.9030003@nicubunu.ro> <50baabb30905290407h352be372tb3a77ae1da0359e1@mail.gmail.com> <4A1FC758.5070803@nicubunu.ro> <50baabb30905290440l1490d87dg2c21f2226604cdb1@mail.gmail.com> <20090529115019.GH29375@redhat.com> <50baabb30905290455y16806bf8r212f23abaa2ac3c0@mail.gmail.com> Message-ID: <20090529115921.GA28912@srcf.ucam.org> On Fri, May 29, 2009 at 01:55:30PM +0200, Chitlesh GOORAH wrote: > On Fri, May 29, 2009 at 1:50 PM, Daniel P. Berrange wrote: > > If the tool were directly containing support for decoding > > such prorietry formats that would be a different matter, because the > > codecs would not pass the legal rules. > > OVM doesn't directly include any fedora forbidden items as well. It > was refused because there was not enough opensource tools to use it. > It is the same situation here. There's plenty of open source tools to play a variety of video codecs. We just can't ship them. This isn't an equivalent situation. -- Matthew Garrett | mjg59 at srcf.ucam.org From chitlesh.goorah at gmail.com Fri May 29 12:02:36 2009 From: chitlesh.goorah at gmail.com (Chitlesh GOORAH) Date: Fri, 29 May 2009 14:02:36 +0200 Subject: gnaughty is a hot babe In-Reply-To: <200905291351.52188.jreznik@redhat.com> References: <4A1E5CC4.2060506@fedoraproject.org> <4A1FC758.5070803@nicubunu.ro> <50baabb30905290440l1490d87dg2c21f2226604cdb1@mail.gmail.com> <200905291351.52188.jreznik@redhat.com> Message-ID: <50baabb30905290502g3550624l3e1e5fe860712be5@mail.gmail.com> On Fri, May 29, 2009 at 1:51 PM, Jaroslav Reznik wrote: > Internet is for porn... > > Sorry I don't know this software but as someone already pointed - it's > opensource, it can be used to download other content. It's same like Adobe > banned rtmpdump as it can be used to download restricted content but Flash > Player is used everyday to watch unlegal content! > > One interesting thing - does it download free content? Are there some porn > sites under CC licence? Free culture, by community for community... > Following your logic, OVM should enter fedora collection as well. !! http://www.opensubscriber.com/message/fedora-devel-list at redhat.com/11366282.html Why did you support OVM entrance as well ? Some OVM users don't always need a simulator in the design flow. Chitlesh From drago01 at gmail.com Fri May 29 12:04:52 2009 From: drago01 at gmail.com (drago01) Date: Fri, 29 May 2009 14:04:52 +0200 Subject: gnaughty is a hot babe In-Reply-To: <50baabb30905290502g3550624l3e1e5fe860712be5@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <4A1FC758.5070803@nicubunu.ro> <50baabb30905290440l1490d87dg2c21f2226604cdb1@mail.gmail.com> <200905291351.52188.jreznik@redhat.com> <50baabb30905290502g3550624l3e1e5fe860712be5@mail.gmail.com> Message-ID: On Fri, May 29, 2009 at 2:02 PM, Chitlesh GOORAH wrote: > On Fri, May 29, 2009 at 1:51 PM, Jaroslav Reznik wrote: >> Internet is for porn... >> >> Sorry I don't know this software but as someone already pointed - it's >> opensource, it can be used to download other content. It's same like Adobe >> banned rtmpdump as it can be used to download restricted content but Flash >> Player is used everyday to watch unlegal content! >> >> One interesting thing - does it download free content? Are there some porn >> sites under CC licence? Free culture, by community for community... >> > > Following your logic, OVM should enter fedora collection as well. !! > > http://www.opensubscriber.com/message/fedora-devel-list at redhat.com/11366282.html > > Why did you support OVM entrance as well ? > > Some OVM users don't always need a simulator in the design flow. Well than we should stop triying to come up with weird rules to ban packages and instead revisit the decision made by FESCo. From foss.mailinglists at gmail.com Fri May 29 12:11:22 2009 From: foss.mailinglists at gmail.com (sankarshan) Date: Fri, 29 May 2009 17:41:22 +0530 Subject: gnaughty is a hot babe In-Reply-To: <4A1E5CC4.2060506@fedoraproject.org> References: <4A1E5CC4.2060506@fedoraproject.org> Message-ID: <35586fc00905290511q52adc87ar2673b1af1dd88ba1@mail.gmail.com> On Thu, May 28, 2009 at 3:13 PM, Rahul Sundaram wrote: > My packaging survey turned up a interesting suggestion > > https://www.redhat.com/archives/fedora-list/2009-May/msg01809.html > > We don't currently have any guidelines covering this but considering the > Debian action to hot babe > > http://lwn.net/Articles/113644/ > > I wanted to asked first, ?is this allowed in Fedora? Given the direction of the thread, do you expect a resolution to come up from the discussion ? -- http://www.gutenberg.net - Fine literature digitally re-published http://www.plos.org - Public Library of Science http://www.creativecommons.org - Flexible copyright for creative work From chitlesh.goorah at gmail.com Fri May 29 12:16:21 2009 From: chitlesh.goorah at gmail.com (Chitlesh GOORAH) Date: Fri, 29 May 2009 14:16:21 +0200 Subject: gnaughty is a hot babe In-Reply-To: <35586fc00905290511q52adc87ar2673b1af1dd88ba1@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <35586fc00905290511q52adc87ar2673b1af1dd88ba1@mail.gmail.com> Message-ID: <50baabb30905290516g30f4fe90y13045c0dc3c25feb@mail.gmail.com> On Fri, May 29, 2009 at 2:11 PM, sankarshan <> wrote: > On Thu, May 28, 2009 at 3:13 PM, Rahul Sundaram > wrote: > >> My packaging survey turned up a interesting suggestion >> >> https://www.redhat.com/archives/fedora-list/2009-May/msg01809.html >> >> We don't currently have any guidelines covering this but considering the >> Debian action to hot babe >> >> http://lwn.net/Articles/113644/ >> >> I wanted to asked first, ?is this allowed in Fedora? > > Given the direction of the thread, do you expect a resolution to come > up from the discussion ? Sometimes, it's worth to discuss it. For example alliance was refused on debian, but approved on fedora. Chitlesh From kevin.kofler at chello.at Fri May 29 12:23:01 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 29 May 2009 14:23:01 +0200 Subject: gnaughty is a hot babe References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <20090529092040.GA29375@redhat.com> Message-ID: Daniel P. Berrange wrote: > IMHO it is not Fedora's job to define family values & moralities. > Such morals/values will vary all around the world, such that no > single list Fedora makes would be satisfactory. If a derived spin > wants to define a set of morals & values then the burden should be > on them to maintain the list of packages that don't comply, not > Fedora. +1 Kevin Kofler From ffesti at redhat.com Fri May 29 12:30:46 2009 From: ffesti at redhat.com (Florian Festi) Date: Fri, 29 May 2009 14:30:46 +0200 Subject: gnaughty is a hot babe In-Reply-To: <50baabb30905290502g3550624l3e1e5fe860712be5@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <4A1FC758.5070803@nicubunu.ro> <50baabb30905290440l1490d87dg2c21f2226604cdb1@mail.gmail.com> <200905291351.52188.jreznik@redhat.com> <50baabb30905290502g3550624l3e1e5fe860712be5@mail.gmail.com> Message-ID: <4A1FD576.5060900@redhat.com> Chitlesh GOORAH wrote: > On Fri, May 29, 2009 at 1:51 PM, Jaroslav Reznik wrote: >> Internet is for porn... >> >> Sorry I don't know this software but as someone already pointed - it's >> opensource, it can be used to download other content. It's same like Adobe >> banned rtmpdump as it can be used to download restricted content but Flash >> Player is used everyday to watch unlegal content! >> >> One interesting thing - does it download free content? Are there some porn >> sites under CC licence? Free culture, by community for community... >> > > Following your logic, OVM should enter fedora collection as well. !! It really doesn't matter how often you repeat a wrong sentence. There are different rules that do apply to code and content in Fedora and OVM got categorized as content and refused by the rules for content. We are talking about a program here. Florian From inode0 at gmail.com Fri May 29 12:46:13 2009 From: inode0 at gmail.com (inode0) Date: Fri, 29 May 2009 07:46:13 -0500 Subject: gnaughty is a hot babe In-Reply-To: <4A1FD576.5060900@redhat.com> References: <4A1E5CC4.2060506@fedoraproject.org> <4A1FC758.5070803@nicubunu.ro> <50baabb30905290440l1490d87dg2c21f2226604cdb1@mail.gmail.com> <200905291351.52188.jreznik@redhat.com> <50baabb30905290502g3550624l3e1e5fe860712be5@mail.gmail.com> <4A1FD576.5060900@redhat.com> Message-ID: On Fri, May 29, 2009 at 7:30 AM, Florian Festi wrote: > Chitlesh GOORAH wrote: >> Following your logic, OVM should enter fedora collection as well. !! > > It really doesn't matter how often you repeat a wrong sentence. > > There are different rules that do apply to code and content in Fedora and > OVM got categorized as content and refused by the rules for content. We are > talking about a program here. True. Someone should ask the question: does it make sense to have different rules if they prevent the inclusion of useful content and allow the inclusion of useless code? John From ssorce at redhat.com Fri May 29 12:50:08 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 29 May 2009 08:50:08 -0400 Subject: gnaughty is a hot babe In-Reply-To: <20090529092040.GA29375@redhat.com> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <20090529092040.GA29375@redhat.com> Message-ID: <1243601409.7279.132.camel@localhost.localdomain> On Fri, 2009-05-29 at 10:20 +0100, Daniel P. Berrange wrote: > On Fri, May 29, 2009 at 11:05:01AM +0300, Muayyad AlSadi wrote: > > in case you have accepted to put such packages in the repo > > > > please maintain a wiki page listing all of them so that we can add > > exclude for all of them in > > fedora .repo files > > > > sorry, but our users trust us [in ojuba.org spin] to provide packages > > that respect our family values and moralities > > IMHO it is not Fedora's job to define family values & moralities. > Such morals/values will vary all around the world, such that no > single list Fedora makes would be satisfactory. If a derived spin > wants to define a set of morals & values then the burden should be > on them to maintain the list of packages that don't comply, not > Fedora. Let's also add the morality is the prime excuse for censorship in many countries. I can't count the amount of clearly censor-grade legislation has passed recently in just the western hemisphere with just the *excuse* of "defending children"* where in some cases stuff related to children was not even named in the text of the law, or if it were it was clearly preposterous and only there to justify the whole set of rules. Let alone countless other moral or religious precepts. That said, if there are clearly identifiable class of programs that may be deemed offensive by a large set of people (and *not* governments), then it would be sensible to mark them so that people can consciously and *individually* decide to (not) install/remove them or use spins that explicitly exclude/include them. Simo. * Of course I am all for defending children, but totally against using a highly sensible topic to shove in legislation that has nothing to do with protection them and all to do with censorship and control. -- Simo Sorce * Red Hat, Inc * New York From kushaldas at gmail.com Fri May 29 12:51:47 2009 From: kushaldas at gmail.com (Kushal Das) Date: Fri, 29 May 2009 18:21:47 +0530 Subject: gnaughty is a hot babe In-Reply-To: References: <4A1E5CC4.2060506@fedoraproject.org> <4A1FC758.5070803@nicubunu.ro> <50baabb30905290440l1490d87dg2c21f2226604cdb1@mail.gmail.com> <200905291351.52188.jreznik@redhat.com> <50baabb30905290502g3550624l3e1e5fe860712be5@mail.gmail.com> <4A1FD576.5060900@redhat.com> Message-ID: On Fri, May 29, 2009 at 6:16 PM, inode0 wrote: > True. Someone should ask the question: does it make sense to have > different rules if they prevent the inclusion of useful content and > allow the inclusion of useless code? Which is useless to me can be very useful to someone else. Kushal -- http://fedoraproject.org http://kushaldas.in From drago01 at gmail.com Fri May 29 12:56:44 2009 From: drago01 at gmail.com (drago01) Date: Fri, 29 May 2009 14:56:44 +0200 Subject: gnaughty is a hot babe In-Reply-To: <1243601409.7279.132.camel@localhost.localdomain> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <20090529092040.GA29375@redhat.com> <1243601409.7279.132.camel@localhost.localdomain> Message-ID: On Fri, May 29, 2009 at 2:50 PM, Simo Sorce wrote: > On Fri, 2009-05-29 at 10:20 +0100, Daniel P. Berrange wrote: >> On Fri, May 29, 2009 at 11:05:01AM +0300, Muayyad AlSadi wrote: >> > in case you have accepted to put such packages in the repo >> > >> > please maintain a wiki page listing all of them so that we can add >> > exclude for all of them in >> > fedora .repo files >> > >> > sorry, but our users trust us [in ojuba.org spin] to provide packages >> > that respect our family values and moralities >> >> IMHO it is not Fedora's job to ?define family values & moralities. >> Such morals/values will vary all around the world, such that no >> single list Fedora makes would be satisfactory. If a derived spin >> wants to define a set of morals & values then the burden should be >> on them to maintain the list of packages that don't comply, not >> Fedora. > > Let's also add the morality is the prime excuse for censorship in many > countries. I can't count the amount of clearly censor-grade legislation > has passed recently in just the western hemisphere with just the > *excuse* of "defending children"* where in some cases stuff related to > children was not even named in the text of the law, or if it were it was > clearly preposterous and only there to justify the whole set of rules. > Let alone countless other moral or religious precepts. > > That said, if there are clearly identifiable class of programs that may > be deemed offensive by a large set of people (and *not* governments), > then it would be sensible to mark them so that people can consciously > and *individually* decide to (not) install/remove them or use spins that > explicitly exclude/include them. > > Simo. > > > > * Of course I am all for defending children, but totally against using a > highly sensible topic to shove in legislation that has nothing to do > with protection them and all to do with censorship and control. +1 From mcepl at redhat.com Fri May 29 12:59:56 2009 From: mcepl at redhat.com (Matej Cepl) Date: Fri, 29 May 2009 12:59:56 +0000 (UTC) Subject: gnaughty is a hot babe References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> Message-ID: Dennis J., Thu, 28 May 2009 21:02:05 +0200: > Murder is a crime, pornography isn't There are many states (including many states of USA) where it is. Mat?j From inode0 at gmail.com Fri May 29 13:00:40 2009 From: inode0 at gmail.com (inode0) Date: Fri, 29 May 2009 08:00:40 -0500 Subject: gnaughty is a hot babe In-Reply-To: References: <4A1E5CC4.2060506@fedoraproject.org> <4A1FC758.5070803@nicubunu.ro> <50baabb30905290440l1490d87dg2c21f2226604cdb1@mail.gmail.com> <200905291351.52188.jreznik@redhat.com> <50baabb30905290502g3550624l3e1e5fe860712be5@mail.gmail.com> <4A1FD576.5060900@redhat.com> Message-ID: On Fri, May 29, 2009 at 7:51 AM, Kushal Das wrote: > On Fri, May 29, 2009 at 6:16 PM, inode0 wrote: >> True. Someone should ask the question: does it make sense to have >> different rules if they prevent the inclusion of useful content and >> allow the inclusion of useless code? > Which is useless to me can be very useful to someone else. That doesn't explain why there is a different standard for content. John From opensource at till.name Fri May 29 13:01:29 2009 From: opensource at till.name (Till Maas) Date: Fri, 29 May 2009 15:01:29 +0200 Subject: Plans for tomorrow's (20090529) FESCo meeting In-Reply-To: <20090529113607.GD3095@hansolo.jdub.homelinux.org> References: <200905291033.20518.opensource@till.name> <20090529113607.GD3095@hansolo.jdub.homelinux.org> Message-ID: <200905291501.35665.opensource@till.name> On Fri May 29 2009, Josh Boyer wrote: > I don't see a problem. Imho outdated content reduces the quality of the wiki, therefore there should be some garbage collection. > If the Feature owner cares enough to keep proposing it, then FESCo will > keep reviewing it. Technical items change over time. Perhaps the > VirtualBox module will make it into the upstream kernel and the Feature > will be viable. Or perhaps a future FESCo will revist kmods. Did you look at the content of the feature page? Even in the very unlikely case that it may be included in Fedora in the future, Fedora will probably be the last distribution to include it, so it is also very unlikely that it even meats the Feature criteria. And if it does, there are only four sentences in the Feature page, that were not in the template. > If the Feature owner doesn't care, then they can delete the page. Either > way, I don't see what the problem is with having it sit in the > FeaturePageIncomplete category. It seems more to me, that the Feature owner does not care, because the package is very incomplete and I got no response from my comment in December 2008 that Virtualbox won't make it into Fedora. Btw. how does the Feature owner delete the page? It seems to me, that this is not easily possible using the wiki interface. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From inode0 at gmail.com Fri May 29 13:06:53 2009 From: inode0 at gmail.com (inode0) Date: Fri, 29 May 2009 08:06:53 -0500 Subject: gnaughty is a hot babe In-Reply-To: <50baabb30905290424m1a51813ckab95c777de9717d6@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <50baabb30905290401y3f2bef33se5b00040ddce608b@mail.gmail.com> <4A1FC15D.9030003@nicubunu.ro> <50baabb30905290407h352be372tb3a77ae1da0359e1@mail.gmail.com> <50baabb30905290424m1a51813ckab95c777de9717d6@mail.gmail.com> Message-ID: On Fri, May 29, 2009 at 6:24 AM, Chitlesh GOORAH wrote: > On Fri, May 29, 2009 at 1:12 PM, Kushal Das wrote: >> Yes that is true , but it does not provide any support to view that >> content, we have many other packages in Fedora which allows to >> download content and they download whatever format the site is >> providing, how the users watch it, it depends on their choice. > > No, it doesn't (not till it is approved) not depend on the user's > choice. My package OVM was blocked by FESCo because there was no > opensource simulator. So if the downloaded videos aren't under an > opensource compatible format, FESCo must rule out its package review. >From my perspective, and I think OVM should have been accepted, we should work to fix what caused OVM to be rejected rather that try to exclude other things using the same "logic." John From kanarip at kanarip.com Fri May 29 13:11:06 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 29 May 2009 15:11:06 +0200 Subject: Who wants a pony ? In-Reply-To: <20090528130649.GI8860@localhost.localdomain> References: <4A1E6EF1.80106@redhat.com> <91157db90905280535j61535404i3ed0f921cdabf572@mail.gmail.com> <4A1E857F.6040603@fedoraproject.org> <20090528130649.GI8860@localhost.localdomain> Message-ID: <4A1FDEEA.4070609@kanarip.com> On 05/28/2009 03:06 PM, Paul W. Frields wrote: > On Thu, May 28, 2009 at 06:07:19PM +0530, Rahul Sundaram wrote: >> On 05/28/2009 06:05 PM, jude ui wrote: >>> On 5/28/09, *Marcela Maslanova*>> > wrote: >>> >>> On 05/28/2009 12:44 PM, Kushal Das wrote: >>> >>> Hi all, >>> >>> If you want one, review >>> https://bugzilla.redhat.com/show_bug.cgi?id=503021 >>> >>> Kushal >>> >>> It hope in different kind of pony but I'll take the review. >>> >>> What do ponies have to do with this? >> I suppose you have to actually click on the link to find out. > > With Fedora, life apparently *could* be a pony farm. Who knew?!? > Actually I'm arguing that it *is* in various places ;-) -Jeroen From mcepl at redhat.com Fri May 29 13:14:21 2009 From: mcepl at redhat.com (Matej Cepl) Date: Fri, 29 May 2009 13:14:21 +0000 (UTC) Subject: Plans for tomorrow's (20090529) FESCo meeting References: <200905291033.20518.opensource@till.name> <20090529113607.GD3095@hansolo.jdub.homelinux.org> <200905291501.35665.opensource@till.name> Message-ID: Till Maas, Fri, 29 May 2009 15:01:29 +0200: > It seems more to me, that the Feature owner does not care, because the > package is very incomplete and I got no response from my comment in > December 2008 that Virtualbox won't make it into Fedora. Btw. how does > the Feature owner delete the page? It seems to me, that this is not > easily possible using the wiki interface. Moreover, it has been included in The Repository Which Shall Not Be Named. Mat?j From dpierce at redhat.com Fri May 29 13:18:41 2009 From: dpierce at redhat.com (Darryl L. Pierce) Date: Fri, 29 May 2009 09:18:41 -0400 Subject: gnaughty is a hot babe In-Reply-To: <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> Message-ID: <20090529131841.GA3587@mcpierce-laptop.rdu.redhat.com> On Fri, May 29, 2009 at 11:05:01AM +0300, Muayyad AlSadi wrote: > sorry, but our users trust us [in ojuba.org spin] to provide packages > that respect our family values and moralities Where do you anything about "family values and moralities" in Fedora's mission statement? I see statements about software being free to use, modify and redistribute, but nothing about software that matches some set of family values. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Virtual Machine Management - http://www.ovirt.org/ Is fearr Gaeilge bhriste n? B?arla cliste. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From dpierce at redhat.com Fri May 29 13:19:59 2009 From: dpierce at redhat.com (Darryl L. Pierce) Date: Fri, 29 May 2009 09:19:59 -0400 Subject: gnaughty is a hot babe In-Reply-To: <4A1FAD0D.4030608@fedoraproject.org> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <20090529092040.GA29375@redhat.com> <385866f0905290230n1170470cq31dc26c6dda35b6d@mail.gmail.com> <4A1FAD0D.4030608@fedoraproject.org> Message-ID: <20090529131959.GB3587@mcpierce-laptop.rdu.redhat.com> On Fri, May 29, 2009 at 03:08:21PM +0530, Rahul Sundaram wrote: > The problem, how do we determine what is offensive to any particular > group? Some people consider 3D shooter games offensive. This is slippery > slope. Unless there is a legal issue, I believe Fedora is going to end > up with that package. For a derivative, you have to pick and choose what > you want. +1 Don't use Fedora as a bully pulpit for blocking packages that you don't like. If you don't want the software, don't install it. _That_ is freedom. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Virtual Machine Management - http://www.ovirt.org/ Is fearr Gaeilge bhriste n? B?arla cliste. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From dpierce at redhat.com Fri May 29 13:25:22 2009 From: dpierce at redhat.com (Darryl L. Pierce) Date: Fri, 29 May 2009 09:25:22 -0400 Subject: gnaughty is a hot babe In-Reply-To: <50baabb30905290424m1a51813ckab95c777de9717d6@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <50baabb30905290401y3f2bef33se5b00040ddce608b@mail.gmail.com> <4A1FC15D.9030003@nicubunu.ro> <50baabb30905290407h352be372tb3a77ae1da0359e1@mail.gmail.com> <50baabb30905290424m1a51813ckab95c777de9717d6@mail.gmail.com> Message-ID: <20090529132522.GC3587@mcpierce-laptop.rdu.redhat.com> On Fri, May 29, 2009 at 01:24:14PM +0200, Chitlesh GOORAH wrote: > No, it doesn't (not till it is approved) not depend on the user's > choice. My package OVM was blocked by FESCo because there was no > opensource simulator. So if the downloaded videos aren't under an > opensource compatible format, FESCo must rule out its package review. Then we better dump anything that uses HTTP since that can be used to download content which is not open source or licensed in a free way. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Virtual Machine Management - http://www.ovirt.org/ Is fearr Gaeilge bhriste n? B?arla cliste. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From fedora at leemhuis.info Fri May 29 13:26:46 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 29 May 2009 15:26:46 +0200 Subject: Plans for tomorrow's (20090529) FESCo meeting In-Reply-To: References: <200905291033.20518.opensource@till.name> <20090529113607.GD3095@hansolo.jdub.homelinux.org> <200905291501.35665.opensource@till.name> Message-ID: <4A1FE296.1010607@leemhuis.info> On 29.05.2009 15:14, Matej Cepl wrote: > Till Maas, Fri, 29 May 2009 15:01:29 +0200: >> It seems more to me, that the Feature owner does not care, because the >> package is very incomplete and I got no response from my comment in >> December 2008 that Virtualbox won't make it into Fedora. Btw. how does >> the Feature owner delete the page? It seems to me, that this is not >> easily possible using the wiki interface. > Moreover, it has been included in The Repository Which Shall Not Be Named. Which is always glad if things can get moved to Fedora sooner or later ;-) CU knurd From alsadi at gmail.com Fri May 29 13:27:37 2009 From: alsadi at gmail.com (Muayyad AlSadi) Date: Fri, 29 May 2009 16:27:37 +0300 Subject: gnaughty is a hot babe In-Reply-To: <20090529131959.GB3587@mcpierce-laptop.rdu.redhat.com> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <20090529092040.GA29375@redhat.com> <385866f0905290230n1170470cq31dc26c6dda35b6d@mail.gmail.com> <4A1FAD0D.4030608@fedoraproject.org> <20090529131959.GB3587@mcpierce-laptop.rdu.redhat.com> Message-ID: <385866f0905290627vcd933a9r98d75cc6f3581ae8@mail.gmail.com> > Where do you anything about "family values and moralities" in Fedora's mission statement? I see statements about software being free to use, that's why I said us [in ojuba.org] as I'm member of both fedora and ojuba but fedora shouln't make it difficult for us by design, it should give us the choice. > That said, if there are clearly identifiable class of programs that may > be deemed offensive by a large set of people (and *not* governments), > then it would be sensible to mark them so that people can consciously > and *individually* decide to (not) install/remove them or use spins that > explicitly exclude/include them. +1 exactly, I did not ask fedora to remove or ban those things, I asked them to make it easy for us to choose I wrote a proposal https://fedoraproject.org/wiki/PackagingDrafts/InappropriateContents please help me make the proposal better before submitting it to https://fedoraproject.org/wiki/PackagingDrafts From opensource at till.name Fri May 29 13:30:06 2009 From: opensource at till.name (Till Maas) Date: Fri, 29 May 2009 15:30:06 +0200 Subject: Plans for tomorrow's (20090529) FESCo meeting In-Reply-To: References: <200905291501.35665.opensource@till.name> Message-ID: <200905291530.13386.opensource@till.name> On Fri May 29 2009, Matej Cepl wrote: > Till Maas, Fri, 29 May 2009 15:01:29 +0200: > > It seems more to me, that the Feature owner does not care, because the > > package is very incomplete and I got no response from my comment in > > December 2008 that Virtualbox won't make it into Fedora. Btw. how does > > the Feature owner delete the page? It seems to me, that this is not > > easily possible using the wiki interface. > > Moreover, it has been included in The Repository Which Shall Not Be Named. Yes, maybe I should have mentioned this, too. It allows to complete the feature shortly after FESCo accepts it, because the packages only need to be imported. Iirc the people involved are already Fedora packagers and therefore the review is also already kind of done. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From kevin.kofler at chello.at Fri May 29 13:30:29 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 29 May 2009 15:30:29 +0200 Subject: Plans for tomorrow's (20090529) FESCo meeting References: <200905291033.20518.opensource@till.name> <20090529113607.GD3095@hansolo.jdub.homelinux.org> <200905291501.35665.opensource@till.name> Message-ID: Matej Cepl wrote: > Moreover, it has been included in The Repository Which Shall Not Be Named. You mean we should not name RPM Fusion? Or link to http://rpmfusion.org/ ? Well, maybe I'll make an effort not to name RPM Fusion. But then again, I think I actually won't make an effort not to name RPM Fusion, because the content in RPM Fusion is not illegal around here. Oops, how many times did RPM Fusion appear in this paragraph? ;-) Kevin Kofler From rawhide at fedoraproject.org Fri May 29 13:37:24 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Fri, 29 May 2009 13:37:24 +0000 (UTC) Subject: rawhide report: 20090529 changes Message-ID: <20090529133724.F0FA71F821C@releng2.fedora.phx.redhat.com> Compose started at Fri May 29 06:15:04 UTC 2009 Updated Packages: anaconda-11.5.0.57-1.fc11 ------------------------- * Thu May 28 2009 Chris Lumens - 11.5.0.57-1 - Create and use unique ids for Device instances. (#500808) (dlehman) - Adjust remaining PartitionDevices' names after removing a partition. (dlehman) xorg-x11-drv-intel-2.7.0-7.fc11 ------------------------------- * Thu May 28 2009 - 2.7.0-7 - Add intel-2.7-dont-vsync-xv.patch to disable Xv vsync, fixes hw lockup for full screen Xv (#499895) Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 2 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From jwboyer at gmail.com Fri May 29 13:44:25 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 29 May 2009 09:44:25 -0400 Subject: Plans for tomorrow's (20090529) FESCo meeting In-Reply-To: <200905291501.35665.opensource@till.name> References: <200905291033.20518.opensource@till.name> <20090529113607.GD3095@hansolo.jdub.homelinux.org> <200905291501.35665.opensource@till.name> Message-ID: <20090529134425.GF3095@hansolo.jdub.homelinux.org> On Fri, May 29, 2009 at 03:01:29PM +0200, Till Maas wrote: >On Fri May 29 2009, Josh Boyer wrote: > >> I don't see a problem. > >Imho outdated content reduces the quality of the wiki, therefore there should >be some garbage collection. > >> If the Feature owner cares enough to keep proposing it, then FESCo will >> keep reviewing it. Technical items change over time. Perhaps the >> VirtualBox module will make it into the upstream kernel and the Feature >> will be viable. Or perhaps a future FESCo will revist kmods. > >Did you look at the content of the feature page? Even in the very unlikely Yes, I did. >case that it may be included in Fedora in the future, Fedora will probably be >the last distribution to include it, so it is also very unlikely that it even >meats the Feature criteria. And if it does, there are only four sentences in >the Feature page, that were not in the template. Yep. >> If the Feature owner doesn't care, then they can delete the page. Either >> way, I don't see what the problem is with having it sit in the >> FeaturePageIncomplete category. > >It seems more to me, that the Feature owner does not care, because the package >is very incomplete and I got no response from my comment in December 2008 that >Virtualbox won't make it into Fedora. Btw. how does the Feature owner delete That seems to be a simple case of a page requiring wiki gardening. Seriously, if we have to have a FESCo policy to allow the deletion of stale wiki pages (Feature or not), then we have gone wrong somewhere. So I suggest we just mark it for deletion and if the Feature owner cares he'll unmark it. >the page? It seems to me, that this is not easily possible using the wiki >interface. https://fedoraproject.org/wiki/Help:Editing#Deleting_Pages josh From kevin.kofler at chello.at Fri May 29 13:33:37 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 29 May 2009 15:33:37 +0200 Subject: Plans for tomorrow's (20090529) FESCo meeting References: <200905291033.20518.opensource@till.name> <20090529113607.GD3095@hansolo.jdub.homelinux.org> Message-ID: Josh Boyer wrote: > Or perhaps a future FESCo will revist kmods. FWIW, I'd certainly vote for a proposal to allow kmods if I get into FESCo and may even bring such a proposal in front of the new FESCo (though IMHO it should not be the old regime with explicit FESCo approval for each, that didn't make any sense, instead there should be no restrictions other than a license compatible with that of the kernel, and of course the restrictions applying to all packages). Kevin Kofler From skvidal at fedoraproject.org Fri May 29 13:54:43 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Fri, 29 May 2009 09:54:43 -0400 (EDT) Subject: Plans for tomorrow's (20090529) FESCo meeting In-Reply-To: References: <200905291033.20518.opensource@till.name> <20090529113607.GD3095@hansolo.jdub.homelinux.org> Message-ID: On Fri, 29 May 2009, Kevin Kofler wrote: > Josh Boyer wrote: >> Or perhaps a future FESCo will revist kmods. > > FWIW, I'd certainly vote for a proposal to allow kmods if I get into FESCo > and may even bring such a proposal in front of the new FESCo (though IMHO > it should not be the old regime with explicit FESCo approval for each, that > didn't make any sense, instead there should be no restrictions other than a > license compatible with that of the kernel, and of course the restrictions > applying to all packages). and if I get elected to fesco I'll make sure to counter any vote for kmods with a vote against them. kmods are a disaster area and proof of this can be found in the near constant stream of "bugs" related to people's systems broken by them in terms of depsolving for them. -sv From ffesti at redhat.com Fri May 29 14:00:10 2009 From: ffesti at redhat.com (Florian Festi) Date: Fri, 29 May 2009 16:00:10 +0200 Subject: gnaughty is a hot babe In-Reply-To: References: <4A1E5CC4.2060506@fedoraproject.org> <4A1FC758.5070803@nicubunu.ro> <50baabb30905290440l1490d87dg2c21f2226604cdb1@mail.gmail.com> <200905291351.52188.jreznik@redhat.com> <50baabb30905290502g3550624l3e1e5fe860712be5@mail.gmail.com> <4A1FD576.5060900@redhat.com> Message-ID: <4A1FEA6A.3090402@redhat.com> inode0 wrote: > On Fri, May 29, 2009 at 7:51 AM, Kushal Das wrote: >> On Fri, May 29, 2009 at 6:16 PM, inode0 wrote: >>> True. Someone should ask the question: does it make sense to have >>> different rules if they prevent the inclusion of useful content and >>> allow the inclusion of useless code? >> Which is useless to me can be very useful to someone else. > > That doesn't explain why there is a different standard for content. It is ok if you know and obey the rules. There is no need for you to understand why they are in place. Anyway, Fedora is a Linux distribution (for those who did not yet realize) an though (free) Linux software (that can be run on Fedora) is what it is all about and content is not (with very few exceptions). Software yes - content no. I really see no way or reason why there should be a common standard for both. Florian From fedora at matbooth.co.uk Fri May 29 14:04:42 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Fri, 29 May 2009 15:04:42 +0100 Subject: Packaging Survey - May 2009 In-Reply-To: <4A1D24AC.4090802@fedoraproject.org> References: <4A1D24AC.4090802@fedoraproject.org> Message-ID: <9497e9990905290704s6a531dc5i772d52601399973e@mail.gmail.com> On Wed, May 27, 2009 at 12:31 PM, Rahul Sundaram wrote: > Hi > > I did a quick survey from Fedora on what software Fedora users are using > that is not available in the repo. Here are the results. If you find > anything interesting, feel free to pick it up. > > https://fedoraproject.org/wiki/Packaging_Survey_May_2009 > > Rahul > Hi, I don't think JEP should be on that list. I've used it in few commercial products and its a thousand dollars a pop for a source code licence: http://www.singularsys.com/order/ Regards, Mat -- Mat Booth www.matbooth.co.uk From mcepl at redhat.com Fri May 29 14:08:13 2009 From: mcepl at redhat.com (Matej Cepl) Date: Fri, 29 May 2009 14:08:13 +0000 (UTC) Subject: Plans for tomorrow's (20090529) FESCo meeting References: <200905291033.20518.opensource@till.name> <20090529113607.GD3095@hansolo.jdub.homelinux.org> <200905291501.35665.opensource@till.name> Message-ID: Kevin Kofler, Fri, 29 May 2009 15:30:29 +0200: > You mean we should not name RPM Fusion? You can. I probably can as well too (I haven't checked lately), but it is just such fun not to name it. :) Mat?j From mfleming at thatfleminggent.com Fri May 29 14:15:49 2009 From: mfleming at thatfleminggent.com (Michael Fleming) Date: Sat, 30 May 2009 00:15:49 +1000 Subject: gnaughty is a hot babe In-Reply-To: References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <20090529092040.GA29375@redhat.com> Message-ID: <20090530001549.312d4958@defender> On Fri, 29 May 2009 14:23:01 +0200 Kevin Kofler wrote: > Daniel P. Berrange wrote: > > IMHO it is not Fedora's job to define family values & moralities. > > Such morals/values will vary all around the world, such that no > > single list Fedora makes would be satisfactory. If a derived spin > > wants to define a set of morals & values then the burden should be > > on them to maintain the list of packages that don't comply, not > > Fedora. > > +1 > > Kevin Kofler > +10. Every culture - or even individual's - moral compass varies from others, even slightly. Trying to define morality for a large non-homogenous group is almost certainly going to upset a significant proportion of that group that don't agree with the definition, often with undesirable results - "it'll all end in tears" would be an appropriate English idiom; IOW doomed - just ask my (Australian) Communications Minister :-). If you're going to maintain a spin for a like-minded community (like ojuba.org is) then the onus is on those maintainers to decide on and cull those packages that they deem inappropriate from their compose. For Fedora to do so would be outside our collective bailiwick (IMHO) and as Kevin correctly notes no single list would please everyone all of the time - I know some folks who may object to gnome-sword for example. Michael. -- Michael Fleming - (EMail/XMPP/Jabber) WWW: http://www.thatfleminggent.com Fedora / Red Hat Packages: http://www.thatfleminggent.com/rpm-packages Twitter: http://twitter.com/thatfleminggent From rc040203 at freenet.de Fri May 29 14:16:19 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 29 May 2009 16:16:19 +0200 Subject: gnaughty is a hot babe In-Reply-To: <4A1FEA6A.3090402@redhat.com> References: <4A1E5CC4.2060506@fedoraproject.org> <4A1FC758.5070803@nicubunu.ro> <50baabb30905290440l1490d87dg2c21f2226604cdb1@mail.gmail.com> <200905291351.52188.jreznik@redhat.com> <50baabb30905290502g3550624l3e1e5fe860712be5@mail.gmail.com> <4A1FD576.5060900@redhat.com> <4A1FEA6A.3090402@redhat.com> Message-ID: <4A1FEE33.8050008@freenet.de> Florian Festi wrote: > inode0 wrote: >> On Fri, May 29, 2009 at 7:51 AM, Kushal Das wrote: >>> On Fri, May 29, 2009 at 6:16 PM, inode0 wrote: >>>> True. Someone should ask the question: does it make sense to have >>>> different rules if they prevent the inclusion of useful content and >>>> allow the inclusion of useless code? >>> Which is useless to me can be very useful to someone else. >> >> That doesn't explain why there is a different standard for content. > > It is ok if you know and obey the rules. There is no need for you to > understand why they are in place. Anyway, Fedora is a Linux distribution > (for those who did not yet realize) an though (free) Linux software > (that can be run on Fedora) is what it is all about and content is not > (with very few exceptions). Software yes - content no. That's essentially the reason why things are as they are. Another (slightly related) reason is to prevent Fedora from being abused as medium for "content distribution". Think about people packaging up "books", "music", "movies" or other media files into rpms and to push them into the Fedora repos. Apart from the bandwidth and diskspace this would require, this would not be much of a technical problem, but it would have a significant impact elsewhere ("legality", "morality" etc. of contents) That said, there is a "gray zone" between "contents" and "software", which need to be decided on a case by case basis. In Fedora's history, emulators, cross toolchains's target libs and game data have been such cases, other cases would be "Free Linux books/movies". > I really see no > way or reason why there should be a common standard for both. Exactly. I'd go one step further: It doesn't make sense. Ralf From inode0 at gmail.com Fri May 29 14:26:47 2009 From: inode0 at gmail.com (inode0) Date: Fri, 29 May 2009 09:26:47 -0500 Subject: gnaughty is a hot babe In-Reply-To: <4A1FEA6A.3090402@redhat.com> References: <4A1E5CC4.2060506@fedoraproject.org> <4A1FC758.5070803@nicubunu.ro> <50baabb30905290440l1490d87dg2c21f2226604cdb1@mail.gmail.com> <200905291351.52188.jreznik@redhat.com> <50baabb30905290502g3550624l3e1e5fe860712be5@mail.gmail.com> <4A1FD576.5060900@redhat.com> <4A1FEA6A.3090402@redhat.com> Message-ID: On Fri, May 29, 2009 at 9:00 AM, Florian Festi wrote: > inode0 wrote: >> >> On Fri, May 29, 2009 at 7:51 AM, Kushal Das wrote: >>> >>> On Fri, May 29, 2009 at 6:16 PM, inode0 wrote: >>>> >>>> True. Someone should ask the question: does it make sense to have >>>> different rules if they prevent the inclusion of useful content and >>>> allow the inclusion of useless code? >>> >>> Which is useless to me can be very useful to someone else. >> >> That doesn't explain why there is a different standard for content. > > It is ok if you know and obey the rules. There is no need for you to > understand why they are in place. Anyway, Fedora is a Linux distribution > (for those who did not yet realize) an though (free) Linux software (that > can be run on Fedora) is what it is all about and content is not (with very > few exceptions). Software yes - content no. I really see no way or reason > why there should be a common standard for both. "To lead the advancement of free and open source software and content as a collaborative community." That is the mission statement of what project? John From dennisml at conversis.de Fri May 29 14:28:38 2009 From: dennisml at conversis.de (Dennis J.) Date: Fri, 29 May 2009 16:28:38 +0200 Subject: gnaughty is a hot babe In-Reply-To: <385866f0905290627vcd933a9r98d75cc6f3581ae8@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <20090529092040.GA29375@redhat.com> <385866f0905290230n1170470cq31dc26c6dda35b6d@mail.gmail.com> <4A1FAD0D.4030608@fedoraproject.org> <20090529131959.GB3587@mcpierce-laptop.rdu.redhat.com> <385866f0905290627vcd933a9r98d75cc6f3581ae8@mail.gmail.com> Message-ID: <4A1FF116.2030303@conversis.de> On 05/29/2009 03:27 PM, Muayyad AlSadi wrote: >> Where do you anything about "family values and moralities" in Fedora's mission statement? I see statements about software being free to use, > > that's why I said us [in ojuba.org] as I'm member of both fedora and ojuba > > but fedora shouln't make it difficult for us by design, it should give > us the choice. > >> That said, if there are clearly identifiable class of programs that may >> be deemed offensive by a large set of people (and *not* governments), >> then it would be sensible to mark them so that people can consciously >> and *individually* decide to (not) install/remove them or use spins that >> explicitly exclude/include them. > +1 > > exactly, I did not ask fedora to remove or ban those things, I asked > them to make it easy for us to choose > > I wrote a proposal > https://fedoraproject.org/wiki/PackagingDrafts/InappropriateContents I don't think you can just flag Packages as inappropriate because everyone has his own definition for that term. If you really want to make this work you'll have to create specific classifications like "nudity" or "violence" so people can make informed decisions. People might be ok with violent content but not nudity. When I see a Package marked only as "inappropriate" that doesn't help me to tell whether *I* would find that inappropriate or not. Regards, Dennis From alsadi at gmail.com Fri May 29 14:31:10 2009 From: alsadi at gmail.com (Muayyad AlSadi) Date: Fri, 29 May 2009 17:31:10 +0300 Subject: gnaughty is a hot babe In-Reply-To: <4A1FEE33.8050008@freenet.de> References: <4A1E5CC4.2060506@fedoraproject.org> <50baabb30905290440l1490d87dg2c21f2226604cdb1@mail.gmail.com> <200905291351.52188.jreznik@redhat.com> <50baabb30905290502g3550624l3e1e5fe860712be5@mail.gmail.com> <4A1FD576.5060900@redhat.com> <4A1FEA6A.3090402@redhat.com> <4A1FEE33.8050008@freenet.de> Message-ID: <385866f0905290731g5a141ca1mf764d0c4839eecd2@mail.gmail.com> > If you're going to maintain a spin for a like-minded community (like ojuba.org is) have you took a look to the proposal ? < https://fedoraproject.org/wiki/PackagingDrafts/InappropriateContents where does it mention anything about the alike-minded community of fanatic government censorship agents in ojuba.org ? our spin in ojuba.org is a fedora based linux distribution, slightly modified to include patches which are essential for our users but those patches where not accepted by the upstream and/or fedora and there are no other functional alternative for that patch (for example the bidi support in wine), we don't work for any government nor do we like to impose family values on fedora. we already have modified packages like -logos and -release-notes ..etc. just as required by fedora trademark guidelines and we have no problem adding exclude to .repo files but give us a technical way to identify what does each package contain. please read the proposal before you offend us again. From notting at redhat.com Fri May 29 14:34:12 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 29 May 2009 10:34:12 -0400 Subject: gnaughty is a hot babe In-Reply-To: <4A1FF116.2030303@conversis.de> References: <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <20090529092040.GA29375@redhat.com> <385866f0905290230n1170470cq31dc26c6dda35b6d@mail.gmail.com> <4A1FAD0D.4030608@fedoraproject.org> <20090529131959.GB3587@mcpierce-laptop.rdu.redhat.com> <385866f0905290627vcd933a9r98d75cc6f3581ae8@mail.gmail.com> <4A1FF116.2030303@conversis.de> Message-ID: <20090529143412.GA29443@nostromo.devel.redhat.com> Dennis J. (dennisml at conversis.de) said: >> I wrote a proposal >> https://fedoraproject.org/wiki/PackagingDrafts/InappropriateContents > > I don't think you can just flag Packages as inappropriate because > everyone has his own definition for that term. If you really want to make > this work you'll have to create specific classifications like "nudity" or > "violence" so people can make informed decisions. People might be ok with > violent content but not nudity. When I see a Package marked only as > "inappropriate" that doesn't help me to tell whether *I* would find that > inappropriate or not. At which point, you need some sort of review board, where then every package gets something like: - TuxPaint is rated E for Everyone - quake3 is rated T for violent content - tcl is rated M for inappropriate language I'm going to go out on a limb and claim we don't have the resources to coherently do this. Bill From pm at datasphere.ch Fri May 29 14:38:20 2009 From: pm at datasphere.ch (Patrick MONNERAT) Date: Fri, 29 May 2009 16:38:20 +0200 Subject: Swapping reviews Message-ID: <1243607900.27826.1.camel@linuxdev.datasphere.ch> Hello list, Package WebCalendar (https://bugzilla.redhat.com/show_bug.cgi?id=471231) is awaiting review for 5 month already. I will be glad to review another package in counterpart of this one's review. Thanks in advance. Patrick From bochecha at fedoraproject.org Fri May 29 14:39:51 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Fri, 29 May 2009 16:39:51 +0200 Subject: gnaughty is a hot babe In-Reply-To: <385866f0905290731g5a141ca1mf764d0c4839eecd2@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <200905291351.52188.jreznik@redhat.com> <50baabb30905290502g3550624l3e1e5fe860712be5@mail.gmail.com> <4A1FD576.5060900@redhat.com> <4A1FEA6A.3090402@redhat.com> <4A1FEE33.8050008@freenet.de> <385866f0905290731g5a141ca1mf764d0c4839eecd2@mail.gmail.com> Message-ID: <2d319b780905290739k3b2f22efwa1b1e503777320d2@mail.gmail.com> >> If you're going to maintain a spin for a like-minded community (like > ojuba.org is) > > have you took a look to the proposal ? < > https://fedoraproject.org/wiki/PackagingDrafts/InappropriateContents > where does it mention anything about the alike-minded community of > fanatic government censorship agents in ojuba.org ? I think what he meant was a community who think alike, i.e. who have the same moral values (which seems to be the case for ojuba.org), not judging the righteousness of those values. ---------- Mathieu Bridon (bochecha) From david at gnsa.us Fri May 29 14:40:50 2009 From: david at gnsa.us (David Nalley) Date: Fri, 29 May 2009 10:40:50 -0400 Subject: Swapping reviews In-Reply-To: <1243607900.27826.1.camel@linuxdev.datasphere.ch> References: <1243607900.27826.1.camel@linuxdev.datasphere.ch> Message-ID: On Fri, May 29, 2009 at 10:38 AM, Patrick MONNERAT wrote: > > Hello list, > ? ? ? ?Package WebCalendar (https://bugzilla.redhat.com/show_bug.cgi?id=471231) is awaiting review for 5 month already. > > I will be glad to review another package in counterpart of this one's review. > Thanks in advance. > > Patrick > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I'll grab it This may be something the folks in infra want to look at for the calendaring solution. From alsadi at gmail.com Fri May 29 14:40:23 2009 From: alsadi at gmail.com (Muayyad AlSadi) Date: Fri, 29 May 2009 17:40:23 +0300 Subject: gnaughty is a hot babe In-Reply-To: <4A1FF116.2030303@conversis.de> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <20090529092040.GA29375@redhat.com> <385866f0905290230n1170470cq31dc26c6dda35b6d@mail.gmail.com> <4A1FAD0D.4030608@fedoraproject.org> <20090529131959.GB3587@mcpierce-laptop.rdu.redhat.com> <385866f0905290627vcd933a9r98d75cc6f3581ae8@mail.gmail.com> <4A1FF116.2030303@conversis.de> Message-ID: <385866f0905290740y525b3d8el89194c4340fbc78b@mail.gmail.com> > I don't think you can just flag Packages as inappropriate because everyone > has his own definition for that term. If you really want to make this work > you'll have to create specific classifications like "nudity" or "violence" > so people can make informed decisions. People might be ok with violent > content but not nudity. When I see a Package marked only as "inappropriate" > that doesn't help me to tell whether *I* would find that inappropriate or > not. > we can use "might be" just like "be polite someone's grandma could be here" and we can list when and why and to whom in the proposal I used the classification used by the upstream if any and I guess all of packages will fall under this. if the upstream says that his package is inappropriate then its worth listing and I guess this is the fedora way. and if the maintainer or reviewer won't show those to his little daughter then it worth being listed I don't demand more than that. BTW: we have specific definitions for those terms but as I said I don't want to impose our definitions and values into fedora, our standards are so high that if something is bad according to any definition then it's bad for us :-) no I mean inspecting a list of tens of packages would be much simpler than inspecting all the tens of thousands of packages From rjones at redhat.com Fri May 29 14:49:20 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 29 May 2009 15:49:20 +0100 Subject: Plans for tomorrow's (20090529) FESCo meeting In-Reply-To: References: <200905291033.20518.opensource@till.name> <20090529113607.GD3095@hansolo.jdub.homelinux.org> Message-ID: <20090529144920.GA31662@thinkpad.fab.redhat.com> On Fri, May 29, 2009 at 03:33:37PM +0200, Kevin Kofler wrote: > Josh Boyer wrote: > > Or perhaps a future FESCo will revist kmods. > > FWIW, I'd certainly vote for a proposal to allow kmods if I get into FESCo > and may even bring such a proposal in front of the new FESCo (though IMHO > it should not be the old regime with explicit FESCo approval for each, that > didn't make any sense, instead there should be no restrictions other than a > license compatible with that of the kernel, and of course the restrictions > applying to all packages). Could someone dispassionately summarise the reasons why kmods were rejected in the first place? I assume the reason was the overhead of maintaining and updating out-of-tree kernel patches? Rich. From ssorce at redhat.com Fri May 29 14:49:21 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 29 May 2009 10:49:21 -0400 Subject: gnaughty is a hot babe In-Reply-To: <4A1FF116.2030303@conversis.de> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <20090529092040.GA29375@redhat.com> <385866f0905290230n1170470cq31dc26c6dda35b6d@mail.gmail.com> <4A1FAD0D.4030608@fedoraproject.org> <20090529131959.GB3587@mcpierce-laptop.rdu.redhat.com> <385866f0905290627vcd933a9r98d75cc6f3581ae8@mail.gmail.com> <4A1FF116.2030303@conversis.de> Message-ID: <1243608561.7279.178.camel@localhost.localdomain> On Fri, 2009-05-29 at 16:28 +0200, Dennis J. wrote: > On 05/29/2009 03:27 PM, Muayyad AlSadi wrote: > >> Where do you anything about "family values and moralities" in Fedora's mission statement? I see statements about software being free to use, > > > > that's why I said us [in ojuba.org] as I'm member of both fedora and ojuba > > > > but fedora shouln't make it difficult for us by design, it should give > > us the choice. > > > >> That said, if there are clearly identifiable class of programs that may > >> be deemed offensive by a large set of people (and *not* governments), > >> then it would be sensible to mark them so that people can consciously > >> and *individually* decide to (not) install/remove them or use spins that > >> explicitly exclude/include them. > > +1 > > > > exactly, I did not ask fedora to remove or ban those things, I asked > > them to make it easy for us to choose > > > > I wrote a proposal > > https://fedoraproject.org/wiki/PackagingDrafts/InappropriateContents > > I don't think you can just flag Packages as inappropriate because everyone > has his own definition for that term. If you really want to make this work > you'll have to create specific classifications like "nudity" or "violence" > so people can make informed decisions. People might be ok with violent > content but not nudity. When I see a Package marked only as "inappropriate" > that doesn't help me to tell whether *I* would find that inappropriate or not. > Oh what a delightful slippery slope ... I'll give you a few examples: in some places a topless is considered totally unacceptable nudity, in others not so much, what definition do you use (there are subtler shades of course) ? In some places a game with people firing at other people with red blood coming out and all is considered strongly violent, but firing at aliens with abstract shapes that have green blood not so much, for others firing at anything is considered violent, what definition do you use ? For some people some language may be considered inappropriate for ""children"" of age 16, for others a 16 is not a child but simply a youth already capable of judging use of language, what do you choose ? For some cultures eating a specific animal is considered an obscenity while for others it is a perfectly normal daily occurrence, do you choose to tag such content ? Simo. -- Simo Sorce * Red Hat, Inc * New York From pm at datasphere.ch Fri May 29 14:51:16 2009 From: pm at datasphere.ch (Patrick MONNERAT) Date: Fri, 29 May 2009 16:51:16 +0200 Subject: Swapping reviews In-Reply-To: References: <1243607900.27826.1.camel@linuxdev.datasphere.ch> Message-ID: <1243608676.27826.5.camel@linuxdev.datasphere.ch> On Fri, 2009-05-29 at 10:40 -0400, David Nalley wrote: > > Package WebCalendar (https://bugzilla.redhat.com/show_bug.cgi?id=471231) is awaiting review for 5 month already. > I'll grab it Many thanks, David. I do not find any pending new review request from you just now, but if you have some, please feel free to ask for. Regards, Patrick From notting at redhat.com Fri May 29 14:53:54 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 29 May 2009 10:53:54 -0400 Subject: Plans for tomorrow's (20090529) FESCo meeting In-Reply-To: <20090529144920.GA31662@thinkpad.fab.redhat.com> References: <200905291033.20518.opensource@till.name> <20090529113607.GD3095@hansolo.jdub.homelinux.org> <20090529144920.GA31662@thinkpad.fab.redhat.com> Message-ID: <20090529145354.GA30106@nostromo.devel.redhat.com> Richard W.M. Jones (rjones at redhat.com) said: > > FWIW, I'd certainly vote for a proposal to allow kmods if I get into FESCo > > and may even bring such a proposal in front of the new FESCo (though IMHO > > it should not be the old regime with explicit FESCo approval for each, that > > didn't make any sense, instead there should be no restrictions other than a > > license compatible with that of the kernel, and of course the restrictions > > applying to all packages). > > Could someone dispassionately summarise the reasons why kmods were > rejected in the first place? I assume the reason was the overhead of > maintaining and updating out-of-tree kernel patches? - Overhead of maintenance and updating - Real-life experience of the existing kmod packages at the time *never* being up to date with the kernel - As part of 'staying close to upstream', kmods... aren't - It provides a crappy user experience with users, where they'll be stuck unable to upgrade, or boot, or use whatever functionality, until the maintainer is able to fix any issues with their kmod (as they will break with kernel changes) - Increased maintenance for the kernel team, which they don't want (similar to the compat package policy) - If a driver is headed upstream, and is needed... just add it to the kernel package proper Bill From drago01 at gmail.com Fri May 29 14:54:16 2009 From: drago01 at gmail.com (drago01) Date: Fri, 29 May 2009 16:54:16 +0200 Subject: Plans for tomorrow's (20090529) FESCo meeting In-Reply-To: <20090529144920.GA31662@thinkpad.fab.redhat.com> References: <200905291033.20518.opensource@till.name> <20090529113607.GD3095@hansolo.jdub.homelinux.org> <20090529144920.GA31662@thinkpad.fab.redhat.com> Message-ID: On Fri, May 29, 2009 at 4:49 PM, Richard W.M. Jones wrote: > On Fri, May 29, 2009 at 03:33:37PM +0200, Kevin Kofler wrote: >> Josh Boyer wrote: >> > Or perhaps a future FESCo will revist kmods. >> >> FWIW, I'd certainly vote for a proposal to allow kmods if I get into FESCo >> and may even bring such a proposal in front of the new FESCo (though IMHO >> it should not be the old regime with explicit FESCo approval for each, that >> didn't make any sense, instead there should be no restrictions other than a >> license compatible with that of the kernel, and of course the restrictions >> applying to all packages). > > Could someone dispassionately summarise the reasons why kmods were > rejected in the first place? ?I assume the reason was the overhead of > maintaining and updating out-of-tree kernel patches? Because they might break on kernel updates, needs to be rebuild everytime and in some cases require patches to work. So we might get in a situation: pushing a kernel update will cause broken deps for users of kmod-foo -> preventing them from installing updates -> security risk. (outdated packages) From a.badger at gmail.com Fri May 29 14:56:46 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 29 May 2009 07:56:46 -0700 Subject: gnaughty is a hot babe In-Reply-To: <385866f0905290210h155da287k145e37d8a76f50d2@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1F998A.9010807@fedoraproject.org> <2d319b780905290151i517bd8b7u832e536645db6eb0@mail.gmail.com> <385866f0905290210h155da287k145e37d8a76f50d2@mail.gmail.com> Message-ID: <4A1FF7AE.1080003@gmail.com> On 05/29/2009 02:10 AM, Muayyad AlSadi wrote: >> The problem with a comps group is that it will lead to having a group >> in graphical installers > > although in ojuba we use ourown comps files, but this is a catastrophe > because they are merged! > I guess there is an option for hidden groups > Have these packages: Provides: policy(adult content) And have a package that's mandatory in your respin that has: Conflicts: policy(adult content) /me taking one of the good ideas from the flag debate. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From skvidal at fedoraproject.org Fri May 29 14:58:25 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Fri, 29 May 2009 10:58:25 -0400 (EDT) Subject: Plans for tomorrow's (20090529) FESCo meeting In-Reply-To: <20090529144920.GA31662@thinkpad.fab.redhat.com> References: <200905291033.20518.opensource@till.name> <20090529113607.GD3095@hansolo.jdub.homelinux.org> <20090529144920.GA31662@thinkpad.fab.redhat.com> Message-ID: On Fri, 29 May 2009, Richard W.M. Jones wrote: > On Fri, May 29, 2009 at 03:33:37PM +0200, Kevin Kofler wrote: >> Josh Boyer wrote: >>> Or perhaps a future FESCo will revist kmods. >> >> FWIW, I'd certainly vote for a proposal to allow kmods if I get into FESCo >> and may even bring such a proposal in front of the new FESCo (though IMHO >> it should not be the old regime with explicit FESCo approval for each, that >> didn't make any sense, instead there should be no restrictions other than a >> license compatible with that of the kernel, and of course the restrictions >> applying to all packages). > > Could someone dispassionately summarise the reasons why kmods were > rejected in the first place? I assume the reason was the overhead of > maintaining and updating out-of-tree kernel patches? > 1. out-of-tree kernel modules should not be encouraged - if it can't be in the upstream kernel then why are we including it in fedora? 2. the behavior for multiply-installed kernels and kernel modules with updates is not-wonderful 3. kernels being released into a repo and the kernel-modules not being caught up plays hell w/proper updates -sv From ssorce at redhat.com Fri May 29 15:01:00 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 29 May 2009 11:01:00 -0400 Subject: gnaughty is a hot babe In-Reply-To: <4A1FF7AE.1080003@gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1F998A.9010807@fedoraproject.org> <2d319b780905290151i517bd8b7u832e536645db6eb0@mail.gmail.com> <385866f0905290210h155da287k145e37d8a76f50d2@mail.gmail.com> <4A1FF7AE.1080003@gmail.com> Message-ID: <1243609260.7279.179.camel@localhost.localdomain> On Fri, 2009-05-29 at 07:56 -0700, Toshio Kuratomi wrote: > On 05/29/2009 02:10 AM, Muayyad AlSadi wrote: > >> The problem with a comps group is that it will lead to having a group > >> in graphical installers > > > > although in ojuba we use ourown comps files, but this is a catastrophe > > because they are merged! > > I guess there is an option for hidden groups > > > > Have these packages: > > Provides: policy(adult content) > > And have a package that's mandatory in your respin that has: > > Conflicts: policy(adult content) > > /me taking one of the good ideas from the flag debate. s/adult content/questionable content/ Simo. -- Simo Sorce * Red Hat, Inc * New York From skvidal at fedoraproject.org Fri May 29 15:02:23 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Fri, 29 May 2009 11:02:23 -0400 (EDT) Subject: gnaughty is a hot babe In-Reply-To: <4A1FF7AE.1080003@gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1F998A.9010807@fedoraproject.org> <2d319b780905290151i517bd8b7u832e536645db6eb0@mail.gmail.com> <385866f0905290210h155da287k145e37d8a76f50d2@mail.gmail.com> <4A1FF7AE.1080003@gmail.com> Message-ID: On Fri, 29 May 2009, Toshio Kuratomi wrote: > On 05/29/2009 02:10 AM, Muayyad AlSadi wrote: >>> The problem with a comps group is that it will lead to having a group >>> in graphical installers >> >> although in ojuba we use ourown comps files, but this is a catastrophe >> because they are merged! >> I guess there is an option for hidden groups >> > > Have these packages: > > Provides: policy(adult content) > > And have a package that's mandatory in your respin that has: > > Conflicts: policy(adult content) > > /me taking one of the good ideas from the flag debate. Except it is obvious that something contains a flag or not. Labeling certain content 'questionable' is going to end up being all over the distro and diluting the value of the tag. Let me put it this way - if we start randomly rating things in a provides tag and gnaughty or hot-babe or pr0n-comfort get labeled this way then I'll make sure I personally add the same tag to: - firefox - yum - sword - gnome-sword -sv From alsadi at gmail.com Fri May 29 15:03:59 2009 From: alsadi at gmail.com (Muayyad AlSadi) Date: Fri, 29 May 2009 18:03:59 +0300 Subject: gnaughty is a hot babe In-Reply-To: <1243608561.7279.178.camel@localhost.localdomain> References: <4A1E5CC4.2060506@fedoraproject.org> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <20090529092040.GA29375@redhat.com> <385866f0905290230n1170470cq31dc26c6dda35b6d@mail.gmail.com> <4A1FAD0D.4030608@fedoraproject.org> <20090529131959.GB3587@mcpierce-laptop.rdu.redhat.com> <385866f0905290627vcd933a9r98d75cc6f3581ae8@mail.gmail.com> <4A1FF116.2030303@conversis.de> <1243608561.7279.178.camel@localhost.localdomain> Message-ID: <385866f0905290803w42e2c99ei340ed8cb41f0ed67@mail.gmail.com> as I said I don't want you to tag them I want you to limit the list for me from more than 10,000 package which increases at arbitrary time to tens of packages on a wiki that I can //watch// (a feature of the wiki) and regarding to your examples provided that they are already accepted in fedora < Have these packages: > Provides: policy(adult content) > ... innovative idea, but this idea needs a definition which a big community like fedora can't put. From berrange at redhat.com Fri May 29 15:06:57 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 29 May 2009 16:06:57 +0100 Subject: gnaughty is a hot babe In-Reply-To: References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1F998A.9010807@fedoraproject.org> <2d319b780905290151i517bd8b7u832e536645db6eb0@mail.gmail.com> <385866f0905290210h155da287k145e37d8a76f50d2@mail.gmail.com> <4A1FF7AE.1080003@gmail.com> Message-ID: <20090529150657.GR29375@redhat.com> On Fri, May 29, 2009 at 11:02:23AM -0400, Seth Vidal wrote: > > > On Fri, 29 May 2009, Toshio Kuratomi wrote: > > >On 05/29/2009 02:10 AM, Muayyad AlSadi wrote: > >>>The problem with a comps group is that it will lead to having a group > >>>in graphical installers > >> > >>although in ojuba we use ourown comps files, but this is a catastrophe > >>because they are merged! > >>I guess there is an option for hidden groups > >> > > > >Have these packages: > > > >Provides: policy(adult content) > > > >And have a package that's mandatory in your respin that has: > > > >Conflicts: policy(adult content) > > > >/me taking one of the good ideas from the flag debate. > > Except it is obvious that something contains a flag or not. > > Labeling certain content 'questionable' is going to end up being all over > the distro and diluting the value of the tag. > > Let me put it this way - if we start randomly rating things in a provides > tag and gnaughty or hot-babe or pr0n-comfort get labeled this way then > I'll make sure I personally add the same tag to: > > - firefox > - yum > - sword > - gnome-sword And every email client, because I'm spammed by countless messages offering adult content every day :-( Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From ssorce at redhat.com Fri May 29 15:07:23 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 29 May 2009 11:07:23 -0400 Subject: gnaughty is a hot babe In-Reply-To: References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1F998A.9010807@fedoraproject.org> <2d319b780905290151i517bd8b7u832e536645db6eb0@mail.gmail.com> <385866f0905290210h155da287k145e37d8a76f50d2@mail.gmail.com> <4A1FF7AE.1080003@gmail.com> Message-ID: <1243609643.7279.183.camel@localhost.localdomain> On Fri, 2009-05-29 at 11:02 -0400, Seth Vidal wrote: > > On Fri, 29 May 2009, Toshio Kuratomi wrote: > > > On 05/29/2009 02:10 AM, Muayyad AlSadi wrote: > >>> The problem with a comps group is that it will lead to having a group > >>> in graphical installers > >> > >> although in ojuba we use ourown comps files, but this is a catastrophe > >> because they are merged! > >> I guess there is an option for hidden groups > >> > > > > Have these packages: > > > > Provides: policy(adult content) > > > > And have a package that's mandatory in your respin that has: > > > > Conflicts: policy(adult content) > > > > /me taking one of the good ideas from the flag debate. > > Except it is obvious that something contains a flag or not. > > Labeling certain content 'questionable' is going to end up being all over > the distro and diluting the value of the tag. > > Let me put it this way - if we start randomly rating things in a provides > tag and gnaughty or hot-babe or pr0n-comfort get labeled this way then > I'll make sure I personally add the same tag to: > > - firefox > - yum > - sword > - gnome-sword yum ? Simo. -- Simo Sorce * Red Hat, Inc * New York From bochecha at fedoraproject.org Fri May 29 15:08:48 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Fri, 29 May 2009 17:08:48 +0200 Subject: gnaughty is a hot babe In-Reply-To: <385866f0905290803w42e2c99ei340ed8cb41f0ed67@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <20090529092040.GA29375@redhat.com> <385866f0905290230n1170470cq31dc26c6dda35b6d@mail.gmail.com> <4A1FAD0D.4030608@fedoraproject.org> <20090529131959.GB3587@mcpierce-laptop.rdu.redhat.com> <385866f0905290627vcd933a9r98d75cc6f3581ae8@mail.gmail.com> <4A1FF116.2030303@conversis.de> <1243608561.7279.178.camel@localhost.localdomain> <385866f0905290803w42e2c99ei340ed8cb41f0ed67@mail.gmail.com> Message-ID: <2d319b780905290808x61001125g7aa94df7bb01e1f4@mail.gmail.com> > it's the job for those who care to check this list and take their own > subset from it according to their own definition. Couldn't it be the job of those who care to maintain this list in the first place ? ---------- Mathieu Bridon (bochecha) From drago01 at gmail.com Fri May 29 15:10:09 2009 From: drago01 at gmail.com (drago01) Date: Fri, 29 May 2009 17:10:09 +0200 Subject: gnaughty is a hot babe In-Reply-To: <1243609643.7279.183.camel@localhost.localdomain> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1F998A.9010807@fedoraproject.org> <2d319b780905290151i517bd8b7u832e536645db6eb0@mail.gmail.com> <385866f0905290210h155da287k145e37d8a76f50d2@mail.gmail.com> <4A1FF7AE.1080003@gmail.com> <1243609643.7279.183.camel@localhost.localdomain> Message-ID: On Fri, May 29, 2009 at 5:07 PM, Simo Sorce wrote: > On Fri, 2009-05-29 at 11:02 -0400, Seth Vidal wrote: >> >> On Fri, 29 May 2009, Toshio Kuratomi wrote: >> >> > On 05/29/2009 02:10 AM, Muayyad AlSadi wrote: >> >>> The problem with a comps group is that it will lead to having a group >> >>> in graphical installers >> >> >> >> although in ojuba we use ourown comps files, but this is a catastrophe >> >> because they are merged! >> >> I guess there is an option for hidden groups >> >> >> > >> > Have these packages: >> > >> > Provides: policy(adult content) >> > >> > And have a package that's mandatory in your respin that has: >> > >> > Conflicts: policy(adult content) >> > >> > /me taking one of the good ideas from the flag debate. >> >> Except it is obvious that something contains a flag or not. >> >> Labeling certain content 'questionable' is going to end up being all over >> the distro and diluting the value of the tag. >> >> Let me put it this way - if we start randomly rating things in a provides >> tag and gnaughty or hot-babe or pr0n-comfort get labeled this way then >> I'll make sure I personally add the same tag to: >> >> - firefox >> - yum >> - sword >> - gnome-sword > > yum ? it can be used to download/install packages with such content. From dr.diesel at gmail.com Fri May 29 15:11:20 2009 From: dr.diesel at gmail.com (Dr. Diesel) Date: Fri, 29 May 2009 10:11:20 -0500 Subject: gnaughty is a hot babe In-Reply-To: <2d319b780905290808x61001125g7aa94df7bb01e1f4@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <20090529092040.GA29375@redhat.com> <385866f0905290230n1170470cq31dc26c6dda35b6d@mail.gmail.com> <4A1FAD0D.4030608@fedoraproject.org> <20090529131959.GB3587@mcpierce-laptop.rdu.redhat.com> <385866f0905290627vcd933a9r98d75cc6f3581ae8@mail.gmail.com> <4A1FF116.2030303@conversis.de> <1243608561.7279.178.camel@localhost.localdomain> <385866f0905290803w42e2c99ei340ed8cb41f0ed67@mail.gmail.com> <2d319b780905290808x61001125g7aa94df7bb01e1f4@mail.gmail.com> Message-ID: <2a28d2ab0905290811l736dd37dq37ee1735c4dc2dea@mail.gmail.com> On Fri, May 29, 2009 at 10:08 AM, Mathieu Bridon (bochecha) < bochecha at fedoraproject.org> wrote: > > it's the job for those who care to check this list and take their own > > subset from it according to their own definition. > > Couldn't it be the job of those who care to maintain this list in the > first place ? > But caring is relative? This decision MUST be your own... > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.badger at gmail.com Fri May 29 15:11:18 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 29 May 2009 08:11:18 -0700 Subject: gnaughty is a hot babe In-Reply-To: References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1F998A.9010807@fedoraproject.org> <2d319b780905290151i517bd8b7u832e536645db6eb0@mail.gmail.com> <385866f0905290210h155da287k145e37d8a76f50d2@mail.gmail.com> <4A1FF7AE.1080003@gmail.com> Message-ID: <4A1FFB16.2090607@gmail.com> On 05/29/2009 08:02 AM, Seth Vidal wrote: > > > On Fri, 29 May 2009, Toshio Kuratomi wrote: > >> On 05/29/2009 02:10 AM, Muayyad AlSadi wrote: >>>> The problem with a comps group is that it will lead to having a group >>>> in graphical installers >>> >>> although in ojuba we use ourown comps files, but this is a catastrophe >>> because they are merged! >>> I guess there is an option for hidden groups >>> >> >> Have these packages: >> >> Provides: policy(adult content) >> >> And have a package that's mandatory in your respin that has: >> >> Conflicts: policy(adult content) >> >> /me taking one of the good ideas from the flag debate. > > Except it is obvious that something contains a flag or not. > > Labeling certain content 'questionable' is going to end up being all > over the distro and diluting the value of the tag. > What about policy(shows skin) ? > Let me put it this way - if we start randomly rating things in a > provides tag and gnaughty or hot-babe or pr0n-comfort get labeled this > way then I'll make sure I personally add the same tag to: > > - firefox > - yum > - sword > - gnome-sword > sword and gnome-sword could certainly get policy(religious) firefox could have: policy(the internet is for p0rn) and yum: policy(ad absurdium) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From maxamillion at gmail.com Fri May 29 15:14:15 2009 From: maxamillion at gmail.com (Adam Miller) Date: Fri, 29 May 2009 10:14:15 -0500 Subject: gnaughty is a hot babe In-Reply-To: <2a28d2ab0905290811l736dd37dq37ee1735c4dc2dea@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <385866f0905290230n1170470cq31dc26c6dda35b6d@mail.gmail.com> <4A1FAD0D.4030608@fedoraproject.org> <20090529131959.GB3587@mcpierce-laptop.rdu.redhat.com> <385866f0905290627vcd933a9r98d75cc6f3581ae8@mail.gmail.com> <4A1FF116.2030303@conversis.de> <1243608561.7279.178.camel@localhost.localdomain> <385866f0905290803w42e2c99ei340ed8cb41f0ed67@mail.gmail.com> <2d319b780905290808x61001125g7aa94df7bb01e1f4@mail.gmail.com> <2a28d2ab0905290811l736dd37dq37ee1735c4dc2dea@mail.gmail.com> Message-ID: We had a really long debate about this package in #fedora-devel yesterday and it basically boils down to 1) Need fedora-legal to check the legality of the app not verifying user's age and legality of the URL of the site being in the C source. 2) If fedora-legal say it is legal, then its up to the Board. I don't see the point of spamming the list over this any further. -Adam -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From skvidal at fedoraproject.org Fri May 29 15:15:46 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Fri, 29 May 2009 11:15:46 -0400 (EDT) Subject: gnaughty is a hot babe In-Reply-To: <4A1FFB16.2090607@gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1F998A.9010807@fedoraproject.org> <2d319b780905290151i517bd8b7u832e536645db6eb0@mail.gmail.com> <385866f0905290210h155da287k145e37d8a76f50d2@mail.gmail.com> <4A1FF7AE.1080003@gmail.com> <4A1FFB16.2090607@gmail.com> Message-ID: On Fri, 29 May 2009, Toshio Kuratomi wrote: > What about > policy(shows skin) ? yes b/c skin is clearly the medium of evil. >> Let me put it this way - if we start randomly rating things in a >> provides tag and gnaughty or hot-babe or pr0n-comfort get labeled this >> way then I'll make sure I personally add the same tag to: >> >> - firefox >> - yum >> - sword >> - gnome-sword >> > sword and gnome-sword could certainly get policy(religious) I can think of some more colorful things to label sword and gnome-sword - I'm sure that will be helpful and non-inflammatory :) > firefox could have: policy(the internet is for p0rn) > and yum: policy(ad absurdium) well, let's be clear - python is to blame, too. and hell the name python is suggestive as well. -sv From skvidal at fedoraproject.org Fri May 29 15:17:27 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Fri, 29 May 2009 11:17:27 -0400 (EDT) Subject: gnaughty is a hot babe In-Reply-To: References: <4A1E5CC4.2060506@fedoraproject.org> <385866f0905290230n1170470cq31dc26c6dda35b6d@mail.gmail.com> <4A1FAD0D.4030608@fedoraproject.org> <20090529131959.GB3587@mcpierce-laptop.rdu.redhat.com> <385866f0905290627vcd933a9r98d75cc6f3581ae8@mail.gmail.com> <4A1FF116.2030303@conversis.de> <1243608561.7279.178.camel@localhost.localdomain> <385866f0905290803w42e2c99ei340ed8cb41f0ed67@mail.gmail.com> <2d319b780905290808x61001125g7aa94df7bb01e1f4@mail.gmail.com> <2a28d2ab0905290811l736dd37dq37ee1735c4dc2dea@mail.gmail.com> Message-ID: On Fri, 29 May 2009, Adam Miller wrote: > We had a really long debate about this package in #fedora-devel > yesterday and it basically boils down to > > 1) Need fedora-legal to check the legality of the app not verifying > user's age and legality of the URL of the site being in the C source. http://en.wikipedia.org/wiki/Legal_status_of_Internet_pornography#United_States "On March 22, 2007, COPA was found to violate the First and Fifth Amendments of the United States Constitution and was struck down." In short - there is no valid law requiring age verification. > 2) If fedora-legal say it is legal, then its up to the Board. I don't think we need to send it to legal to determine this. -sv From a.badger at gmail.com Fri May 29 15:19:27 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 29 May 2009 08:19:27 -0700 Subject: gnaughty is a hot babe In-Reply-To: <50baabb30905290424m1a51813ckab95c777de9717d6@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <50baabb30905290401y3f2bef33se5b00040ddce608b@mail.gmail.com> <4A1FC15D.9030003@nicubunu.ro> <50baabb30905290407h352be372tb3a77ae1da0359e1@mail.gmail.com> <50baabb30905290424m1a51813ckab95c777de9717d6@mail.gmail.com> Message-ID: <4A1FFCFF.3080103@gmail.com> On 05/29/2009 04:24 AM, Chitlesh GOORAH wrote: > On Fri, May 29, 2009 at 1:12 PM, Kushal Das wrote: >> Yes that is true , but it does not provide any support to view that >> content, we have many other packages in Fedora which allows to >> download content and they download whatever format the site is >> providing, how the users watch it, it depends on their choice. > > No, it doesn't (not till it is approved) not depend on the user's > choice. My package OVM was blocked by FESCo because there was no > opensource simulator. So if the downloaded videos aren't under an > opensource compatible format, FESCo must rule out its package review. > > I think these are actually very different cases. OVM is content which is useless without code that can deal with it. There is a lack of opensource code to deal with it. Therefore it is useless in our out-of-the-box distribution. What you're arguing about here is that open source code exists whose primary purpose is to download things from the internet. None of that is impacted by whether the content being downloaded can be viewed out of the box or not. Note that I disagree with FESCo's decision on OVM so I'm not necessarily any better at interpreting how FESCo's decision affects other packages than you. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From skvidal at fedoraproject.org Fri May 29 14:59:39 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Fri, 29 May 2009 10:59:39 -0400 (EDT) Subject: Plans for tomorrow's (20090529) FESCo meeting In-Reply-To: References: <200905291033.20518.opensource@till.name> <20090529113607.GD3095@hansolo.jdub.homelinux.org> <20090529144920.GA31662@thinkpad.fab.redhat.com> Message-ID: On Fri, 29 May 2009, drago01 wrote: > > Because they might break on kernel updates, needs to be rebuild > everytime and in some cases require patches to work. > > So we might get in a situation: pushing a kernel update will cause > broken deps for users of kmod-foo -> preventing them from installing > updates -> security risk. (outdated packages) > There is no 'might' about it. it happens. all the time. -sv From drago01 at gmail.com Fri May 29 15:21:30 2009 From: drago01 at gmail.com (drago01) Date: Fri, 29 May 2009 17:21:30 +0200 Subject: gnaughty is a hot babe In-Reply-To: References: <4A1E5CC4.2060506@fedoraproject.org> <20090529131959.GB3587@mcpierce-laptop.rdu.redhat.com> <385866f0905290627vcd933a9r98d75cc6f3581ae8@mail.gmail.com> <4A1FF116.2030303@conversis.de> <1243608561.7279.178.camel@localhost.localdomain> <385866f0905290803w42e2c99ei340ed8cb41f0ed67@mail.gmail.com> <2d319b780905290808x61001125g7aa94df7bb01e1f4@mail.gmail.com> <2a28d2ab0905290811l736dd37dq37ee1735c4dc2dea@mail.gmail.com> Message-ID: On Fri, May 29, 2009 at 5:17 PM, Seth Vidal wrote: > > > On Fri, 29 May 2009, Adam Miller wrote: > >> We had a really long debate about this package in #fedora-devel >> yesterday and it basically boils down to >> >> 1) Need fedora-legal to check the legality of the app not verifying >> user's age and legality of the URL of the site being in the C source. > > http://en.wikipedia.org/wiki/Legal_status_of_Internet_pornography#United_States > > "On March 22, 2007, COPA was found to violate the First and Fifth Amendments > of the United States Constitution and was struck down." > > In short - there is no valid law requiring age verification. In the US .... From jkeating at redhat.com Fri May 29 15:27:40 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 29 May 2009 08:27:40 -0700 Subject: Plans for tomorrow's (20090529) FESCo meeting In-Reply-To: <20090529145354.GA30106@nostromo.devel.redhat.com> References: <200905291033.20518.opensource@till.name> <20090529113607.GD3095@hansolo.jdub.homelinux.org> <20090529144920.GA31662@thinkpad.fab.redhat.com> <20090529145354.GA30106@nostromo.devel.redhat.com> Message-ID: <1243610860.3037.104.camel@localhost.localdomain> On Fri, 2009-05-29 at 10:53 -0400, Bill Nottingham wrote: > - If a driver is headed upstream, and is needed... just add it to the kernel > package proper Not just driver. We said that the kernel team could choose to include any out of tree stuff they deem acceptable, but they would include it in the kernel proper rather than as a nasty kernel module package hack. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From opensource at till.name Fri May 29 15:29:57 2009 From: opensource at till.name (Till Maas) Date: Fri, 29 May 2009 17:29:57 +0200 Subject: add security related packages categorization to comps? Message-ID: <200905291730.08853.opensource@till.name> Hiyas, the Security spin[0] categorizes several security related packages in categories like "Wireless" or "Forensics". It would be useful to have this information also in comps, so one can easier search for e.g. Forensics software available in Fedora. Is it ok if I just add such groups to comps with the specified packages or are there any objections? Btw. is it possible to have a Security group which contains all the subgroups? Regards Till [0] https://fedoraproject.org/wiki/SecuritySpin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mschmidt at redhat.com Fri May 29 15:31:46 2009 From: mschmidt at redhat.com (Michal Schmidt) Date: Fri, 29 May 2009 17:31:46 +0200 Subject: gnaughty is a hot babe In-Reply-To: <385866f0905290803w42e2c99ei340ed8cb41f0ed67@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <20090529092040.GA29375@redhat.com> <385866f0905290230n1170470cq31dc26c6dda35b6d@mail.gmail.com> <4A1FAD0D.4030608@fedoraproject.org> <20090529131959.GB3587@mcpierce-laptop.rdu.redhat.com> <385866f0905290627vcd933a9r98d75cc6f3581ae8@mail.gmail.com> <4A1FF116.2030303@conversis.de> <1243608561.7279.178.camel@localhost.localdomain> <385866f0905290803w42e2c99ei340ed8cb41f0ed67@mail.gmail.com> Message-ID: <20090529173146.043dba2d@brian.englab.brq.redhat.com> On Fri, 29 May 2009 18:03:59 +0300 Muayyad AlSadi wrote: > as I said I don't want you to tag them I want you to limit the list > for me from more than 10,000 package which increases at arbitrary time > to tens of packages on a wiki that I can //watch// (a feature of the > wiki) Deciding whether to put a package on some list is equivalent to tagging. Go ahead, start this wiki page, try to find others who find it important to help you maintain it. What you're asking is that others (who don't care about this issue and can't even realistically know what your exact requirements are) do the work for you. This can not bring satisfactory results. Michal From jkeating at redhat.com Fri May 29 15:37:19 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 29 May 2009 08:37:19 -0700 Subject: gnaughty is a hot babe In-Reply-To: References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1F998A.9010807@fedoraproject.org> <2d319b780905290151i517bd8b7u832e536645db6eb0@mail.gmail.com> <385866f0905290210h155da287k145e37d8a76f50d2@mail.gmail.com> <4A1FF7AE.1080003@gmail.com> Message-ID: <1243611439.3037.107.camel@localhost.localdomain> On Fri, 2009-05-29 at 11:02 -0400, Seth Vidal wrote: > - firefox > - yum These are a bit rediculous and you know it. Neither of these come pre-configured to get to the content. You have to actively seek it out. gnaughty doesn't require that, it's hardwired to get you the content with no effort on your part. > - sword > - gnome-sword -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Fri May 29 15:40:34 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 29 May 2009 08:40:34 -0700 Subject: gnaughty is a hot babe In-Reply-To: References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1F998A.9010807@fedoraproject.org> <2d319b780905290151i517bd8b7u832e536645db6eb0@mail.gmail.com> <385866f0905290210h155da287k145e37d8a76f50d2@mail.gmail.com> <4A1FF7AE.1080003@gmail.com> <4A1FFB16.2090607@gmail.com> Message-ID: <4A2001F2.1090303@gmail.com> On 05/29/2009 08:15 AM, Seth Vidal wrote: > > > On Fri, 29 May 2009, Toshio Kuratomi wrote: > >> What about >> policy(shows skin) ? > > yes b/c skin is clearly the medium of evil. > Of course! skin *shudder*. But you asked for something that could be objectively measured rather than something subject to the whims of the person viewing the content. This attempts to meet that criteria. > >> firefox could have: policy(the internet is for p0rn) >> and yum: policy(ad absurdium) > > well, let's be clear - python is to blame, too. > > and hell the name python is suggestive as well. > So correct! I think we should add: policy(innuendo) to every package. And a few random ones just to keep people on their toes. -Toshio "doesn't get serious about censorship discussions until 9:00 PDT" Kuratomi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From skvidal at fedoraproject.org Fri May 29 15:40:48 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Fri, 29 May 2009 11:40:48 -0400 (EDT) Subject: gnaughty is a hot babe In-Reply-To: <1243611439.3037.107.camel@localhost.localdomain> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1F998A.9010807@fedoraproject.org> <2d319b780905290151i517bd8b7u832e536645db6eb0@mail.gmail.com> <385866f0905290210h155da287k145e37d8a76f50d2@mail.gmail.com> <4A1FF7AE.1080003@gmail.com> <1243611439.3037.107.camel@localhost.localdomain> Message-ID: On Fri, 29 May 2009, Jesse Keating wrote: > On Fri, 2009-05-29 at 11:02 -0400, Seth Vidal wrote: >> - firefox >> - yum > > These are a bit rediculous and you know it. Neither of these come > pre-configured to get to the content. You have to actively seek it out. > gnaughty doesn't require that, it's hardwired to get you the content > with no effort on your part. PK comes preconfigured to download the metadata and ask the user if they want to update pkgs. Some of those pkgs may contain content a user does not want to see. Since yum is at the base of that stack, yum is at fault, right? we're on a silly slope and putting provides tags into certain pkgs is just plain dumb - wanna put a wiki page up - that's fine. polluting provides tags is not a good plan. -sv From kevin.kofler at chello.at Fri May 29 15:45:18 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 29 May 2009 17:45:18 +0200 Subject: Plans for tomorrow's (20090529) FESCo meeting References: <200905291033.20518.opensource@till.name> <20090529113607.GD3095@hansolo.jdub.homelinux.org> <20090529144920.GA31662@thinkpad.fab.redhat.com> Message-ID: drago01 wrote: > So we might get in a situation: pushing a kernel update will cause > broken deps for users of kmod-foo -> preventing them from installing > updates -> security risk. (outdated packages) How does putting those kmods in a third-party repo fix this? And they WILL and DO end up there. Even if you get RPM Fusion to ban kmods (which I doubt will ever happen), they'll just migrate to another third-party repo. You can't eliminate kmods entirely, no matter how hard you try. Having them within Fedora would actually allow syncing the updates to kernel updates by using a Bodhi grouped update, which would make this much less of an issue. Kevin Kofler From skvidal at fedoraproject.org Fri May 29 15:46:23 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Fri, 29 May 2009 11:46:23 -0400 (EDT) Subject: Plans for tomorrow's (20090529) FESCo meeting In-Reply-To: References: <200905291033.20518.opensource@till.name> <20090529113607.GD3095@hansolo.jdub.homelinux.org> <20090529144920.GA31662@thinkpad.fab.redhat.com> Message-ID: On Fri, 29 May 2009, Kevin Kofler wrote: > How does putting those kmods in a third-party repo fix this? And they WILL > and DO end up there. Even if you get RPM Fusion to ban kmods (which I doubt > will ever happen), they'll just migrate to another third-party repo. You > can't eliminate kmods entirely, no matter how hard you try. I don't know about that - let's try harder and see if we can. :) -sv From kevin.kofler at chello.at Fri May 29 15:49:41 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 29 May 2009 17:49:41 +0200 Subject: Plans for tomorrow's (20090529) FESCo meeting References: <200905291033.20518.opensource@till.name> <20090529113607.GD3095@hansolo.jdub.homelinux.org> <20090529144920.GA31662@thinkpad.fab.redhat.com> <20090529145354.GA30106@nostromo.devel.redhat.com> <1243610860.3037.104.camel@localhost.localdomain> Message-ID: Jesse Keating wrote: > Not just driver. We said that the kernel team could choose to include > any out of tree stuff they deem acceptable, but they would include it in > the kernel proper rather than as a nasty kernel module package hack. The problem is that they say "no" almost every time, even to the modules FESCo had previously approved as kmods (em8300, sysprof). They now sit as kmods in RPM Fusion. Kevin Kofler From a.badger at gmail.com Fri May 29 15:49:37 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 29 May 2009 08:49:37 -0700 Subject: gnaughty is a hot babe In-Reply-To: <385866f0905290803w42e2c99ei340ed8cb41f0ed67@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <20090529092040.GA29375@redhat.com> <385866f0905290230n1170470cq31dc26c6dda35b6d@mail.gmail.com> <4A1FAD0D.4030608@fedoraproject.org> <20090529131959.GB3587@mcpierce-laptop.rdu.redhat.com> <385866f0905290627vcd933a9r98d75cc6f3581ae8@mail.gmail.com> <4A1FF116.2030303@conversis.de> <1243608561.7279.178.camel@localhost.localdomain> <385866f0905290803w42e2c99ei340ed8cb41f0ed67@mail.gmail.com> Message-ID: <4A200411.1050303@gmail.com> On 05/29/2009 08:03 AM, Muayyad AlSadi wrote: > as I said I don't want you to tag them I want you to limit the list > for me from more than 10,000 package which increases at arbitrary time > > to tens of packages on a wiki that I can //watch// (a feature of the wiki) > > and regarding to your examples provided that they are already accepted in fedora > < In some places a game with people firing at other people with red blood > coming out and all is considered strongly violent, but firing at aliens > with abstract shapes that have green blood not so much, for others > firing at anything is considered violent, what definition do you use ? > EOQ > > it's not important what is my definition > the important thing is to have a place for those who care to look at > and decide, yes different people will have different definitions so > what ? if a package is placed in that wiki page this does not mean > it's tagged banned or whatever > it means that it might be inappropriate for some poeple > it's the job for those who care to check this list and take their own > subset from it according to their own definition. > Well... If you're going to argue along those lines then I'd also argue that it's up to those who care about restricting the package set to maintain the list. Because having package maintainers identify what might potentially be offensive to people in cultures widely removed from themselves and adding them to a non-binding, out-of-spec file list on the wiki is going to break down on so many levels. If you want better tools to help the people who care about different sorts of offensive content maintain and generate such a list, we have something to talk about. But having "add something to a wiki list" become a Packaging Guideline is something I'll vote against. We're trying to move things like this (for instance, the retired package list) off of the wiki, not add more to it. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From jwboyer at gmail.com Fri May 29 15:53:49 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 29 May 2009 11:53:49 -0400 Subject: Plans for tomorrow's (20090529) FESCo meeting In-Reply-To: References: <200905291033.20518.opensource@till.name> <20090529113607.GD3095@hansolo.jdub.homelinux.org> <20090529144920.GA31662@thinkpad.fab.redhat.com> Message-ID: <20090529155349.GG3095@hansolo.jdub.homelinux.org> On Fri, May 29, 2009 at 05:45:18PM +0200, Kevin Kofler wrote: >drago01 wrote: >> So we might get in a situation: pushing a kernel update will cause >> broken deps for users of kmod-foo -> preventing them from installing >> updates -> security risk. (outdated packages) > >How does putting those kmods in a third-party repo fix this? And they WILL >and DO end up there. Even if you get RPM Fusion to ban kmods (which I doubt >will ever happen), they'll just migrate to another third-party repo. You >can't eliminate kmods entirely, no matter how hard you try. Having them >within Fedora would actually allow syncing the updates to kernel updates by >using a Bodhi grouped update, which would make this much less of an issue. I am respectfully requesting that you start an entirely new mail thread if you really want to continue this discussion. josh From bochecha at fedoraproject.org Fri May 29 15:57:27 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Fri, 29 May 2009 17:57:27 +0200 Subject: Plans for tomorrow's (20090529) FESCo meeting In-Reply-To: References: <200905291033.20518.opensource@till.name> <20090529113607.GD3095@hansolo.jdub.homelinux.org> <20090529144920.GA31662@thinkpad.fab.redhat.com> Message-ID: <2d319b780905290857l33cc68apb4e1acc4beda0a90@mail.gmail.com> >> How does putting those kmods in a third-party repo fix this? And they WILL >> and DO end up there. Even if you get RPM Fusion to ban kmods (which I >> doubt >> will ever happen), they'll just migrate to another third-party repo. You >> can't eliminate kmods entirely, no matter how hard you try. kmod-gspca has been available in livna for a long time. And I loved it, as it provided me an easy way to use my webcam. But at every kernel update, it was a PITA to wait for the kmod until I could update the kernel. If Fedora had accepted the kmod in its repositories, would it have ever been included in mainstream kernel as it is today (which is the only real solution) ? By refusing kmods, we have more motivation to actually try and include upstream what we really need to use. If we can simply install the kmod, who cares if it's upstreamed ? ---------- Mathieu Bridon (bochecha) From jkeating at redhat.com Fri May 29 16:00:20 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 29 May 2009 09:00:20 -0700 Subject: gnaughty is a hot babe In-Reply-To: <20090529115019.GH29375@redhat.com> References: <4A1E5CC4.2060506@fedoraproject.org> <50baabb30905290401y3f2bef33se5b00040ddce608b@mail.gmail.com> <4A1FC15D.9030003@nicubunu.ro> <50baabb30905290407h352be372tb3a77ae1da0359e1@mail.gmail.com> <4A1FC758.5070803@nicubunu.ro> <50baabb30905290440l1490d87dg2c21f2226604cdb1@mail.gmail.com> <20090529115019.GH29375@redhat.com> Message-ID: <1243612820.3037.110.camel@localhost.localdomain> On Fri, 2009-05-29 at 12:50 +0100, Daniel P. Berrange wrote: > It is not Fedora's place to police *usage* of apps, only whether the > app > or package has a compliant license and follows the defined packaging & > legal rules. If the tool were directly containing support for decoding > such prorietry formats that would be a different matter, because the > codecs would not pass the legal rules. > Then do you find it OK to package up a bunch of packages that provide nothing but gnome or KDE menu entries that launch porn internet sites? What about packages that add bookmarks for these in Firefox (disregarding the fact that Firefox can only have one bookmarks package at this point)? Technically it's "free software", could be packaged within the guidelines, and wouldn't be illegal on the surface, but is this really acceptable things to distribute under the Fedora brand? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From ffesti at redhat.com Fri May 29 16:02:18 2009 From: ffesti at redhat.com (Florian Festi) Date: Fri, 29 May 2009 18:02:18 +0200 Subject: gnaughty is a hot babe In-Reply-To: References: <4A1E5CC4.2060506@fedoraproject.org> <4A1FC758.5070803@nicubunu.ro> <50baabb30905290440l1490d87dg2c21f2226604cdb1@mail.gmail.com> <200905291351.52188.jreznik@redhat.com> <50baabb30905290502g3550624l3e1e5fe860712be5@mail.gmail.com> <4A1FD576.5060900@redhat.com> <4A1FEA6A.3090402@redhat.com> Message-ID: <4A20070A.2040508@redhat.com> inode0 wrote: > On Fri, May 29, 2009 at 9:00 AM, Florian Festi wrote: >> inode0 wrote: >>> On Fri, May 29, 2009 at 7:51 AM, Kushal Das wrote: >>>> On Fri, May 29, 2009 at 6:16 PM, inode0 wrote: >>>>> True. Someone should ask the question: does it make sense to have >>>>> different rules if they prevent the inclusion of useful content and >>>>> allow the inclusion of useless code? >>>> Which is useless to me can be very useful to someone else. >>> That doesn't explain why there is a different standard for content. >> It is ok if you know and obey the rules. There is no need for you to >> understand why they are in place. Anyway, Fedora is a Linux distribution >> (for those who did not yet realize) an though (free) Linux software (that >> can be run on Fedora) is what it is all about and content is not (with very >> few exceptions). Software yes - content no. I really see no way or reason >> why there should be a common standard for both. > > "To lead the advancement of free and open source software and content > as a collaborative community." > > That is the mission statement of what project? The Fedora Project with is close but not exactly the same as the Fedora Linux distribution. If you want to do more for free and open content start a new sub project or join one of the sub projects that already work on content (like "Fedora Documentation" or "Fedora Artwork") Florian From alsadi at gmail.com Fri May 29 16:02:31 2009 From: alsadi at gmail.com (Muayyad AlSadi) Date: Fri, 29 May 2009 19:02:31 +0300 Subject: gnaughty is a hot babe In-Reply-To: References: <4A1E5CC4.2060506@fedoraproject.org> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1F998A.9010807@fedoraproject.org> <2d319b780905290151i517bd8b7u832e536645db6eb0@mail.gmail.com> <385866f0905290210h155da287k145e37d8a76f50d2@mail.gmail.com> <4A1FF7AE.1080003@gmail.com> <4A1FFB16.2090607@gmail.com> Message-ID: <385866f0905290902x56ed73bat6e7a68b14a5d95e3@mail.gmail.com> > - yum as I said I demand for a list even if it's with false positives > Couldn't it be the job of those who care to maintain this list in the first place ? no problem, just give me a procedural way other than watching all packages in pkgdb [so that I catch them before they are submitted to the repo] my proposal is like this when someone wants to pack something for fedora and he himself or the upstream wants to tells us about it, then he knows how todo that and where to place his note no more, no less, I have just wrote how do I think about that list https://fedoraproject.org/wiki/PackagingDrafts/InappropriateContents#Example stop censorship conspiracy theory. I don't care what does the the law in US, UK, AU say I care about the little daughter of some brother in this universe. law-makers in most countries think of holes then design their laws around the holes. From jkeating at redhat.com Fri May 29 16:03:23 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 29 May 2009 09:03:23 -0700 Subject: gnaughty is a hot babe In-Reply-To: <200905291351.52188.jreznik@redhat.com> References: <4A1E5CC4.2060506@fedoraproject.org> <4A1FC758.5070803@nicubunu.ro> <50baabb30905290440l1490d87dg2c21f2226604cdb1@mail.gmail.com> <200905291351.52188.jreznik@redhat.com> Message-ID: <1243613003.3037.112.camel@localhost.localdomain> On Fri, 2009-05-29 at 13:51 +0200, Jaroslav Reznik wrote: > > Sorry I don't know this software but as someone already pointed - it's > opensource, it can be used to download other content. Actually it can't. It's hard coded to download the porn from one specific website that acts as a porn directory. Hardcoded in C even, you'd have to significantly patch the source in order to use this software for any other purpose. That is the single most significant difference between it and p0rn-comfort. p0rn-comfort has no preset configuration, hardcoded or not. YOU the user have to tell it what image sites to gather from, and you have to find those sites via your browser. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Fri May 29 16:02:51 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Fri, 29 May 2009 12:02:51 -0400 (EDT) Subject: gnaughty is a hot babe In-Reply-To: <1243612820.3037.110.camel@localhost.localdomain> References: <4A1E5CC4.2060506@fedoraproject.org> <50baabb30905290401y3f2bef33se5b00040ddce608b@mail.gmail.com> <4A1FC15D.9030003@nicubunu.ro> <50baabb30905290407h352be372tb3a77ae1da0359e1@mail.gmail.com> <4A1FC758.5070803@nicubunu.ro> <50baabb30905290440l1490d87dg2c21f2226604cdb1@mail.gmail.com> <20090529115019.GH29375@redhat.com> <1243612820.3037.110.camel@localhost.localdomain> Message-ID: On Fri, 29 May 2009, Jesse Keating wrote: > On Fri, 2009-05-29 at 12:50 +0100, Daniel P. Berrange wrote: >> It is not Fedora's place to police *usage* of apps, only whether the >> app >> or package has a compliant license and follows the defined packaging & >> legal rules. If the tool were directly containing support for decoding >> such prorietry formats that would be a different matter, because the >> codecs would not pass the legal rules. >> > > Then do you find it OK to package up a bunch of packages that provide > nothing but gnome or KDE menu entries that launch porn internet sites? > What about packages that add bookmarks for these in Firefox > (disregarding the fact that Firefox can only have one bookmarks package > at this point)? Technically it's "free software", could be packaged > within the guidelines, and wouldn't be illegal on the surface, but is > this really acceptable things to distribute under the Fedora brand? > and I think the distinction being made is that the bookmarks and menu items are content-only, not software. -sv From a.badger at gmail.com Fri May 29 16:03:53 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 29 May 2009 09:03:53 -0700 Subject: gnaughty is a hot babe In-Reply-To: References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1F998A.9010807@fedoraproject.org> <2d319b780905290151i517bd8b7u832e536645db6eb0@mail.gmail.com> <385866f0905290210h155da287k145e37d8a76f50d2@mail.gmail.com> <4A1FF7AE.1080003@gmail.com> <1243611439.3037.107.camel@localhost.localdomain> Message-ID: <4A200769.2020303@gmail.com> On 05/29/2009 08:40 AM, Seth Vidal wrote: > > we're on a silly slope and putting provides tags into certain pkgs is > just plain dumb - wanna put a wiki page up - that's fine. > > polluting provides tags is not a good plan. > Here's a proposal then: Packages that some people in some cultures may have problems with can be tagged as such. Those tags can then be used by people who care to filter out packages they don't want to be visible. These tags are to be created and attached to packages by users (including package maintainers as they use the packages too). Tags can be free-form and number of times a tag was selected for a package will be kept. Tags will be separate from the binary rpm files but will be associated with the packages. It's up to depsolver authors to decide if the tags will be used in any way in their programs. It's up to people working on derived distributions/spins to decide how to use the available tags to filter the package set. No mandatory step for adding tags will be imposed for all package maintainers in the Packaging Guidelines. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From jkeating at redhat.com Fri May 29 16:07:25 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 29 May 2009 09:07:25 -0700 Subject: Plans for tomorrow's (20090529) FESCo meeting In-Reply-To: References: <200905291033.20518.opensource@till.name> <20090529113607.GD3095@hansolo.jdub.homelinux.org> <20090529144920.GA31662@thinkpad.fab.redhat.com> <20090529145354.GA30106@nostromo.devel.redhat.com> <1243610860.3037.104.camel@localhost.localdomain> Message-ID: <1243613245.3037.114.camel@localhost.localdomain> On Fri, 2009-05-29 at 17:49 +0200, Kevin Kofler wrote: > Jesse Keating wrote: > > Not just driver. We said that the kernel team could choose to include > > any out of tree stuff they deem acceptable, but they would include it in > > the kernel proper rather than as a nasty kernel module package hack. > > The problem is that they say "no" almost every time, even to the modules > FESCo had previously approved as kmods (em8300, sysprof). They now sit as > kmods in RPM Fusion. > > Kevin Kofler > And as the kernel maintainers, it's their right to say no, as particularly with the kernel any addon software can have major impact on the entire kernel. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From smooge at gmail.com Fri May 29 16:07:43 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 29 May 2009 10:07:43 -0600 Subject: gnaughty is a hot babe In-Reply-To: <4A200411.1050303@gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <20090529092040.GA29375@redhat.com> <385866f0905290230n1170470cq31dc26c6dda35b6d@mail.gmail.com> <4A1FAD0D.4030608@fedoraproject.org> <20090529131959.GB3587@mcpierce-laptop.rdu.redhat.com> <385866f0905290627vcd933a9r98d75cc6f3581ae8@mail.gmail.com> <4A1FF116.2030303@conversis.de> <1243608561.7279.178.camel@localhost.localdomain> <385866f0905290803w42e2c99ei340ed8cb41f0ed67@mail.gmail.com> <4A200411.1050303@gmail.com> Message-ID: <80d7e4090905290907m56772478j87bdcd7e1bd61288@mail.gmail.com> Very long thread deleted. Could we all cool it a bit and think for a bit about the following questions 1) Does this discussion need to occur right before a release where there are bigger problems to test/find. 2) Are we discussing anything. People are stating their points of view but its all a one-way discussion as no one is looking to change minds just beat the other side to the last post. 3) Don't we have release blockers to check? -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From skvidal at fedoraproject.org Fri May 29 16:07:44 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Fri, 29 May 2009 12:07:44 -0400 (EDT) Subject: gnaughty is a hot babe In-Reply-To: <385866f0905290902x56ed73bat6e7a68b14a5d95e3@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1F998A.9010807@fedoraproject.org> <2d319b780905290151i517bd8b7u832e536645db6eb0@mail.gmail.com> <385866f0905290210h155da287k145e37d8a76f50d2@mail.gmail.com> <4A1FF7AE.1080003@gmail.com> <4A1FFB16.2090607@gmail.com> <385866f0905290902x56ed73bat6e7a68b14a5d95e3@mail.gmail.com> Message-ID: On Fri, 29 May 2009, Muayyad AlSadi wrote: > stop censorship conspiracy theory. > I don't care what does the the law in US, UK, AU say > I care about the little daughter of some brother in this universe. just so we're clear - you might want to be careful about the use of the word "demand". At least where I'm from "demands" are only made by those with something I want in return or some sort of power. I think you'd be better off making requests. -sv From dr.diesel at gmail.com Fri May 29 16:09:34 2009 From: dr.diesel at gmail.com (Dr. Diesel) Date: Fri, 29 May 2009 11:09:34 -0500 Subject: gnaughty is a hot babe In-Reply-To: <385866f0905290902x56ed73bat6e7a68b14a5d95e3@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1F998A.9010807@fedoraproject.org> <2d319b780905290151i517bd8b7u832e536645db6eb0@mail.gmail.com> <385866f0905290210h155da287k145e37d8a76f50d2@mail.gmail.com> <4A1FF7AE.1080003@gmail.com> <4A1FFB16.2090607@gmail.com> <385866f0905290902x56ed73bat6e7a68b14a5d95e3@mail.gmail.com> Message-ID: <2a28d2ab0905290909x1e41a03cw68ded6f27c81b274@mail.gmail.com> On Fri, May 29, 2009 at 11:02 AM, Muayyad AlSadi wrote: > > - yum > > as I said I demand for a list even if it's with false positives > Demand, again, has he learned anything? This is ridiculous, somebody ban this guy. -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Fri May 29 16:09:22 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 29 May 2009 09:09:22 -0700 Subject: add security related packages categorization to comps? In-Reply-To: <200905291730.08853.opensource@till.name> References: <200905291730.08853.opensource@till.name> Message-ID: <1243613362.3037.115.camel@localhost.localdomain> On Fri, 2009-05-29 at 17:29 +0200, Till Maas wrote: > Hiyas, > > the Security spin[0] categorizes several security related packages in > categories like "Wireless" or "Forensics". It would be useful to have this > information also in comps, so one can easier search for e.g. Forensics > software available in Fedora. > > Is it ok if I just add such groups to comps with the specified packages or are > there any objections? Btw. is it possible to have a Security group which > contains all the subgroups? I think that would be acceptable, but I wouldn't want to see a bunch of one or two package groups. A new category could be created which holds within it all the groups you're creating. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From awilliam at redhat.com Fri May 29 16:11:27 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 29 May 2009 09:11:27 -0700 Subject: rawhide report: 20090528 changes In-Reply-To: <4A1F714C.80905@fedoraproject.org> References: <20090528140501.4121D1F8217@releng2.fedora.phx.redhat.com> <4A1F714C.80905@fedoraproject.org> Message-ID: <1243613487.2937.189.camel@adam.local.net> On Fri, 2009-05-29 at 10:53 +0530, Rahul Sundaram wrote: > On 05/28/2009 07:35 PM, Rawhide Report wrote: > > Compose started at Thu May 28 06:15:03 UTC 2009 > > > > Updated Packages: > > > > kernel-2.6.29.4-167.fc11 > > ------------------------ > > * Wed May 27 2009 Kyle McMartin 2.6.29.4-164 > > - drm-intel-disable-kms-i8xx.patch: disable KMS by default on 845, 855, > > and 865. It can be forced on with i915.modeset=1 boot parameter. > > > > * Wed May 27 2009 Kyle McMartin 2.6.29.4-165 > > - Enable KMS/gem on I865. > > - drm-no-gem-on-i8xx.patch: Remove I865 so GEM will be enabled. > > - drm-intel-disable-kms-i8xx.patch: Enable KMS on I865. > > - Two fixes from Eric Anholt to fix i8x5: > > drm-i915-apply-a-big-hammer-to-865-gem-object.patch > > drm-i915-fix-tiling-pitch.patch > > > > * Wed May 27 2009 Kristian H?gsberg - 2.6.29.4-166 > > - Add drm-intel-set-domain-on-fault.patch to fix random gem object > > corruption when swapping (495323 and probably others). > > - Enable kms on 845 and 855 as well, Erics tiling patch should fix > > those too. > > > > * Wed May 27 2009 Kristian H?gsberg - 2.6.4.167 > > - Actually disable drm-intel-disable-kms-i8xx.patch. > > Seems a lot of back and forth. What's going on? Can someone tell me the > final state of expected behaviour is various cards? It would be useful > to point users to this. I was going to explain yesterday and then decided I shouldn't - guess I should have :) This mostly relates to bug 502077, filed on May 21st (so quite late in cycle). Intel i865 cards were experiencing random hangs with kernel modesetting enabled (which was the default). There was a single unconfirmed report of the same issue affect i845, and another single unconfirmed report for i855. Since it was so late in the cycle and it felt like every time we zapped one KMS bug, another popped up to take its place, QA team / RelEng, at a blocker meeting, recommended disabling KMS for i865 chips. Kyle came in to make this change, and he (along with the other intel/kernel devs) decided to disable KMS for i845 and i855 as well because of the other reports (I think they were under the impression it was more certain that i845 / i855 also suffered from this issue). That's -164. Kristian wasn't happy with this approach, and preferred to try and fix the real bug. Together with Kyle, he identified a potential fix, and built a kernel with that fix included and KMS re-enabled on i865 (that's -165) and got testing for it. A couple of i865 users confirmed that it fixed their issue. We then discussed it a bit further and I explained that we'd only one one unconfirmed report of hangs for both i845 and i855, and I'd actually actively asked other users of those chips if they were experiencing hangs and they'd said no. So we decided that, as it was unclear whether i845 and i855 had really ever suffered from this exact issue, and the patch should fix it for them as well as i865 even if they did, we should go ahead and re-enable KMS for all three chipsets (that's -166 and -167). So, from 163 to 167, the sum total of changes was really just the addition of the patch to fix the hanging problem (and also drm-intel-set-domain-on-fault.patch , which is for another bug that we considered critical). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From emmanuel.seyman at club-internet.fr Fri May 29 16:16:07 2009 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Fri, 29 May 2009 18:16:07 +0200 Subject: gnaughty is a hot babe In-Reply-To: <385866f0905290902x56ed73bat6e7a68b14a5d95e3@mail.gmail.com> References: <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1F998A.9010807@fedoraproject.org> <2d319b780905290151i517bd8b7u832e536645db6eb0@mail.gmail.com> <385866f0905290210h155da287k145e37d8a76f50d2@mail.gmail.com> <4A1FF7AE.1080003@gmail.com> <4A1FFB16.2090607@gmail.com> <385866f0905290902x56ed73bat6e7a68b14a5d95e3@mail.gmail.com> Message-ID: <20090529161607.GA24421@orient.maison.lan> * Muayyad AlSadi [29/05/2009 18:08] : > > as I said I demand for a list even if it's with false positives That's simple. Treat all packages in the repo as having inappropriate content. Emmanuel From skvidal at fedoraproject.org Fri May 29 16:15:38 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Fri, 29 May 2009 12:15:38 -0400 (EDT) Subject: gnaughty is a hot babe In-Reply-To: <80d7e4090905290907m56772478j87bdcd7e1bd61288@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <20090529092040.GA29375@redhat.com> <385866f0905290230n1170470cq31dc26c6dda35b6d@mail.gmail.com> <4A1FAD0D.4030608@fedoraproject.org> <20090529131959.GB3587@mcpierce-laptop.rdu.redhat.com> <385866f0905290627vcd933a9r98d75cc6f3581ae8@mail.gmail.com> <4A1FF116.2030303@conversis.de> <1243608561.7279.178.camel@localhost.localdomain> <385866f0905290803w42e2c99ei340ed8cb41f0ed67@mail.gmail.com> <4A200411.1050303@gmail.com> <80d7e4090905290907m56772478j87bdcd7e1bd61288@mail.gmail.com> Message-ID: On Fri, 29 May 2009, Stephen John Smoogen wrote: > Very long thread deleted. > > Could we all cool it a bit and think for a bit about the following questions > > 1) Does this discussion need to occur right before a release where > there are bigger problems to test/find. > 2) Are we discussing anything. People are stating their points of view > but its all a one-way discussion as no one is looking to change minds > just beat the other side to the last post. > 3) Don't we have release blockers to check? I agree we have other things that need to be done. The reason I'm arguing about this package (and others like it) is that I do not want us getting rid of software due to some provincial thoughts about what is or is not "appropriate". But most importantly I don't want more oppression to win. I'm tired of it winning. -sv From inode0 at gmail.com Fri May 29 16:17:37 2009 From: inode0 at gmail.com (inode0) Date: Fri, 29 May 2009 11:17:37 -0500 Subject: gnaughty is a hot babe In-Reply-To: <4A20070A.2040508@redhat.com> References: <4A1E5CC4.2060506@fedoraproject.org> <200905291351.52188.jreznik@redhat.com> <50baabb30905290502g3550624l3e1e5fe860712be5@mail.gmail.com> <4A1FD576.5060900@redhat.com> <4A1FEA6A.3090402@redhat.com> <4A20070A.2040508@redhat.com> Message-ID: On Fri, May 29, 2009 at 11:02 AM, Florian Festi wrote: > inode0 wrote: >> "To lead the advancement of free and open source software and content >> as a collaborative community." >> >> That is the mission statement of what project? > > The Fedora Project with is close but not exactly the same as the Fedora > Linux distribution. If you want to do more for free and open content start a > new sub project or join one of the sub projects that already work on content > (like "Fedora Documentation" or "Fedora Artwork") Thanks for the personal advice but I think I will choose to continue trying to convince FESCo that excluding free, properly packaged, content that is useful to members of the Fedora community and that promotes future development and use of free software is a mistake instead. John From jkeating at redhat.com Fri May 29 16:19:20 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 29 May 2009 09:19:20 -0700 Subject: gnaughty is a hot babe In-Reply-To: References: <4A1E5CC4.2060506@fedoraproject.org> <50baabb30905290401y3f2bef33se5b00040ddce608b@mail.gmail.com> <4A1FC15D.9030003@nicubunu.ro> <50baabb30905290407h352be372tb3a77ae1da0359e1@mail.gmail.com> <4A1FC758.5070803@nicubunu.ro> <50baabb30905290440l1490d87dg2c21f2226604cdb1@mail.gmail.com> <20090529115019.GH29375@redhat.com> <1243612820.3037.110.camel@localhost.localdomain> Message-ID: <1243613960.3037.118.camel@localhost.localdomain> On Fri, 2009-05-29 at 12:02 -0400, Seth Vidal wrote: > > and I think the distinction being made is that the bookmarks and menu > items are content-only, not software. So an application that reads the included above mentioned "bookmarks" to let you click to go to those sites is OK? Bookmarks alone, bad. Bookmarks bundled with the application to read them good? Once the app was in, would it be good to package up other packages of just bookmarks for that app? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Fri May 29 16:17:49 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Fri, 29 May 2009 12:17:49 -0400 (EDT) Subject: gnaughty is a hot babe In-Reply-To: <4A200769.2020303@gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1F998A.9010807@fedoraproject.org> <2d319b780905290151i517bd8b7u832e536645db6eb0@mail.gmail.com> <385866f0905290210h155da287k145e37d8a76f50d2@mail.gmail.com> <4A1FF7AE.1080003@gmail.com> <1243611439.3037.107.camel@localhost.localdomain> <4A200769.2020303@gmail.com> Message-ID: On Fri, 29 May 2009, Toshio Kuratomi wrote: > On 05/29/2009 08:40 AM, Seth Vidal wrote: >> >> we're on a silly slope and putting provides tags into certain pkgs is >> just plain dumb - wanna put a wiki page up - that's fine. >> >> polluting provides tags is not a good plan. >> > Here's a proposal then: > > Packages that some people in some cultures may have problems with can be > tagged as such. Those tags can then be used by people who care to > filter out packages they don't want to be visible. > > These tags are to be created and attached to packages by users > (including package maintainers as they use the packages too). Tags can > be free-form and number of times a tag was selected for a package will > be kept. Tags will be separate from the binary rpm files but will be > associated with the packages. > > It's up to depsolver authors to decide if the tags will be used in any > way in their programs. It's up to people working on derived > distributions/spins to decide how to use the available tags to filter > the package set. No mandatory step for adding tags will be imposed for > all package maintainers in the Packaging Guidelines. I'm fine with tags. I cannot wait for a "family friendly foundation" to mark up our package tags. It shall be a joy. -sv From kevin.kofler at chello.at Fri May 29 16:14:51 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 29 May 2009 18:14:51 +0200 Subject: gnaughty is a hot babe References: <4A1E5CC4.2060506@fedoraproject.org> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1F998A.9010807@fedoraproject.org> <2d319b780905290151i517bd8b7u832e536645db6eb0@mail.gmail.com> <385866f0905290210h155da287k145e37d8a76f50d2@mail.gmail.com> <4A1FF7AE.1080003@gmail.com> <4A1FFB16.2090607@gmail.com> <385866f0905290902x56ed73bat6e7a68b14a5d95e3@mail.gmail.com> <2a28d2ab0905290909x1e41a03cw68ded6f27c81b274@mail.gmail.com> Message-ID: Dr. Diesel wrote: > Demand, again, has he learned anything? This is ridiculous, somebody ban > this guy. That's just the language barrier. E.g. in French, "demander" is more like "request" than "demand". English is clearly not his first language, possibly not even his second language, I don't think he means what you think he means. Kevin Kofler From dennisml at conversis.de Fri May 29 16:20:50 2009 From: dennisml at conversis.de (Dennis J.) Date: Fri, 29 May 2009 18:20:50 +0200 Subject: gnaughty is a hot babe In-Reply-To: <20090529143412.GA29443@nostromo.devel.redhat.com> References: <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <20090529092040.GA29375@redhat.com> <385866f0905290230n1170470cq31dc26c6dda35b6d@mail.gmail.com> <4A1FAD0D.4030608@fedoraproject.org> <20090529131959.GB3587@mcpierce-laptop.rdu.redhat.com> <385866f0905290627vcd933a9r98d75cc6f3581ae8@mail.gmail.com> <4A1FF116.2030303@conversis.de> <20090529143412.GA29443@nostromo.devel.redhat.com> Message-ID: <4A200B62.7020503@conversis.de> On 05/29/2009 04:34 PM, Bill Nottingham wrote: > Dennis J. (dennisml at conversis.de) said: >>> I wrote a proposal >>> https://fedoraproject.org/wiki/PackagingDrafts/InappropriateContents >> >> I don't think you can just flag Packages as inappropriate because >> everyone has his own definition for that term. If you really want to make >> this work you'll have to create specific classifications like "nudity" or >> "violence" so people can make informed decisions. People might be ok with >> violent content but not nudity. When I see a Package marked only as >> "inappropriate" that doesn't help me to tell whether *I* would find that >> inappropriate or not. > > At which point, you need some sort of review board, where then every > package gets something like: > > - TuxPaint is rated E for Everyone > - quake3 is rated T for violent content > - tcl is rated M for inappropriate language > > I'm going to go out on a limb and claim we don't have the resources to > coherently do this. I don't see why we would need a review board. Just add a guideline asking packagers to tag their packages if they think the contents could be inappropriate out of courtesy toward their fellow community members. If some packagers don't give a damn then that's fine and not a lot can be done about that but why not give the community the tools to self regulate? Just because there is a general guideline does not mean there has to be enforcement through an iron-fisted review board. Regards, Dennis From a.badger at gmail.com Fri May 29 16:20:52 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 29 May 2009 09:20:52 -0700 Subject: gnaughty is a hot babe In-Reply-To: <1243612820.3037.110.camel@localhost.localdomain> References: <4A1E5CC4.2060506@fedoraproject.org> <50baabb30905290401y3f2bef33se5b00040ddce608b@mail.gmail.com> <4A1FC15D.9030003@nicubunu.ro> <50baabb30905290407h352be372tb3a77ae1da0359e1@mail.gmail.com> <4A1FC758.5070803@nicubunu.ro> <50baabb30905290440l1490d87dg2c21f2226604cdb1@mail.gmail.com> <20090529115019.GH29375@redhat.com> <1243612820.3037.110.camel@localhost.localdomain> Message-ID: <4A200B64.8080703@gmail.com> On 05/29/2009 09:00 AM, Jesse Keating wrote: > On Fri, 2009-05-29 at 12:50 +0100, Daniel P. Berrange wrote: >> It is not Fedora's place to police *usage* of apps, only whether the >> app >> or package has a compliant license and follows the defined packaging & >> legal rules. If the tool were directly containing support for decoding >> such prorietry formats that would be a different matter, because the >> codecs would not pass the legal rules. >> > > Then do you find it OK to package up a bunch of packages that provide > nothing but gnome or KDE menu entries that launch porn internet sites? > What about packages that add bookmarks for these in Firefox > (disregarding the fact that Firefox can only have one bookmarks package > at this point)? Technically it's "free software", could be packaged > within the guidelines, and wouldn't be illegal on the surface, Actually, it's not. It's borderline free content. (borderline because the bookmarks themselves are free but the content they point at may or may not be free.) > but is > this really acceptable things to distribute under the Fedora brand? > If you're talking about free software (which gets us back to gnaughty, not to the bookmark example) then I think the answer should be yes. To me, Fedora's Everything repo should be open to any maintained free software that is legal for us to distribute. One of our goals has been to reduce the need for users to have to get software from external repos. We don't serve that purpose by cutting around the edges of the packageset and telling people that they should put their packages in another repository. If we do that, one day we'll find that we're back to Fedora Core and fedora.us except that one will be called Fedora Project and the other RPM Fusion. Fedora will do a much better job of protecting its brand by controlling what goes into the DVD installer and the default livecd than by enforcing more and more restrictions on what can go into the Everything repo. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From jkeating at redhat.com Fri May 29 16:21:34 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 29 May 2009 09:21:34 -0700 Subject: gnaughty is a hot babe In-Reply-To: <2a28d2ab0905290909x1e41a03cw68ded6f27c81b274@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1F998A.9010807@fedoraproject.org> <2d319b780905290151i517bd8b7u832e536645db6eb0@mail.gmail.com> <385866f0905290210h155da287k145e37d8a76f50d2@mail.gmail.com> <4A1FF7AE.1080003@gmail.com> <4A1FFB16.2090607@gmail.com> <385866f0905290902x56ed73bat6e7a68b14a5d95e3@mail.gmail.com> <2a28d2ab0905290909x1e41a03cw68ded6f27c81b274@mail.gmail.com> Message-ID: <1243614094.3037.120.camel@localhost.localdomain> On Fri, 2009-05-29 at 11:09 -0500, Dr. Diesel wrote: > > > On Fri, May 29, 2009 at 11:02 AM, Muayyad AlSadi > wrote: > > - yum > > as I said I demand for a list even if it's with false > positives > > Demand, again, has he learned anything? This is ridiculous, somebody > ban this guy. Language barriers can be difficult. Lets give the poster the benefit of the doubt here in that "demand", at least in the way that I and others interpret it (as Seth stated), is not the word he's looking for. This is extremely far away from reason to "ban" somebody. > -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alsadi at gmail.com Fri May 29 16:23:17 2009 From: alsadi at gmail.com (Muayyad AlSadi) Date: Fri, 29 May 2009 19:23:17 +0300 Subject: gnaughty is a hot babe In-Reply-To: References: <4A1E5CC4.2060506@fedoraproject.org> <4A1F998A.9010807@fedoraproject.org> <2d319b780905290151i517bd8b7u832e536645db6eb0@mail.gmail.com> <385866f0905290210h155da287k145e37d8a76f50d2@mail.gmail.com> <4A1FF7AE.1080003@gmail.com> <4A1FFB16.2090607@gmail.com> <385866f0905290902x56ed73bat6e7a68b14a5d95e3@mail.gmail.com> Message-ID: <385866f0905290923j6294dcar6071cf453d6d0607@mail.gmail.com> > or some sort of power. hmmm, I guess it's the power of friendship :-) seriously, I'm sorry, I did not meant it like that, no problem, I request that whenever someone pack a package that he does not want his 8 years old daughter to add it to the list as I don't care for false positives like firefox or yum because yum does not read the wiki page. From frankly3d at gmail.com Fri May 29 16:23:37 2009 From: frankly3d at gmail.com (Frank Murphy) Date: Fri, 29 May 2009 17:23:37 +0100 Subject: gnaughty is a hot babe In-Reply-To: <385866f0905290902x56ed73bat6e7a68b14a5d95e3@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1F998A.9010807@fedoraproject.org> <2d319b780905290151i517bd8b7u832e536645db6eb0@mail.gmail.com> <385866f0905290210h155da287k145e37d8a76f50d2@mail.gmail.com> <4A1FF7AE.1080003@gmail.com> <4A1FFB16.2090607@gmail.com> <385866f0905290902x56ed73bat6e7a68b14a5d95e3@mail.gmail.com> Message-ID: <4A200C09.9010007@gmail.com> Muayyad AlSadi wrote: >> - yum >> > > as I said I demand for a list even if it's with false positives > > >> Couldn't it be the job of those who care to maintain this list in the >> > first place ? > > no problem, just give me a procedural way other than watching all > packages in pkgdb [so that I catch them before they are submitted to > the repo] > > I think "Package Review" list does this already. Sign up you will know in advance. There is only a certain number of entries per day. Frank From skvidal at fedoraproject.org Fri May 29 16:22:24 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Fri, 29 May 2009 12:22:24 -0400 (EDT) Subject: gnaughty is a hot babe In-Reply-To: <1243613960.3037.118.camel@localhost.localdomain> References: <4A1E5CC4.2060506@fedoraproject.org> <50baabb30905290401y3f2bef33se5b00040ddce608b@mail.gmail.com> <4A1FC15D.9030003@nicubunu.ro> <50baabb30905290407h352be372tb3a77ae1da0359e1@mail.gmail.com> <4A1FC758.5070803@nicubunu.ro> <50baabb30905290440l1490d87dg2c21f2226604cdb1@mail.gmail.com> <20090529115019.GH29375@redhat.com> <1243612820.3037.110.camel@localhost.localdomain> <1243613960.3037.118.camel@localhost.localdomain> Message-ID: On Fri, 29 May 2009, Jesse Keating wrote: > On Fri, 2009-05-29 at 12:02 -0400, Seth Vidal wrote: >> >> and I think the distinction being made is that the bookmarks and menu >> items are content-only, not software. > > So an application that reads the included above mentioned "bookmarks" to > let you click to go to those sites is OK? Bookmarks alone, bad. > Bookmarks bundled with the application to read them good? Once the app > was in, would it be good to package up other packages of just bookmarks > for that app? I was just explaining the distinction being made. I'm actually fine with bookmark collection packages and/or menu items. they are probably silly - but if someone wants them and will maintain them, so be it. -sv From awilliam at redhat.com Fri May 29 16:30:06 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 29 May 2009 09:30:06 -0700 Subject: gnaughty is a hot babe In-Reply-To: <4A1FB5CC.1060204@gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1FAFE3.80302@gmail.com> <2a28d2ab0905290259g8103cb7p9856559a611ed465@mail.gmail.com> <4A1FB5CC.1060204@gmail.com> Message-ID: <1243614606.2937.194.camel@adam.local.net> On Fri, 2009-05-29 at 11:15 +0100, Frank Murphy (Frankly3d) wrote: > But I think morality it is delving away from fedora, > unless it is global socially objectionable, > maybe Child-Porn. I see this is this week's merry train-wreck of a discussion, but I can't resist pointing out that even that isn't as clear-cut as you'd expect: in Japan you can perfectly easily buy manga depicting extremely young children having sex and just be thought of as a bit weird. (But just like in the grown-up versions, the actual...appendages have to be very minimally censored...*unlike* in most countries). Such things would technically be legal in probably most western countries, but very heavily frowned upon to say the least, and as a matter of practice, I don't think you can really buy them elsewhere. To derive a more useful principle: there's almost no universal agreement on any issue of what's 'culturally', 'morally', 'ethically' or whatever acceptable, so it's effectively impossible for Fedora as a project to create an 'Objectionable Content' label and apply it in a way that's useful. If you are producing a spin for a group with sufficiently continguous views on such things, it falls to you and no-one else to ensure that the materials in your spin are appropriate for your audience. 'We' - the project as a whole - don't necessarily share or even fully understand your moral perspective, so you can't rely on us to do it for you. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From frankly3d at gmail.com Fri May 29 16:31:00 2009 From: frankly3d at gmail.com (Frank Murphy (Frankly3d)) Date: Fri, 29 May 2009 17:31:00 +0100 Subject: Devel-Spins F11\Rawhide? Message-ID: <4A200DC4.2000700@gmail.com> What is the most recent Devel-Spin? Will there be one for GA? Frank -- msn: frankly3d skype: frankly3d Mailing-List Reply to: Mailing-List Still Learning, Unicode where possible From alsadi at gmail.com Fri May 29 16:34:56 2009 From: alsadi at gmail.com (Muayyad AlSadi) Date: Fri, 29 May 2009 19:34:56 +0300 Subject: gnaughty is a hot babe In-Reply-To: <1243614606.2937.194.camel@adam.local.net> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1FAFE3.80302@gmail.com> <2a28d2ab0905290259g8103cb7p9856559a611ed465@mail.gmail.com> <4A1FB5CC.1060204@gmail.com> <1243614606.2937.194.camel@adam.local.net> Message-ID: <385866f0905290934x2f800262w362ea1b7a62298da@mail.gmail.com> don't think of that list/tags as censor ship,it's just an advice from a friend. From dennisml at conversis.de Fri May 29 16:41:10 2009 From: dennisml at conversis.de (Dennis J.) Date: Fri, 29 May 2009 18:41:10 +0200 Subject: gnaughty is a hot babe In-Reply-To: References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1F998A.9010807@fedoraproject.org> <2d319b780905290151i517bd8b7u832e536645db6eb0@mail.gmail.com> <385866f0905290210h155da287k145e37d8a76f50d2@mail.gmail.com> <4A1FF7AE.1080003@gmail.com> Message-ID: <4A201026.7060504@conversis.de> On 05/29/2009 05:02 PM, Seth Vidal wrote: > > > On Fri, 29 May 2009, Toshio Kuratomi wrote: > >> On 05/29/2009 02:10 AM, Muayyad AlSadi wrote: >>>> The problem with a comps group is that it will lead to having a group >>>> in graphical installers >>> >>> although in ojuba we use ourown comps files, but this is a catastrophe >>> because they are merged! >>> I guess there is an option for hidden groups >>> >> >> Have these packages: >> >> Provides: policy(adult content) >> >> And have a package that's mandatory in your respin that has: >> >> Conflicts: policy(adult content) >> >> /me taking one of the good ideas from the flag debate. > > Except it is obvious that something contains a flag or not. > > Labeling certain content 'questionable' is going to end up being all > over the distro and diluting the value of the tag. > > Let me put it this way - if we start randomly rating things in a > provides tag and gnaughty or hot-babe or pr0n-comfort get labeled this > way then I'll make sure I personally add the same tag to: > > - firefox > - yum > - sword > - gnome-sword So the reason you acted in a benevolent way in this community is only because it didn't give you an opening and the moment that happens you promise to attack it? While I'm in general agreement that censorship in any form is bad that's a pretty sad statement to make. Regards, Dennis From awilliam at redhat.com Fri May 29 16:44:21 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 29 May 2009 09:44:21 -0700 Subject: gnaughty is a hot babe In-Reply-To: <385866f0905290740y525b3d8el89194c4340fbc78b@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <20090529092040.GA29375@redhat.com> <385866f0905290230n1170470cq31dc26c6dda35b6d@mail.gmail.com> <4A1FAD0D.4030608@fedoraproject.org> <20090529131959.GB3587@mcpierce-laptop.rdu.redhat.com> <385866f0905290627vcd933a9r98d75cc6f3581ae8@mail.gmail.com> <4A1FF116.2030303@conversis.de> <385866f0905290740y525b3d8el89194c4340fbc78b@mail.gmail.com> Message-ID: <1243615461.2937.195.camel@adam.local.net> On Fri, 2009-05-29 at 17:40 +0300, Muayyad AlSadi wrote: > no I mean inspecting a list of tens of packages would be much simpler > than inspecting all the tens of thousands of packages You're just transferring the work. In order to *generate* the list of tens of packages to make _your_ life easier, someone else has to inspect the tens of thousands of packages. And try to make sure they understand your particular moral compass, to make sure anything you might find offensive gets onto the list of tens of packages. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From awilliam at redhat.com Fri May 29 16:47:52 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 29 May 2009 09:47:52 -0700 Subject: Plans for tomorrow's (20090529) FESCo meeting In-Reply-To: References: <200905291033.20518.opensource@till.name> <20090529113607.GD3095@hansolo.jdub.homelinux.org> <20090529144920.GA31662@thinkpad.fab.redhat.com> Message-ID: <1243615672.2937.197.camel@adam.local.net> On Fri, 2009-05-29 at 10:59 -0400, Seth Vidal wrote: > > On Fri, 29 May 2009, drago01 wrote: > > > > > Because they might break on kernel updates, needs to be rebuild > > everytime and in some cases require patches to work. > > > > So we might get in a situation: pushing a kernel update will cause > > broken deps for users of kmod-foo -> preventing them from installing > > updates -> security risk. (outdated packages) > > > > There is no 'might' about it. > > it happens. > > all the time. There is a solution to this particular point, which it seems many who use kmods don't seem to know about: akmods. Install the akmod for your kmod, and if the pre-built kmod hasn't yet been updated when a new kernel is released, the akmod handles the problem (it gets automatically built at boot time). That doesn't address all the other problems, of course, which are valid. And it doesn't help if the new kernel happens to have changed the interface somehow so the module source doesn't build any more. But there _is_ a solution for the "the code still builds fine but the repository didn't update the pre-built binary yet" case. Just sayin'. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From notting at redhat.com Fri May 29 16:48:12 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 29 May 2009 12:48:12 -0400 Subject: gnaughty is a hot babe In-Reply-To: <4A200B62.7020503@conversis.de> References: <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <20090529092040.GA29375@redhat.com> <385866f0905290230n1170470cq31dc26c6dda35b6d@mail.gmail.com> <4A1FAD0D.4030608@fedoraproject.org> <20090529131959.GB3587@mcpierce-laptop.rdu.redhat.com> <385866f0905290627vcd933a9r98d75cc6f3581ae8@mail.gmail.com> <4A1FF116.2030303@conversis.de> <20090529143412.GA29443@nostromo.devel.redhat.com> <4A200B62.7020503@conversis.de> Message-ID: <20090529164812.GA32291@nostromo.devel.redhat.com> Dennis J. (dennisml at conversis.de) said: >> At which point, you need some sort of review board, where then every >> package gets something like: >> >> - TuxPaint is rated E for Everyone >> - quake3 is rated T for violent content >> - tcl is rated M for inappropriate language >> >> I'm going to go out on a limb and claim we don't have the resources to >> coherently do this. > > I don't see why we would need a review board. Just add a guideline asking > packagers to tag their packages if they think the contents could be > inappropriate out of courtesy toward their fellow community members. > > If some packagers don't give a damn then that's fine and not a lot can be > done about that but why not give the community the tools to self > regulate? > > Just because there is a general guideline does not mean there has to be > enforcement through an iron-fisted review board. Without some sort of standards, the tags would likely become meaningless to rely on in practice. (See also: the RPM Group tag.) Bill From sundaram at fedoraproject.org Fri May 29 16:47:49 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 29 May 2009 22:17:49 +0530 Subject: rawhide report: 20090528 changes In-Reply-To: <1243613487.2937.189.camel@adam.local.net> References: <20090528140501.4121D1F8217@releng2.fedora.phx.redhat.com> <4A1F714C.80905@fedoraproject.org> <1243613487.2937.189.camel@adam.local.net> Message-ID: <4A2011B5.8050706@fedoraproject.org> On 05/29/2009 09:41 PM, Adam Williamson wrote: > On Fri, 2009-05-29 at 10:53 +0530, Rahul Sundaram wrote: >>> kernel-2.6.29.4-167.fc11 >>> ------------------------ >>> * Wed May 27 2009 Kyle McMartin 2.6.29.4-164 >>> - drm-intel-disable-kms-i8xx.patch: disable KMS by default on 845, 855, >>> and 865. It can be forced on with i915.modeset=1 boot parameter. > > So, from 163 to 167, the sum total of changes was really just the > addition of the patch to fix the hanging problem (and also > drm-intel-set-domain-on-fault.patch , which is for another bug that we > considered critical). The last change on 167 says that KMS is disabled on these chipsets. You seem to be saying it is actually enabled by default? Rahul From alsadi at gmail.com Fri May 29 16:49:24 2009 From: alsadi at gmail.com (Muayyad AlSadi) Date: Fri, 29 May 2009 19:49:24 +0300 Subject: gnaughty is a hot babe In-Reply-To: <1243615461.2937.195.camel@adam.local.net> References: <4A1E5CC4.2060506@fedoraproject.org> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <20090529092040.GA29375@redhat.com> <385866f0905290230n1170470cq31dc26c6dda35b6d@mail.gmail.com> <4A1FAD0D.4030608@fedoraproject.org> <20090529131959.GB3587@mcpierce-laptop.rdu.redhat.com> <385866f0905290627vcd933a9r98d75cc6f3581ae8@mail.gmail.com> <4A1FF116.2030303@conversis.de> <385866f0905290740y525b3d8el89194c4340fbc78b@mail.gmail.com> <1243615461.2937.195.camel@adam.local.net> Message-ID: <385866f0905290949n136744caya733b297d006bd8e@mail.gmail.com> > You're just transferring the work. In order to *generate* the list of > tens of packages to make _your_ life easier, someone else has to inspect > the tens of thousands of packages. and the someone else you refer to is fedora censorship board! no no like that, I asked for a unified place to put those things in the wiki if the maintainer decided that he does not want to add his package to the list we are not going to shoot him. it's just an advice from a friend keep that in mind From sundaram at fedoraproject.org Fri May 29 16:52:45 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 29 May 2009 22:22:45 +0530 Subject: Plans for tomorrow's (20090529) FESCo meeting In-Reply-To: <2d319b780905290857l33cc68apb4e1acc4beda0a90@mail.gmail.com> References: <200905291033.20518.opensource@till.name> <20090529113607.GD3095@hansolo.jdub.homelinux.org> <20090529144920.GA31662@thinkpad.fab.redhat.com> <2d319b780905290857l33cc68apb4e1acc4beda0a90@mail.gmail.com> Message-ID: <4A2012DD.805@fedoraproject.org> On 05/29/2009 09:27 PM, Mathieu Bridon (bochecha) wrote: > > By refusing kmods, we have more motivation to actually try and include > upstream what we really need to use. If we can simply install the > kmod, who cares if it's upstreamed ? We generally do care about whether something is upstream or not for various reasons discussed many times here but also because we push out new kernel updates often within a particular release and that has a good chance of breaking out of tree modules. End users do care about that as well. Rahul From kevin.kofler at chello.at Fri May 29 16:53:27 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 29 May 2009 18:53:27 +0200 Subject: rawhide report: 20090528 changes References: <20090528140501.4121D1F8217@releng2.fedora.phx.redhat.com> <4A1F714C.80905@fedoraproject.org> <1243613487.2937.189.camel@adam.local.net> <4A2011B5.8050706@fedoraproject.org> Message-ID: Rahul Sundaram wrote: >>>> * Wed May 27 2009 Kyle McMartin 2.6.29.4-164 >>>> - drm-intel-disable-kms-i8xx.patch: disable KMS by default on 845, 855, >>>> and 865. It can be forced on with i915.modeset=1 boot parameter. > > The last change on 167 says that KMS is disabled on these chipsets. You > seem to be saying it is actually enabled by default? That's not the last change, it's the change in -164. The changelog is not properly ordered. Kevin Kofler From sundaram at fedoraproject.org Fri May 29 16:55:50 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 29 May 2009 22:25:50 +0530 Subject: Packaging Survey - May 2009 In-Reply-To: <9497e9990905290704s6a531dc5i772d52601399973e@mail.gmail.com> References: <4A1D24AC.4090802@fedoraproject.org> <9497e9990905290704s6a531dc5i772d52601399973e@mail.gmail.com> Message-ID: <4A201396.5070105@fedoraproject.org> On 05/29/2009 07:34 PM, Mat Booth wrote: > > I don't think JEP should be on that list. I've used it in few > commercial products and its a thousand dollars a pop for a source code > licence: > > http://www.singularsys.com/order/ JEP in the wiki is linked to http://sourceforge.net/projects/jep/. Are you even talking about the same software? Rahul From awilliam at redhat.com Fri May 29 16:58:10 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 29 May 2009 09:58:10 -0700 Subject: gnaughty is a hot babe In-Reply-To: <385866f0905290949n136744caya733b297d006bd8e@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <20090529092040.GA29375@redhat.com> <385866f0905290230n1170470cq31dc26c6dda35b6d@mail.gmail.com> <4A1FAD0D.4030608@fedoraproject.org> <20090529131959.GB3587@mcpierce-laptop.rdu.redhat.com> <385866f0905290627vcd933a9r98d75cc6f3581ae8@mail.gmail.com> <4A1FF116.2030303@conversis.de> <385866f0905290740y525b3d8el89194c4340fbc78b@mail.gmail.com> <1243615461.2937.195.camel@adam.local.net> <385866f0905290949n136744caya733b297d006bd8e@mail.gmail.com> Message-ID: <1243616290.2937.200.camel@adam.local.net> On Fri, 2009-05-29 at 19:49 +0300, Muayyad AlSadi wrote: > > You're just transferring the work. In order to *generate* the list of > > tens of packages to make _your_ life easier, someone else has to inspect > > the tens of thousands of packages. > and the someone else you refer to is fedora censorship board! > no no like that, > I asked for a unified place to put those things in the wiki > if the maintainer decided that he does not want to add his package to > the list we are not going to shoot him. If all you want is a page on the Wiki for you and notional other people who are interested in excluding certain packages from their spins or whatever to co-ordinate on listing which packages might be an issue, then I don't think anyone would really object to that - all along we've been saying that it's fine for you to include or exclude whatever you like from your own spin on whatever grounds you choose, and this would just be a bit of organization to help you with that. I certainly wouldn't object to it. However, you haven't proposed it as that; you seem to have proposed it as a packaging guideline. All packagers are supposed to respect packaging guidelines (we only don't call them 'rules' because we're trying to be all happy-clappy). If you really want this to be something that packagers don't have to worry about unless they actually care about it, then it shouldn't be a packaging guideline. You should just create it as a page on the Wiki with no official status in any procedure. I don't believe you need anyone's permission to do that, you can just go ahead and do it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From a.badger at gmail.com Fri May 29 17:00:06 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 29 May 2009 10:00:06 -0700 Subject: Plans for tomorrow's (20090529) FESCo meeting In-Reply-To: <1243615672.2937.197.camel@adam.local.net> References: <200905291033.20518.opensource@till.name> <20090529113607.GD3095@hansolo.jdub.homelinux.org> <20090529144920.GA31662@thinkpad.fab.redhat.com> <1243615672.2937.197.camel@adam.local.net> Message-ID: <4A201496.2070205@gmail.com> On 05/29/2009 09:47 AM, Adam Williamson wrote: > There is a solution to this particular point, which it seems many who > use kmods don't seem to know about: akmods. Install the akmod for your > kmod, and if the pre-built kmod hasn't yet been updated when a new > kernel is released, the akmod handles the problem (it gets automatically > built at boot time). > I've used dkms (the infrastructural package is in Fedora although there's no modules in fedora to use it). It seems similar to what you describe. > That doesn't address all the other problems, of course, which are valid. > And it doesn't help if the new kernel happens to have changed the > interface somehow so the module source doesn't build any more. But there This ended up being the blocker for my personal use. For FESCo, I remember the requirement that gcc and other build tools were needed on an end user system was a big issue. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From awilliam at redhat.com Fri May 29 17:07:13 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 29 May 2009 10:07:13 -0700 Subject: gnaughty is a hot babe In-Reply-To: <1243612820.3037.110.camel@localhost.localdomain> References: <4A1E5CC4.2060506@fedoraproject.org> <50baabb30905290401y3f2bef33se5b00040ddce608b@mail.gmail.com> <4A1FC15D.9030003@nicubunu.ro> <50baabb30905290407h352be372tb3a77ae1da0359e1@mail.gmail.com> <4A1FC758.5070803@nicubunu.ro> <50baabb30905290440l1490d87dg2c21f2226604cdb1@mail.gmail.com> <20090529115019.GH29375@redhat.com> <1243612820.3037.110.camel@localhost.localdomain> Message-ID: <1243616833.2937.201.camel@adam.local.net> On Fri, 2009-05-29 at 09:00 -0700, Jesse Keating wrote: > Then do you find it OK to package up a bunch of packages that provide > nothing but gnome or KDE menu entries that launch porn internet sites? I am heartily interested in your ideas and wish to read your pamphlet! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From dennisml at conversis.de Fri May 29 17:07:33 2009 From: dennisml at conversis.de (Dennis J.) Date: Fri, 29 May 2009 19:07:33 +0200 Subject: gnaughty is a hot babe In-Reply-To: <20090529164812.GA32291@nostromo.devel.redhat.com> References: <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <20090529092040.GA29375@redhat.com> <385866f0905290230n1170470cq31dc26c6dda35b6d@mail.gmail.com> <4A1FAD0D.4030608@fedoraproject.org> <20090529131959.GB3587@mcpierce-laptop.rdu.redhat.com> <385866f0905290627vcd933a9r98d75cc6f3581ae8@mail.gmail.com> <4A1FF116.2030303@conversis.de> <20090529143412.GA29443@nostromo.devel.redhat.com> <4A200B62.7020503@conversis.de> <20090529164812.GA32291@nostromo.devel.redhat.com> Message-ID: <4A201655.5000607@conversis.de> On 05/29/2009 06:48 PM, Bill Nottingham wrote: > Dennis J. (dennisml at conversis.de) said: >>> At which point, you need some sort of review board, where then every >>> package gets something like: >>> >>> - TuxPaint is rated E for Everyone >>> - quake3 is rated T for violent content >>> - tcl is rated M for inappropriate language >>> >>> I'm going to go out on a limb and claim we don't have the resources to >>> coherently do this. >> >> I don't see why we would need a review board. Just add a guideline asking >> packagers to tag their packages if they think the contents could be >> inappropriate out of courtesy toward their fellow community members. >> >> If some packagers don't give a damn then that's fine and not a lot can be >> done about that but why not give the community the tools to self >> regulate? >> >> Just because there is a general guideline does not mean there has to be >> enforcement through an iron-fisted review board. > > Without some sort of standards, the tags would likely become meaningless > to rely on in practice. (See also: the RPM Group tag.) Then let the people who are affected with this come up with a proposal and deal with it on it's technical merits. There is no enforcement involved. If that proposal is too difficult/complex to implement it can be rejected. If a packager is unwilling to put such a classification in his package then it's up to the people concerned to work it out. Regards, Dennis From awilliam at redhat.com Fri May 29 17:11:26 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 29 May 2009 10:11:26 -0700 Subject: rawhide report: 20090528 changes In-Reply-To: <4A2011B5.8050706@fedoraproject.org> References: <20090528140501.4121D1F8217@releng2.fedora.phx.redhat.com> <4A1F714C.80905@fedoraproject.org> <1243613487.2937.189.camel@adam.local.net> <4A2011B5.8050706@fedoraproject.org> Message-ID: <1243617086.2937.203.camel@adam.local.net> On Fri, 2009-05-29 at 22:17 +0530, Rahul Sundaram wrote: > On 05/29/2009 09:41 PM, Adam Williamson wrote: > > On Fri, 2009-05-29 at 10:53 +0530, Rahul Sundaram wrote: > > >>> kernel-2.6.29.4-167.fc11 > >>> ------------------------ > >>> * Wed May 27 2009 Kyle McMartin 2.6.29.4-164 > >>> - drm-intel-disable-kms-i8xx.patch: disable KMS by default on 845, 855, > >>> and 865. It can be forced on with i915.modeset=1 boot parameter. > > > > > So, from 163 to 167, the sum total of changes was really just the > > addition of the patch to fix the hanging problem (and also > > drm-intel-set-domain-on-fault.patch , which is for another bug that we > > considered critical). > > The last change on 167 says that KMS is disabled on these chipsets. You > seem to be saying it is actually enabled by default? As Kevin says, the changelog isn't well ordered - note the date/email/revision line, that's the changes in -164. The changelog shows 164, 165, 166, 167, 163. I wonder if this will ever get fixed :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From fedora at matbooth.co.uk Fri May 29 17:17:37 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Fri, 29 May 2009 18:17:37 +0100 Subject: Packaging Survey - May 2009 In-Reply-To: <4A201396.5070105@fedoraproject.org> References: <4A1D24AC.4090802@fedoraproject.org> <9497e9990905290704s6a531dc5i772d52601399973e@mail.gmail.com> <4A201396.5070105@fedoraproject.org> Message-ID: <9497e9990905291017k5fe803dfn30a188b85d603fa8@mail.gmail.com> On Fri, May 29, 2009 at 5:55 PM, Rahul Sundaram wrote: > On 05/29/2009 07:34 PM, Mat Booth wrote: > >> >> I don't think JEP should be on that list. I've used it in few >> commercial products and its a thousand dollars a pop for a source code >> licence: >> >> http://www.singularsys.com/order/ > > JEP in the wiki is linked to http://sourceforge.net/projects/jep/. Are > you even talking about the same software? > Yes, I think we are. At the very top of the page you link to it says: "As of 2008-09-29 23:14, this project may now be found at: http://www.singularsys.com/jep" -- Mat Booth www.matbooth.co.uk From sundaram at fedoraproject.org Fri May 29 17:20:32 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 29 May 2009 22:50:32 +0530 Subject: Packaging Survey - May 2009 In-Reply-To: <9497e9990905291017k5fe803dfn30a188b85d603fa8@mail.gmail.com> References: <4A1D24AC.4090802@fedoraproject.org> <9497e9990905290704s6a531dc5i772d52601399973e@mail.gmail.com> <4A201396.5070105@fedoraproject.org> <9497e9990905291017k5fe803dfn30a188b85d603fa8@mail.gmail.com> Message-ID: <4A201960.7040205@fedoraproject.org> On 05/29/2009 10:47 PM, Mat Booth wrote: > "As of 2008-09-29 23:14, this project may now be found at: > http://www.singularsys.com/jep" Wouldn't older versions still exist under the open source license? Are they still useful? Rahul From sundaram at fedoraproject.org Fri May 29 17:22:02 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 29 May 2009 22:52:02 +0530 Subject: rawhide report: 20090528 changes In-Reply-To: References: <20090528140501.4121D1F8217@releng2.fedora.phx.redhat.com> <4A1F714C.80905@fedoraproject.org> <1243613487.2937.189.camel@adam.local.net> <4A2011B5.8050706@fedoraproject.org> Message-ID: <4A2019BA.9010106@fedoraproject.org> On 05/29/2009 10:23 PM, Kevin Kofler wrote: > Rahul Sundaram wrote: >>>>> * Wed May 27 2009 Kyle McMartin 2.6.29.4-164 >>>>> - drm-intel-disable-kms-i8xx.patch: disable KMS by default on 845, 855, >>>>> and 865. It can be forced on with i915.modeset=1 boot parameter. >> >> The last change on 167 says that KMS is disabled on these chipsets. You >> seem to be saying it is actually enabled by default? > > That's not the last change, it's the change in -164. The changelog is not > properly ordered. Ugh. That explains my confusion. Thanks. Rahul From kevin.kofler at chello.at Fri May 29 17:20:26 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 29 May 2009 19:20:26 +0200 Subject: Packaging Survey - May 2009 References: <4A1D24AC.4090802@fedoraproject.org> <9497e9990905290704s6a531dc5i772d52601399973e@mail.gmail.com> <4A201396.5070105@fedoraproject.org> <9497e9990905291017k5fe803dfn30a188b85d603fa8@mail.gmail.com> Message-ID: Mat Booth wrote: > Yes, I think we are. At the very top of the page you link to it says: > > "As of 2008-09-29 23:14, this project may now be found at: > http://www.singularsys.com/jep" So that's one of those evil packages which has switched to become non-Free. People caring about it need to organize a fork as soon as possible. Kevin Kofler From awilliam at redhat.com Fri May 29 17:32:25 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 29 May 2009 10:32:25 -0700 Subject: Plans for tomorrow's (20090529) FESCo meeting In-Reply-To: <4A201496.2070205@gmail.com> References: <200905291033.20518.opensource@till.name> <20090529113607.GD3095@hansolo.jdub.homelinux.org> <20090529144920.GA31662@thinkpad.fab.redhat.com> <1243615672.2937.197.camel@adam.local.net> <4A201496.2070205@gmail.com> Message-ID: <1243618345.2937.210.camel@adam.local.net> On Fri, 2009-05-29 at 10:00 -0700, Toshio Kuratomi wrote: > On 05/29/2009 09:47 AM, Adam Williamson wrote: > > > There is a solution to this particular point, which it seems many who > > use kmods don't seem to know about: akmods. Install the akmod for your > > kmod, and if the pre-built kmod hasn't yet been updated when a new > > kernel is released, the akmod handles the problem (it gets automatically > > built at boot time). > > > I've used dkms (the infrastructural package is in Fedora although > there's no modules in fedora to use it). It seems similar to what you > describe. Yes, vanilla DKMS works like this: it doesn't use pre-built binaries at all, it's just about wrapping the module source up into a convenient lump and having a bit of infrastructure to automatically compile it during startup if appropriate. > > That doesn't address all the other problems, of course, which are valid. > > And it doesn't help if the new kernel happens to have changed the > > interface somehow so the module source doesn't build any more. But there > > This ended up being the blocker for my personal use. For FESCo, I > remember the requirement that gcc and other build tools were needed on > an end user system was a big issue. Yeah, that's the drawback to a pure source approach. Mandriva took DKMS and hacked it up so that it creates both pre-built binaries and 'source' packages (much like kmods and akmods in the kmod system), so that if you have a system without the build chain things will work as long as you're running a supported kernel and the updates are in sync, but if you have the whole build chain, the 'source' DKMS package covers you if you're running a different kernel or whatever. RPM Fusion does much the same by providing both kmods and akmods. It works for MDV but only with rather a lot of effort to ensure the binary packages are kept in sync with kernel updates, and there were a couple of releases where NVIDIA and ATI users suffered because this wasn't the case, and they didn't have the kernel headers installed so the DKMS 'source' packages didn't cover them. NVIDIA and ATI are the major use case for MDV (and, frankly, for RPM Fusion), so I came around to the view that it isn't really a good idea to have kmods or DKMS in Fedora; the major use case for them doesn't apply to Fedora and never will, and the other objections are pretty valid for all the other cases for which DKMS / kmods can be used (either this stuff should go straight into the kernel or we should not ship it). And the pain involved in keeping the pre-built binaries in sync with the kernel is significant. On kmods vs. DKMS, I've now both built packages that use both and used both on my own system. My perception is that DKMS is a much cleaner system and saner to package, but kmod works slightly faster on boot. So personally I prefer DKMS, but I may be biased (you usually prefer the first implementation of anything you come across, as students of music are aware :>) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From alsadi at gmail.com Fri May 29 17:36:20 2009 From: alsadi at gmail.com (Muayyad AlSadi) Date: Fri, 29 May 2009 20:36:20 +0300 Subject: gnaughty is a hot babe In-Reply-To: <4A201655.5000607@conversis.de> References: <4A1EDFAD.4090803@conversis.de> <385866f0905290230n1170470cq31dc26c6dda35b6d@mail.gmail.com> <4A1FAD0D.4030608@fedoraproject.org> <20090529131959.GB3587@mcpierce-laptop.rdu.redhat.com> <385866f0905290627vcd933a9r98d75cc6f3581ae8@mail.gmail.com> <4A1FF116.2030303@conversis.de> <20090529143412.GA29443@nostromo.devel.redhat.com> <4A200B62.7020503@conversis.de> <20090529164812.GA32291@nostromo.devel.redhat.com> <4A201655.5000607@conversis.de> Message-ID: <385866f0905291036v5cf1e69ex8d41df1585a50dda@mail.gmail.com> > You're just transferring the work. In order to *generate* the list of > tens of packages to make _your_ life easier, someone else has to inspect > the tens of thousands of packages. I forgot to mention that I'm not the only one who cares think of OLPC having a pre-installed something similar to gnaughty by default how would it appear after the "G for Gun" issue some schools have fedora installed on their students desktops, I guess they too needs to know such packages. making each of them individually inspecting all packages is not an option. > However, you haven't proposed it as that; you seem to have proposed it as a packaging guideline. in the beginning I did not proposed a packaging guideline but I was told to make it a packaging guideline proposal I asked for a unified wiki page that packagers should know that it exists and they have the right to add to it. > There is no enforcement involved. If that proposal is too Difficult/complex to implement it can be rejected. If a packager is unwilling to put such a classification in his package then it's up to the people concerned to work it out. it's a wiki page, if the packager was unwilling to put such classification then he have no right to stop the reviewer from editing the wiki page and if they both where unwilling to do so, they both have no right from stopping the first offended user from editing the wiki page, that's all. so I can't see when it can cause a package to be rejected. > what is allowed or not allowed because one can not assume that everyone thinks the same way this is not about allowing or not allowing packages or content. It's about a place to know what packages that might be offensive or inappropriate and each group should expect this list to have false positives. > Also, others may have said this, but the word demand is a 'violent' word in English. It intones harsh consequences if one's wants are not met and is one that causes fear and anger as a result. I am not sure you mean that. I said I'm sorry. anyway some dictionary says < http://dictionary.reference.com/browse/demand to call for or require as just, proper, or necessary: This task demands patience. Justice demands objectivity. and of course I feel that I asked for something that is just and proper and necessary. but I did not mean to force it. From chitlesh.goorah at gmail.com Fri May 29 17:38:17 2009 From: chitlesh.goorah at gmail.com (Chitlesh GOORAH) Date: Fri, 29 May 2009 19:38:17 +0200 Subject: gnaughty is a hot babe In-Reply-To: <4A1FD576.5060900@redhat.com> References: <4A1E5CC4.2060506@fedoraproject.org> <4A1FC758.5070803@nicubunu.ro> <50baabb30905290440l1490d87dg2c21f2226604cdb1@mail.gmail.com> <200905291351.52188.jreznik@redhat.com> <50baabb30905290502g3550624l3e1e5fe860712be5@mail.gmail.com> <4A1FD576.5060900@redhat.com> Message-ID: <50baabb30905291038p2202aafcp60d0a1ea2e78ff@mail.gmail.com> On Fri, May 29, 2009 at 2:30 PM, Florian Festi wrote: > It really doesn't matter how often you repeat a wrong sentence. > > There are different rules that do apply to code and content in Fedora and > OVM got categorized as content and refused by the rules for content. We are > talking about a program here. FYI, actually it depends how you look at it: - from a software point of view, it's content. - from a hardware point of view, it's libraries and verification methodologies. This confused a lot. Chitlesh From xavier at bachelot.org Fri May 29 17:49:41 2009 From: xavier at bachelot.org (Xavier Bachelot) Date: Fri, 29 May 2009 19:49:41 +0200 Subject: Swapping reviews In-Reply-To: <1243607900.27826.1.camel@linuxdev.datasphere.ch> References: <1243607900.27826.1.camel@linuxdev.datasphere.ch> Message-ID: <4A202035.1060101@bachelot.org> Patrick MONNERAT wrote: > Hello list, > Package WebCalendar (https://bugzilla.redhat.com/show_bug.cgi?id=471231) is awaiting review for 5 month already. > > I will be glad to review another package in counterpart of this one's review. > Thanks in advance. > > Patrick > I have a webcalendar package I never submitted. You may want to take a look and if you find anything you like, feel free to take. http://www.bachelot.org/fedora/SPECS/webcalendar.spec http://www.bachelot.org/fedora/SRPMS/webcalendar-1.2.0-2.fc10.src.rpm Regards, Xavier From ssorce at redhat.com Fri May 29 17:55:23 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 29 May 2009 13:55:23 -0400 Subject: gnaughty is a hot babe In-Reply-To: <1243614606.2937.194.camel@adam.local.net> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1FAFE3.80302@gmail.com> <2a28d2ab0905290259g8103cb7p9856559a611ed465@mail.gmail.com> <4A1FB5CC.1060204@gmail.com> <1243614606.2937.194.camel@adam.local.net> Message-ID: <1243619723.4093.8.camel@localhost.localdomain> On Fri, 2009-05-29 at 09:30 -0700, Adam Williamson wrote: > On Fri, 2009-05-29 at 11:15 +0100, Frank Murphy (Frankly3d) wrote: > > > But I think morality it is delving away from fedora, > > unless it is global socially objectionable, > > maybe Child-Porn. > > I see this is this week's merry train-wreck of a discussion, but I can't > resist pointing out that even that isn't as clear-cut as you'd expect: > in Japan you can perfectly easily buy manga depicting extremely young > children having sex and just be thought of as a bit weird. (But just > like in the grown-up versions, the actual...appendages have to be very > minimally censored...*unlike* in most countries). Such things would > technically be legal in probably most western countries, but very > heavily frowned upon to say the least, and as a matter of practice, I > don't think you can really buy them elsewhere. FYI: Here in the US a 30+ year old manga collector is waiting for a sentence that can put him in jail for up to 15 years because he had a few of those manga. He didn't concentrate on any specific genre, he had thousands of manga's of any kind, so it is clear that he is not a pedophile, yet apparently he's going to be sentenced for something very akin to a thought-crime. My 2c just to reinforce the concept that what is acceptable or even criminal or not is extremely variable nation by nation. > To derive a more useful principle: there's almost no universal agreement > on any issue of what's 'culturally', 'morally', 'ethically' or whatever > acceptable, so it's effectively impossible for Fedora as a project to > create an 'Objectionable Content' label and apply it in a way that's > useful. If you are producing a spin for a group with sufficiently > continguous views on such things, it falls to you and no-one else to > ensure that the materials in your spin are appropriate for your > audience. 'We' - the project as a whole - don't necessarily share or > even fully understand your moral perspective, so you can't rely on us to > do it for you. I think this is the main point Muayyad should understand. Muayyad, if you feel this sort of filtering is necessary then you simply can't trust others to do it. Even if they had any interest in doing it because they may simply not understand your moral boundaries, let alone share them. Your best bet is to ask for help in your own community and come up with a method to allow your community members to tag packages, in a wiki associated to your spin, and then use those tags to build your package list. This would make it much easier for you and for the Fedora project. Simo. -- Simo Sorce * Red Hat, Inc * New York From bruno at wolff.to Fri May 29 18:06:14 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Fri, 29 May 2009 13:06:14 -0500 Subject: Plans for tomorrow's (20090529) FESCo meeting In-Reply-To: <1243618345.2937.210.camel@adam.local.net> References: <200905291033.20518.opensource@till.name> <20090529113607.GD3095@hansolo.jdub.homelinux.org> <20090529144920.GA31662@thinkpad.fab.redhat.com> <1243615672.2937.197.camel@adam.local.net> <4A201496.2070205@gmail.com> <1243618345.2937.210.camel@adam.local.net> Message-ID: <20090529180614.GA1312@wolff.to> On Fri, May 29, 2009 at 10:32:25 -0700, Adam Williamson wrote: > > NVIDIA and ATI are the major use case for MDV (and, frankly, for RPM > Fusion), so I came around to the view that it isn't really a good idea > to have kmods or DKMS in Fedora; the major use case for them doesn't > apply to Fedora and never will, and the other objections are pretty > valid for all the other cases for which DKMS / kmods can be used (either > this stuff should go straight into the kernel or we should not ship it). > And the pain involved in keeping the pre-built binaries in sync with the > kernel is significant. If you use telephony hardware you also have this problem as Digium doesn't want to upstream Dahdi / Zaptel so they can sell custom versions of the kernel drivers under different licenses. And no one else seems to have enough interest to fork the project and get it upstreamed. I suspect Sangoma has similar issues, but I don't own any of their stuff. From jwboyer at gmail.com Fri May 29 18:28:57 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 29 May 2009 14:28:57 -0400 Subject: gnaughty is a hot babe In-Reply-To: <1243616290.2937.200.camel@adam.local.net> References: <20090529092040.GA29375@redhat.com> <385866f0905290230n1170470cq31dc26c6dda35b6d@mail.gmail.com> <4A1FAD0D.4030608@fedoraproject.org> <20090529131959.GB3587@mcpierce-laptop.rdu.redhat.com> <385866f0905290627vcd933a9r98d75cc6f3581ae8@mail.gmail.com> <4A1FF116.2030303@conversis.de> <385866f0905290740y525b3d8el89194c4340fbc78b@mail.gmail.com> <1243615461.2937.195.camel@adam.local.net> <385866f0905290949n136744caya733b297d006bd8e@mail.gmail.com> <1243616290.2937.200.camel@adam.local.net> Message-ID: <20090529182857.GH3095@hansolo.jdub.homelinux.org> On Fri, May 29, 2009 at 09:58:10AM -0700, Adam Williamson wrote: >On Fri, 2009-05-29 at 19:49 +0300, Muayyad AlSadi wrote: >> > You're just transferring the work. In order to *generate* the list of >> > tens of packages to make _your_ life easier, someone else has to inspect >> > the tens of thousands of packages. >> and the someone else you refer to is fedora censorship board! >> no no like that, >> I asked for a unified place to put those things in the wiki >> if the maintainer decided that he does not want to add his package to >> the list we are not going to shoot him. > >If all you want is a page on the Wiki for you and notional other people >who are interested in excluding certain packages from their spins or >whatever to co-ordinate on listing which packages might be an issue, >then I don't think anyone would really object to that - all along we've >been saying that it's fine for you to include or exclude whatever you >like from your own spin on whatever grounds you choose, and this would >just be a bit of organization to help you with that. I certainly >wouldn't object to it. > >However, you haven't proposed it as that; you seem to have proposed it >as a packaging guideline. All packagers are supposed to respect >packaging guidelines (we only don't call them 'rules' because we're >trying to be all happy-clappy). If you really want this to be something >that packagers don't have to worry about unless they actually care about >it, then it shouldn't be a packaging guideline. You should just create >it as a page on the Wiki with no official status in any procedure. I >don't believe you need anyone's permission to do that, you can just go >ahead and do it. I will take blame for the packaging guideline. I suggested one be written based on what seemed to be a request to have this driven automatically for all packages. If this is just a volunteer-only, totally optional wiki page then I also see no problem. If this is something to be mandated, then the guideline would be necessary. josh From awilliam at redhat.com Fri May 29 19:09:48 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 29 May 2009 12:09:48 -0700 Subject: Plans for tomorrow's (20090529) FESCo meeting In-Reply-To: <20090529180614.GA1312@wolff.to> References: <200905291033.20518.opensource@till.name> <20090529113607.GD3095@hansolo.jdub.homelinux.org> <20090529144920.GA31662@thinkpad.fab.redhat.com> <1243615672.2937.197.camel@adam.local.net> <4A201496.2070205@gmail.com> <1243618345.2937.210.camel@adam.local.net> <20090529180614.GA1312@wolff.to> Message-ID: <1243624188.2937.213.camel@adam.local.net> On Fri, 2009-05-29 at 13:06 -0500, Bruno Wolff III wrote: > On Fri, May 29, 2009 at 10:32:25 -0700, > Adam Williamson wrote: > > > > NVIDIA and ATI are the major use case for MDV (and, frankly, for RPM > > Fusion), so I came around to the view that it isn't really a good idea > > to have kmods or DKMS in Fedora; the major use case for them doesn't > > apply to Fedora and never will, and the other objections are pretty > > valid for all the other cases for which DKMS / kmods can be used (either > > this stuff should go straight into the kernel or we should not ship it). > > And the pain involved in keeping the pre-built binaries in sync with the > > kernel is significant. > > If you use telephony hardware you also have this problem as Digium doesn't > want to upstream Dahdi / Zaptel so they can sell custom versions of > the kernel drivers under different licenses. That is, indeed, a problem. > And no one else seems to have > enough interest to fork the project and get it upstreamed. That would appear to be the correct solution :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From bochecha at fedoraproject.org Fri May 29 19:21:05 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Fri, 29 May 2009 21:21:05 +0200 Subject: gnaughty is a hot babe In-Reply-To: <385866f0905291036v5cf1e69ex8d41df1585a50dda@mail.gmail.com> References: <4A1EDFAD.4090803@conversis.de> <4A1FAD0D.4030608@fedoraproject.org> <20090529131959.GB3587@mcpierce-laptop.rdu.redhat.com> <385866f0905290627vcd933a9r98d75cc6f3581ae8@mail.gmail.com> <4A1FF116.2030303@conversis.de> <20090529143412.GA29443@nostromo.devel.redhat.com> <4A200B62.7020503@conversis.de> <20090529164812.GA32291@nostromo.devel.redhat.com> <4A201655.5000607@conversis.de> <385866f0905291036v5cf1e69ex8d41df1585a50dda@mail.gmail.com> Message-ID: <2d319b780905291221g62a59ef3wef8803e3143974df@mail.gmail.com> > it's a wiki page, if the packager was unwilling to put such > classification then he have no right to stop the reviewer from editing > the wiki page and if they both where unwilling to do so, they both > have no right from stopping the first offended user from editing the > wiki page, that's all. > so I can't see ?when it can cause a package to be rejected. You do realize that it's probably what is going to happen the most often: neither the packager nor the reviewer will care and add the package to the wiki page. Sure, maybe we'll try to be educated and add our packages to the wiki page in the beginning. But after some time, if it's not enforced, we (those who do not care) will just forget it. So I'm afraid that in the end, you (and those who care) will be the ones maintaining such a list. Now if that's what you want, others said it before: just do it, no one will stop you. Create the wiki page with a note about the fact that there might be false positives and that this is not mandatory to enter the Fedora repositories, add the few packages you know might be offensive to some people, and advertise the page here, closing this discussion in the same time :) Those who care will help you, those who don't will continue not caring or maybe try to discipline themselves and add their potentially offensive packages to the list. Regards, ---------- Mathieu Bridon (bochecha) From jussilehtola at fedoraproject.org Fri May 29 19:22:30 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Fri, 29 May 2009 22:22:30 +0300 Subject: gnaughty is a hot babe In-Reply-To: <1243619723.4093.8.camel@localhost.localdomain> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1FAFE3.80302@gmail.com> <2a28d2ab0905290259g8103cb7p9856559a611ed465@mail.gmail.com> <4A1FB5CC.1060204@gmail.com> <1243614606.2937.194.camel@adam.local.net> <1243619723.4093.8.camel@localhost.localdomain> Message-ID: <1243624950.2559.68.camel@localhost.localdomain> On Fri, 2009-05-29 at 13:55 -0400, Simo Sorce wrote: > I think this is the main point Muayyad should understand. > > Muayyad, if you feel this sort of filtering is necessary then > you simply can't trust others to do it. > Even if they had any interest in doing it because they may simply not > understand your moral boundaries, let alone share them. > > Your best bet is to ask for help in your own community and come up with > a method to allow your community members to tag packages, in a wiki > associated to your spin, and then use those tags to build your package > list. > > This would make it much easier for you and for the Fedora project. +1 There are so many different types of packages that could be considered controversial from cultural, idealistic or religious reasons that there is simply no way to please everyone. For instance, creationists might consider anything that has to do with evolution (such as evolution simulations or gene programs) as controversial, whereas for scientists they might be a necessity for daily work. Or, people such as RMS might consider every package which enhances interoperability with proprietary systems (such as Evolution's Exchange plugin) as suspicious. As to the implementation, as has been already suggested you can make your own internet page [even in the fedorapeople wiki?] (either by yourself or with a group of other concerned people) about packages you find controversial. Or, you can make your own repository that contains a metapackage which Conflicts with the packages you find detestable (or obsoletes them so that they can't be installed and they are even automatically removed from the systems that have some of them installed). Or even better: you can create your own spin / distribution with the packages you find detestable removed. Simply start from a minimal install and add only the packages you need. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From alsadi at gmail.com Fri May 29 19:52:38 2009 From: alsadi at gmail.com (Muayyad AlSadi) Date: Fri, 29 May 2009 22:52:38 +0300 Subject: gnaughty is a hot babe In-Reply-To: <1243624950.2559.68.camel@localhost.localdomain> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1FAFE3.80302@gmail.com> <2a28d2ab0905290259g8103cb7p9856559a611ed465@mail.gmail.com> <4A1FB5CC.1060204@gmail.com> <1243614606.2937.194.camel@adam.local.net> <1243619723.4093.8.camel@localhost.localdomain> <1243624950.2559.68.camel@localhost.localdomain> Message-ID: <385866f0905291252y8afbd5bob701cd09aee8e18e@mail.gmail.com> > So I'm afraid that in the end, you (and those who care) will be the ones maintaining such a list. NP, how about calling that wiki page InappropriatePackagesAdvisory ? From awilliam at redhat.com Fri May 29 20:10:00 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 29 May 2009 13:10:00 -0700 Subject: gnaughty is a hot babe In-Reply-To: <1243624950.2559.68.camel@localhost.localdomain> References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1FAFE3.80302@gmail.com> <2a28d2ab0905290259g8103cb7p9856559a611ed465@mail.gmail.com> <4A1FB5CC.1060204@gmail.com> <1243614606.2937.194.camel@adam.local.net> <1243619723.4093.8.camel@localhost.localdomain> <1243624950.2559.68.camel@localhost.localdomain> Message-ID: <1243627800.2937.232.camel@adam.local.net> On Fri, 2009-05-29 at 22:22 +0300, Jussi Lehtola wrote: > Or even better: you can create your own spin / distribution with the > packages you find detestable removed. Simply start from a minimal > install and add only the packages you need. You don't seem to have followed the discussion from the beginning. He is the maintainer of such a spin. What he seems to be looking for is a central reference point of convenience where people who maintain such spins can note down what packages are potentially troublesome for future reference. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From bochecha at fedoraproject.org Fri May 29 20:45:18 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Fri, 29 May 2009 22:45:18 +0200 Subject: gnaughty is a hot babe In-Reply-To: <385866f0905291252y8afbd5bob701cd09aee8e18e@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1FAFE3.80302@gmail.com> <2a28d2ab0905290259g8103cb7p9856559a611ed465@mail.gmail.com> <4A1FB5CC.1060204@gmail.com> <1243614606.2937.194.camel@adam.local.net> <1243619723.4093.8.camel@localhost.localdomain> <1243624950.2559.68.camel@localhost.localdomain> <385866f0905291252y8afbd5bob701cd09aee8e18e@mail.gmail.com> Message-ID: <2d319b780905291345j2e566d21vcbca4765b5505b51@mail.gmail.com> On Fri, May 29, 2009 at 21:52, Muayyad AlSadi wrote: >> So I'm afraid that in the end, you (and those who care) will be the ones maintaining such a list. > > NP, how about calling that wiki page InappropriatePackagesAdvisory ? Don't tie words together, separate them with spaces (MediaWiki will transform them in underscores). This will ease the searching. Also, those packages are not inappropriate. They _might be_. Try to keep this nuance in the name of the page, this will avoid some people to be pissed (well, some others will always be :). The rest is just common sense, name it the way you want. Regards, ---------- Mathieu Bridon (bochecha) From drago01 at gmail.com Fri May 29 20:54:08 2009 From: drago01 at gmail.com (drago01) Date: Fri, 29 May 2009 22:54:08 +0200 Subject: Plans for tomorrow's (20090529) FESCo meeting In-Reply-To: <2d319b780905290857l33cc68apb4e1acc4beda0a90@mail.gmail.com> References: <200905291033.20518.opensource@till.name> <20090529113607.GD3095@hansolo.jdub.homelinux.org> <20090529144920.GA31662@thinkpad.fab.redhat.com> <2d319b780905290857l33cc68apb4e1acc4beda0a90@mail.gmail.com> Message-ID: On Fri, May 29, 2009 at 5:57 PM, Mathieu Bridon (bochecha) wrote: >>> How does putting those kmods in a third-party repo fix this? And they WILL >>> and DO end up there. Even if you get RPM Fusion to ban kmods (which I >>> doubt >>> will ever happen), they'll just migrate to another third-party repo. You >>> can't eliminate kmods entirely, no matter how hard you try. > > kmod-gspca has been available in livna for a long time. And I loved > it, as it provided me an easy way to use my webcam. > > But at every kernel update, it was a PITA to wait for the kmod until I > could update the kernel. > > If Fedora had accepted the kmod in its repositories, would it have > ever been included in mainstream kernel as it is today (which is the > only real solution) ? > > By refusing kmods, we have more motivation to actually try and include > upstream what we really need to use. If we can simply install the > kmod, who cares if it's upstreamed ? This particular one _IS_ upstreamed. It was merged upstream in 2.6.28. 2.6.29.4 is in F10 updates-testing and F11 will ship with a .29 based kernel anyway. So you don't really need it anymore ;) From stickster at gmail.com Fri May 29 20:56:59 2009 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 29 May 2009 16:56:59 -0400 Subject: gnaughty is a hot babe In-Reply-To: <20090529182857.GH3095@hansolo.jdub.homelinux.org> References: <385866f0905290230n1170470cq31dc26c6dda35b6d@mail.gmail.com> <4A1FAD0D.4030608@fedoraproject.org> <20090529131959.GB3587@mcpierce-laptop.rdu.redhat.com> <385866f0905290627vcd933a9r98d75cc6f3581ae8@mail.gmail.com> <4A1FF116.2030303@conversis.de> <385866f0905290740y525b3d8el89194c4340fbc78b@mail.gmail.com> <1243615461.2937.195.camel@adam.local.net> <385866f0905290949n136744caya733b297d006bd8e@mail.gmail.com> <1243616290.2937.200.camel@adam.local.net> <20090529182857.GH3095@hansolo.jdub.homelinux.org> Message-ID: <20090529205659.GY8435@localhost.localdomain> On Fri, May 29, 2009 at 02:28:57PM -0400, Josh Boyer wrote: > On Fri, May 29, 2009 at 09:58:10AM -0700, Adam Williamson wrote: > >On Fri, 2009-05-29 at 19:49 +0300, Muayyad AlSadi wrote: > >> > You're just transferring the work. In order to *generate* the list of > >> > tens of packages to make _your_ life easier, someone else has to inspect > >> > the tens of thousands of packages. > >> and the someone else you refer to is fedora censorship board! > >> no no like that, > >> I asked for a unified place to put those things in the wiki > >> if the maintainer decided that he does not want to add his package to > >> the list we are not going to shoot him. > > > >If all you want is a page on the Wiki for you and notional other people > >who are interested in excluding certain packages from their spins or > >whatever to co-ordinate on listing which packages might be an issue, > >then I don't think anyone would really object to that - all along we've > >been saying that it's fine for you to include or exclude whatever you > >like from your own spin on whatever grounds you choose, and this would > >just be a bit of organization to help you with that. I certainly > >wouldn't object to it. > > > >However, you haven't proposed it as that; you seem to have proposed it > >as a packaging guideline. All packagers are supposed to respect > >packaging guidelines (we only don't call them 'rules' because we're > >trying to be all happy-clappy). If you really want this to be something > >that packagers don't have to worry about unless they actually care about > >it, then it shouldn't be a packaging guideline. You should just create > >it as a page on the Wiki with no official status in any procedure. I > >don't believe you need anyone's permission to do that, you can just go > >ahead and do it. > > I will take blame for the packaging guideline. I suggested one be > written based on what seemed to be a request to have this driven > automatically for all packages. > > If this is just a volunteer-only, totally optional wiki page then I > also see no problem. If this is something to be mandated, then the > guideline would be necessary. This is the sanest answer I've heard thus far. If you want a wiki page to display or track something like this, create it. If others feel it's useful, they will help. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From jkeating at redhat.com Fri May 29 20:57:11 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 29 May 2009 13:57:11 -0700 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 Message-ID: <1243630631.3037.149.camel@localhost.localdomain> We're announcing a Fedora Activity day coming up very very soon (apologies for the short notice). This activity day is for maintainers, QA, and release engineering folks to meet and discuss ongoing issues with the Fedora Development Cycle and to create a proposal on how to fix many of the issues. Note, this is not an event to decide on a solution, it is an event to decide on a proposal, which will then be shared with the whole community for more input and work. The timing of this is very short, so that we may have a chance at changing something within the Fedora 12 development cycle. Funding for the event was only confirmed a day or two ago, hence the late notice. If unable to attend (which most will be) but highly interested in helping with the process, we will be attempting to setup a Fedora Talk conference room to use throughout the event, as well as an IRC channel. We'll try to blog the process as well and gather feedback to be used during the event. If you will be able to attend in person, please add your name to the wiki page [1] so that we can properly plan the space needed within RHT. While the wiki page says that the page is still under construction, the dates are solid, the hours during the day are mostly solid, and the location (one of the RHT buildings) is solid. Please feel free to use the discussion page on the wiki to express your thoughts about the event and what problems you're having with the development cycle. Even thoughts on the initial proposal I drew up at the bottom of the wiki page would be welcome, although I do believe that this event will result in a proposal different from what is currently listed. Again we apologize for the short notice! [1]: https://fedoraproject.org/wiki/Fedora_Activity_Day_Fedora_Development_Cycle_2009 -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From awilliam at redhat.com Fri May 29 21:08:00 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 29 May 2009 14:08:00 -0700 Subject: Plans for tomorrow's (20090529) FESCo meeting In-Reply-To: References: <200905291033.20518.opensource@till.name> <20090529113607.GD3095@hansolo.jdub.homelinux.org> <20090529144920.GA31662@thinkpad.fab.redhat.com> <2d319b780905290857l33cc68apb4e1acc4beda0a90@mail.gmail.com> Message-ID: <1243631280.2937.235.camel@adam.local.net> On Fri, 2009-05-29 at 22:54 +0200, drago01 wrote: > > kmod-gspca has been available in livna for a long time. And I loved > > it, as it provided me an easy way to use my webcam. > > > > But at every kernel update, it was a PITA to wait for the kmod until I > > could update the kernel. > > > > If Fedora had accepted the kmod in its repositories, would it have > > ever been included in mainstream kernel as it is today (which is the > > only real solution) ? > > > > By refusing kmods, we have more motivation to actually try and include > > upstream what we really need to use. If we can simply install the > > kmod, who cares if it's upstreamed ? > > This particular one _IS_ upstreamed. It was merged upstream in 2.6.28. > 2.6.29.4 is in F10 updates-testing and F11 will ship with a .29 based > kernel anyway. > > So you don't really need it anymore ;) That was his point. He was saying that, if kmods were accepted in Fedora, Fedora developers and users may not have done the work / provided the pressure for it to be upstreamed. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From maxamillion at gmail.com Fri May 29 21:43:45 2009 From: maxamillion at gmail.com (Adam Miller) Date: Fri, 29 May 2009 16:43:45 -0500 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <1243630631.3037.149.camel@localhost.localdomain> References: <1243630631.3037.149.camel@localhost.localdomain> Message-ID: On the wiki page is says that the Budget will be used for certain attendees "Flights, Hotel, Transportation to/from airport/hotel/office/food" I was just curious how that list of attendees who's bill will be taken care of is/was decided upon? -Adam -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From jkeating at redhat.com Fri May 29 22:17:02 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 29 May 2009 15:17:02 -0700 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: References: <1243630631.3037.149.camel@localhost.localdomain> Message-ID: <1243635422.3037.155.camel@localhost.localdomain> On Fri, 2009-05-29 at 16:43 -0500, Adam Miller wrote: > On the wiki page is says that the Budget will be used for certain > attendees "Flights, Hotel, Transportation to/from > airport/hotel/office/food" I was just curious how that list of > attendees who's bill will be taken care of is/was decided upon? We invited a couple members specifically to this event, and those folks will be covered. I organized the event and wanted specific people there, and got the funding for those people. I think that's how FADs are going to work, somebody has an idea, organizes it and decides (with help of the Fedora Community Action Team) who is funded. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From inode0 at gmail.com Fri May 29 22:48:44 2009 From: inode0 at gmail.com (inode0) Date: Fri, 29 May 2009 17:48:44 -0500 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <1243630631.3037.149.camel@localhost.localdomain> References: <1243630631.3037.149.camel@localhost.localdomain> Message-ID: On Fri, May 29, 2009 at 3:57 PM, Jesse Keating wrote: > We're announcing a Fedora Activity day coming up very very soon > (apologies for the short notice). ?This activity day is for maintainers, > QA, and release engineering folks to meet and discuss ongoing issues > with the Fedora Development Cycle and to create a proposal on how to fix > many of the issues. ?Note, this is not an event to decide on a solution, > it is an event to decide on a proposal, which will then be shared with > the whole community for more input and work. > > ... snip ... Jesse, I just want to wish you guys a great and productive FAD. I hope it inspires other community members to look for opportunities within the parts of the project they work on to organize their own FADs in the future. If a group of folks in Docs or Art or Infra or whatever could get something important done faster/better by getting together in the same place please do it. If you think you have a good idea but are uncertain how to make it happen feel free to ping your friendly neighborhood ambassador and we'd be happy to help you get the ball rolling. John From kevin.kofler at chello.at Sat May 30 01:28:59 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 30 May 2009 03:28:59 +0200 Subject: gnaughty is a hot babe References: <4A1E5CC4.2060506@fedoraproject.org> <20090528205136.023d31ac@defender> <20090528130643.50677d14@schafwiese> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1FAFE3.80302@gmail.com> <2a28d2ab0905290259g8103cb7p9856559a611ed465@mail.gmail.com> <4A1FB5CC.1060204@gmail.com> <1243614606.2937.194.camel@adam.local.net> <1243619723.4093.8.camel@localhost.localdomain> <1243624950.2559.68.camel@localhost.localdomain> Message-ID: Jussi Lehtola wrote: > For instance, creationists might consider anything that has to do with > evolution (such as evolution simulations or gene programs) as > controversial Or even the mail client which happens to be called "Evolution". Kevin Kofler From jspaleta at gmail.com Sat May 30 02:25:50 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 29 May 2009 18:25:50 -0800 Subject: gnaughty is a hot babe In-Reply-To: References: <4A1E5CC4.2060506@fedoraproject.org> <4A1EDFAD.4090803@conversis.de> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1FAFE3.80302@gmail.com> <2a28d2ab0905290259g8103cb7p9856559a611ed465@mail.gmail.com> <4A1FB5CC.1060204@gmail.com> <1243614606.2937.194.camel@adam.local.net> <1243619723.4093.8.camel@localhost.localdomain> <1243624950.2559.68.camel@localhost.localdomain> Message-ID: <604aa7910905291925i53ef830fs82d1a9437fd8566a@mail.gmail.com> On Fri, May 29, 2009 at 5:28 PM, Kevin Kofler wrote: > Or even the mail client which happens to be called "Evolution". I know for a fact that said mail client is a product of intelligent design...so that should take the edge of that particular debate. -jef"nice threadjacking attempt, I salute you!"spaleta From poelstra at redhat.com Sat May 30 04:52:07 2009 From: poelstra at redhat.com (John Poelstra) Date: Fri, 29 May 2009 21:52:07 -0700 Subject: Plans for tomorrow's (20090529) FESCo meeting In-Reply-To: <200905291501.35665.opensource@till.name> References: <200905291033.20518.opensource@till.name> <20090529113607.GD3095@hansolo.jdub.homelinux.org> <200905291501.35665.opensource@till.name> Message-ID: <4A20BB77.8000604@redhat.com> Till Maas said the following on 05/29/2009 06:01 AM Pacific Time: > On Fri May 29 2009, Josh Boyer wrote: > >> I don't see a problem. > > Imho outdated content reduces the quality of the wiki, therefore there should > be some garbage collection. > >> If the Feature owner cares enough to keep proposing it, then FESCo will >> keep reviewing it. Technical items change over time. Perhaps the >> VirtualBox module will make it into the upstream kernel and the Feature >> will be viable. Or perhaps a future FESCo will revist kmods. > > Did you look at the content of the feature page? Even in the very unlikely > case that it may be included in Fedora in the future, Fedora will probably be > the last distribution to include it, so it is also very unlikely that it even > meats the Feature criteria. And if it does, there are only four sentences in > the Feature page, that were not in the template. > > >> If the Feature owner doesn't care, then they can delete the page. Either >> way, I don't see what the problem is with having it sit in the >> FeaturePageIncomplete category. > > It seems more to me, that the Feature owner does not care, because the package > is very incomplete and I got no response from my comment in December 2008 that > Virtualbox won't make it into Fedora. Btw. how does the Feature owner delete > the page? It seems to me, that this is not easily possible using the wiki > interface. > Try this :) https://fedoraproject.org/wiki/FedoraProject:Deletion From pmatilai at laiskiainen.org Sat May 30 08:15:47 2009 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Sat, 30 May 2009 11:15:47 +0300 (EEST) Subject: Removing %clean (Was Re: Agenda for the 2009-05-26 Packaging Committee meeting) In-Reply-To: <4A1C3CD7.7040600@redhat.com> References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1C3CD7.7040600@redhat.com> Message-ID: On Tue, 26 May 2009, Tom \spot\ Callaway wrote: > On 05/26/2009 04:10 AM, Richard W.M. Jones wrote: >> I vote for also removing the %clean section. > > So, looking at this objectively, here are the technical problems: > > * We're defining a BuildRoot in the spec, but that definition is no > longer used (Fedora 10 or higher), because rpm now automagically sets it > for us. > * We're typing rm -rf %{buildroot} multiple times in every single Fedora > specfile. We want to invoke it twice: > - As the very first operation of the %install scriptlet > - As the very first operation of the %clean scriptlet > > The concerns around removing the BuildRoot from the spec is that if that > spec is taken to an older system, the spec would either > * Not work > * Set the BuildRoot to / and cause massive system destruction > > The good news is that for all the Fedora targets that we care about, if > BuildRoot is unset, it is just unset. It never gets set to / on anything > we care about (including RHEL 4 and 5, I checked). > And I really don't think we need to care about anything older than RHEL > 4 (roughly equivalent to Fedora 6). A comment in the packaging > guidelines should be sufficient, so simply dropping the unnecessary > BuildRoot definition as soon as Fedora 9 is EOL seems like a sane course > of action. > > The %install scriptlet case is reasonably simple to solve with > redhat-rpm-config's customized macros file, simply add: > > %__spec_install_pre %{___build_pre}\ > [ "$RPM_BUILD_ROOT" != "/" ] && rm -rf "${RPM_BUILD_ROOT}"\ > mkdir -p `dirname "$RPM_BUILD_ROOT"`\ > mkdir "$RPM_BUILD_ROOT"\ > %{nil} > > This ensures that every time %install is invoked in a spec file, it > checks that buildroot isn't / (which, it should never ever be, but given > the past history, doesn't hurt to check), then deletes it. Next, it > makes the basedir of $RPM_BUILD_ROOT, in case that doesn't exist, then > makes the buildroot for us, saving additional pain in some Fedora spec > files where the make install process is either too dumb to do this for > us (or non-existant). Yup, %install part is mostly a no-brainer. While at it... redhat-rpm-config redefines %install, %build and some others as macros which has some strange/unwanted side-effects. Switching these to use templates instead wouldn't hurt. > The %clean scriptlet case is harder. Lets get the easy case out of the > way, removing the obligatory rm -rf %{buildroot} invocation: > > %__spec_clean_pre %{___build_pre}\ > [ "$RPM_BUILD_ROOT" != "/" ] && rm -rf "${RPM_BUILD_ROOT}"\ > %{nil} > > With that, every time %clean is invoked in a spec file, it checks that > buildroot isn't /, and then deletes it if it is not. > > However, that doesn't really resolve the deeper desire, which is as > Richard points out, is to remove the need to explicitly state the %clean > section at all. If we need to overload it beyond its defaults, we should > be able to invoke it manually and append to it, but if it is not set, it > should be invoked automagically. > > RPM doesn't act this way. For all scriptlets, their absence does not > result in automatic invocation (there is no idea of "always executed" > default scriptlets in a spec), but instead is how they are omitted. I > can certainly see valid use cases where a package would not want %clean > to be invoked. It might be possible to change RPM's behavior to > introduce a disabler mechanism for default "always executed" scriptlets: > > > %disable %check > > > This would be a significant behavior change for RPM, and not something > we could do with distribution specific macro tweaks. It would also break > backwards compatibility with older RPM spec files, which has > traditionally been avoided. Another, perhaps simpler alternative would be making rpm inject default %clean action when spec doesn't define one. To disable/customize the default behavior, you'd just add an empty (or otherwise custom) %clean in the spec, no special disabler logic required. It is of course a change of behavior in rpm but allows getting rid of the %clean section in 99% of specs and permits backwards compatibility too: if you want to have %clean do (or not do) whatever you want, you just keep the %clean section in the spec. It'd make those special cases stand out clearly too, all you have to do is grep for %clean. > > ***** > > So, given those facts, and assuming that RPM isn't changing its > behaviors anytime soon, we can make macro changes in redhat-rpm-config > and change from this: > > BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) > ... > > %install > rm -rf %{buildroot} > make DESTDIR=%{buildroot} install > ... > > %clean > rm -rf %{buildroot} > ... > > TO: > > ... > %install > make DESTDIR=%{buildroot} install > ... > %clean > ... > > Is anyone opposed to that? No objections to BuildRoot and %install parts, but I'd suggest leaving %clean out of it for the time being, as this is on direct collision course with the above suggestion of built-in default %clean. - Panu - From alsadi at gmail.com Sat May 30 09:44:13 2009 From: alsadi at gmail.com (Muayyad AlSadi) Date: Sat, 30 May 2009 12:44:13 +0300 Subject: gnaughty is a hot babe In-Reply-To: <604aa7910905291925i53ef830fs82d1a9437fd8566a@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1FAFE3.80302@gmail.com> <2a28d2ab0905290259g8103cb7p9856559a611ed465@mail.gmail.com> <4A1FB5CC.1060204@gmail.com> <1243614606.2937.194.camel@adam.local.net> <1243619723.4093.8.camel@localhost.localdomain> <1243624950.2559.68.camel@localhost.localdomain> <604aa7910905291925i53ef830fs82d1a9437fd8566a@mail.gmail.com> Message-ID: <385866f0905300244l61ae869bl8090bc6138c99cec@mail.gmail.com> does the upstream web site for evolution carries a note that it's not suitable for certain group of users ? does the maintainers or reviewers see that it should ? am I the only one who knows that "if p then q" will evaluate to T when p=F yes, I hope that no one in fedora project pack nudity images in official repos of fedora, but I have no power to stop them from doing so, that's way I suggested when someone want's to do let he warn us in a wiki page if he or his upstream carries such a note. some one asked me to pay the rating fees for every package! other started to give me examples about different people having different opinions I consider all this is off-topic. yes, English is not my first language, and law is not one of my interests, and for sure there exists a better phrasing of the page https://fedoraproject.org/wiki/PackagingDrafts/InappropriateContents but nobody have shown me a serious problem in that page > Don't tie words together, separate them with spaces (MediaWiki will transform them in underscores). ok that's an easy task Inappropriate_Packages_Advisory > Also, those packages are not inappropriate. They _might be_. let's say Suggested_Inappropriate_Packages_Advisory but I guess that Advisory and Suggested carries same meaning I think we should go with one of the two words (either Suggested or Advisory) From jussilehtola at fedoraproject.org Sat May 30 09:52:03 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Sat, 30 May 2009 12:52:03 +0300 Subject: gnaughty is a hot babe In-Reply-To: <385866f0905300244l61ae869bl8090bc6138c99cec@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1FAFE3.80302@gmail.com> <2a28d2ab0905290259g8103cb7p9856559a611ed465@mail.gmail.com> <4A1FB5CC.1060204@gmail.com> <1243614606.2937.194.camel@adam.local.net> <1243619723.4093.8.camel@localhost.localdomain> <1243624950.2559.68.camel@localhost.localdomain> <604aa7910905291925i53ef830fs82d1a9437fd8566a@mail.gmail.com> <385866f0905300244l61ae869bl8090bc6138c99cec@mail.gmail.com> Message-ID: <1243677123.4732.1.camel@localhost.localdomain> On Sat, 2009-05-30 at 12:44 +0300, Muayyad AlSadi wrote: > yes, English is not my first language, and law is not one of my > interests, and for sure there exists a better phrasing of the page > https://fedoraproject.org/wiki/PackagingDrafts/InappropriateContents > > but nobody have shown me a serious problem in that page Yes, they have: there's no way there's going to be a Packaging Guideline on the matter (a Packaging Draft is a Packaging Guideline wanna-be / to-be). If you want such a page just do it and don't try to make it an official guideline. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From pmatilai at laiskiainen.org Sat May 30 09:53:07 2009 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Sat, 30 May 2009 12:53:07 +0300 (EEST) Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <20090527072531.GA2413@amd.home.annexia.org> <4A1D91D4.4080909@redhat.com> Message-ID: On Wed, 27 May 2009, Seth Vidal wrote: > > On Wed, 27 May 2009, Tom \"spot\" Callaway wrote: > >> On 05/27/2009 03:07 PM, Seth Vidal wrote: >>> but I'm sure we'll muddle through - provided this is included in >>> upstream rpm. >> >> I think the key here is that we're waiting to deal with this particular >> dilemma when upstream rpm has this functionality set. >> > > and the last time I asked - the current patches for this feature for rpm were > from suse's rpm and they were not liked, at all, by other rpm.org devs. Apart from some mostly cosmetical issues, the problem with the soft dependency patches of Suse (which Mandriva uses too) is not so much what they do, but what they dont do. I've been on the verge of committing the patches several times and got stuck in the semantics swamp as many times. The Suse patches only define "rpm doesn't care" semantics, leaving everything to upper layers. Which seems kinda ok at first sight, but on a closer look I always end up with "but rpm does need to know, to some extent at least." Take for example package A with Requires(post): C Recommends(post): B What does that mean? Probably the %post script of A does something extra if B is present at that time, otherwise it wouldn't have such a dependency (one possible example of this could be mkinitrd). So at the very least ordering code in rpm should know about the soft dependencies, at which point rpm needs to have means to work with soft dependency sets too. Or consider "Recommends: B >= 1.2" - what exactly does this mean? The package does something "better" if B is installed too, but what if we only have B 1.0 installed/available. Does the package even work with B 1.0? If it doesn't work with B 1.0, should rpm emit an error in such a case? If the version doesn't match, should B be pulled in anyway? Or like you pointed out, what if a soft dependency conflicts with something. That something might even be pulled in due to other soft dependencies. Or hard dependencies of a soft dependency are unresolvable, is it an error or just quietly ignore the entire soft dep. Etc. And that's just one side of it, the other half (Enhances) introduces a whole new dependency type: reverse dependencies (ie a package can claim another package to depend on itself) which is unlike anything rpm currently knows about. What makes it even more of an oddball is that there are no hard reverse dependencies, only soft ones. Reverse (soft or not) dependencies would be useful in a number of cases for third party repositories and such but they're also quite controversial and "dangerous" if abused. - Panu - From pmatilai at laiskiainen.org Sat May 30 10:36:02 2009 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Sat, 30 May 2009 13:36:02 +0300 (EEST) Subject: mimehandler automatic Provides? In-Reply-To: <4A1A5C85.6000508@ioa.s.u-tokyo.ac.jp> References: <20090525103501.0f1b7571@faldor.intranet> <4A1A5C85.6000508@ioa.s.u-tokyo.ac.jp> Message-ID: On Mon, 25 May 2009, Mamoru Tasaka wrote: > Michael Schwendt wrote, at 05/25/2009 05:35 PM +9:00: >> Are they related to >> http://fedoraproject.org/wiki/Features/AutoFontsAndMimeInstaller >> ? > > Yes. > >> audacity = 1.3.7-0.6.beta.fc11 >> Build Time 2009-03-02 16:40:30 GMT >> >> mimehandler(application/ogg) >> mimehandler(application/x-audacity-project) >> mimehandler(audio/basic) >> mimehandler(audio/x-aifc) >> mimehandler(audio/x-aiff) >> mimehandler(audio/x-aiffc) >> mimehandler(audio/x-wav) >> >> >> And in a later build they are not added anymore. >> >> audacity = 1.3.7-0.7.beta.fc11 >> Build Time 2009-05-13 08:50:08 GMT >> Searching the Wiki for "mimehandler" yields no results. > > I guess this is related to > - https://bugzilla.redhat.com/show_bug.cgi?id=494817 > - and "file" seems to have changed between these two days. Rpm changed too between these two, and that's what makes the difference here: tweak for something else broke this particular case. > Note that Panu said that the above bug was fixed in F-12 > rpm and actually 1.3.7-0.7.beta.fc12 has some mimetype Provides. Yup, the fix needs pulling into F11 too along with some others, but the fixes aren't quite critical enough to warrant requesting a freeze break and I dont really want yet another zero-day update either... but anyway an update to F11 rpm is pending sooner than later. - Panu - From bochecha at fedoraproject.org Sat May 30 11:19:20 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Sat, 30 May 2009 13:19:20 +0200 Subject: gnaughty is a hot babe In-Reply-To: <385866f0905300244l61ae869bl8090bc6138c99cec@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <4A1FAFE3.80302@gmail.com> <2a28d2ab0905290259g8103cb7p9856559a611ed465@mail.gmail.com> <4A1FB5CC.1060204@gmail.com> <1243614606.2937.194.camel@adam.local.net> <1243619723.4093.8.camel@localhost.localdomain> <1243624950.2559.68.camel@localhost.localdomain> <604aa7910905291925i53ef830fs82d1a9437fd8566a@mail.gmail.com> <385866f0905300244l61ae869bl8090bc6138c99cec@mail.gmail.com> Message-ID: <2d319b780905300419q2b95c46aue7c70a5062f04fef@mail.gmail.com> >> Don't tie words together, separate them with spaces (MediaWiki will transform them in underscores). > > ok that's an easy task > Inappropriate_Packages_Advisory > >> Also, those packages are not inappropriate. They _might be_. > let's say Suggested_Inappropriate_Packages_Advisory > but I guess that Advisory and Suggested carries same meaning > I think we should go with one of the two words (either Suggested or Advisory) I think you should just do it and stop asking for permission :) Pick an appropriate name and create the page. If you are not sure because you're not a native english speaker, I'd suggest ? Potentially Inappropriate Packages ? as a name (but I'm not a native english speaker either :). Once again, just create the page, leave a notice about it here (providing the URL) and let this thread die in peace. You'll see that those who care will help you and edit the page, adding more packages to the list. You'll have your list, package maintainers won't have to abide to a restrictive guideline, everyone will be happy. In the end, the only ones who will keep this thread alive are those who are simply ranting because they like to rant. No need to respond to them. ;) Regards, ---------- Mathieu Bridon (bochecha) From frankly3d at gmail.com Sat May 30 12:23:47 2009 From: frankly3d at gmail.com (Frank Murphy (Frankly3d)) Date: Sat, 30 May 2009 13:23:47 +0100 Subject: Fedora Mips\Arm Processors? Message-ID: <4A212553.8020200@gmail.com> Looking at following: http://broadcast.oreilly.com/2009/05/the-mips-processor-and-the-150-1.html How is Fedora in regards to running mips\arm processors? Frank -- msn: frankly3d skype: frankly3d Mailing-List Reply to: Mailing-List Still Learning, Unicode where possible From andreas at bawue.net Sat May 30 13:15:54 2009 From: andreas at bawue.net (Andreas Thienemann) Date: Sat, 30 May 2009 15:15:54 +0200 (CEST) Subject: RPM Soft dependencies (Was: Re: Agenda for the 2009-05-26 Packaging Committee meeting) In-Reply-To: References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <20090527072531.GA2413@amd.home.annexia.org> <4A1D91D4.4080909@redhat.com> Message-ID: On Sat, 30 May 2009, Panu Matilainen wrote: > Apart from some mostly cosmetical issues, the problem with the soft > dependency patches of Suse (which Mandriva uses too) is not so much what > they do, but what they dont do. I've been on the verge of committing the > patches several times and got stuck in the semantics swamp as many times. > The Suse patches only define "rpm doesn't care" semantics, leaving > everything to upper layers. Which seems kinda ok at first sight, but on a > closer look I always end up with "but rpm does need to know, to some > extent at least." Your example explains why the current SuSE way of doing soft dependencies is not the best way of doing it. But I think everyone is in agreement that we need soft dependencies in order to sort out our current dependency mess. It increasingly happens that half the desktop is being pulled in for system services. Soft dependencies, together with dlopen() might be a good way of solving this. Therefore I'm wondering: Are there any better ways of solving this and when can we expect them? :) regards, andreas From andreas at bawue.net Sat May 30 13:26:15 2009 From: andreas at bawue.net (Andreas Thienemann) Date: Sat, 30 May 2009 15:26:15 +0200 (CEST) Subject: gnaughty is a hot babe In-Reply-To: <385866f0905300244l61ae869bl8090bc6138c99cec@mail.gmail.com> References: <4A1E5CC4.2060506@fedoraproject.org> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1FAFE3.80302@gmail.com> <2a28d2ab0905290259g8103cb7p9856559a611ed465@mail.gmail.com> <4A1FB5CC.1060204@gmail.com> <1243614606.2937.194.camel@adam.local.net> <1243619723.4093.8.camel@localhost.localdomain> <1243624950.2559.68.camel@localhost.localdomain> <604aa7910905291925i53ef830fs82d1a9437fd8566a@mail.gmail.com> <385866f0905300244l61ae869bl8090bc6138c99cec@mail.gmail.com> Message-ID: On Sat, 30 May 2009, Muayyad AlSadi wrote: > does the upstream web site for evolution carries a note that it's not > suitable for certain group of users ? > does the maintainers or reviewers see that it should ? Read the lwn.net article about hot babe. The easily offended editor mentioned that the --color functionality of ls offends him and he wants it gone. If a reviewer feels the same your page will be swamped with "bogus" reports of offending tools. Or if another fedora user disagrees with a tool being flagged as "inappropriate", he might even remove the tool from the list. > am I the only one who knows that "if p then q" will evaluate to T when p=F As you neither did define the relation of T or F to either p or q your "proof" is just a logical fallacy. I fear the same is true for your inappropriateness-rating. It's full of fail. > some one asked me to pay the rating fees for every package! > other started to give me examples about different people having > different opinions > I consider all this is off-topic. I think your missing the point. People pointing out problems with your approach are not off-topic. They are very much on-topic. Declaring their objections as off-topic doesn't make the underlying problem go away. > yes, English is not my first language, and law is not one of my > interests, and for sure there exists a better phrasing of the page > https://fedoraproject.org/wiki/PackagingDrafts/InappropriateContents > but nobody have shown me a serious problem in that page Read the discussion, read the comment placed directly on the page. I think the best way of solving your issue is to gather other people interested in your specific spin and generate a list of acceptable programs. Don't base it on any opinion a random fedora user might or might not have. Have the list on a page you directly control. This is especially important as any programm you might not flag correctly will reflect badly on your spin. The wiki on fedoraproject.org is most likely not the right place for such a list. You know the saying: Right tool for the right job. regards, andreas From rawhide at fedoraproject.org Sat May 30 13:42:11 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Sat, 30 May 2009 13:42:11 +0000 (UTC) Subject: rawhide report: 20090530 changes Message-ID: <20090530134211.D94211F8217@releng2.fedora.phx.redhat.com> Compose started at Sat May 30 06:15:04 UTC 2009 Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 0 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From dan at danny.cz Sat May 30 14:41:46 2009 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Sat, 30 May 2009 16:41:46 +0200 Subject: Fedora Mips\Arm Processors? In-Reply-To: <4A212553.8020200@gmail.com> References: <4A212553.8020200@gmail.com> Message-ID: <1243694506.3740.55.camel@eagle.danny.cz> Frank Murphy (Frankly3d) p??e v So 30. 05. 2009 v 13:23 +0100: > Looking at following: > > http://broadcast.oreilly.com/2009/05/the-mips-processor-and-the-150-1.html > > How is Fedora in regards to running mips\arm processors? Fedora/ARM is an alive secondary architecture - see https://fedoraproject.org/wiki/Architectures/ARM for details. There is no public effort to port Fedora to MIPS, but someone (connected to a netbook vendor?) was asking some questions about our buildsystem. Dan From mschwendt at gmail.com Sat May 30 15:11:10 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sat, 30 May 2009 17:11:10 +0200 Subject: rawhide report: 20090528 changes In-Reply-To: <1243617086.2937.203.camel@adam.local.net> References: <20090528140501.4121D1F8217@releng2.fedora.phx.redhat.com> <4A1F714C.80905@fedoraproject.org> <1243613487.2937.189.camel@adam.local.net> <4A2011B5.8050706@fedoraproject.org> <1243617086.2937.203.camel@adam.local.net> Message-ID: <20090530171110.30d3b3c3@faldor.intranet> On Fri, 29 May 2009 10:11:26 -0700, Adam wrote: > As Kevin says, the changelog isn't well ordered - note the > date/email/revision line, that's the changes in -164. The changelog > shows 164, 165, 166, 167, 163. I wonder if this will ever get fixed :) http://yum.baseurl.org/ticket/6 with patches - 12/19/08 ("james" disagrees with me, but he's wrong [1]) http://yum.baseurl.org/ticket/7 with patch - 12/20/08 adds the missing changelog entries for rebuilds done on the same day (no reply yet) And of course, once the tools are fixed, infrastructure needs updates. -- [1] To reverse the changelog entries (oldest first) in the metadata means that every utility that wants to display the changelog entries must reverse them once more. *urks* From kevin.kofler at chello.at Sat May 30 15:26:35 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 30 May 2009 17:26:35 +0200 Subject: gnaughty is a hot babe References: <4A1E5CC4.2060506@fedoraproject.org> <385866f0905290105o24d2dc23xea62acc07d979829@mail.gmail.com> <4A1FAFE3.80302@gmail.com> <2a28d2ab0905290259g8103cb7p9856559a611ed465@mail.gmail.com> <4A1FB5CC.1060204@gmail.com> <1243614606.2937.194.camel@adam.local.net> <1243619723.4093.8.camel@localhost.localdomain> <1243624950.2559.68.camel@localhost.localdomain> <604aa7910905291925i53ef830fs82d1a9437fd8566a@mail.gmail.com> <385866f0905300244l61ae869bl8090bc6138c99cec@mail.gmail.com> Message-ID: Muayyad AlSadi wrote: > some one asked me to pay the rating fees for every package! If you want a professional rating, that's going to be your only option. It seems clear to me from the discussion that nobody else around here is interested in paying for an official rating of every single package in Fedora. If you're OK with volunteers rating the packages, then you won't have to pay anyone, just ask for like-minded people to help you go through the packages and rate them. I'm sure you'll find some in your custom remix's community. But don't expect Fedora packagers to do the work for you. Kevin Kofler From kevin.kofler at chello.at Sat May 30 15:28:29 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 30 May 2009 17:28:29 +0200 Subject: rawhide report: 20090528 changes References: <20090528140501.4121D1F8217@releng2.fedora.phx.redhat.com> <4A1F714C.80905@fedoraproject.org> <1243613487.2937.189.camel@adam.local.net> <4A2011B5.8050706@fedoraproject.org> <1243617086.2937.203.camel@adam.local.net> <20090530171110.30d3b3c3@faldor.intranet> Message-ID: Michael Schwendt wrote: > [1] To reverse the changelog entries (oldest first) in the metadata means > that every utility that wants to display the changelog entries must > reverse them once more. *urks* Why do we care at all whether the changelog entries are newest first or oldest first? All I care about is that the order is consistent! Kevin Kofler From mschwendt at gmail.com Sat May 30 16:00:24 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sat, 30 May 2009 18:00:24 +0200 Subject: rawhide report: 20090528 changes In-Reply-To: References: <20090528140501.4121D1F8217@releng2.fedora.phx.redhat.com> <4A1F714C.80905@fedoraproject.org> <1243613487.2937.189.camel@adam.local.net> <4A2011B5.8050706@fedoraproject.org> <1243617086.2937.203.camel@adam.local.net> <20090530171110.30d3b3c3@faldor.intranet> Message-ID: <20090530180024.3bb6856c@faldor.intranet> On Sat, 30 May 2009 17:28:29 +0200, Kevin wrote: > Michael Schwendt wrote: > > [1] To reverse the changelog entries (oldest first) in the metadata means > > that every utility that wants to display the changelog entries must > > reverse them once more. *urks* > > Why do we care at all whether the changelog entries are newest first or > oldest first? All I care about is that the order is consistent! > > Kevin Kofler In RPM they are newest first, so why reverse them in the metadata? The order is only inconsistent because createrepo sorts them, which doesn't work because the timestamps are not accurate enough. From alsadi at gmail.com Sat May 30 16:00:34 2009 From: alsadi at gmail.com (Muayyad AlSadi) Date: Sat, 30 May 2009 19:00:34 +0300 Subject: gnaughty is a hot babe In-Reply-To: References: <4A1E5CC4.2060506@fedoraproject.org> <2a28d2ab0905290259g8103cb7p9856559a611ed465@mail.gmail.com> <4A1FB5CC.1060204@gmail.com> <1243614606.2937.194.camel@adam.local.net> <1243619723.4093.8.camel@localhost.localdomain> <1243624950.2559.68.camel@localhost.localdomain> <604aa7910905291925i53ef830fs82d1a9437fd8566a@mail.gmail.com> <385866f0905300244l61ae869bl8090bc6138c99cec@mail.gmail.com> Message-ID: <385866f0905300900s65eabf92le4a4acdf1a4bc214@mail.gmail.com> >> am I the only one who knows that "if p then q" will evaluate to T when p=F > As you neither did define the relation of T or F to either p or q your "proof" is just a logical fallacy. I fear the same is true for your inappropriateness-rating. It's full of fail. the statement was like this "if it was rated, if the upstream, if the maintainer feels ... -> add a comment" if non of those happened, ie. it was not rated nor the upstream carries such note nor the maintainer feels that it should then the whole statement is true ie. it should not stop the package from being accepted. > The wiki on fedoraproject.org is most likely not the right place for such a list. then ok, it seems this is true and I realize that too late sorry for wasting your time. From vonbrand at inf.utfsm.cl Sat May 30 16:09:16 2009 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sat, 30 May 2009 12:09:16 -0400 Subject: RPM Soft dependencies (Was: Re: Agenda for the 2009-05-26 Packaging Committee meeting) In-Reply-To: References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <20090527072531.GA2413@amd.home.annexia.org> <4A1D91D4.4080909@redhat.com> Message-ID: <200905301609.n4UG9G0M007345@laptop14.inf.utfsm.cl> Andreas Thienemann wrote: > On Sat, 30 May 2009, Panu Matilainen wrote: > > Apart from some mostly cosmetical issues, the problem with the soft > > dependency patches of Suse (which Mandriva uses too) is not so much what > > they do, but what they dont do. I've been on the verge of committing the > > patches several times and got stuck in the semantics swamp as many times. > > The Suse patches only define "rpm doesn't care" semantics, leaving > > everything to upper layers. Which seems kinda ok at first sight, but on a > > closer look I always end up with "but rpm does need to know, to some > > extent at least." > > Your example explains why the current SuSE way of doing soft dependencies > is not the best way of doing it. This whole "soft dependencies" idea has been discussed to death numerous times already, and the conclusion has always been that they really don't solve anything. There is a wide range of very different functionalities under this idea: Suggestions for additional packages that might be useful for a tiny minority to packages that should be installed together always except if you are extremely tight on space, packages that work well together, packages that form a set with a common UI, ... > But I think everyone is in agreement that we need soft dependencies in > order to sort out our current dependency mess. Haven't seen any such. Care to explain? > It increasingly happens > that half the desktop is being pulled in for system services. Then either the system services require too much "desktop" (bug to be fixed, has nothing whatsoever to do with soft dependencies) or the desktop is insinuating itself too much into the system (very little can be done about this, GUIs and desktops and ... _are_ the primary use of current systems, soft dependencies won't do anything about that tendency). > Soft > dependencies, together with dlopen() might be a good way of solving this. That doesn't solve anything, it just complicates applications (need fallbacks when something isn't available, need to handle oldish versions, ...) > Therefore I'm wondering: Are there any better ways of solving this File concrete bugs. Suggest alternatives. Keep complaining when a text-only system requires GUI components. > and > when can we expect them? :) Whenever you help fixing the bugs filed in the area ;-) -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From bruno at wolff.to Sat May 30 16:20:47 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Sat, 30 May 2009 11:20:47 -0500 Subject: dependency errors while upgrading vom F10 to Rawhide (F11) In-Reply-To: References: <4A1BAABF.8050603@kiewel-online.ch> <1243362014.16232.92.camel@adam.local.net> <4A1C4062.5090506@kiewel-online.ch> <1243369064.16232.100.camel@adam.local.net> Message-ID: <20090530162047.GA1898@wolff.to> On Tue, May 26, 2009 at 16:20:00 -0400, Seth Vidal wrote: > > The biggest problem you are likely to run into with a yum-based upgrade > is situations where updating something takes out the foundation on which > yum is running. Another showstopper is when you can't run mkinitrd for the new kernel properly under the old kernel. From Matt_Domsch at dell.com Sat May 30 18:47:13 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 30 May 2009 13:47:13 -0500 Subject: Plans for tomorrow's (20090529) FESCo meeting In-Reply-To: <1243618345.2937.210.camel@adam.local.net> References: <200905291033.20518.opensource@till.name> <20090529113607.GD3095@hansolo.jdub.homelinux.org> <20090529144920.GA31662@thinkpad.fab.redhat.com> <1243615672.2937.197.camel@adam.local.net> <4A201496.2070205@gmail.com> <1243618345.2937.210.camel@adam.local.net> Message-ID: <20090530184713.GA4369@auslistsprd01.us.dell.com> On Fri, May 29, 2009 at 10:32:25AM -0700, Adam Williamson wrote: > On Fri, 2009-05-29 at 10:00 -0700, Toshio Kuratomi wrote: > > On 05/29/2009 09:47 AM, Adam Williamson wrote: > > > > > There is a solution to this particular point, which it seems many who > > > use kmods don't seem to know about: akmods. Install the akmod for your > > > kmod, and if the pre-built kmod hasn't yet been updated when a new > > > kernel is released, the akmod handles the problem (it gets automatically > > > built at boot time). > > > > > I've used dkms (the infrastructural package is in Fedora although > > there's no modules in fedora to use it). It seems similar to what you > > describe. > > Yes, vanilla DKMS works like this: it doesn't use pre-built binaries at > all, it's just about wrapping the module source up into a convenient > lump and having a bit of infrastructure to automatically compile it > during startup if appropriate. If you have a package that contains pre-built binaries, DKMS will happily use those. We use that model on the "Enterprise" distros all the time. > > > That doesn't address all the other problems, of course, which are valid. > > > And it doesn't help if the new kernel happens to have changed the > > > interface somehow so the module source doesn't build any more. But there > > > > This ended up being the blocker for my personal use. For FESCo, I > > remember the requirement that gcc and other build tools were needed on > > an end user system was a big issue. > > Yeah, that's the drawback to a pure source approach. Agreed. > Mandriva took DKMS and hacked it up so that it creates both pre-built > binaries and 'source' packages (much like kmods and akmods in the kmod > system), so that if you have a system without the build chain things > will work as long as you're running a supported kernel and the updates > are in sync, but if you have the whole build chain, the 'source' DKMS > package covers you if you're running a different kernel or whatever. RPM > Fusion does much the same by providing both kmods and akmods. I do wish MDV would send such patches upstream... I always had to go hunting for patches. FWIW, the Linux Foundation Driver Backport Working Group [1] has standardized on using DKMS as a developer tool for building [a]kmod-like packages (KMPs in Novell terminology). But of course, that's still targeted at backporting fixes / drivers to "older" kernels in the "stable" Enterprise distros. DKMS and related tools really don't make sense for use as a delivery mechanism for Fedora and other rapidly changing non-commercial-supported distributions . Different target audience, different expected experience. [1] http://www.linuxfoundation.org/collaborate/workgroups/driver-backport -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From markg85 at gmail.com Sat May 30 19:30:36 2009 From: markg85 at gmail.com (Mark) Date: Sat, 30 May 2009 21:30:36 +0200 Subject: welcome to fedora In-Reply-To: <64b14b300905290413m222c25b1v4ab68cff9481d75b@mail.gmail.com> References: <64b14b300905290413m222c25b1v4ab68cff9481d75b@mail.gmail.com> Message-ID: <6e24a8e80905301230k790017bfn3e27f4a01bc267d5@mail.gmail.com> If i'm right (correct me otherwise) there used to be a "Welcome... " in the early fedora days (fedora core 1? 2 or 3?) or perhaps even the last few redhat releases (redhat 8 or 9) which had that. I just don't quite remember it... I personally wouldn't be in favor of another. When you install fedora now you have some kind of fullscreen welcome. That should be enough. Doing more is just spamming the user with welcome screens. On Fri, May 29, 2009 at 1:13 PM, Valent Turkovic wrote: > http://images.howtoforge.com/images/the_perfect_desktop_linux_mint_7_gloria/15.jpg > > I saw this and thought that it would also be a nice idea to have in > fedora, like a welcome screen "Wellcome to Fedora" or something > similar... > What are your thoughts on this? > > -- > http://kernelreloaded.blog385.com/ > linux, blog, anime, spirituality, windsurf, wireless > registered as user #367004 with the Linux Counter, http://counter.li.org. > ICQ: 2125241, Skype: valent.turkovic > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From kwhiskerz at gmail.com Sun May 31 04:46:46 2009 From: kwhiskerz at gmail.com (Petrus de Calguarium) Date: Sat, 30 May 2009 22:46:46 -0600 Subject: welcome to fedora References: <64b14b300905290413m222c25b1v4ab68cff9481d75b@mail.gmail.com> Message-ID: Valent Turkovic wrote: > I saw this and thought that it would also be a nice idea I like the current Plymouth theme with the white circle that gradually fills in and them 'pops out' with the fedora infinity F. It looks really cool. Isn't that a nice welcome? It is definitely very elegant. If you edit /etc/motd and put "Welcome to Fedora" into it, it will say that to you when you do a text login. From awilliam at redhat.com Sun May 31 05:14:13 2009 From: awilliam at redhat.com (Adam Williamson) Date: Sat, 30 May 2009 22:14:13 -0700 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <20090527072531.GA2413@amd.home.annexia.org> <4A1D91D4.4080909@redhat.com> Message-ID: <1243746853.2937.246.camel@adam.local.net> On Sat, 2009-05-30 at 12:53 +0300, Panu Matilainen wrote: > Take for example package A with > Requires(post): C > Recommends(post): B > Or consider "Recommends: B >= 1.2" - what exactly does this mean? The FWIW, I've definitely never seen a "Suggests(post)" (or anything other than a plain "Suggests:") in Mandriva, and I don't recall seeing a versioned one either. So it's not something I'd put much thought into. Your caveats about those cases seem correct, though. If we want to do it really properly, I think we'd wind up with something at least as subtle as Debian's system - two levels of soft deps in one direction, and a reverse soft dep - and probably policies on how they are allowed to be used and what certain cases, like the ones you outline, should mean. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From awilliam at redhat.com Sun May 31 05:23:11 2009 From: awilliam at redhat.com (Adam Williamson) Date: Sat, 30 May 2009 22:23:11 -0700 Subject: RPM Soft dependencies (Was: Re: Agenda for the 2009-05-26 Packaging Committee meeting) In-Reply-To: <200905301609.n4UG9G0M007345@laptop14.inf.utfsm.cl> References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <20090527072531.GA2413@amd.home.annexia.org> <4A1D91D4.4080909@redhat.com> <200905301609.n4UG9G0M007345@laptop14.inf.utfsm.cl> Message-ID: <1243747391.2937.255.camel@adam.local.net> On Sat, 2009-05-30 at 12:09 -0400, Horst H. von Brand wrote: > This whole "soft dependencies" idea has been discussed to death numerous > times already, and the conclusion has always been that they really don't > solve anything. There is a wide range of very different functionalities > under this idea: Suggestions for additional packages that might be useful > for a tiny minority to packages that should be installed together always > except if you are extremely tight on space, packages that work well > together, packages that form a set with a common UI, ... I can't agree with that. There's cases where they're clearly very useful. One obvious one I maintain for Mandriva is Elisa (which just got renamed to Moovida). If certain other packages are involved, it gains very useful features...but it works perfectly well without them, and some users may not want those features. A soft dependency covers this situation pretty perfectly; by default you get the extra dependencies installed so the features will be available, but if you're someone who needs to optimize disk space or number of installed packages you'll have configured urpmi not to install soft dependencies so you won't get them, and if you didn't do that but you later decide to remove one of the soft deps, you can. I consider this a significant win, the package would be objectively less good without this. Here's the external soft deps in the packages... # visualizations in music playback Suggests: gstreamer0.10-libvisual # iPod support Suggests: python-gpod # For UPnP support Suggests: python-coherence # For the weather report plugin Suggests: python-pymetar # lets moovida be a UPNP server Suggests: python-coherence # DAAP support Suggests: python-daap # Needed for DAAP plugin Suggests: avahi-python # Needed for yes.fm support Suggests: python-simplejson # For LIRC input support Suggests: python-lirc I really think the soft deps are the right way to do things here. Those things aren't hard deps, the app works without them, and there are perfectly valid reasons you might not want them. But on the other hand, it kinda sucks to have no indication of the fact that they provide significant useful features to Moovida in the package metadata. They're certainly not things you'd easily figure out on your own, you'd probably just think Moovida couldn't *do* that stuff. I'm having a hard time seeing how the soft deps aren't performing a really useful function, here. That was just one example. I used soft deps in quite a lot of my MDV packages. They just seemed a good way to handle several situations. mc is another example of an app which works with quite a minimal set of other packages installed, but has a lot more features with more installed. I really think it's nice to have a way to handle this. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From a.badger at gmail.com Sun May 31 05:34:06 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 30 May 2009 22:34:06 -0700 Subject: RPM Soft dependencies (Was: Re: Agenda for the 2009-05-26 Packaging Committee meeting) In-Reply-To: <1243747391.2937.255.camel@adam.local.net> References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <20090527072531.GA2413@amd.home.annexia.org> <4A1D91D4.4080909@redhat.com> <200905301609.n4UG9G0M007345@laptop14.inf.utfsm.cl> <1243747391.2937.255.camel@adam.local.net> Message-ID: <4A2216CE.5030900@gmail.com> On 05/30/2009 10:23 PM, Adam Williamson wrote: > One obvious one I maintain for Mandriva is Elisa (which just got renamed > to Moovida). If certain other packages are involved, it gains very > useful features...but it works perfectly well without them, and some > users may not want those features. A soft dependency covers this > situation pretty perfectly; by default you get the extra dependencies > installed so the features will be available, but if you're someone who > needs to optimize disk space or number of installed packages you'll have > configured urpmi not to install soft dependencies so you won't get them, > and if you didn't do that but you later decide to remove one of the soft > deps, you can. What is the behaviour when a package with soft deps on another package is upgraded and the soft dependency is currently not installed? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From sundaram at fedoraproject.org Sun May 31 05:48:14 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 31 May 2009 11:18:14 +0530 Subject: Review request: Arista transcoder using gstreamer Message-ID: <4A221A1E.2080904@fedoraproject.org> Hi LWN has a article on Arista and Transmageddon http://lwn.net/Articles/333904/ Transmageddon requires a new release of pyobject2 from upstream for it to work in Fedora 11. So I have packaged Arista first. If anyone is interested in doing a review, pick up https://bugzilla.redhat.com/show_bug.cgi?id=502477 Rahul From awilliam at redhat.com Sun May 31 05:55:35 2009 From: awilliam at redhat.com (Adam Williamson) Date: Sat, 30 May 2009 22:55:35 -0700 Subject: RPM Soft dependencies (Was: Re: Agenda for the 2009-05-26 Packaging Committee meeting) In-Reply-To: <4A2216CE.5030900@gmail.com> References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <20090527072531.GA2413@amd.home.annexia.org> <4A1D91D4.4080909@redhat.com> <200905301609.n4UG9G0M007345@laptop14.inf.utfsm.cl> <1243747391.2937.255.camel@adam.local.net> <4A2216CE.5030900@gmail.com> Message-ID: <1243749335.2937.262.camel@adam.local.net> On Sat, 2009-05-30 at 22:34 -0700, Toshio Kuratomi wrote: > On 05/30/2009 10:23 PM, Adam Williamson wrote: > > > One obvious one I maintain for Mandriva is Elisa (which just got renamed > > to Moovida). If certain other packages are involved, it gains very > > useful features...but it works perfectly well without them, and some > > users may not want those features. A soft dependency covers this > > situation pretty perfectly; by default you get the extra dependencies > > installed so the features will be available, but if you're someone who > > needs to optimize disk space or number of installed packages you'll have > > configured urpmi not to install soft dependencies so you won't get them, > > and if you didn't do that but you later decide to remove one of the soft > > deps, you can. > > What is the behaviour when a package with soft deps on another package > is upgraded and the soft dependency is currently not installed? What is it, in MDV and SUSE? Can't remember, off the top of my head. What should it be? Interesting question, indeed. Either option is wrong for someone. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From frankly3d at gmail.com Sun May 31 07:12:44 2009 From: frankly3d at gmail.com (Frank Murphy (Frankly3d)) Date: Sun, 31 May 2009 08:12:44 +0100 Subject: Mono (& Moonlight) Licensing? Revisited Message-ID: <4A222DEC.7080106@gmail.com> http://www.itwire.com/content/view/25215/1090/1/1 Not intending to burn the house down. But, going by this article: http://www.itwire.com/content/view/25215/1090/1/1 Dated 25th May. Unease sets in. Frank -- msn: frankly3d skype: frankly3d Mailing-List Reply to: Mailing-List Still Learning, Unicode where possible From thomasj at fedoraproject.org Sun May 31 08:01:01 2009 From: thomasj at fedoraproject.org (Thomas Janssen) Date: Sun, 31 May 2009 10:01:01 +0200 Subject: welcome to fedora In-Reply-To: References: <64b14b300905290413m222c25b1v4ab68cff9481d75b@mail.gmail.com> Message-ID: Well, from my point of view, the OP doesn't meant to have a "Welcome to Fedora" text alone. I think he meant more likely the other stuff. Like, clickable: "Discover that" , "Get online help here" , "Find information about whatever there". And thats not a bad idea. At least it is very new-user-friendly. -- LG Thomas Dubium sapientiae initium From bochecha at fedoraproject.org Sun May 31 09:29:03 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Sun, 31 May 2009 11:29:03 +0200 Subject: RPM Soft dependencies (Was: Re: Agenda for the 2009-05-26 Packaging Committee meeting) In-Reply-To: <1243747391.2937.255.camel@adam.local.net> References: <4A1D91D4.4080909@redhat.com> <200905301609.n4UG9G0M007345@laptop14.inf.utfsm.cl> <1243747391.2937.255.camel@adam.local.net> Message-ID: <2d319b780905310229u33b31183n26422d01a225ff94@mail.gmail.com> > users may not want those features. A soft dependency covers this > situation pretty perfectly; by default you get the extra dependencies > installed so the features will be available, but if you're someone who > needs to optimize disk space or number of installed packages you'll have > configured urpmi not to install soft dependencies so you won't get them, > and if you didn't do that but you later decide to remove one of the soft > deps, you can. I consider this a significant win, the package would be > objectively less good without this. How do you know _later_ which installed packages could be removed as they only came via soft dependencies ? ? package-cleanup --soft-leaves ? or something like that ? ---------- Mathieu Bridon (bochecha) From sundaram at fedoraproject.org Sun May 31 10:00:01 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 31 May 2009 15:30:01 +0530 Subject: welcome to fedora In-Reply-To: References: <64b14b300905290413m222c25b1v4ab68cff9481d75b@mail.gmail.com> Message-ID: <4A225521.7020305@fedoraproject.org> On 05/31/2009 01:31 PM, Thomas Janssen wrote: > Well, from my point of view, the OP doesn't meant to have a "Welcome > to Fedora" text alone. I think he meant more likely the other stuff. > Like, clickable: "Discover that" , "Get online help here" , "Find > information about whatever there". > > And thats not a bad idea. At least it is very new-user-friendly. It has been suggested before and accepted that as a useful idea. Someone needs to take the next step and implement it. Rahul From sundaram at fedoraproject.org Sun May 31 10:03:39 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 31 May 2009 15:33:39 +0530 Subject: Mono (& Moonlight) Licensing? Revisited In-Reply-To: <4A222DEC.7080106@gmail.com> References: <4A222DEC.7080106@gmail.com> Message-ID: <4A2255FB.8030105@fedoraproject.org> On 05/31/2009 12:42 PM, Frank Murphy (Frankly3d) wrote: > http://www.itwire.com/content/view/25215/1090/1/1 > > Not intending to burn the house down. > But, going by this article: > http://www.itwire.com/content/view/25215/1090/1/1 > Dated 25th May. Unease sets in. It is not clear what your intend is? Moonlight is already marked as not permitted http://fedoraproject.org/wiki/ForbiddenItems#Moonlight Mono is in due to OIN http://gregdek.livejournal.com/4008.html Rahul From frankly3d at gmail.com Sun May 31 10:11:10 2009 From: frankly3d at gmail.com (Frank Murphy (Frankly3D)) Date: Sun, 31 May 2009 11:11:10 +0100 Subject: Mono (& Moonlight) Licensing? Revisited In-Reply-To: <4A2255FB.8030105@fedoraproject.org> References: <4A222DEC.7080106@gmail.com> <4A2255FB.8030105@fedoraproject.org> Message-ID: <4A2257BE.8070203@gmail.com> Rahul Sundaram wrote: > On 05/31/2009 12:42 PM, Frank Murphy (Frankly3d) wrote: >> http://www.itwire.com/content/view/25215/1090/1/1 >> >> Not intending to burn the house down. >> But, going by this article: >> http://www.itwire.com/content/view/25215/1090/1/1 >> Dated 25th May. Unease sets in. > > It is not clear what your intend is? Moonlight is already marked as not > permitted Available Packages Name : mono-moonlight Arch : i586 Version : 2.4 Release : 19.fc11 Size : 1.5 M Repo : fedora Summary : All the parts required for moonlight compilation URL : http://www.mono-project.com/Main_Page License : MIT Description: mono-moonlight are all the parts required for moonlight compilation > > http://fedoraproject.org/wiki/ForbiddenItems#Moonlight > > Mono is in due to OIN > > http://gregdek.livejournal.com/4008.html Doesn't clarify things for me. Frank From sundaram at fedoraproject.org Sun May 31 10:16:50 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 31 May 2009 15:46:50 +0530 Subject: Mono (& Moonlight) Licensing? Revisited In-Reply-To: <4A2257BE.8070203@gmail.com> References: <4A222DEC.7080106@gmail.com> <4A2255FB.8030105@fedoraproject.org> <4A2257BE.8070203@gmail.com> Message-ID: <4A225912.2040309@fedoraproject.org> On 05/31/2009 03:41 PM, Frank Murphy (Frankly3D) wrote: > Rahul Sundaram wrote: >> On 05/31/2009 12:42 PM, Frank Murphy (Frankly3d) wrote: >>> http://www.itwire.com/content/view/25215/1090/1/1 >>> >>> Not intending to burn the house down. >>> But, going by this article: >>> http://www.itwire.com/content/view/25215/1090/1/1 >>> Dated 25th May. Unease sets in. >> >> It is not clear what your intend is? Moonlight is already marked as not >> permitted > > Available Packages > Name : mono-moonlight This is not moonlight itself. https://bugzilla.redhat.com/show_bug.cgi?id=492048 Rahul From jussilehtola at fedoraproject.org Sun May 31 10:18:21 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Sun, 31 May 2009 13:18:21 +0300 Subject: RPM Soft dependencies (Was: Re: Agenda for the 2009-05-26 Packaging Committee meeting) In-Reply-To: <2d319b780905310229u33b31183n26422d01a225ff94@mail.gmail.com> References: <4A1D91D4.4080909@redhat.com> <200905301609.n4UG9G0M007345@laptop14.inf.utfsm.cl> <1243747391.2937.255.camel@adam.local.net> <2d319b780905310229u33b31183n26422d01a225ff94@mail.gmail.com> Message-ID: <1243765101.2560.6.camel@localhost.localdomain> On Sun, 2009-05-31 at 11:29 +0200, Mathieu Bridon (bochecha) wrote: > > users may not want those features. A soft dependency covers this > > situation pretty perfectly; by default you get the extra dependencies > > installed so the features will be available, but if you're someone who > > needs to optimize disk space or number of installed packages you'll have > > configured urpmi not to install soft dependencies so you won't get them, > > and if you didn't do that but you later decide to remove one of the soft > > deps, you can. I consider this a significant win, the package would be > > objectively less good without this. > > How do you know _later_ which installed packages could be removed as > they only came via soft dependencies ? > > ? package-cleanup --soft-leaves ? or something like that ? Is this possible now even with hard dependencies? If I install package A that requires B and C, but decide I don't like it so I remove package A, B and C still stay on my system. For me the situation sounds quite clear: you have a switch somewhere which controls if soft dependencies are treated as hard dependencies or ignored. If you install some package that has soft dependencies and the switch is on, everything is pulled in. The same thing in case a package is updated and it has unsatisfied soft dependencies. If the switch is off all soft dependencies are ignored both in install and update. On a minimalist system one could have those flags off for everything else than, say httpd. A two-tier system (Recommends, Suggests) could also be treated this way: you could have a treat-recommends-as-requires flag and a treat-suggestions-as-requires flag. This would enable a more fine-grained control. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From forum at ru.bir.ru Sun May 31 10:22:56 2009 From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus)) Date: Sun, 31 May 2009 14:22:56 +0400 Subject: Why not to create Fedora-us and Fedora-non-us branches? In-Reply-To: <4A1C2961.70703@redhat.com> References: <20090526170612.GJ9951@nostromo.devel.redhat.com> <1243358736.3144.23.camel@localhost.localdomain> <4A1C2961.70703@redhat.com> Message-ID: Stephen Gallagher wrote: > Is there a reason that an interested party (in a locale where such > export is legal) couldn't just create a custom spin on their own (and > using their own build system) to create a Fedora-T6 spin (or for > trademark reasons, rebrand it)? I can see this being a perfectly good > premise for setting up a SIG... I thing such regional "spins" exists now. For example RussianFedora in Russian [1]. It includes mp3 codec and many other, because Russia do not admit software patents. Furthermore, it is not just "illegal spin", [2] cite: At a key meeting with Werner Knoblich, Red Hat Vice President for EMEA, he announced support for a Russian Fedora association and for Red Hat development in the Russian Federation. He also expressed support for open source infrastructure and applications, and the development of a repository for industry best practice. [snip] Both Red Hat and VDEL, the organizers of Russian Fedora projects, will provide this center with financial and technological support and also help to build the wider local and international IT industry network needed for this Ministry initiative =====end cite===== So, it is inspired by RedHat and it is not set any barrier to ship it with software what prohibited in main Fedora! So, back to main question - this is example of Europe-based infrastructure. On that any who wish may build self own spins as I think. [1] http://russianfedora.ru/ [2] http://www.osldistribution.com/news (second news) From bochecha at fedoraproject.org Sun May 31 10:36:09 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Sun, 31 May 2009 12:36:09 +0200 Subject: RPM Soft dependencies (Was: Re: Agenda for the 2009-05-26 Packaging Committee meeting) In-Reply-To: <1243765101.2560.6.camel@localhost.localdomain> References: <4A1D91D4.4080909@redhat.com> <200905301609.n4UG9G0M007345@laptop14.inf.utfsm.cl> <1243747391.2937.255.camel@adam.local.net> <2d319b780905310229u33b31183n26422d01a225ff94@mail.gmail.com> <1243765101.2560.6.camel@localhost.localdomain> Message-ID: <2d319b780905310336x2cf9d0a2w57f7d10f007885ee@mail.gmail.com> >> > users may not want those features. A soft dependency covers this >> > situation pretty perfectly; by default you get the extra dependencies >> > installed so the features will be available, but if you're someone who >> > needs to optimize disk space or number of installed packages you'll have >> > configured urpmi not to install soft dependencies so you won't get them, >> > and if you didn't do that but you later decide to remove one of the soft >> > deps, you can. I consider this a significant win, the package would be >> > objectively less good without this. >> >> How do you know _later_ which installed packages could be removed as >> they only came via soft dependencies ? >> >> ? package-cleanup --soft-leaves ? or something like that ? > > Is this possible now even with hard dependencies? If I install package A > that requires B and C, but decide I don't like it so I remove package A, > B and C still stay on my system. Then you use ? package-cleanup --leaves ?. This will list the packages that were dragged in as dependencies but on which nothing depend anymore. ---------- Mathieu Bridon (bochecha) From sundaram at fedoraproject.org Sun May 31 11:28:07 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 31 May 2009 16:58:07 +0530 Subject: Why not to create Fedora-us and Fedora-non-us branches? In-Reply-To: References: <20090526170612.GJ9951@nostromo.devel.redhat.com> <1243358736.3144.23.camel@localhost.localdomain> <4A1C2961.70703@redhat.com> Message-ID: <4A2269C7.1010800@fedoraproject.org> On 05/31/2009 03:52 PM, Pavel Alexeev (aka Pahan-Hubbitus) wrote: > Stephen Gallagher wrote: > > Is there a reason that an interested party (in a locale where such >> export is legal) couldn't just create a custom spin on their own (and >> using their own build system) to create a Fedora-T6 spin (or for >> trademark reasons, rebrand it)? I can see this being a perfectly good >> premise for setting up a SIG... > > I thing such regional "spins" exists now. For example RussianFedora in > Russian [1]. It includes mp3 codec and many other, because Russia do not > admit software patents. > > Furthermore, it is not just "illegal spin", I don't know about illegal but the name "Russian Fedora" is a violation of the Fedora trademark guidelines, clearly. Rahul From frankly3d at gmail.com Sun May 31 11:41:53 2009 From: frankly3d at gmail.com (Frank Murphy (Frankly3d)) Date: Sun, 31 May 2009 12:41:53 +0100 Subject: Why not to create Fedora-us and Fedora-non-us branches? In-Reply-To: <4A2269C7.1010800@fedoraproject.org> References: <20090526170612.GJ9951@nostromo.devel.redhat.com> <1243358736.3144.23.camel@localhost.localdomain> <4A1C2961.70703@redhat.com> <4A2269C7.1010800@fedoraproject.org> Message-ID: <4A226D01.1020408@gmail.com> Rahul Sundaram wrote: > On 05/31/2009 03:52 PM, Pavel Alexeev (aka Pahan-Hubbitus) wrote: >> Stephen Gallagher wrote: >> >> >> Furthermore, it is not just "illegal spin", > > I don't know about illegal but the name "Russian Fedora" is a violation > of the Fedora trademark guidelines, clearly. > > Rahul > There appears to be a tracker for ovelap. https://bugzilla.redhat.com/show_bug.cgi?id=496433 Frank -- msn: frankly3d skype: frankly3d Mailing-List Reply to: Mailing-List Still Learning, Unicode where possible From valent.turkovic at gmail.com Sun May 31 11:47:25 2009 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sun, 31 May 2009 13:47:25 +0200 Subject: welcome to fedora In-Reply-To: <4A225521.7020305@fedoraproject.org> References: <64b14b300905290413m222c25b1v4ab68cff9481d75b@mail.gmail.com> <4A225521.7020305@fedoraproject.org> Message-ID: <64b14b300905310447o1f001c58u36b43d61f1b269e6@mail.gmail.com> On Sun, May 31, 2009 at 12:00 PM, Rahul Sundaram wrote: > On 05/31/2009 01:31 PM, Thomas Janssen wrote: >> Well, from my point of view, the OP doesn't meant to have a "Welcome >> to Fedora" text alone. I think he meant more likely the other stuff. >> Like, clickable: "Discover that" , "Get online help here" , "Find >> information about whatever there". >> >> And thats not a bad idea. At least it is very new-user-friendly. > > It has been suggested before and accepted that as a useful idea. Someone > needs to take the next step and implement it. Which tools would you recommend somebody uses to make this welcome screen? -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From ville.skytta at iki.fi Sun May 31 11:48:45 2009 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 31 May 2009 14:48:45 +0300 Subject: RPM Soft dependencies (Was: Re: Agenda for the 2009-05-26 Packaging Committee meeting) In-Reply-To: <2d319b780905310336x2cf9d0a2w57f7d10f007885ee@mail.gmail.com> References: <1243765101.2560.6.camel@localhost.localdomain> <2d319b780905310336x2cf9d0a2w57f7d10f007885ee@mail.gmail.com> Message-ID: <200905311448.45745.ville.skytta@iki.fi> On Sunday 31 May 2009, Mathieu Bridon (bochecha) wrote: > Then you use ? package-cleanup --leaves ?. > > This will list the packages that were dragged in as dependencies but > on which nothing depend anymore. s/that were dragged in as dependencies but//. I don't think package-cleanup currently has any idea/cares why something was installed. From atorkhov at gmail.com Sun May 31 11:54:24 2009 From: atorkhov at gmail.com (Alexey Torkhov) Date: Sun, 31 May 2009 15:54:24 +0400 Subject: Why not to create Fedora-us and Fedora-non-us branches? In-Reply-To: <4A2269C7.1010800@fedoraproject.org> References: <20090526170612.GJ9951@nostromo.devel.redhat.com> <1243358736.3144.23.camel@localhost.localdomain> <4A1C2961.70703@redhat.com> <4A2269C7.1010800@fedoraproject.org> Message-ID: <1243770864.26053.8.camel@localhost.localdomain> On Sun, 2009-05-31 at 16:58 +0530, Rahul Sundaram wrote: > On 05/31/2009 03:52 PM, Pavel Alexeev (aka Pahan-Hubbitus) wrote: > > Stephen Gallagher wrote: > > > Is there a reason that an interested party (in a locale where such > >> export is legal) couldn't just create a custom spin on their own (and > >> using their own build system) to create a Fedora-T6 spin (or for > >> trademark reasons, rebrand it)? I can see this being a perfectly good > >> premise for setting up a SIG... > > > > I thing such regional "spins" exists now. For example RussianFedora in > > Russian [1]. It includes mp3 codec and many other, because Russia do not > > admit software patents. > > > > Furthermore, it is not just "illegal spin", > > I don't know about illegal but the name "Russian Fedora" is a violation > of the Fedora trademark guidelines, clearly. Usage of trademark was granted to Russian Fedora by agreement between Red Hat and other company that represent it here, AFAIK. Max Spevack was on presentation on Russian Fedora launch. Alexey From sundaram at fedoraproject.org Sun May 31 12:03:18 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 31 May 2009 17:33:18 +0530 Subject: Why not to create Fedora-us and Fedora-non-us branches? In-Reply-To: <1243770864.26053.8.camel@localhost.localdomain> References: <20090526170612.GJ9951@nostromo.devel.redhat.com> <1243358736.3144.23.camel@localhost.localdomain> <4A1C2961.70703@redhat.com> <4A2269C7.1010800@fedoraproject.org> <1243770864.26053.8.camel@localhost.localdomain> Message-ID: <4A227206.9010601@fedoraproject.org> On 05/31/2009 05:24 PM, Alexey Torkhov wrote: > On Sun, 2009-05-31 at 16:58 +0530, Rahul Sundaram wrote: > > Usage of trademark was granted to Russian Fedora by agreement between > Red Hat and other company that represent it here, AFAIK. > Max Spevack was on presentation on Russian Fedora launch. I don't see it recorded in https://fedoraproject.org/wiki/Trademark_licensees It doesn't fit the trademark guidelines either. While Red Hat can legally grant a license to anyone and doesn't have to abide by the guidelines, I would expect it to do so nevertheless. So why a special exception for "Russian Fedora"? Rahul From frankly3d at gmail.com Sun May 31 12:12:33 2009 From: frankly3d at gmail.com (Frank Murphy (Frankly3d)) Date: Sun, 31 May 2009 13:12:33 +0100 Subject: Is The Devel Sig alive or Dead? Message-ID: <4A227431.6040308@gmail.com> Lat meeting log seems to be: http://fedoraproject.org/wiki/SIGs/Development#Communication Frank -- msn: frankly3d skype: frankly3d Mailing-List Reply to: Mailing-List Still Learning, Unicode where possible From atorkhov at gmail.com Sun May 31 12:18:07 2009 From: atorkhov at gmail.com (Alexey Torkhov) Date: Sun, 31 May 2009 16:18:07 +0400 Subject: Why not to create Fedora-us and Fedora-non-us branches? In-Reply-To: <4A227206.9010601@fedoraproject.org> References: <20090526170612.GJ9951@nostromo.devel.redhat.com> <1243358736.3144.23.camel@localhost.localdomain> <4A1C2961.70703@redhat.com> <4A2269C7.1010800@fedoraproject.org> <1243770864.26053.8.camel@localhost.localdomain> <4A227206.9010601@fedoraproject.org> Message-ID: <1243772287.26053.15.camel@localhost.localdomain> On Sun, 2009-05-31 at 17:33 +0530, Rahul Sundaram wrote: > On 05/31/2009 05:24 PM, Alexey Torkhov wrote: > > On Sun, 2009-05-31 at 16:58 +0530, Rahul Sundaram wrote: > > > > > Usage of trademark was granted to Russian Fedora by agreement between > > Red Hat and other company that represent it here, AFAIK. > > Max Spevack was on presentation on Russian Fedora launch. > > I don't see it recorded in > > https://fedoraproject.org/wiki/Trademark_licensees > > It doesn't fit the trademark guidelines either. While Red Hat can > legally grant a license to anyone and doesn't have to abide by the > guidelines, I would expect it to do so nevertheless. So why a special > exception for "Russian Fedora"? I don't know the details of an agreement, ask legal team for that. Alexey From sundaram at fedoraproject.org Sun May 31 12:18:23 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 31 May 2009 17:48:23 +0530 Subject: Is The Devel Sig alive or Dead? In-Reply-To: <4A227431.6040308@gmail.com> References: <4A227431.6040308@gmail.com> Message-ID: <4A22758F.2070704@fedoraproject.org> On 05/31/2009 05:42 PM, Frank Murphy (Frankly3d) wrote: > Lat meeting log seems to be: > http://fedoraproject.org/wiki/SIGs/Development#Communication It's not active anymore. The Fedora Development custom spin has also been dropped. Rahul From sundaram at fedoraproject.org Sun May 31 12:24:21 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 31 May 2009 17:54:21 +0530 Subject: Why not to create Fedora-us and Fedora-non-us branches? In-Reply-To: <1243772287.26053.15.camel@localhost.localdomain> References: <20090526170612.GJ9951@nostromo.devel.redhat.com> <1243358736.3144.23.camel@localhost.localdomain> <4A1C2961.70703@redhat.com> <4A2269C7.1010800@fedoraproject.org> <1243770864.26053.8.camel@localhost.localdomain> <4A227206.9010601@fedoraproject.org> <1243772287.26053.15.camel@localhost.localdomain> Message-ID: <4A2276F5.7040904@fedoraproject.org> On 05/31/2009 05:48 PM, Alexey Torkhov wrote: > On Sun, 2009-05-31 at 17:33 +0530, Rahul Sundaram wrote: >> On 05/31/2009 05:24 PM, Alexey Torkhov wrote: >>> On Sun, 2009-05-31 at 16:58 +0530, Rahul Sundaram wrote: >> >>> >>> Usage of trademark was granted to Russian Fedora by agreement between >>> Red Hat and other company that represent it here, AFAIK. >>> Max Spevack was on presentation on Russian Fedora launch. >> >> I don't see it recorded in >> >> https://fedoraproject.org/wiki/Trademark_licensees >> >> It doesn't fit the trademark guidelines either. While Red Hat can >> legally grant a license to anyone and doesn't have to abide by the >> guidelines, I would expect it to do so nevertheless. So why a special >> exception for "Russian Fedora"? > > I don't know the details of an agreement, ask legal team for that. I don't need to know the details of the agreement. If any such agreement exists, it should follow the trademark guidelines that Fedora set for rest of the community and not be given special exceptions. Can the Fedora Board look into this? Rahul From bochecha at fedoraproject.org Sun May 31 12:32:57 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Sun, 31 May 2009 14:32:57 +0200 Subject: RPM Soft dependencies (Was: Re: Agenda for the 2009-05-26 Packaging Committee meeting) In-Reply-To: <200905311448.45745.ville.skytta@iki.fi> References: <1243765101.2560.6.camel@localhost.localdomain> <2d319b780905310336x2cf9d0a2w57f7d10f007885ee@mail.gmail.com> <200905311448.45745.ville.skytta@iki.fi> Message-ID: <2d319b780905310532r49f0bd56neb1c9cc67fa2e60a@mail.gmail.com> >> Then you use ? package-cleanup --leaves ?. >> >> This will list the packages that were dragged in as dependencies but >> on which nothing depend anymore. > > s/that were dragged in as dependencies but//. ?I don't think package-cleanup > currently has any idea/cares why something was installed. No, my sentence was confusing. ? package-cleanup --leaves ? will tell you what installed packages are no longer required by any other on your system. Of course, it can't know why you installed them or even if something outside of its scope (e.g. a program you compiled manually) still needs one of those. I shouldn't have spoken about the intent of the user, you're right. :) To be more correct, ? --leaves ? will list packages on which no others depend AND that match the defined ? leaf_regex ?. A quick look at the source seems to indicate that returned packages will be mostly libraries, as the default leaf_regex appears to be "(^(compat-)?lib.+|.*libs?[\d-]*$)". ---------- Mathieu Bridon (bochecha) From frankly3d at gmail.com Sun May 31 12:35:43 2009 From: frankly3d at gmail.com (Frank Murphy (Frankly3d)) Date: Sun, 31 May 2009 13:35:43 +0100 Subject: Is The Devel Sig alive or Dead? In-Reply-To: <4A22758F.2070704@fedoraproject.org> References: <4A227431.6040308@gmail.com> <4A22758F.2070704@fedoraproject.org> Message-ID: <4A22799F.4040306@gmail.com> Rahul Sundaram wrote: > On 05/31/2009 05:42 PM, Frank Murphy (Frankly3d) wrote: >> Lat meeting log seems to be: >> http://fedoraproject.org/wiki/SIGs/Development#Communication > > It's not active anymore. The Fedora Development custom spin has also > been dropped. > Guessing lack of Interest? So what would be the best Install Desktop + what devel. Packages required. Or could I use F10-Devel and update using Revisor\kickstart? Frank -- msn: frankly3d skype: frankly3d Mailing-List Reply to: Mailing-List Still Learning, Unicode where possible From sundaram at fedoraproject.org Sun May 31 12:40:41 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 31 May 2009 18:10:41 +0530 Subject: Is The Devel Sig alive or Dead? In-Reply-To: <4A22799F.4040306@gmail.com> References: <4A227431.6040308@gmail.com> <4A22758F.2070704@fedoraproject.org> <4A22799F.4040306@gmail.com> Message-ID: <4A227AC9.3040903@fedoraproject.org> On 05/31/2009 06:05 PM, Frank Murphy (Frankly3d) wrote: > Rahul Sundaram wrote: >> On 05/31/2009 05:42 PM, Frank Murphy (Frankly3d) wrote: >>> Lat meeting log seems to be: >>> http://fedoraproject.org/wiki/SIGs/Development#Communication >> >> It's not active anymore. The Fedora Development custom spin has also >> been dropped. >> > > > Guessing lack of Interest? > > So what would be the best > Install Desktop + what devel. Packages required. Yes and yes. Rahul From jonathan.underwood at gmail.com Sun May 31 12:58:00 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 31 May 2009 13:58:00 +0100 Subject: Mono (& Moonlight) Licensing? Revisited In-Reply-To: <4A2257BE.8070203@gmail.com> References: <4A222DEC.7080106@gmail.com> <4A2255FB.8030105@fedoraproject.org> <4A2257BE.8070203@gmail.com> Message-ID: <645d17210905310558i6d1f7c35jacf3f933a9eb35d5@mail.gmail.com> 2009/5/31 Frank Murphy (Frankly3D) : >> http://gregdek.livejournal.com/4008.html > > > Doesn't clarify things for me. Yes, things have changed a fair bit since the OIN was initially set up - most notably the agreements that now exist between MS and Novell. Presumably, since Novell were a key player in the OIN, this now weakens the whole OIN effort, particularly w.r.t mono etc. Looks like this could really do with being revisited by Legal. Some interesting commentary on some aspects of the article originally linked to by the OP: http://www.osnews.com/story/21586/Mono_Moonlight_Patent_Encumbered_Or_Not_ J. From sundaram at fedoraproject.org Sun May 31 13:02:32 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 31 May 2009 18:32:32 +0530 Subject: Mono (& Moonlight) Licensing? Revisited In-Reply-To: <645d17210905310558i6d1f7c35jacf3f933a9eb35d5@mail.gmail.com> References: <4A222DEC.7080106@gmail.com> <4A2255FB.8030105@fedoraproject.org> <4A2257BE.8070203@gmail.com> <645d17210905310558i6d1f7c35jacf3f933a9eb35d5@mail.gmail.com> Message-ID: <4A227FE8.8080501@fedoraproject.org> On 05/31/2009 06:28 PM, Jonathan Underwood wrote: > 2009/5/31 Frank Murphy (Frankly3D) : >>> http://gregdek.livejournal.com/4008.html >> >> >> Doesn't clarify things for me. > > Yes, things have changed a fair bit since the OIN was initially set up > - most notably the agreements that now exist between MS and Novell. > Presumably, since Novell were a key player in the OIN, this now > weakens the whole OIN effort, particularly w.r.t mono etc. Looks like > this could really do with being revisited by Legal. If you have specific concerns, take it fedora-legal list. Developers cannot give you any legal opinions. Rahul From jonathan.underwood at gmail.com Sun May 31 13:04:41 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 31 May 2009 14:04:41 +0100 Subject: Mono (& Moonlight) Licensing? Revisited In-Reply-To: <4A227FE8.8080501@fedoraproject.org> References: <4A222DEC.7080106@gmail.com> <4A2255FB.8030105@fedoraproject.org> <4A2257BE.8070203@gmail.com> <645d17210905310558i6d1f7c35jacf3f933a9eb35d5@mail.gmail.com> <4A227FE8.8080501@fedoraproject.org> Message-ID: <645d17210905310604i8ea4868vb15c45f7d35c1c72@mail.gmail.com> 2009/5/31 Rahul Sundaram : > On 05/31/2009 06:28 PM, Jonathan Underwood wrote: >> 2009/5/31 Frank Murphy (Frankly3D) : >>>> http://gregdek.livejournal.com/4008.html >>> >>> >>> Doesn't clarify things for me. >> >> Yes, things have changed a fair bit since the OIN was initially set up >> - most notably the agreements that now exist between MS and Novell. >> Presumably, since Novell were a key player in the OIN, this now >> weakens the whole OIN effort, particularly w.r.t mono etc. Looks like >> this could really do with being revisited by Legal. > > If you have specific concerns, take it fedora-legal list. Developers > cannot give you any legal opinions. I wasn't asking them to. From kevin.kofler at chello.at Sun May 31 13:22:12 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 31 May 2009 15:22:12 +0200 Subject: Agenda for the 2009-05-26 Packaging Committee meeting References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <20090527072531.GA2413@amd.home.annexia.org> <4A1D91D4.4080909@redhat.com> <1243746853.2937.246.camel@adam.local.net> Message-ID: Adam Williamson wrote: > FWIW, I've definitely never seen a "Suggests(post)" (or anything other > than a plain "Suggests:") in Mandriva, and I don't recall seeing a > versioned one either. So it's not something I'd put much thought into. > Your caveats about those cases seem correct, though. IMHO, Suggests(post) should just be an error, it doesn't make any sense whatsoever. Things needed in scriptlets need to be hard requirements. Kevin Kofler From rawhide at fedoraproject.org Sun May 31 14:36:18 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Sun, 31 May 2009 14:36:18 +0000 (UTC) Subject: rawhide report: 20090531 changes Message-ID: <20090531143618.8A9D41B8003@releng2.fedora.phx.redhat.com> Compose started at Sun May 31 06:15:06 UTC 2009 Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 0 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From ngompa13 at gmail.com Sun May 31 14:36:51 2009 From: ngompa13 at gmail.com (King InuYasha) Date: Sun, 31 May 2009 09:36:51 -0500 Subject: Mono (& Moonlight) Licensing? Revisited In-Reply-To: <645d17210905310604i8ea4868vb15c45f7d35c1c72@mail.gmail.com> References: <4A222DEC.7080106@gmail.com> <4A2255FB.8030105@fedoraproject.org> <4A2257BE.8070203@gmail.com> <645d17210905310558i6d1f7c35jacf3f933a9eb35d5@mail.gmail.com> <4A227FE8.8080501@fedoraproject.org> <645d17210905310604i8ea4868vb15c45f7d35c1c72@mail.gmail.com> Message-ID: <8278b1b0905310736r1dfef6feof9cd874905b1c3ba@mail.gmail.com> If you are as scared of legal issues as you seem to be, then just pull ASP.net, ADO.net, and Winforms out. You would make a lot of people mad, but if you are really paranoid... Look at this for more info: http://mono-project.com/License#Patents Also, regarding Moonlight 2, it is merely a subset of Mono, with some extra APIs suited for it, the only real difference between Moonlight and Mono is codecs. And you don't even have to include those, since Moonlight by default does not require them and can download them automatically when they are needed. I really don't see why you should freak out over Moonlight, if Mono is protected, then Moonlight 2 should be protected, since it is a form of Mono itself. On Sun, May 31, 2009 at 8:04 AM, Jonathan Underwood < jonathan.underwood at gmail.com> wrote: > 2009/5/31 Rahul Sundaram : > > On 05/31/2009 06:28 PM, Jonathan Underwood wrote: > >> 2009/5/31 Frank Murphy (Frankly3D) : > >>>> http://gregdek.livejournal.com/4008.html > >>> > >>> > >>> Doesn't clarify things for me. > >> > >> Yes, things have changed a fair bit since the OIN was initially set up > >> - most notably the agreements that now exist between MS and Novell. > >> Presumably, since Novell were a key player in the OIN, this now > >> weakens the whole OIN effort, particularly w.r.t mono etc. Looks like > >> this could really do with being revisited by Legal. > > > > If you have specific concerns, take it fedora-legal list. Developers > > cannot give you any legal opinions. > > I wasn't asking them to. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdieter at math.unl.edu Sun May 31 14:40:38 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 31 May 2009 09:40:38 -0500 Subject: RPM Soft dependencies (Was: Re: Agenda for the 2009-05-26 Packaging Committee meeting) References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <20090527072531.GA2413@amd.home.annexia.org> <4A1D91D4.4080909@redhat.com> <200905301609.n4UG9G0M007345@laptop14.inf.utfsm.cl> Message-ID: Horst H. von Brand wrote: > This whole "soft dependencies" idea has been discussed to death numerous > times already, and the conclusion has always been that they really don't > solve anything. Whoa. That's far from my recollection, which is that most folks (me included) seem to think some variant of this would be nice, it's just that the implementation details would be *hard*. -- Rex From a.badger at gmail.com Sun May 31 15:01:17 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 31 May 2009 08:01:17 -0700 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <20090527072531.GA2413@amd.home.annexia.org> <4A1D91D4.4080909@redhat.com> <1243746853.2937.246.camel@adam.local.net> Message-ID: <4A229BBD.3040302@gmail.com> On 05/31/2009 06:22 AM, Kevin Kofler wrote: > Adam Williamson wrote: >> FWIW, I've definitely never seen a "Suggests(post)" (or anything other >> than a plain "Suggests:") in Mandriva, and I don't recall seeing a >> versioned one either. So it's not something I'd put much thought into. >> Your caveats about those cases seem correct, though. > > IMHO, Suggests(post) should just be an error, it doesn't make any sense > whatsoever. Things needed in scriptlets need to be hard requirements. > Actually we have several things that are not hard requires in scriptlets. I can't think of any that would be better served by having a Suggests(post) off the top of my head, though. Example: http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#Icon_Cache -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From sundaram at fedoraproject.org Sun May 31 15:07:50 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 31 May 2009 20:37:50 +0530 Subject: Mono (& Moonlight) Licensing? Revisited In-Reply-To: <8278b1b0905310736r1dfef6feof9cd874905b1c3ba@mail.gmail.com> References: <4A222DEC.7080106@gmail.com> <4A2255FB.8030105@fedoraproject.org> <4A2257BE.8070203@gmail.com> <645d17210905310558i6d1f7c35jacf3f933a9eb35d5@mail.gmail.com> <4A227FE8.8080501@fedoraproject.org> <645d17210905310604i8ea4868vb15c45f7d35c1c72@mail.gmail.com> <8278b1b0905310736r1dfef6feof9cd874905b1c3ba@mail.gmail.com> Message-ID: <4A229D46.3090309@fedoraproject.org> On 05/31/2009 08:06 PM, King InuYasha wrote: > > I really don't see why you should freak out over Moonlight, if Mono is > protected, then Moonlight 2 should be protected, since it is a form of > Mono itself. The legal opinion is different and we got to go by that. Rahul From skvidal at fedoraproject.org Sun May 31 15:32:20 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Sun, 31 May 2009 11:32:20 -0400 (EDT) Subject: RPM Soft dependencies (Was: Re: Agenda for the 2009-05-26 Packaging Committee meeting) In-Reply-To: <1243765101.2560.6.camel@localhost.localdomain> References: <4A1D91D4.4080909@redhat.com> <200905301609.n4UG9G0M007345@laptop14.inf.utfsm.cl> <1243747391.2937.255.camel@adam.local.net> <2d319b780905310229u33b31183n26422d01a225ff94@mail.gmail.com> <1243765101.2560.6.camel@localhost.localdomain> Message-ID: On Sun, 31 May 2009, Jussi Lehtola wrote: > > Is this possible now even with hard dependencies? If I install package A > that requires B and C, but decide I don't like it so I remove package A, > B and C still stay on my system. If you install the yum-plugin remove-with-leaves - you'll find the above situation does not occur. -sv From kmaraas at broadpark.no Sun May 31 15:47:54 2009 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Sun, 31 May 2009 17:47:54 +0200 Subject: rawhide report: 20090528 changes In-Reply-To: <1243613487.2937.189.camel@adam.local.net> References: <20090528140501.4121D1F8217@releng2.fedora.phx.redhat.com> <4A1F714C.80905@fedoraproject.org> <1243613487.2937.189.camel@adam.local.net> Message-ID: <1243784874.9220.4.camel@nc6400> fr., 29.05.2009 kl. 09.11 -0700, skrev Adam Williamson: > > This mostly relates to bug 502077, filed on May 21st (so quite late in > cycle). Intel i865 cards were experiencing random hangs with kernel > modesetting enabled (which was the default). There was a single > unconfirmed report of the same issue affect i845, and another single > unconfirmed report for i855. > I just tried the latest kernel now and was rewarded with a hang during boot. I've filed a bug earlier about hangs with more information here: https://bugzilla.redhat.com/show_bug.cgi?id=492686 This all started around the time KMS was introduced, and the only way I've found to have a working system is to pass maxcpus=1 to the boot command line. The latest kernel even hung with this passed to it. Cheers Kjartan From alsadi at gmail.com Sun May 31 16:39:55 2009 From: alsadi at gmail.com (Muayyad AlSadi) Date: Sun, 31 May 2009 19:39:55 +0300 Subject: welcome to fedora In-Reply-To: <64b14b300905310447o1f001c58u36b43d61f1b269e6@mail.gmail.com> References: <64b14b300905290413m222c25b1v4ab68cff9481d75b@mail.gmail.com> <4A225521.7020305@fedoraproject.org> <64b14b300905310447o1f001c58u36b43d61f1b269e6@mail.gmail.com> Message-ID: <385866f0905310939w3a9ed91co8b3dd1805cd81c39@mail.gmail.com> maybe a trivial pygtk script ? From awilliam at redhat.com Sun May 31 16:06:24 2009 From: awilliam at redhat.com (Adam Williamson) Date: Sun, 31 May 2009 09:06:24 -0700 Subject: RPM Soft dependencies (Was: Re: Agenda for the 2009-05-26 Packaging Committee meeting) In-Reply-To: <1243749335.2937.262.camel@adam.local.net> References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <20090527072531.GA2413@amd.home.annexia.org> <4A1D91D4.4080909@redhat.com> <200905301609.n4UG9G0M007345@laptop14.inf.utfsm.cl> <1243747391.2937.255.camel@adam.local.net> <4A2216CE.5030900@gmail.com> <1243749335.2937.262.camel@adam.local.net> Message-ID: <1243785984.2937.265.camel@adam.local.net> On Sat, 2009-05-30 at 22:55 -0700, Adam Williamson wrote: > > What is the behaviour when a package with soft deps on another package > > is upgraded and the soft dependency is currently not installed? > > What is it, in MDV and SUSE? Can't remember, off the top of my head. > What should it be? Interesting question, indeed. Either option is wrong > for someone. BTW, there is a way to handle this, but like proper orphan detection it would require yum to hold some sort of history. yum could do the right thing if it knew whether you had manually removed the soft dependency in question after installing the initial package, or not. I can't think of a 'clean' way to handle this without some kind of history tracking, though. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From sundaram at fedoraproject.org Sun May 31 16:52:39 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 31 May 2009 22:22:39 +0530 Subject: welcome to fedora In-Reply-To: <64b14b300905310447o1f001c58u36b43d61f1b269e6@mail.gmail.com> References: <64b14b300905290413m222c25b1v4ab68cff9481d75b@mail.gmail.com> <4A225521.7020305@fedoraproject.org> <64b14b300905310447o1f001c58u36b43d61f1b269e6@mail.gmail.com> Message-ID: <4A22B5D7.8070601@fedoraproject.org> On 05/31/2009 05:17 PM, Valent Turkovic wrote: > On Sun, May 31, 2009 at 12:00 PM, Rahul Sundaram > wrote: >> On 05/31/2009 01:31 PM, Thomas Janssen wrote: >>> Well, from my point of view, the OP doesn't meant to have a "Welcome >>> to Fedora" text alone. I think he meant more likely the other stuff. >>> Like, clickable: "Discover that" , "Get online help here" , "Find >>> information about whatever there". >>> >>> And thats not a bad idea. At least it is very new-user-friendly. >> >> It has been suggested before and accepted that as a useful idea. Someone >> needs to take the next step and implement it. > > Which tools would you recommend somebody uses to make this welcome screen? It would depend on the desktop you are targeting. PyGTK would be trivial for GNOME and QT for KDE. Xfce has a tips and tricks app that could be modified. It is also likely that whatever Mint is using already has the source code available. Rahul From kevin.kofler at chello.at Sun May 31 17:07:56 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 31 May 2009 19:07:56 +0200 Subject: Agenda for the 2009-05-26 Packaging Committee meeting References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <20090527072531.GA2413@amd.home.annexia.org> <4A1D91D4.4080909@redhat.com> <1243746853.2937.246.camel@adam.local.net> <4A229BBD.3040302@gmail.com> Message-ID: Toshio Kuratomi wrote: > Actually we have several things that are not hard requires in > scriptlets. I can't think of any that would be better served by having > a Suggests(post) off the top of my head, though. Indeed, those are different, they're "run this if it's installed, but we don't have to do anything if it isn't, because it means it doesn't need to run in the first place". It doesn't make sense to Suggests(post) anything there. Kevin Kofler From kevin.kofler at chello.at Sun May 31 17:15:03 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 31 May 2009 19:15:03 +0200 Subject: Mono (& Moonlight) Licensing? Revisited References: <4A222DEC.7080106@gmail.com> <4A2255FB.8030105@fedoraproject.org> <4A2257BE.8070203@gmail.com> <645d17210905310558i6d1f7c35jacf3f933a9eb35d5@mail.gmail.com> <4A227FE8.8080501@fedoraproject.org> <645d17210905310604i8ea4868vb15c45f7d35c1c72@mail.gmail.com> <8278b1b0905310736r1dfef6feof9cd874905b1c3ba@mail.gmail.com> Message-ID: King InuYasha wrote: > I really don't see why you should freak out over Moonlight, if Mono is > protected, then Moonlight 2 should be protected, since it is a form of > Mono itself. Moonlight needs to go to RPM Fusion anyway because it needs to link to FFmpeg, unless you want to use the proprietary codec pack from M$ (yuck!). So it's no use arguing about whether Moonlight itself is patent-encumbered or not. Kevin Kofler From emmanuel.seyman at club-internet.fr Sun May 31 17:44:58 2009 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Sun, 31 May 2009 19:44:58 +0200 Subject: Fedora Mips\Arm Processors? In-Reply-To: <1243694506.3740.55.camel@eagle.danny.cz> References: <4A212553.8020200@gmail.com> <1243694506.3740.55.camel@eagle.danny.cz> Message-ID: <20090531174458.GA22264@orient.maison.lan> * Dan Hor?k [30/05/2009 18:03] : > > There is no public effort to port Fedora to MIPS, but someone (connected > to a netbook vendor?) was asking some questions about our buildsystem. As the proud owner of a MIPS-powered netbook, I'ld be glad to participate in a MIPS SIG. Emmanuel From jkeating at redhat.com Sun May 31 18:15:42 2009 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 31 May 2009 11:15:42 -0700 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <20090527072531.GA2413@amd.home.annexia.org> <4A1D91D4.4080909@redhat.com> <1243746853.2937.246.camel@adam.local.net> <4A229BBD.3040302@gmail.com> Message-ID: <1243793742.3037.181.camel@localhost.localdomain> On Sun, 2009-05-31 at 19:07 +0200, Kevin Kofler wrote: > Toshio Kuratomi wrote: > > Actually we have several things that are not hard requires in > > scriptlets. I can't think of any that would be better served by having > > a Suggests(post) off the top of my head, though. > > Indeed, those are different, they're "run this if it's installed, but we > don't have to do anything if it isn't, because it means it doesn't need to > run in the first place". It doesn't make sense to Suggests(post) anything > there. > > Kevin Kofler > Conceivably though you can have a scenario where if a suggested package is present, you'll want to make use of it in the %pre section of the suggesting package, and fail gracefully if it isn't there. So Suggests: isn't enough, you'd need to order it so that if you choose to install the suggestion, it gets installed prior to the suggesting package, hence Suggests(post). -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Sun May 31 19:18:40 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 31 May 2009 15:18:40 -0400 Subject: Removing %clean (Was Re: Agenda for the 2009-05-26 Packaging Committee meeting) In-Reply-To: References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1C3CD7.7040600@redhat.com> Message-ID: <4A22D810.1080101@redhat.com> On 05/30/2009 04:15 AM, Panu Matilainen wrote: > No objections to BuildRoot and %install parts, but I'd suggest leaving > %clean out of it for the time being, as this is on direct collision > course with the above suggestion of built-in default %clean. If a built-in default %clean is coming, then I'll happily leave that out. Do you need me to file a bug requesting that feature? ~spot From forum at ru.bir.ru Sun May 31 19:33:05 2009 From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus)) Date: Sun, 31 May 2009 23:33:05 +0400 Subject: Why not to create Fedora-us and Fedora-non-us branches? In-Reply-To: <4A227206.9010601@fedoraproject.org> References: <20090526170612.GJ9951@nostromo.devel.redhat.com> <1243358736.3144.23.camel@localhost.localdomain> <4A1C2961.70703@redhat.com> <4A2269C7.1010800@fedoraproject.org> <1243770864.26053.8.camel@localhost.localdomain> <4A227206.9010601@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > On 05/31/2009 05:24 PM, Alexey Torkhov wrote: >> On Sun, 2009-05-31 at 16:58 +0530, Rahul Sundaram wrote: > >> Usage of trademark was granted to Russian Fedora by agreement between >> Red Hat and other company that represent it here, AFAIK. >> Max Spevack was on presentation on Russian Fedora launch. > > I don't see it recorded in > > https://fedoraproject.org/wiki/Trademark_licensees > > It doesn't fit the trademark guidelines either. While Red Hat can > legally grant a license to anyone and doesn't have to abide by the > guidelines, I would expect it to do so nevertheless. So why a special > exception for "Russian Fedora"? > > Rahul I also do not known details of legal, but may be just contact RedHat and add domains russianfedora.ru and russianfedora.com to the list https://fedoraproject.org/wiki/Trademark_licensees ?