date:20091209

On Wed, Dec 09, 2009 at 06:51:59 +0100,
  Ralf Corsepius rc040...@freenet.de wrote:
 
 Seems to me, as if some people in Fedora's leadership don't want to
 understand that being able to deploy Linux on old or recycled
 hardware used to be one big selling point in Linux.

I think the question is really, is Fedora suitable for being deployed
on older hardware? Currently it isn't (for some value of older).

I think if people wanted to try and make this happen, it could happen.
But it would be a lot of work and might be different enough that it
couldn't use the Fedora brand.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: thunderbird is removing spaces

2009-12-09 Thread Joachim Backes


On 12/09/2009 01:23 PM, Stefan Assmann wrote:

Hi,

thunderbird seem to remove spaces from lines that only consist of one or
more spaces. Any way of preventing thunderbird from doing so? I already
have mailnews.send_plaintext_flowed false and turned of line wrapping.

With these option sending patches works pretty well, only recently I
had a patch that got corrupted because of spaces being removed.

Any ideas?

   Stefan


Hi Stefan,

I'm running the recently (yesterday) released 3.0 version of thunderbird 
from mozilla.org, and I can confirm the same behaviour, but have no 
solution how to get rid from this.


Regards

Joachim Backes

--
Joachim Backes joachim.bac...@rhrk.uni-kl.de

http://www.rhrk.uni-kl.de/~backes



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: abrt issue

2009-12-09 Thread Jiri Moskovcak



$ yum update abrt --enablerepo=updatetesting and try the updated version which
should fix some problems with debuginfo installing.


It should be:
yum update abrt --enablerepo=updates-testing, but it seems it didn't hit 
the repository yet even thou I got the email.


J.
attachment: jmoskovc.vcf-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: abrt issue

2009-12-09 Thread Neal Becker

Jiri Moskovcak wrote:

 On 12/09/2009 02:05 PM, Neal Becker wrote:
 Jiri Moskovcak wrote:

 On 12/09/2009 01:47 PM, Neal Becker wrote:
 I just got a crash in kde plasma.  Traceback is not useful, because of
 missing debug pacakges.

 I'm told I can reload after 'installing the needed packages', but
 there is no clue what packages are needed.

 A bit of a mystery.  It seems sometimes abrt will go ahead and download
 needed debuginfo packages, but other times (like today), it doesn't,
 and doesn't offer any clue what packages are missing.

 Weird, ABRT should tell you the exact package you should install
 debuginfo for. I just tried that and abrt says this:

 Reporting disabled because the backtrace is unusable.
 Please try to install debuginfo manually by using command:
 *debuginfo-install python*
 the use the Refresh button to regenerate the backtrace.

 Jirka

 Yes, I've gotten messages like this sometimes, and that's what I was
 looking
 for.  But not today.

 Maybe related?
 Dec  9 07:50:11 localhost abrtd: New crash, saving
 Dec  9 07:50:11 localhost abrtd: Activation of plugin 'RunApp' was not
 successful: Plugin 'RunApp' is not registered

 
 This shouldn't be related, but I'm wondering where did you get the line
 reload after 'installing the needed packages' it doesn't come from
 ABRT.
This is not an exact quote, but it's what I got from abrt when I clicked on 
'next'.

I don't know what debuginfo package is needed.  rpm -qa '*plasma*' doesn't 
give a good answer.  Why isn't abrt telling me?

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: abrt issue

2009-12-09 Thread Jiri Moskovcak


On 12/09/2009 02:23 PM, Neal Becker wrote:

Jiri Moskovcak wrote:


On 12/09/2009 02:05 PM, Neal Becker wrote:

Jiri Moskovcak wrote:


On 12/09/2009 01:47 PM, Neal Becker wrote:

I just got a crash in kde plasma.  Traceback is not useful, because of
missing debug pacakges.

I'm told I can reload after 'installing the needed packages', but
there is no clue what packages are needed.

A bit of a mystery.  It seems sometimes abrt will go ahead and download
needed debuginfo packages, but other times (like today), it doesn't,
and doesn't offer any clue what packages are missing.


Weird, ABRT should tell you the exact package you should install
debuginfo for. I just tried that and abrt says this:

Reporting disabled because the backtrace is unusable.
Please try to install debuginfo manually by using command:
*debuginfo-install python*
the use the Refresh button to regenerate the backtrace.

Jirka


Yes, I've gotten messages like this sometimes, and that's what I was
looking
for.  But not today.

Maybe related?
Dec  9 07:50:11 localhost abrtd: New crash, saving
Dec  9 07:50:11 localhost abrtd: Activation of plugin 'RunApp' was not
successful: Plugin 'RunApp' is not registered



This shouldn't be related, but I'm wondering where did you get the line
reload after 'installing the needed packages' it doesn't come from
ABRT.

This is not an exact quote, but it's what I got from abrt when I clicked on
'next'.

I don't know what debuginfo package is needed.  rpm -qa '*plasma*' doesn't
give a good answer.  Why isn't abrt telling me?



It definitely is telling you. You can see it either in main window in 
column Package or in the report window if you scrolldown the backtrace 
you'll see row package


J.
attachment: jmoskovc.vcf-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: F12 updates-testing issue: X flickers and fails to start

2009-12-09 Thread Linuxguy123

On Wed, 2009-12-09 at 10:36 +0100, Michal Schmidt wrote:
 On Wed, 9 Dec 2009 11:12:07 +0200 (EET) Pekka Savola wrote:
  Now gdm login however doesn't show my username and fingerprint login 
  is no longer an option
 
 Looks like the issue with hal-0.5.14-1:
 https://admin.fedoraproject.org/updates/F12/FEDORA-2009-12840


I think it has something to do with display power management and the
monitor brightness level. I can replicate the behavior by simply
adjusting the display brightness in a KDE session.

I have logged 2 bugs that are possibly related to this.

https://bugzilla.redhat.com/show_bug.cgi?id=528188

https://bugzilla.redhat.com/show_bug.cgi?id=525767



-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: F12 updates-testing issue: X flickers and fails to start

2009-12-09 Thread Linuxguy123

On Wed, 2009-12-09 at 06:27 -0700, Linuxguy123 wrote:
 On Wed, 2009-12-09 at 10:36 +0100, Michal Schmidt wrote:
  On Wed, 9 Dec 2009 11:12:07 +0200 (EET) Pekka Savola wrote:
   Now gdm login however doesn't show my username and fingerprint login 
   is no longer an option
  
  Looks like the issue with hal-0.5.14-1:
  https://admin.fedoraproject.org/updates/F12/FEDORA-2009-12840
 
 
 I think it has something to do with display power management and the
 monitor brightness level. I can replicate the behavior by simply
 adjusting the display brightness in a KDE session.
 
 I have logged 2 bugs that are possibly related to this.
 
 https://bugzilla.redhat.com/show_bug.cgi?id=528188
 
 https://bugzilla.redhat.com/show_bug.cgi?id=525767
 

I recommend connecting an external monitor to see if the issue is
display specific and have you tried ctrl-alt-F6 to get to a console at
login and then going back to the X session with ctrl-alt-F1 ?


-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Useless setroubleshoot alerts

2009-12-09 Thread Christopher Brown

