Re: orphaning gwibber, any takers?
On 04/01/10 21:47, Tom spot Callaway wrote: On 01/04/2010 04:25 PM, Ian Weller wrote: I know Gwibber is widely used by Fedora users because there are a crapton of abrt reports for it and I just can't keep up with it. :) If no one else wants it, I will take it. I'd prefer to comaintain it with someone who has more time than I do. :) I'd happily co-maintain - I use gwibber a fair amount and can probably have a stab at debugging some of the issues. Cheers Alex. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
New covenant published (was: Re: moonlight and the new covenant)
On 19/12/09 11:03, Alex Hudson wrote: The covenant is published as far as I can see here: No, that's the previous one which was not good enough. The new one is not yet published. Correction: it's now published here - http://www.microsoft.com/interop/msnovellcollab/newmoonlight.mspx To my untrained eye, it seems to cover Moonlight fully, the termination clause doesn't work retroactively, it includes coverage for the Mono portions and it seems to apply for everyone - hopefully this is a good thing. It seems to remove previous objections about Novell-only-ness. Thanks Alex. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: New covenant published
On 23/12/09 18:58, Tom spot Callaway wrote: On 12/23/2009 01:56 PM, Alex Hudson wrote: Can I ask on what grounds? Is the patent license insufficient, or is there some other problem? It's difficult to fix things if we don't know what's broken. The most obvious issue is that it does not cover Distributors besides Novell. I thought that was the whole reason a new covenant has been issued, so that people other than Novell could distribute it. Looking over it, I don't really see where any distinction between Novell and anyone else is made. It would be useful to have some response from legal people about the exact issues which remain. It seems to me highly unlikely that problems are going to be resolved unless the problems are made clear; and the movement on this issue appears to be in the right direction. I realise a number of people don't care for Mono-related technologies, but it would be sad to see Fedora left out in the cold for this stuff. Cheers Alex. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: moonlight and the new covenant
On 19/12/09 10:36, Julian Sikorski wrote according to Miguel [1], the moonlight covenant was updated and now allows for redistribution by third parties. Does it change anything wrt. its inclusion in Fedora? I doubt it's worth asking until the new covenant is actually published, which is supposed to happen next week. If what they are saying, that people who get Moonlight without being a Novell customer are covered by the patent covenant, I would hope that removes whatever stumbling block remains. Cheers Alex. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: moonlight and the new covenant
On 19/12/09 11:00, Julian Aloofi wrote: Am Samstag, den 19.12.2009, 10:47 + schrieb Alex Hudson: I doubt it's worth asking until the new covenant is actually published, which is supposed to happen next week. The covenant is published as far as I can see here: No, that's the previous one which was not good enough. The new one is not yet published. Thanks Alex. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
On 27/11/09 06:08, Dave Airlie wrote: Don't use radeonhd, the Fedora X team don't support it and never have. I'm thinking it should reallyt be removed from the distro at this point as it makes things worse rather than better. If you do this, please consider having a radeonhd-radeon testing day for people like myself - radeonhd works for me where radeon doesn't: https://bugzilla.redhat.com/show_bug.cgi?id=492723 (I haven't yet tested with F12 final, it's on my to-do list - but the various alphas/betas didn't improve matters) I would have thought that the radeon driver capabilities should be very close to radeonhd, some of these bugs should be easy to squash (he says ;). Cheers Alex. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Updates-testing (was: Re: thunderbird upgrade - wtf?)
On 14/10/09 15:31, Jesse Keating wrote: On Wed, 2009-10-14 at 09:27 -0500, Mike McGrath wrote: The problem isn't GLODA and smart folders, it's that we have no process in place to identify and deal with problems like this before it's too late. Aside from updates-testing you mean, where people can test potential updates and give feedback as to how they work on their systems? For me, there is a bit of a problem with updates-testing: the machine I work on is my primary desktop, and I'm extremely wary of getting myself into a situation I can't easily get out of. Now, you might argue that avoiding u-t is essentially avoiding the inevitable (and Tbird 3 has shown me that, so I agree), but it is riskier. What would sell me totally on u-t was if there was something where I can roll back bad packages. I'm pretty sure there are various obscure technical reasons why rolling back isn't possible in 100% of cases, but I don't think that's necessary. So long as it's in the high 90%s then it's good enough, and to be honest I would want to avoid testing updates I can't revert like the plague anyway: not being able to roll back to my mind is a good indicator of not being suitable for a stable release. In my ideal world, PackageKit would update my stuff with testing updates, and anything which broke could be reverted back to some previous date or something - either by package if I can identify it, or by actual last-known-good date. I'm sure that's a tonne of work, but that's the only way I can see the testing system making sense for people who rely on their Fedora desktop. Cheers Alex. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing
On 14/10/09 16:49, Mike McGrath wrote: I've suggested this very thing in a F-A-B thread this week. We, packagers, have no way to fix a mistake and very few things preventing us from making them: https://www.redhat.com/archives/fedora-advisory-board/2009-October/msg00168.html I love this! I would say having an experimental repo wouldn't be as good as having per-app repos: for me, there are apps I care about and want to test, and others I use infrequently and couldn't contribute much to. However, if on the other hand there was some way of marking out which packages I wanted to pull from experimental (or updates-testing for that matter), then well and good. I think experimental is needed, though. Some apps really need longer baking before getting into Fedora proper: Tbird 3 for me is an excellent example, although probably for the maintainer one which is much more obvious in hindsight. The change in mission makes a huge amount of sense (being usable, if not bug-free, has to be a top priority in my mind). For my money, a great proposal though, thanks. Alex. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing
On 14/10/09 16:47, Seth Vidal wrote: yum downgrade pkgname it works fine for the simple-ish cases. If that works, then gravy. I can't admit to having tried it in the past - although, I'm not really a yum user, I use packagekit, and indeed pk whines at me to turn off the legacy software when I run yum ;) Ideally, for me, this would be something pk can trigger (and maybe give me a way of contributing to the testing karma at the same time - that would rock). Personally, though, I would think that if that is a feature we're advertising then it should be policy that either a. package maintainers strive to ensure their packages are mainly downgradable (certainly within a stable release) or b. the packages are marked as don't downgrade me and yum/whatever issues the appropriate expletive when you try to do that. I would say again that any package update which cannot be downgraded would be one I would think hard about releasing into a stable Fedora. Cheers Alex. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum-presto not on by default
On 23/09/09 17:00, Jesse Keating wrote: On Wed, 2009-09-23 at 10:23 -0400, Seth Vidal wrote: ...but to me this is all a _problem_in_xz_, not presto/deltarpms. If nobody can fix xz before F12 GA then IMNSO we should revert the compression to something that works agreed. Dropping xz at this point would mean another full mass rebuild. Do-able but needs to happen very very soon. I'd be interested in trying to fix xz (I disagree entirely that this is an xz bug; it's a bug in the assumptions of those whose used it for the wrong purpose), but presumably it means rebuilding packages built on certain arches anyway - and if that's not easy to determine, does that imply a rebuild anyway? Cheers Alex. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Page size pain / localisation / possible F13 feature
Hi everyone. Living in a European milieu I generally prefer my page sizes to be set to the likes of A4. One thing which keeps aggravating me is the myriad places where I keep having to repeat to the computer my preference. In Thunderbird and Firefox right now, if I open up 'Page Settings' it says 'US Letter'. The one and only printer I have only has A4 (and is set that way), and I've told Fedora in various places that I'm in the UK and speak British English. OOo somehow gets it right; potentially this is something I overrode at some point - I still have various letter-shaped documents and PDFs on my system. Clearly something is missing. /etc/papersize is empty, paperconf returns 'a4', /etc/libpaper.d is empty, the default printer is set to my A4 printer, 'locale' outputs lots of en_GB entries but $LC_PAPER isn't set. I've been through every Preference and Administrative menu option I can find which might be relevant, including a few which weren't, and I've no idea how all this stuff is supposed to be hooked up. If there is some overriding admin option, I've missed it (and the accompanying docs ;). This is a real pain point which could probably solved _really_ easily. There was a localisation feature proposed for F10: http://fedoraproject.org/wiki/Features/LocalePreferences ... that attempts to solve the more general issue (keyboard layouts etc., which have also bitten me - it's not very obvious at all how to set that stuff properly at the moment). Is there any additional interest (other than me!) for getting this feature back on its feet again for F13? Thanks! Alex. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Page size pain / localisation / possible F13 feature
On 27/08/09 18:40, Tom spot Callaway wrote: On 08/27/2009 12:11 PM, John J. McDonough wrote: Do we even have an inventory of places where page size matters? And then, are those that get it right actually using some standard source, or do they simply use a different default? A great first step would be to go make a list of the applications included on the Desktop spin that support printing, and identify how it configures its settings. That data might make it clear what the system default should be, and efforts could then be made to patch the other applications to use it. I think that's a brilliant idea. I'll undertake to do this in the next couple of weeks - I'll work on the F12 set first, because obviously that's going to be very similar to F13 anyway. Am I ok to re-activate the localisation feature for F13, or should I be starting a new feature for this? Thanks Alex. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