2009/12/8 Konstantin Ryabitsev i...@fedoraproject.org:
 From the point of view of security usability, this is cardinal sin:

 http://file.status.net/identica/tieguy-20091208T063036-ngc2rhp.png

 If we start the warning message with SELinux has detected suspicious
 behaviour on your system and end it with You can safely ignore this
 avc, then we are doing everyone a nasty disservice. Please, let's fix
 it as soon as possible. I understand the need for SELinux to log
 things purely for auditing purposes, but the user must NOT see those
 alerts, or we'll condition everyone to just dismiss them.

 I'm fairly certain this is a bug, but I've not yet bz'd it, as I
 wanted to make sure that this is not intended behaviour.

If it is then it is proof of insanity. I shy away from any Yet
Another SELinux Rant type stuff but this is plain ridiculous. I had
Gnome-terminal up this morning and was shelled into a remote box.
Thats it. Then I got a warning of the above - something to do with
bash and prelink. Couldn't care less really.

The end result is me disabling SELinux on my box. Sorry, I don't have
time or inclination to file a bug on this constant irritant ever since
it was introduced as nobody seems to take notice. Instead I'm asked
to:

# chcon_text_rel_slib insert_irritating_long_option_here
add_some_random_characters_for_good_measure_}{)()(*^^$%$1

or something. SELinux was quite good on F11 and F12. Now it would seem
it is starting to regress again.

/rant

-- 
Christopher Brown

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Fedora release criteria completely revised

2009-12-09 Thread John Poelstra


Adam Williamson said the following on 12/08/2009 07:12 AM Pacific Time:

On Tue, 2009-12-08 at 15:07 +0100, Kevin Kofler wrote:
Plus, why was the KDE SIG not invited? (We had at least 4 KDE SIG folks 
present at FUDCon.) 


We had a pre-hackfest meeting for the whole FUDCon attendee list where
everyone who wanted to hack on something stood up and announced what
they would be hacking on. John Poelstra announced at that meeting that
we would be gathering to work on the release criteria. The KDE people
who were at FUDCon were at that meeting, so they were in a position to
know about the work. I was running around all day telling people what we
were working on, it wasn't a secret.

Are you planning to ship Fedora 13 even if the KDE Live 
image is broken?


That depends on whether you want us to or not. :) If a SIG has criteria
they want to add to the list, and they can commit to fulfilling those
criteria and be willing to take the responsibility of causing a release
to slip if they _don't_ fulfill them, we can certainly add those to the
lists. If KDE has minimum functional levels for the KDE spin that they
can commit to, please do send them to this thread and we'll look at
putting them in the criteria.

We intentionally didn't specifically address the issue of the relative
'importance' of spins in the criteria as it's a difficult topic and one
that's not really appropriate to decide in this place. The existing
criteria didn't address this either - they didn't say anything about
_any_ spin having to be not 'broken' before we ship - so there's no
change there.


This is a good clarification that we should add to the criteria page--it 
only speaks to requirements to release our default offering.  It is also 
a framework to add more detail to once the Target Audience discussion 
is finalized.


The Fedora QA process, for as long as I've been near it has focused on 
the default offering which has the Gnome desktop.


I don't speak for the QA group, but to my knowledge Fedora QA has never 
officially tested or been responsible for testing any of the spins, 
including KDE.  When I was part of the spins process it was understood 
that each Spins team was responsible for testing their spin.


It would be a mistake to take the new release criteria pages and attempt 
to mold them to make them be all things to all Spins.  Just as each of 
the public releases (Alpha, Beta, and Final) have different target 
audiences, so do the spins themselves.


What would make sense would be for each of the Spins SIGS to copy the 
release criteria pages and mold their own from them. The Fedora QA Team 
already has enough things on their plate and they are doing a great job, 
but don't muddy the waters by trying to mix two target audiences into 
the same release criteria.


John

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Fedora release criteria completely revised

2009-12-09 Thread Dominik 'Rathann' Mierzejewski

On Monday, 07 December 2009 at 23:55, Adam Williamson wrote:
[...]
 https://fedoraproject.org/wiki/Fedora_13_Alpha_Release_Criteria
 https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria

16. Automatic mounting on insertion of removable media must work

It should be clarified with ... after GUI login, because it sure never
worked before a user is logged in. Also it never worked when user was
logged in via text console, did it?

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

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Promoting i386 version over x86_64?

2009-12-09 Thread Dominik 'Rathann' Mierzejewski

On Tuesday, 08 December 2009 at 20:07, Jon Masters wrote:
 On Tue, 2009-12-08 at 18:41 +0100, drago01 wrote:
  On Tue, Dec 8, 2009 at 5:27 PM, Rallias UberNerd
 
   But wouldn't it be better to use 32 bit when less then 4 GB of ram is
   present?
  
  no, using x86_64 means more registers, sse2 as default floating point
  instruction set, better calling convention (register passing vs.
  stack) or in other words in most cases faster code.
 
 Indeed. Intel 64 (x86_64) is really a different animal. More registers,

Actually, x86_64 is an AMD invention (originally called AMD64)
and is called EM64T by Intel. The only Intel 64 I can think of
is IA64, i.e. Itanium (called Itanic by some).

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

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Why pavucontrol is not installed by default?

2009-12-09 Thread Bastien Nocera

On Wed, 2009-12-09 at 13:51 +0100, Christof Damian wrote:
 On Tue, Dec 8, 2009 at 12:59, Tomasz Torcz to...@pipebreaker.pl wrote:
  On Tue, Dec 08, 2009 at 09:51:55AM -0200, Paulo Cavalcanti wrote:
   pavucontrol is regarded as advance tool, but also partly
  obsolete. Current gnome-volume-control superseded most of
  its functionality: controlling different streams volume,
  switching profile, outputs, fallback devices.
 
 I am curious: If pavucontrol is obsolete, is there some other tool to
 tell skype to use headsets, while rhythmbox uses the speakers?

It's not obsolete, it's just not installed by default.

 pavucontrol currently crashes (and pulseaudio) for me on one machine
 and I need this functionality.

File bugs!

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

rawhide and tagging requests

2009-12-09 Thread Peter Robinson

Hi All,

What's the status of the issues with the rawhide compose? Are they
going to be fixed and a push done before the upcoming extended outage?
What about outstanding tag build-override requests?

Cheers,
Peter

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Promoting i386 version over x86_64?

2009-12-09 Thread Ralf Corsepius


On 12/09/2009 02:05 PM, Bruno Wolff III wrote:

On Wed, Dec 09, 2009 at 06:51:59 +0100,
   Ralf Corsepiusrc040...@freenet.de  wrote:
   

Seems to me, as if some people in Fedora's leadership don't want to
understand that being able to deploy Linux on old or recycled
hardware used to be one big selling point in Linux.
 

I think the question is really, is Fedora suitable for being deployed
on older hardware?

In its early days, it was.


  Currently it isn't (for some value of older).
   
Ageed, it isn't anymore. As I feel, sarcasm Fedora has followed up 
Microsoft the Vista way /sarcasm


Those using modern hardware may find this cool, those who don't, 
switch away to using different distros.




I think if people wanted to try and make this happen, it could happen.
   
sigh It wasn't a lot of work in the early Fedora day - It simply 
worked out of the box! /sign


However, some $DEITY's have decided otherwise ...

I am inclined to think inevitably, because such platforms aren't the 
platforms most developers use nor the platforms RHEL is aiming at ... 
These people think in terms of Quad machines and RH clients, but 
forget about the amount of old machines which are still actively being 
used and about use-case niches.


Ralf


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Promoting i386 version over x86_64?

2009-12-09 Thread Nicolas Mailhot



Le Mer 9 décembre 2009 15:00, Dominik 'Rathann' Mierzejewski a écrit :

 Actually, x86_64 is an AMD invention (originally called AMD64)
 and is called EM64T by Intel. The only Intel 64 I can think of
 is IA64, i.e. Itanium (called Itanic by some).

When Intel realised Itanium was a failure, they dumped the ia32/ia64
classification and adopted x32/x64 (which is the same thing, except x64 !=
ia64, talk about hiding past mistakes)

-- 
Nicolas Mailhot


-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Promoting i386 version over x86_64?

2009-12-09 Thread Matthew Garrett

On Wed, Dec 09, 2009 at 03:00:51PM +0100, Dominik 'Rathann' Mierzejewski wrote:

 Actually, x86_64 is an AMD invention (originally called AMD64)
 and is called EM64T by Intel. The only Intel 64 I can think of
 is IA64, i.e. Itanium (called Itanic by some).

http://www.intel.com/technology/intel64/

We have always been at war with Itanium,

-- 
Matthew Garrett | mj...@srcf.ucam.org

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Promoting i386 version over x86_64?

2009-12-09 Thread James Antill

On Wed, 2009-12-09 at 15:26 +0100, Ralf Corsepius wrote:
 However, some $DEITY's have decided otherwise ...
 
 I am inclined to think inevitably, because such platforms aren't the 
 platforms most developers use nor the platforms RHEL is aiming at ... 
 These people think in terms of Quad machines and RH clients, but 
 forget about the amount of old machines which are still actively being 
 used and about use-case niches.

 A+ for, eventually, coming to the obvious solution. Although,
personally, I haven't had a quad core yet all the computers I currently
have running are either laptops or dual cores. The minimum RAM size on
any of these 5 boxes is 2GB.

 I'd be surprised to find that anyone working as a full time developer
has any (non-virt) boxes that are spec'd less than that.
 And yes, shockingly, developers will test on the machines they have
easy access to.

 So, yeh, if _you_ want to support slower machines ... _you_ will have
to do the work, you might get help from the community but just ranting
on f-d-l Everyone should solve my problems is unlikely to actually
help. IMO.

-- 
James Antill - ja...@fedoraproject.org
http://yum.baseurl.org/wiki/releases
http://yum.baseurl.org/wiki/whatsnew/3.2.25
http://yum.baseurl.org/wiki/YumMultipleMachineCaching

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Promoting i386 version over x86_64?

2009-12-09 Thread John Reiser


On 12/09/2009 07:14 AM, James Antill wrote:

... The minimum RAM size on any of these 5 boxes is 2GB.

  I'd be surprised to find that anyone working as a full time developer
has any (non-virt) boxes that are spec'd less than that.


Surprise!  I have 4 boxes that are 1GB or less (as low as 320MB),
and several that are 2GB or more.


 And yes, shockingly, developers will test on the machines they have
easy access to.


Sometimes I doubt even that, particularly when shipped software
has python syntax errors (type mismatch, wrong number of arguments,
no such member, ...)

--

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Why pavucontrol is not installed by default?

2009-12-09 Thread Christof Damian

On Wed, Dec 9, 2009 at 15:14, Bastien Nocera bnoc...@redhat.com wrote:
 I am curious: If pavucontrol is obsolete, is there some other tool to
 tell skype to use headsets, while rhythmbox uses the speakers?

 It's not obsolete, it's just not installed by default.

 pavucontrol currently crashes (and pulseaudio) for me on one machine
 and I need this functionality.

 File bugs!

I do, but this one is already in bugzilla as far as I can see. I just
wanted to mention why I am looking for an alternative.

Christof

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Promoting i386 version over x86_64?

2009-12-09 Thread Ralf Corsepius


On 12/09/2009 04:14 PM, James Antill wrote:

On Wed, 2009-12-09 at 15:26 +0100, Ralf Corsepius wrote:



  So, yeh, if _you_ want to support slower machines

Well, I do not want to, I can't avoid to ...


... _you_ will have
to do the work, you might get help from the community but just ranting
on f-d-l Everyone should solve my problems is unlikely to actually
help. IMO.


There is an easier solution: Stop using/promoting/advertising Fedora and 
switch to a different distro ...


Ralf



--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Promoting i386 version over x86_64?




On Wed, 9 Dec 2009, Ralf Corsepius wrote:


On 12/09/2009 04:14 PM, James Antill wrote:

On Wed, 2009-12-09 at 15:26 +0100, Ralf Corsepius wrote:



  So, yeh, if _you_ want to support slower machines

Well, I do not want to, I can't avoid to ...


... _you_ will have
to do the work, you might get help from the community but just ranting
on f-d-l Everyone should solve my problems is unlikely to actually
help. IMO.


There is an easier solution: Stop using/promoting/advertising Fedora and 
switch to a different distro ...




okay, for you, that sounds like it may be the best option. You are 
obviously unhappy with fedora. We've appreciated your constructive 
contributions but if you are no longer interested in working on/with 
fedora, then we wish you well in your endeavors.


It would be most polite to officially orphan your packages before you go.

Thanks and good luck in the future.
-sv

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Promoting i386 version over x86_64?

2009-12-09 Thread Rahul Sundaram

On 12/09/2009 10:17 PM, Ralf Corsepius wrote:
 On 12/09/2009 04:14 PM, James Antill wrote:
 On Wed, 2009-12-09 at 15:26 +0100, Ralf Corsepius wrote:
 
   So, yeh, if _you_ want to support slower machines
 Well, I do not want to, I can't avoid to ...
 
 ... _you_ will have
 to do the work, you might get help from the community but just ranting
 on f-d-l Everyone should solve my problems is unlikely to actually
 help. IMO.
 
 There is an easier solution: Stop using/promoting/advertising Fedora and
 switch to a different distro ...

Absolutely. Fedora can't be everything to everybody. If noone is willing
to do the work involved, try and find the tools to do the job better.
Just ranting isn't useful.

Rahul

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Promoting i386 version over x86_64?

2009-12-09 Thread Ralf Corsepius


On 12/09/2009 05:51 PM, Seth Vidal wrote:



On Wed, 9 Dec 2009, Ralf Corsepius wrote:


On 12/09/2009 04:14 PM, James Antill wrote:

On Wed, 2009-12-09 at 15:26 +0100, Ralf Corsepius wrote:



So, yeh, if _you_ want to support slower machines

Well, I do not want to, I can't avoid to ...


... _you_ will have
to do the work, you might get help from the community but just ranting
on f-d-l Everyone should solve my problems is unlikely to actually
help. IMO.


There is an easier solution: Stop using/promoting/advertising Fedora
and switch to a different distro ...



okay, for you, that sounds like it may be the best option. You are
obviously unhappy with fedora.

Did I say this? I am unhappy with Fedora's management's decisions.

Technically, Fedora is quite usable (most of the time), on more or 
modern machines.



We've appreciated your constructive
contributions but if you are no longer interested in working on/with
fedora, then we wish you well in your endeavors.
If I wasn't interested in Fedora, I wouldn't complain. It's just that 
Fedora increasingly diverges from my needs and increasingly is not 
applicable for my purposes.


Less abstract: This development forces me to not recommend Fedora (or 
RHEL) to customers.



It would be most polite to officially orphan your packages before you go.
Thanks you for sheding more insights in how you intend to take community 
interests into account.



--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: yum download estimates and stalls




On Wed, 9 Dec 2009, Richard W.M. Jones wrote:


I don't want to make unfair comparisons to the famous bug in Windows
Vista[1], but it seems as if when a yum download stalls, then the
estimates can start to look a little large:

rawhide/primar 20% [-   ]  0.0 B/s | 2.5 MB 2046434610655583470384211558:24 ETA



What ver of python-urlgrabber do you have installed?

And there is a patch posted I've not merged yet, mainly b/c I was out of 
the world for the weekend.


-sv

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Fedora release criteria completely revised

2009-12-09 Thread Adam Williamson

On Tue, 2009-12-08 at 09:19 -0500, Colin Walters wrote:
 Hi Adam,
 
 Looks really great in general!  

Thanks!

 One specific comment, for Final 9; I
 think we need a more specific definition of and subsequent login.
 Does that mean that you just type your username/password and look at
 the default desktop?

This is what it was intended to mean, actually running apps I would have
defined as 'login and use'. How would you suggest wording a
clarification?

-- 
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@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Changed license for clojure-1.0.0 (CPL - EPL)

2009-12-09 Thread Jochen Schmitt

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hallo,

I want to notifiy you, that the license of clojure-1.0.0 was changed
from the Common Public License to Eclipse Public License 1.0.

Best Regards:

Jochen Schmitt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iJwEAQECAAYFAksf3z4ACgkQZLAIBz9lVu9FjAQAm0uRZ+7wVodnGkmLKiAummkt
z/ZyLib/40TNDy3+HujMDZfFezyXXS+VmGWR4S4JZMjONOCA20g87AGWP+oSGwMD
L6B5IfeLhsYi+lzr+0h1B++gDxarpRN1uyQV6QteHiSuGoJQAkXIPVHJL5TRmCyu
En+3SyiWLEZjiCcrhxU=
=05MF
-END PGP SIGNATURE-

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: F12 updates-testing issue: X flickers and fails to start

Linuxguy123 wrote:
 I have logged 2 bugs that are possibly related to this.
 
 https://bugzilla.redhat.com/show_bug.cgi?id=528188
 
 https://bugzilla.redhat.com/show_bug.cgi?id=525767

Huh? One of these is a Nouveau bug, the other is a bug in the proprietary 
nvidia driver, both of them already happened with F12 as released, so these 
have absolutely nothing to do with this thread.

These bugs filed by Rex Dieter about issues caused by HAL 0.5.14 are 
probably more relevant:
https://bugzilla.redhat.com/show_bug.cgi?id=545258
https://bugzilla.redhat.com/show_bug.cgi?id=545639

Kevin Kofler

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: yum download estimates and stalls

2009-12-09 Thread Richard W.M. Jones

On Wed, Dec 09, 2009 at 12:20:12PM -0500, Seth Vidal wrote:
 On Wed, 9 Dec 2009, Richard W.M. Jones wrote:

 I don't want to make unfair comparisons to the famous bug in Windows
 Vista[1], but it seems as if when a yum download stalls, then the
 estimates can start to look a little large:

 rawhide/primar 20% [-   ]  0.0 B/s | 2.5 MB 2046434610655583470384211558:24 
 ETA


 What ver of python-urlgrabber do you have installed?

python-urlgrabber-3.9.1-4.fc12.noarch

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.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

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Fedora release criteria completely revised

2009-12-09 Thread Colin Walters

On Wed, Dec 9, 2009 at 5:27 PM, Adam Williamson awill...@redhat.com wrote:

 This is what it was intended to mean, actually running apps I would have
 defined as 'login and use'. How would you suggest wording a
 clarification?

Looking at it again, it's fairly clear that this just covers the
desktop view, given criteria 12.  So this looks fine, thanks!

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

kernel update highly recommended

2009-12-09 Thread Kyle McMartin

Hi folks,

I'd highly recommend if you're running 2.6.31 or 2.6.32, that you update
to the latest kernel in the koji builds here:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1864871
http://koji.fedoraproject.org/koji/taskinfo?taskID=1864876

They fix a rather severe security problem with ext4 caused by
insufficient permission checking by the ext4 ioctl code, allowing a
malicious local user to corrupt files. Note, the ioctl isn't currently
used by userspace, so if you build your own kernels, you can just nuke
the entire EXT4_IOC_MOVE_EXT ioctl case.

NOTE: This is only a problem if you're using EXT4, if you aren't, you're
safe.

I'll get these pushed out to stable asap, but I wanted to let folks know
just in case rawhide doesn't compose before the downtime.

regards, Kyle M.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: kernel update highly recommended

2009-12-09 Thread Nathanael D. Noblet


On 12/09/2009 11:14 AM, Kyle McMartin wrote:

Hi folks,

I'd highly recommend if you're running 2.6.31 or 2.6.32, that you update
to the latest kernel in the koji builds here:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1864871
http://koji.fedoraproject.org/koji/taskinfo?taskID=1864876

They fix a rather severe security problem with ext4 caused by
insufficient permission checking by the ext4 ioctl code, allowing a
malicious local user to corrupt files. Note, the ioctl isn't currently
used by userspace, so if you build your own kernels, you can just nuke
the entire EXT4_IOC_MOVE_EXT ioctl case.

NOTE: This is only a problem if you're using EXT4, if you aren't, you're
safe.

I'll get these pushed out to stable asap, but I wanted to let folks know
just in case rawhide doesn't compose before the downtime.


This a rawhide only issue or F12 as well?

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: kernel update highly recommended

On Wed, Dec 09, 2009 at 11:20:02 -0700,
  Nathanael D. Noblet nathan...@gnat.ca wrote:
 
 This a rawhide only issue or F12 as well?

It affects F12. You want the -166 kernel. However right now it is still
building. (I didn't check to see if some arches are done already.) The
updated kernel for rawhide has completed building.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: kernel update highly recommended

On Wed, Dec 09, 2009 at 12:23:50 -0600,
  Bruno Wolff III br...@wolff.to wrote:
 On Wed, Dec 09, 2009 at 11:20:02 -0700,
   Nathanael D. Noblet nathan...@gnat.ca wrote:
  
  This a rawhide only issue or F12 as well?
 
 It affects F12. You want the -166 kernel. However right now it is still
 building. (I didn't check to see if some arches are done already.) The
 updated kernel for rawhide has completed building.

The 686 step is not quite done yet, but eveything else is. You can grab
the rpms that are done by walking down into the tasks. The build will
probably be done in a few minutes though.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Promoting i386 version over x86_64?

2009-12-09 Thread Ville Skyttä

On Wednesday 09 December 2009, Ralf Corsepius wrote:
 On 12/08/2009 09:26 PM, Ville Skyttä wrote:

  These probably aren't things to be generally overly concerned
  about though,
 
 ... try a yum update over GSM or over a modem and you'll very soon
 experience what I am talking about.

Been there, done that occasionally.  Scenarios like that just don't happen to 
be part of what I meant by generally.

But I'd have nothing against purifying x86_64 repos and instructing people 
who need something from ix86 repos to enable them as well.  I suppose this is 
something PackageKit could even suggest on demand.  Anyway I also suppose that 
if it was this simple, it would have been done already.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Why pavucontrol is not installed by default?

2009-12-09 Thread Jon Masters

On Tue, 2009-12-08 at 21:45 +, Bastien Nocera wrote:
 On Tue, 2009-12-08 at 14:05 -0500, Jon Masters wrote:

  The new gnome-volume-control is so cut-down it's not useful to me. In
  the quest to be more Mac-like in removing mixer controls
 
 No, it's in a quest of providing *solutions* to user's problems, and not
 blindly showing everything the software and the hardware can do.

I couldn't disagree more strongly. As a Linux user, I want the show me
everything option. I don't care if I have to check a box to do it, but
I want to see all the knobs and dials. And I at least expect not to have
what I'm doing with alsamixer interfered with by the other tools.

Jon.


-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Why pavucontrol is not installed by default?

2009-12-09 Thread Jon Masters

On Wed, 2009-12-09 at 02:44 -0500, Orcan Ogetbil wrote:
 On Tue, Dec 8, 2009 at 2:05 PM, Jon Masters wrote:
 
  The new gnome-volume-control is so cut-down it's not useful to me. In
  the quest to be more Mac-like in removing mixer controls (and not even
  having any obvious advanced mode), I now have a choice of no audio or
  having full volume LFE output *and* whatever mixer level I have set for
  the master output. alsamixer works fine, but then I can't use the volume
  sliders on my desktop and it gets rather awkward.

 Sadly, they consider this bug as an enhancement. I have had friends
 who had the same hardware with me but they were using another OS. I
 remember them being jealous because I had so much more control over
 same sound card. It made me proud at the time. I fear that this
 disease of oversimplifying will make us forget why we are using Linux.

All paranoia and ranting aside, there is some truth to this. There is a
definite trend in the Linux community to want to cater to the lowest
common denominator by being more Mac/Windows-esque. I put up with it
because I can usually ignore it (I refuse on principal to use a GUI to
copy a file, for example, but that's just me being weird), but I don't
see the harm in hiding the advanced stuff under a checkbox - the
advanced mixer stuff is still there underneath after all.

Jon.


-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: F12 updates-testing issue: X flickers and fails to start

2009-12-09 Thread Linuxguy123

On Wed, 2009-12-09 at 18:36 +0100, Kevin Kofler wrote:
 Linuxguy123 wrote:
  I have logged 2 bugs that are possibly related to this.
  
  https://bugzilla.redhat.com/show_bug.cgi?id=528188
  
  https://bugzilla.redhat.com/show_bug.cgi?id=525767
 
 Huh? One of these is a Nouveau bug, the other is a bug in the proprietary 
 nvidia driver, both of them already happened with F12 as released, so these 
 have absolutely nothing to do with this thread.

That is what you say.  How exactly did you determine that ? OR are you
guessing ?

I say they have similar symptoms.  I said they *might* be related.  

I bet my bugs have nothing to do with the nouveau or nvidia drivers.
I've been saying that all along.  I guess we will find out.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Request for help maintaining packages while away.

2009-12-09 Thread Jeff Spaleta

Good Alaskan Morning!

In two weeks I'm going to be in Antarctica for a month+ and I'm
looking for other packagers to step in for me and maintain my packages
and prepare them for F13.  I'm not exactly sure what my time and
bandwidth access will be so I'm planning for the worst and that I'll
be reliably off the grid through mid Feb.   Please let me know if you
can take on a co-maintainer/primary maintainer role for any of the
packges and see them through the next couple of months.

Here's the set of packages that I own.  I will be contacting existing
co-maintainers for individual packages in the list separately this
week.

ScientificPython -- A collection of Python modules that are useful for
scientific computing
g3data -- Program for extracting the data from scanned graphs
gourmet -- Recipe Manager for the GNOME desktop environment
gpodder -- Podcast receiver/catcher written in Python
istanbul -- Desktop Session Recorder
nec2c -- Translation of NEC2 antenna modeling tool from FORTRAN to C
pyscript -- PyScript - Postscript graphics with Python
python-basemap -- Plots data on map projections (with continental and
political boundaries)
python-basemap-data -- Data for python-basemap
python-dateutil -- Powerful extensions to the standard datetime module
python-matplotlib -- Python plotting library
python-xlib -- X client library for Python
pytz -- World Timezone Definitions for Python
revelation -- Password manager for GNOME 2
safekeep -- The SafeKeep backup system
scipy -- Scipy: Scientific Tools for Python
telescope-server -- Opensource Telescope control servers to interface
with stellarium
usbsink -- USBSink is a GNOME


-jefDoes living in Alaska and travelling to Antarctica make me bipolar?spaleta

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Request for help maintaining packages while away.

2009-12-09 Thread Jon Ciesla


Jeff Spaleta wrote:

Good Alaskan Morning!

In two weeks I'm going to be in Antarctica for a month+ and I'm
looking for other packagers to step in for me and maintain my packages
and prepare them for F13.  I'm not exactly sure what my time and
bandwidth access will be so I'm planning for the worst and that I'll
be reliably off the grid through mid Feb.   Please let me know if you
can take on a co-maintainer/primary maintainer role for any of the
packges and see them through the next couple of months.

Here's the set of packages that I own.  I will be contacting existing
co-maintainers for individual packages in the list separately this
week.

ScientificPython -- A collection of Python modules that are useful for
scientific computing
g3data -- Program for extracting the data from scanned graphs
gourmet -- Recipe Manager for the GNOME desktop environment
gpodder -- Podcast receiver/catcher written in Python
istanbul -- Desktop Session Recorder
nec2c -- Translation of NEC2 antenna modeling tool from FORTRAN to C
pyscript -- PyScript - Postscript graphics with Python
python-basemap -- Plots data on map projections (with continental and
political boundaries)
python-basemap-data -- Data for python-basemap
python-dateutil -- Powerful extensions to the standard datetime module
python-matplotlib -- Python plotting library
python-xlib -- X client library for Python
pytz -- World Timezone Definitions for Python
revelation -- Password manager for GNOME 2
safekeep -- The SafeKeep backup system
scipy -- Scipy: Scientific Tools for Python
telescope-server -- Opensource Telescope control servers to interface
with stellarium
usbsink -- USBSink is a GNOME


-jefDoes living in Alaska and travelling to Antarctica make me bipolar?spaleta

  

Sweet!  Have a fun and safe trip.

I can probably help out with scipy, I'll apply as co-maintainer.

--
in your fear, seek only peace
in your fear, seek only love

-d. bowie

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Promoting i386 version over x86_64?




On Wed, 9 Dec 2009, Ville Skyttä wrote:


On Wednesday 09 December 2009, Ralf Corsepius wrote:

On 12/08/2009 09:26 PM, Ville Skyttä wrote:



These probably aren't things to be generally overly concerned
about though,


... try a yum update over GSM or over a modem and you'll very soon
experience what I am talking about.


Been there, done that occasionally.  Scenarios like that just don't happen to
be part of what I meant by generally.

But I'd have nothing against purifying x86_64 repos and instructing people
who need something from ix86 repos to enable them as well.  I suppose this is
something PackageKit could even suggest on demand.  Anyway I also suppose that
if it was this simple, it would have been done already.



if you want to purify x86_64 you can always add:

exclude=*.i[3456]86

to your yum.conf under [main]


-sv
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: abrt issue

2009-12-09 Thread José Matos

On Wednesday 09 December 2009 12:47:44 Neal Becker wrote:
 I just got a crash in kde plasma.  Traceback is not useful, because of 
 missing debug pacakges.

Downgrading hal and hal-libs fixes the crash. I noticed the other thread where 
this bug is reported. I was seeing both
https://bugzilla.redhat.com/show_bug.cgi?id=545639
https://bugzilla.redhat.com/show_bug.cgi?id=545258

You need to downgrade hal-libs as well or else yum will pick hal-libs.i686 and 
that will require to install glibc.i686 and friends.

-- 
José Abílio

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Fedora release criteria completely revised

2009-12-09 Thread Adam Williamson

On Wed, 2009-12-09 at 14:54 +0100, Dominik 'Rathann' Mierzejewski wrote:
 On Monday, 07 December 2009 at 23:55, Adam Williamson wrote:
 [...]
  https://fedoraproject.org/wiki/Fedora_13_Alpha_Release_Criteria
  https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria
 
 16. Automatic mounting on insertion of removable media must work
 
 It should be clarified with ... after GUI login, because it sure never
 worked before a user is logged in. Also it never worked when user was
 logged in via text console, did it?

Good point - changed. Thanks.

-- 
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@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Promoting i386 version over x86_64?

John Reiser wrote:
 Sometimes I doubt even that, particularly when shipped software
 has python syntax errors (type mismatch, wrong number of arguments,
 no such member, ...)

rantThe joys of interpreted languages… In a compiled language, such an 
error would just fail the build./rant

Kevin Kofler

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Promoting i386 version over x86_64?

Ville Skyttä wrote:
 Yeah, I've done that in some setups but I was talking about purifying the
 _repos_ above; that setting doesn't affect them, e.g. it doesn't make the
 metadata to be downloaded any smaller.  (As said, not that I think it's a
 big general issue at all, but just that I'd personally have nothing
 against if it would be fixed nevertheless.)

Kicking out multilibs from the repos might also make it much faster to 
compose updates repositories. A lot of time is wasted computing multilibs 
now.

Kevin Kofler

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Promoting i386 version over x86_64?

Dominik 'Rathann' Mierzejewski wrote:
 Actually, x86_64 is an AMD invention (originally called AMD64)
 and is called EM64T by Intel. The only Intel 64 I can think of
 is IA64, i.e. Itanium (called Itanic by some).

EM64T was renamed to Intel 64 eons ago.

Kevin Kofler

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: abrt issue

Neal Becker wrote:
 I don't know what debuginfo package is needed.  rpm -qa '*plasma*' doesn't
 give a good answer.

Probably kdebase-workspace (and its dependencies, like kdelibs, but 
debuginfo-install takes care of that automatically).

Kevin Kofler

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Request for help maintaining packages while away.

2009-12-09 Thread Paul W. Frields

On Wed, Dec 09, 2009 at 10:24:16AM -0900, Jeff Spaleta wrote:
 Good Alaskan Morning!
 
 In two weeks I'm going to be in Antarctica for a month+ and I'm
 looking for other packagers to step in for me and maintain my packages
 and prepare them for F13.  I'm not exactly sure what my time and
 bandwidth access will be so I'm planning for the worst and that I'll
 be reliably off the grid through mid Feb.   Please let me know if you
 can take on a co-maintainer/primary maintainer role for any of the
 packges and see them through the next couple of months.
 
 Here's the set of packages that I own.  I will be contacting existing
 co-maintainers for individual packages in the list separately this
 week.
 
 ScientificPython -- A collection of Python modules that are useful for
 scientific computing
 g3data -- Program for extracting the data from scanned graphs
 gourmet -- Recipe Manager for the GNOME desktop environment
 gpodder -- Podcast receiver/catcher written in Python
 istanbul -- Desktop Session Recorder
 nec2c -- Translation of NEC2 antenna modeling tool from FORTRAN to C
 pyscript -- PyScript - Postscript graphics with Python
 python-basemap -- Plots data on map projections (with continental and
 political boundaries)
 python-basemap-data -- Data for python-basemap
 python-dateutil -- Powerful extensions to the standard datetime module
 python-matplotlib -- Python plotting library
 python-xlib -- X client library for Python
 pytz -- World Timezone Definitions for Python
 revelation -- Password manager for GNOME 2
 safekeep -- The SafeKeep backup system
 scipy -- Scipy: Scientific Tools for Python
 telescope-server -- Opensource Telescope control servers to interface
 with stellarium
 usbsink -- USBSink is a GNOME

Jef, I'll help with istanbul.  If anyone else out there is considering
doing so, please feel free to team up with me.

-- 
Paul W. Frieldshttp://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-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Request for help maintaining packages while away.

2009-12-09 Thread Jeff Spaleta

On Wed, Dec 9, 2009 at 12:26 PM, Paul W. Frields sticks...@gmail.com wrote:
 Jef, I'll help with istanbul.  If anyone else out there is considering
 doing so, please feel free to team up with me.

Other than revelation(which essentially has a dead
upstream)...Istanbul is probably the most in need of more development
love.  Upstream seems to be inactive with no release activity in quite
a while.  There's a lot of deprecation warnings for some pygtk calls
that I would love to clean up in time for F13. And there are a couple
of abrt crash tickets being spawned by istanbul.. which maybe traced
back to gdk libraries calls if I'm reading the crash dumps correctly.

-jef

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Planning the accessibility stack rebase

2009-12-09 Thread Matthias Clasen

As some of you may know, the accessibility framework is getting ported
from CORBA/ORBit to DBus [1]. The (ambitious) upstream plan is to have
this transition completed in time for GNOME 2.30, ie within the F-13
timeframe.

This is a big effort, and the accessibility guys need all the help they
can get. To help with testing and feedback, I plan to get the new
accessibility stack into rawhide in early January. I have done initial
packages for the at-spi2 components [2], but they are not quite ready
for prime time yet (they don't have the coexistence part entirely sorted
out).

Some details about the changes that coming:

The CORBA-based at-spi package is being replaced by three components:

at-spi2-core - protocol definitions and registry daemon

at-spi2-atk - the atk-bridge GTK+ module

pyatspi - Python bindings for at-spi

There is no replacement for the cspi 'C bindings' at the moment. The
current users of cspi are being ported to use D-Bus directly
(mousetweaks) or replaced (gok being replaced by Caribou [3]). I am not
sure about the porting status of dasher...

To make the transition phase less painful, there are some efforts to
allow the old and new stacks to coexist. The CORBA-based at-spi stuff
will install its atk-bridge module and Python bindings somewhere else,
and there will be a desktop file that sets the GTK_PATH environment
variable and a pyatspi.pth Python module that sets some Python path.
These path-tweaks will be triggered by a GConf key, allowing both stacks
to be installed at the same time and allowing users and testers to
switch back and forth between the stacks.

It would be great if people who are interested in accessibility on
Fedora could chime in and help with planning this to make the transition
as smooth as it can. I'm sure there will be some bumps along the way
anyway...

Matthias

PS Having written all this down, I realize that I should probably turn
this into a feature page...

[1]
http://www.linuxfoundation.org/collaborate/workgroups/accessibility/atk/at-spi/at-spi_on_d-bus
[2] http://bugzilla.redhat.com/show_bug.cgi?id=544628
http://bugzilla.redhat.com/show_bug.cgi?id=544629
http://bugzilla.redhat.com/show_bug.cgi?id=544630
[3] http://live.gnome.org/Caribou

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Promoting i386 version over x86_64?




On Wed, 9 Dec 2009, Chris Adams wrote:


Once upon a time, Ville Skyttä ville.sky...@iki.fi said:

Yeah, I've done that in some setups but I was talking about purifying the
_repos_ above; that setting doesn't affect them, e.g. it doesn't make the
metadata to be downloaded any smaller.  (As said, not that I think it's a big
general issue at all, but just that I'd personally have nothing against if it
would be fixed nevertheless.)


One way to make this smaller (without any overlap) would be to split the
current two (i386 and x86_64) repos into three: i386-common, i386,
x86_64.  For an i386 system, you use i386 and i386-common, for a
multilib x86_64 system you use x86_64 and i386-common, and for a pure
x86_64 system you use just x86_64.

I don't know if it is worth the trouble though.


and then you have to do that as well for updates. :(

-sv
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Non responsive maintainer: Karol Trzcionka

2009-12-09 Thread Rahul Sundaram

Hi,

As per policy at
http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers,
I have filed

https://bugzilla.redhat.com/show_bug.cgi?id=546072

Rahul

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Non responsive maintainer: Karol Trzcionka

2009-12-09 Thread Debayan Banerjee

2009/12/10 Rahul Sundaram sunda...@fedoraproject.org:
 Hi,

 As per policy at
 http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers,
 I have filed

 https://bugzilla.redhat.com/show_bug.cgi?id=546072

This person used to maintain the Tesseract OCR software. He has not
packaged the latest version which is 2.04
http://code.google.com/p/tesseract-ocr/downloads/list. I work on
this project actively, and would love to maintain the package.
However, I am a complete n00b to RPM packaging, and would require some
hand holding (I shall do the googling).


 Rahul

 --
 fedora-devel-list mailing list
 fedora-devel-list@redhat.com
 https://www.redhat.com/mailman/listinfo/fedora-devel-list




-- 
Regards,
Debayan Banerjee

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Non responsive maintainer: Karol Trzcionka

2009-12-09 Thread Debayan Banerjee

2009/12/10 Debayan Banerjee debaya...@gmail.com:
 2009/12/10 Rahul Sundaram sunda...@fedoraproject.org:
 Hi,

 As per policy at
 http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers,
 I have filed

 https://bugzilla.redhat.com/show_bug.cgi?id=546072

 This person used to maintain the Tesseract OCR software. He has not
 packaged the latest version which is 2.04
 http://code.google.com/p/tesseract-ocr/downloads/list. I work on
 this project actively, and would love to maintain the package.
 However, I am a complete n00b to RPM packaging,

ermm, I do know how to write spec files, and build RPMs, but am a bit
unsure about the process of uploading the packages upstream to Fedora
repos. Again, I shall Google and learn.


-- 
Regards,
Debayan Banerjee

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Non responsive maintainer: Karol Trzcionka

2009-12-09 Thread Christoph Wickert

Am Donnerstag, den 10.12.2009, 04:02 +0530 schrieb Debayan Banerjee:

 ermm, I do know how to write spec files, and build RPMs, but am a bit
 unsure about the process of uploading the packages upstream to Fedora
 repos. Again, I shall Google and learn.

https://fedoraproject.org/wiki/Join_the_package_collection_maintainers

Regards,
Christoph

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Non responsive maintainer: Karol Trzcionka

2009-12-09 Thread Rahul Sundaram

On 12/10/2009 04:02 AM, Debayan Banerjee wrote:
 2009/12/10 Debayan Banerjee
 2009/12/10 Rahul Sundaram 
 Hi,

 As per policy at
 http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers,
 I have filed

 https://bugzilla.redhat.com/show_bug.cgi?id=546072

 This person used to maintain the Tesseract OCR software. He has not
 packaged the latest version which is 2.04
 http://code.google.com/p/tesseract-ocr/downloads/list. I work on
 this project actively, and would love to maintain the package.
 However, I am a complete n00b to RPM packaging,
 
 ermm, I do know how to write spec files, and build RPMs, but am a bit
 unsure about the process of uploading the packages upstream to Fedora
 repos. Again, I shall Google and learn.

I see updates on other software up until Aug so not sure it is required
yet but come up to #fedora-india and I will let you know the details.

Rahul


-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

upstart-0.6.3 in rawhide, tomorrow 2009-12-10

2009-12-09 Thread Bill Nottingham

https://fedoraproject.org/wiki/Features/Upstart0.6.0

was approved at last week's FESCo meeting. It was built today, and will
land in rawhide tomorrow.

What this means for you:

It's going to be a bit of a bumpy first yum upgrade. You will likely have
to reboot with 'reboot -f', as the job formats have changed
slightly, and the communication with init(8) has changed.

Once you reboot, things should work pretty much the same.

All users have been converted with the exception of readahead[1],
unless we missed some.

Obvious FAQ:

Q: Should we port our SysV scripts to native upstart scripts?

A: No, not at this time.

Bill

[1] because I missed in in the first scan and haven't had a chance to
talk to the maintainer.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Request for help maintaining packages while away.

2009-12-09 Thread José Matos

On Wednesday 09 December 2009 19:38:55 Jeff Spaleta wrote:
 For F13 you probably want to push latest versions  of the both scipy
 and matplotlib together. So if you take scipy* sign up for matplotlib*
 as well.

Not only those but also:
python-basemap -- Plots data on map projections (with continental and
political boundaries)
python-basemap-data -- Data for python-basemap
python-dateutil -- Powerful extensions to the standard datetime module
pytz -- World Timezone Definitions for Python

and also not directly related but
ScientificPython -- A collection of Python modules that are useful for
scientific computing

is more or less on the bundle.

Those are packages that interest me, and I would like to see them in good 
shape. :-)

FWIW, the sage bundle would be a nice bonus. :-)

 -jef

-- 
José Abílio

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Docs Installation Guide - Submission and Download problem

2009-12-09 Thread Paul W. Frields

On Fri, Dec 04, 2009 at 10:51:59AM +0200, Dimitris Glezos wrote:
 2009/12/3 Ruediger Landmann r.landm...@redhat.com:
  On 12/02/2009 05:47 PM, Dimitris Glezos wrote:
 
  Rudi, you could clear the cache and refresh it.
 
 
  Really? How do I do that? I'd thought that a button like that would be 
  useful for the
  maintainer of a project
 
 This button is available on the web interface on component pages for
 maintainers.
 
  , not least of which because changes to a POT in the repo don't 
  automatically
  trigger a refresh (of course!) while submissions of updated POs do.
 
 This functionality has been available in Transifex for a while, it's
 just that Fedora is still running an old (and unmaintained) version.

Diego posted the summary of what needs to be done here:

https://fedorahosted.org/fedora-infrastructure/ticket/1455#comment:10

In short, we need a few people to step up and help with the process
Diego posted.

We already do have a L10n Admin group[1] that should be overseeing and
managing this process, to ensure a successful rollout for translators.
Their charter is to maintain the infrastructure for translators, and
this clearly falls into that area.  I've heard from two of the people
in that group that they can't do all this work themselves, but haven't
heard from Ankit or Asgeir about it.

What I would suggest is that Diego should help with bullet #4 on that
list, as it probably requires the greatest degree of specific
technical knowledge, in this case a database upgrade.  The rest of the
work on that ticket could likely be done entirely by the remainder of
the team, maybe with limited input from Diego.  It would be helpful
for Asgeir or Ankit to help manage this set of tasks in collaboration
with Diego, who has appropriate package access.  (I'm cc'ing Ignacio
directly as well, so he can add appropriate CVS access for any other
people who are willing to help maintain the EL-5 package used on our
Infrastructure.)

Without help, it's doubtful there will be a new Transifex rolled out,
and that means some of the problems people are experiencing will
continue, even though they're already fixed upstream.  I'm cc'ing the
docs, devel, and infrastructure lists to see if any of the people in
areas well served by translators are willing to help see this project
through.  It's time to pull together, guys, and see if we can help the
translators who give so much across the whole Fedora Project.

* * *
[1] https://fedoraproject.org/wiki/L10N/Tools#Website

-- 
Paul W. Frieldshttp://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-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: kernel update highly recommended

2009-12-09 Thread Christopher Brown

2009/12/9 Kyle McMartin k...@mcmartin.ca:

 NOTE: This is only a problem if you're using EXT4, if you aren't, you're
 safe.

ReiserFS FTW!!! :)


-- 
Christopher Brown

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Request for help maintaining packages while away.

2009-12-09 Thread Paul W. Frields

On Wed, Dec 09, 2009 at 12:38:11PM -0900, Jeff Spaleta wrote:
 On Wed, Dec 9, 2009 at 12:26 PM, Paul W. Frields sticks...@gmail.com wrote:
  Jef, I'll help with istanbul.  If anyone else out there is considering
  doing so, please feel free to team up with me.
 
 Other than revelation(which essentially has a dead
 upstream)...Istanbul is probably the most in need of more development
 love.  Upstream seems to be inactive with no release activity in quite
 a while.  There's a lot of deprecation warnings for some pygtk calls
 that I would love to clean up in time for F13. And there are a couple
 of abrt crash tickets being spawned by istanbul.. which maybe traced
 back to gdk libraries calls if I'm reading the crash dumps correctly.

Dave Malcolm was looking at an underlying GTK (or maybe GDK?) bug this
weekend at FUDCon if memory serves.  I'll also do what I can for
existing bugs in my Copious Spare Time(tm).

You might be interested in knowing that we had some discussion at
FUDCon about extending my PulseCaster project (currently only
functional in the most gracious sense) to cover more 'casting needs
while maintaining a simple, usable interface:

* Newscast -- single person audio, e.g. reading the news
* Screencast -- single person audio + desktop screencap
* Interview -- multi-person audio
* App discussion or instruction -- multi-person audio + one desktop
  screencap
* Save to file or send to streaming server

I'm planning on spending some time on the project as part of my
Christmas vacation.  We had a lot of great ideas for how this
functionality will work, but I do want some UI review for it including
comparing it to GNOME HIG.

-- 
Paul W. Frieldshttp://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-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Docs Installation Guide - Submission and Download problem

2009-12-09 Thread Noriko Mizumoto


Paul W. Frields さんは書きました:

On Fri, Dec 04, 2009 at 10:51:59AM +0200, Dimitris Glezos wrote:

2009/12/3 Ruediger Landmann r.landm...@redhat.com:

On 12/02/2009 05:47 PM, Dimitris Glezos wrote:

Rudi, you could clear the cache and refresh it.


Really? How do I do that? I'd thought that a button like that would be useful 
for the
maintainer of a project

This button is available on the web interface on component pages for
maintainers.


, not least of which because changes to a POT in the repo don't automatically
trigger a refresh (of course!) while submissions of updated POs do.

This functionality has been available in Transifex for a while, it's
just that Fedora is still running an old (and unmaintained) version.


Diego posted the summary of what needs to be done here:

https://fedorahosted.org/fedora-infrastructure/ticket/1455#comment:10

In short, we need a few people to step up and help with the process
Diego posted.

We already do have a L10n Admin group[1] that should be overseeing and
managing this process, to ensure a successful rollout for translators.
Their charter is to maintain the infrastructure for translators, and
this clearly falls into that area.  I've heard from two of the people
in that group that they can't do all this work themselves, but haven't
heard from Ankit or Asgeir about it.

What I would suggest is that Diego should help with bullet #4 on that
list, as it probably requires the greatest degree of specific
technical knowledge, in this case a database upgrade.  The rest of the
work on that ticket could likely be done entirely by the remainder of
the team, maybe with limited input from Diego.  It would be helpful
for Asgeir or Ankit to help manage this set of tasks in collaboration
with Diego, who has appropriate package access.  (I'm cc'ing Ignacio
directly as well, so he can add appropriate CVS access for any other
people who are willing to help maintain the EL-5 package used on our
Infrastructure.)

Without help, it's doubtful there will be a new Transifex rolled out,
and that means some of the problems people are experiencing will
continue, even though they're already fixed upstream.  I'm cc'ing the
docs, devel, and infrastructure lists to see if any of the people in
areas well served by translators are willing to help see this project
through.  It's time to pull together, guys, and see if we can help the
translators who give so much across the whole Fedora Project.


Thanks Paul,
We are very much appreciated if any of you guys can give a hand to L10n 
team this time, as by coincidence both of Ankit and Asgeir are having 
leave (most likely traveling) and they might not be able have connection 
at all.


I like to add brother i18n team as well.

noriko


* * *
[1] https://fedoraproject.org/wiki/L10N/Tools#Website



--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: rawhide and tagging requests

2009-12-09 Thread Jesse Keating

On Wed, 2009-12-09 at 06:43 -0800, Jesse Keating wrote:
 All the broken deps preventing a compose attempt have been cleared
 out.
 However the new rpm build was busted in a way that it made the compose
 fall over, a new build of rpm is coming and I hope to kick off another
 rawhide attempt when it lands. 

Ugh, things are still broken on the rpm front.  My attempt from earlier
fell over, may not get a fix in place for tonight's attempt either :/

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


signature.asc
Description: This is a digitally signed message part
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: rawhide and tagging requests

On Wed, Dec 09, 2009 at 18:15:53 -0800,
  Jesse Keating jkeat...@redhat.com wrote:
 On Wed, 2009-12-09 at 06:43 -0800, Jesse Keating wrote:
  All the broken deps preventing a compose attempt have been cleared
  out.
  However the new rpm build was busted in a way that it made the compose
  fall over, a new build of rpm is coming and I hope to kick off another
  rawhide attempt when it lands. 
 
 Ugh, things are still broken on the rpm front.  My attempt from earlier
 fell over, may not get a fix in place for tonight's attempt either :/

Thanks for the update.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Promoting i386 version over x86_64?




On Wed, 9 Dec 2009, Gregory Maxwell wrote:


On Wed, Dec 9, 2009 at 4:51 PM, Seth Vidal skvi...@fedoraproject.org wrote:

and then you have to do that as well for updates. :(


Not if you don't have a separate updates repo, no?



still need an updates-testing.

-sv

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: X on UEFI systems.

2009-12-09 Thread Dave Airlie

On Thu, 2009-12-10 at 07:32 +0300, Vasily Levchenko wrote:
 Hi, folks.
 
 
 Currently at Virtualbox has introduced UEFI support in 3.1 release.
 But there is one issue with X server. When trying configure X with
 -configure. Resulted xorg.conf.new looks right except missed Modes.
 Observing code I've supposed that missed information should be somehow
 fetched from screen info (prepared by EFIFB)
 via ioctl(..,FBIOGET_FSCREENINFO,...), but for some reasons it isn't
 called and doing strace of X -configure the /dev/fb0 is open and than
 immediately closed ([pastebin.org]). So the question is what should be
 added in VirtualBox/UEFI firmware to get full xorg.conf? 
  

Does it not work without an xorg.conf, that would be the first goal.

Dave.



-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Bug 544065] Re-base against current upstream production release

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=544065





--- Comment #5 from Fedora Update System upda...@fedoraproject.org  
2009-12-09 23:16:36 EDT ---
perl-Image-ExifTool-8.00-1.fc11 has been pushed to the Fedora 11 stable
repository.  If problems still persist, please make note of it in this bug
report.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list

[Bug 544065] Re-base against current upstream production release

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=544065


Fedora Update System upda...@fedoraproject.org changed:

   What|Removed |Added

   Fixed In Version|8.00-1.fc12 |8.00-1.fc11




-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list

[Bug 544065] Re-base against current upstream production release

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=544065





--- Comment #4 from Fedora Update System upda...@fedoraproject.org  
2009-12-09 23:16:21 EDT ---
perl-Image-ExifTool-8.00-1.fc12 has been pushed to the Fedora 12 stable
repository.  If problems still persist, please make note of it in this bug
report.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list

[Bug 544065] Re-base against current upstream production release