date:20131105

On Tue, 2013-11-05 at 11:19 -0500, Matthias Clasen wrote:
> On Tue, 2013-11-05 at 08:23 +0100, drago01 wrote:
> > On Tue, Nov 5, 2013 at 3:03 AM, Adam Williamson  wrote:
> > > On Sun, 2013-10-27 at 01:46 +0200, Kevin Kofler wrote:
> > >> Adam Williamson wrote:
> > >> > I don't think we'd really be correct in blocking the release for such
> > >> > issues - especially not Beta. We used to have 'polish' criteria for
> > >> > Final which at least required the icons used in the system menus - i.e.
> > >> > what's specified in the app's .desktop file - to be sane for all
> > >> > installed applications, but we dropped that (and other polish criteria)
> > >> > with the F19/F20 criteria re-write on the basis that they were really
> > >> > stretching a bit too far and would be unlikely to hold up to a 'last
> > >> > blocker before release' acid test. Stuff like this doesn't break
> > >> > anyone's use of the system catastrophically and can reasonably be fixed
> > >> > with updates.
> > >>
> > >> But it also affects the live images (making them look very unpolished) 
> > >> and
> > >> we don't respin those.
> > >
> > > That's why I said 'reasonably' not 'perfectly' :) I can see an argument
> > > for blocking Final, though in practice, I don't think our current
> > > standards are such that it really makes sense to claim our final
> > > releases are so smooth as to be worth enforcing a high standard of
> > > polish via the blocker mechanisms
> > 
> > Then we should that. There is a difference between "perfect" and something 
> > that
> > looks obviously broken.
> 
> Are we really fighting about the classification of fixed bugs here, or
> is there a new issue that I am not aware of ?

It's become a question of whether there should be a Beta or Final
requirement for icons to be present / "look good", I think.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: AppData: what if screenshots are the wrong aspect ratio?

2013-11-05 Thread Mathieu Bridon

Hi,

drago01 already answered your screenshot question, but...

On Tue, 2013-11-05 at 14:25 -0700, Jerry James wrote:
> I just took a look at making AppData xml files for the packages I
> maintain.  I started with the alphabetically first one (why not?):
> abe.  Here is my first attempt:
> 
> 
> 
>  abe.desktop

I'm pretty sure it should just be "abe" here, not "abe.desktop".

>  CC0
>  Abe's Amazing Adventure
>  
>   
>Abe's Amazing Adventure is a scrolling, platform-jumping, key-collecting,
>ancient pyramid exploring game, vaguely in the style of similar games for
>the Commodore+4.  The game is intended to show young people (I'm writing
>it for my son's birthday) all the cool games they missed.
>   

Maybe split that into two paragraphs, so it looks nicer and more
readable in the GUI?


-- 
Mathieu

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora 20-Beta RC4 AMIS

2013-11-05 Thread Dennis Gilmore

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

hi all,

Beta RC2 images have been uploaded to EC2 and are available at 

ami-c3e3bbaa : us-east-1 image for i386
ami-d3e2baba : us-east-1 image for x86_64

additionally if your looking to the AMI's they have been added to files
in the release tree
http://dl.fedoraproject.org/pub/alt/stage/20-Beta-RC4/Images/i386/Fedora-Images-i386-20-Beta-AMI
http://dl.fedoraproject.org/pub/alt/stage/20-Beta-RC4/Images/x86_64/Fedora-Images-x86_64-20-Beta-AMI

when we get to final Beta and the images are uploaded to all regions
they will all be listed and the file will be gpg signed in the final
tree

Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJSeaP8AAoJEH7ltONmPFDRk9IP/jnNhm8M088uIJw/4LQYfy7n
UtBF6NnEb1yUg2TSMuprVc4z1ZczG2t/UPZiQW5j6QnXLg+72XjYmr/9W/BhH1AR
rrzIOzQskrD1HK0yvkTt8P2KEgulCsUknx5PDgwY1pe3A55kHLiB/ePpUY0Sow8V
6bzHAaOdyX8RhumqkwB1GkVMavH89jgzmSntu0+qa/Yp8Y4H6gPr+6BpNtLUz9tu
fH15kqBayGzvNhoXzDtgiKF+eH/KITcdngNxjVIDSWYacYdhgbN3cYXI6z9D9Ylj
b5g11XfNwlB50hzQIldFyOdHVJtIqEA97uixPlHVBGfP1+vF5cbb40DK2qWNv87m
MmqGpXb3nvC9RKwQWbEHgAaIDAOFqFs+AD5AyDlBJRl9J0w4WvXEZpJwCWaaRJLf
1gEyr5m/K0GAyFPgtxsAvGjNzJUrA958++5QHy4Ogpq2dXd0ZcTedIz3Vu5FLvTG
tHsmSJet3wmfMsVXw5lqGdSKqsYMfxIe/eLSzhqkSn9ckbrLMBpUqSxqiFXel3Lt
qNvnyec8lDZcn1PsN6OhAvktpB5bvfy0xcOObikmGAEaQByNZ3sCxxOp8zJ7azrR
9E1MfpGgle1S1arOLoVCvG5S+Gp3HFxdI37BqFG6Qxwu2Cab9dYAN8T7whNzr68z
8yCKj2s2W3dctfNK4FYv
=5Nfl
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

On Tue, 2013-11-05 at 16:52 -0500, Matthew Miller wrote:
> On Tue, Nov 05, 2013 at 01:23:01PM -0800, Adam Williamson wrote:
> > So let me step into my handy Tardis and bring back a vignette from the
> > Real World after Fedora and other distributions bless upstream app
> > distribution as a preferred channel:
> 
> I'm not sure I can match this for evocativeness, but:
> 
> > Manager: ...so, executive summary: you're saying you'd _like_ to spend a
> > not insubstantial chunk of your fairly expensive time working to jump
> > through some hoops so our Shiny New Application can be included in these
> > 'downstream distribution' things, but if I insist, you can whack a
> > button to put it in the Linux App Store and we can go to press with our
> > announcement tomorrow?
> > 
> > Well-Intentioned Techie A: (gulps)...yes.
> > 
> > Manager: Whack that button, techie. Whack it hard. Now get out of my
> > office, I have to call the PR department.
> 
> In a different future where there is no such magic button, what brings
> enlightenment to the manager? I think maybe the conversation goes much like
> yours, except with "and don't bother me about 'getting into downstream
> distributions' again".

There's two differences:

1) It's substantially easier for users to get your app from their distro
repos than from your own distribution system
2) It's probably rather more work for you to maintain your own
distribution system

To summarize it cynically - the comparative shittiness of current
third-party distribution methods (various podunk frameworks which don't
really work, non-repo packages, or the old
statically-compiled-binary-in-a-tarball being your only options) works
in favour of distro packaging.

Yes, in an ideal world (as I was saying) we could get everyone on board
with 'distro packaging is better than even a good third party
distribution framework once you get over the initial startup costs!'
even if we improve third party distribution, but in the _real_ world, it
may be the  case that once we make third party distribution X% more
convenient for both sides and X% more officially blessed by
distributions, suddenly no-one cares about distro packaging any more.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Test-Announce] Fedora 20 Beta Release Candidate 4 (RC4) Available Now!

2013-11-05 Thread Andre Robatino

NOTE: The 32- and 64-bit Security Spins are over their respective size
targets.

As per the Fedora 20 schedule [1], Fedora 20 Beta Release Candidate 4
(RC4) is now available for testing. Content information, including
changes, can be found at
https://fedorahosted.org/rel-eng/ticket/5787#comment:26 . Please see the
following pages for download links (including delta ISOs) and testing
instructions. Normally dl.fedoraproject.org should provide the fastest
download, but download-ib01.fedoraproject.org is available as a mirror
(with an approximately 1 hour lag) in case of trouble. To use it, just
replace "dl" with "download-ib01" in the download URL.

Installation:

https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test

Base:

https://fedoraproject.org/wiki/Test_Results:Current_Base_Test

Desktop:

https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test

Ideally, all Alpha and Beta priority test cases for Installation [2],
Base [3], and Desktop [4] should pass in order to meet the Beta Release
Criteria [5]. Help is available on #fedora-qa on irc.freenode.net [6],
or on the test list [7].

Create Fedora 20 Beta test compose (TC) and release candidate (RC)
https://fedorahosted.org/rel-eng/ticket/5787

Current Blocker and Freeze Exception bugs:
http://qa.fedoraproject.org/blockerbugs/current

[1] http://fedorapeople.org/groups/schedule/f-20/f-20-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Installation_validation_testing
[3] https://fedoraproject.org/wiki/QA:Base_validation_testing
[4] https://fedoraproject.org/wiki/QA:Desktop_validation_testing
[5] https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria
[6] irc://irc.freenode.net/fedora-qa
[7] https://admin.fedoraproject.org/mailman/listinfo/test



signature.asc
Description: OpenPGP digital signature
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

Olav Vitters wrote:
> Various concerns have been raised. Just write them down, make a plan to
> address them, done.

But many of those concerns are inherent to the concept of "sandboxed 
applications" or the methods of delivery they'd enable and cannot possibly 
be addressed, ever. The whole concept is fatally flawed.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

Miloslav Trmač wrote:
> Look at all the software that has been written for GTK1 and obsolete
> libraries that hasn't been ported and therefore no longer runs on
> Fedora.  Wouldn't it have been nice to continue to have a practical
> option to use that software, even if it doesn't integrate that well
> and it no longer has an active maintainer?

You're talking to the person who is doing most of the maintenance effort on 
qt3 and kdelibs3 and who is always vetoing any proposals to retire them.

I do care about keeping the stuff we ship working, a lot even. But keeping 
compatibility libraries for old sonames where a simple rebuild is enough to 
fix all the software we ship is just useless. Compatibility libraries only 
make sense where porting is not trivial.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

Simo Sorce wrote:
> * and *ideally* I mean SELinux sanbdboxed with specific APIs that must
> be used to interact with the rest of the system, so that the application
> doesn't have free reign over users files.

So you want to remove my freedom to disable SELinux? Way to go…


Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

Bastien Nocera wrote:
> Might not want to put answers in people's mouths. Did you read up on the
> various bundling techniques that were explored and the API/ABI guarantees
> we want to offer? I'll stop short of paraphrasing you.

The fact that bundling is even being "explored" as a "technique" at all 
makes me puke!

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

drago01 wrote:
> Depends on what you mean by "power user" (I hate this meaningless
> term) if it means "software developer" then
> yes. If it means "someone that spends his whole day in config dialogs"
> then no.

A power user is somebody experienced with computers who uses them regularly 
and who wants to customize his/her system to his/her liking, not be forced 
into a straightjacket UI designed for people who have never touched a 
computer before that cannot be configured in any way. Software developers 
definitely fit into that category.

Nobody will spend their whole day in configuration dialogs. Even if they are 
many options, those dialogs are something you set your preferences in once 
and then (hopefully) never have to touch again. (Of course, if you change 
your defaults every day due to some "usability" study on complete newbies 
which totally ignores the habit factor, then yes, they would have to reenter 
the dialogs. But not offering the option does not help, it will just make 
the user curse at you for making him suffer an unwanted change to his/her 
habitual workflow or move to a software that gives him/her the option.) And 
offering the option does not preclude having sane defaults, which means only 
those people who WANT to change something even SEE the dialog at all. So the 
option does not hurt the people who are not looking for it, that claim is 
just not true.

In short: Make the defaults as sane as possible, but still allow the user to 
change them if they disagree with you on what is "sane". The more options, 
the better.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

On Tue, Nov 5, 2013 at 5:02 PM, Matthias Clasen  wrote:
> On Tue, 2013-11-05 at 16:32 -0500, Josh Boyer wrote:
>
>> > Right, that's exactly what I was saying. I just think this is all the
>> > _original poster_ was talking about, not any kind of automatic
>> > configuration of such repositories. (Or at least, you can read it that
>> > way).
>>
>> OK.  I guess that's fine, but it seems like a non-goal to me.  I mean,
>> it already works that way.  All adding it to the PRD would do would
>> make an easy thing to check off the list as "met".
>
> I would actually like to go a little further, and make it easy to enable
> 'clean' third-party repositories. If we imagine a future where e.g.
> valve is hosting a repository with their steam client, or say, the
> chromium web browser is available from the a fedora people page, I would
> really like it if searching for 'steam' or 'chromium' in gnome-software
> would bring up a text that said something like: The software you are
> looking for is available from a third-party repository. Do you want to
> enable it ?

That was how I understood the original proposal.  And that's the
conversation that needs to happen at a higher level outside of the WG
before it can really be a reality.

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

I wrote:
> So now after the "good balance", you bring up the "Change" with a capital
> 'C' (plagiarized from Barack Obama). Can you please cut down on the
> buzzword-loaden rhetoric bullshit?

PS: Since it has been pointed out to me that it can be misunderstood as 
such, please don't take this as a rant against Obama. It's a rant against 
plagiarizing the "Change" rhetoric to promote just about anything as long as 
it's different. Riding the buzzword wave to promote just about anything with 
a regurgitation of somebody else's fashionable discourse is easy, but not 
the way to win any argument.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

Matthew Miller wrote:
> I really would like all my desktop applications to run in a sandbox,
> whether they come from upstream directly or from us.

Why? This artificially restricts what your applications can do and also 
hurts performance. It doesn't buy us anything other than problems! And what 
about libraries? Will they get bundled into each sandbox as the "app" 
principle seems to suggest?

Kevin Kofler
(who has SELinux disabled)

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

Matthias Clasen wrote:
> I would actually like to go a little further, and make it easy to enable
> 'clean' third-party repositories. If we imagine a future where e.g.
> valve is hosting a repository with their steam client, or say, the
> chromium web browser is available from the a fedora people page, I would
> really like it if searching for 'steam' or 'chromium' in gnome-software
> would bring up a text that said something like: The software you are
> looking for is available from a third-party repository. Do you want to
> enable it ?

I think users will not understand why all the vendor repositories with non-
free crap are there and the stuff they are actually looking for is not.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: AppData: what if screenshots are the wrong aspect ratio?

2013-11-05 Thread Jerry James

On Tue, Nov 5, 2013 at 4:20 PM, drago01  wrote:
> http://blogs.gnome.org/hughsie/2013/10/08/how-to-take-169-screenshots/

I was confused until I got to the comments. :-)  Thanks for the
pointer.  That cleared things up for me.  Regards,
-- 
Jerry James
http://www.jamezone.org/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: AppData: what if screenshots are the wrong aspect ratio?

On Tue, Nov 5, 2013 at 10:25 PM, Jerry James  wrote:
> I just took a look at making AppData xml files for the packages I
> maintain.  I started with the alphabetically first one (why not?):
> abe.  Here is my first attempt:
>
> 
> 
>  abe.desktop
>  CC0
>  Abe's Amazing Adventure
>  
>   
>Abe's Amazing Adventure is a scrolling, platform-jumping, key-collecting,
>ancient pyramid exploring game, vaguely in the style of similar games for
>the Commodore+4.  The game is intended to show young people (I'm writing
>it for my son's birthday) all the cool games they missed.
>   
>  
>  
>type="default">http://abe.sourceforge.net/screen0-4-1.png
>   http://abe.sourceforge.net/screen2-4-2.png
>  
>  http://abe.sourceforge.net/
>  
> 
>
> But those screenshots are not the right aspect ratio.  What is the
> right thing to do here?  Just use this anyway and let the GUIs decide
> how to resize the screenshots?  Download the screenshots and figure
> out how to massage them into the right aspect ratio on my machine?  If
> so, where do I store the massaged screenshots?
>
> Also, the documentation at
> http://people.freedesktop.org/~hughsient/appdata/ doesn't say what a
> screenshot type is supposed to be.  I gathered that one should have
> type "default" and the rest should have no type by looking at some
> examples.  If that's not correct, could the documentation be updated
> to explain this, please?

http://blogs.gnome.org/hughsie/2013/10/08/how-to-take-169-screenshots/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

2013-11-05 Thread Colin Walters

On Tue, 2013-11-05 at 13:23 -0800, Adam Williamson wrote:
>  If
> distros move away from the gospel of centralized distribution 

Some people working on technologies in this area may have that as a
goal, but I think it's absolutely crucial to continue to support the
"package" model of application distribution as well.

Consider applications like Boxes or virt-manager - these are tightly
tied into the virtualization libraries which are in turn tightly tied
into the operating system plumbing - and that's fine and makes sense!

The two other cases are:
- Less tightly coupled Free Software 
- Proprietary software

This is a fantastically complex discussion for a number of reasons just
with respect to terminology - for example, Debian has a non-free
repository that is "centralized", or at least more centralized than
Fedora.

I know you had a long mail, but your example didn't state whether 
"Shiny New Application" was Free Software or proprietary, or whether it
was tightly coupled or not, etc.  These aspects matter, and there's a
lot of grey area in the continuum.

But I guess a bottom line is as a member of the upstream GNOME
community, I would argue very much against any application mechanism
which did not allow applications to *also* be shipped in the traditional
package model.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

2013-11-05 Thread Matthias Clasen

On Tue, 2013-11-05 at 16:32 -0500, Josh Boyer wrote:

> > Right, that's exactly what I was saying. I just think this is all the
> > _original poster_ was talking about, not any kind of automatic
> > configuration of such repositories. (Or at least, you can read it that
> > way).
> 
> OK.  I guess that's fine, but it seems like a non-goal to me.  I mean,
> it already works that way.  All adding it to the PRD would do would
> make an easy thing to check off the list as "met".

I would actually like to go a little further, and make it easy to enable
'clean' third-party repositories. If we imagine a future where e.g.
valve is hosting a repository with their steam client, or say, the
chromium web browser is available from the a fedora people page, I would
really like it if searching for 'steam' or 'chromium' in gnome-software
would bring up a text that said something like: The software you are
looking for is available from a third-party repository. Do you want to
enable it ?

Matthias

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

2013-11-05 Thread Bastien Nocera

- Original Message -
> On Mon, 2013-11-04 at 16:15 -0500, Bastien Nocera wrote:
> > 
> > - Original Message -
> > > I don't get your example but I agree with Reindl Harald - Linux
> > > Distribution is a set of software that works as one coherent
> > > environment. Let it be 10, 100 or 1000 different packages but
> > > they're chosen, compiled and adjusted to work together. This is the
> > > strength of Linux as operating system.
> > 
> > I'd like to see the QA matrix on that one...
> 
> It's hideous, but I suspect the QA matrix for sandboxed apps would be
> even worse. Are you going to guarantee to me that the sandboxing will be
> 100% perfect - that we'll *never* have the case where a 'sandboxed' app
> works on Ubuntu 13.04 but not on Fedora 18?

There's bugs in every software. But it should work. That's the aim.

> Yeah, I didn't think so...

Might not want to put answers in people's mouths. Did you read up on the
various bundling techniques that were explored and the API/ABI guarantees we
want to offer? I'll stop short of paraphrasing you.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

On Tue, Nov 05, 2013 at 01:23:01PM -0800, Adam Williamson wrote:
> So let me step into my handy Tardis and bring back a vignette from the
> Real World after Fedora and other distributions bless upstream app
> distribution as a preferred channel:

I'm not sure I can match this for evocativeness, but:

> Manager: ...so, executive summary: you're saying you'd _like_ to spend a
> not insubstantial chunk of your fairly expensive time working to jump
> through some hoops so our Shiny New Application can be included in these
> 'downstream distribution' things, but if I insist, you can whack a
> button to put it in the Linux App Store and we can go to press with our
> announcement tomorrow?
> 
> Well-Intentioned Techie A: (gulps)...yes.
> 
> Manager: Whack that button, techie. Whack it hard. Now get out of my
> office, I have to call the PR department.

In a different future where there is no such magic button, what brings
enlightenment to the manager? I think maybe the conversation goes much like
yours, except with "and don't bother me about 'getting into downstream
distributions' again".

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

2013-11-05 Thread Rahul Sundaram

Hi

On Tue, Nov 5, 2013 at 4:06 PM, Adam Williamson wrote:

> I would like that too, to be clear. That is why I used the term
> "upstream distribution" and not the term "sandboxed apps". Sandboxing is
> a desirable technology for both upstream and centralized distribution,
>

I am not sure that is a good distinction either.  I mean, upstream could
provide some metadata which can be aggregated and used by a centralized
interface.  Perhaps we should use distribution packages vs upstream
packages instead?

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

On Tue, 2013-11-05 at 16:32 -0500, Josh Boyer wrote:
> On Tue, Nov 5, 2013 at 4:29 PM, Adam Williamson  wrote:
> > On Tue, 2013-11-05 at 15:23 -0500, Josh Boyer wrote:
> >> On Tue, Nov 5, 2013 at 2:58 PM, Adam Williamson  
> >> wrote:
> >> > On Fri, 2013-11-01 at 14:22 -0400, Josh Boyer wrote:
> >> >
> >> >> > - What about watching films, listening to music? I think it is a basic
> >> >> > requirement for students (at least for me).
> >> >> >
> >> >> > Maybe we should add a that a student should be able to play videos and
> >> >> > listen to music. It should be easy to install required codes
> >> >> > (free/nonfree/patente) if they are available in the repositories 
> >> >> > (yes, I
> >> >> > mean rpmfusion)
> >> >>
> >> >> This would require approval beyond the WG, as it goes against Fedora's
> >> >> policies.  Note, I am not saying you are incorrect, just that it's a
> >> >> conversation to be had elsewhere first.
> >> >
> >> > Ensuring that it's possible/easy to install plugins from third party
> >> > repositories when appropriate if those third party repositories are
> >> > defined is not, I don't believe, against any policies, or we could not
> >> > have the automatic codec installation mechanisms in Totem and Rhythmbox.
> >> > (Which, as I read it, is the kind of thing this comment was about).
> >>
> >> The codec search only works if you have repositories configured that
> >> have packages that match the Provides (as far as I understand).
> >> Fedora policy says that we do not promote or install such
> >> repositories.  This is the "don't talk about RPMFusion" rule.
> >>
> >> So sure, we can have software that will pull things in if the user has
> >> done some manual intervention.  We just cant, currently, do that thing
> >> for them.
> >
> > Right, that's exactly what I was saying. I just think this is all the
> > _original poster_ was talking about, not any kind of automatic
> > configuration of such repositories. (Or at least, you can read it that
> > way).
> 
> OK.  I guess that's fine, but it seems like a non-goal to me.  I mean,
> it already works that way.  All adding it to the PRD would do would
> make an easy thing to check off the list as "met".

I suppose we should go back to the OP and ask for clarification of
exactly what the idea was, at this point :)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

On Tue, 2013-11-05 at 22:15 +0100, Olav Vitters wrote:
> On Tue, Nov 05, 2013 at 12:56:47PM -0800, Adam Williamson wrote:
> > bad outcome as low as possible. "Let's just try it and see what
> > happens!" is not a mature approach to risk management.
> 
> Ehr, instead of promoting something as supported, just start off slow.
> Call if alpha, write down all the concerns, etc. Announcing this as the
> new supported + preferred way is not what is intended IMO.
> 
> Your post effectively read as stop energy IMO. It is impossible to get
> everything right at the first version. Just ensure everyones expectation
> is correct. Call it experimental + alpha initially.
> 
> Various concerns have been raised. Just write them down, make a plan to
> address them, done.

What I'm trying to do is contribute to ensuring that happens. As I wrote
in another post, I've always thought it'd be great if distros could
collaborate on a single approved framework/channel for third party
software releases (preferably before Valve does it for us). But it
definitely _does_ need to be the case that this is done carefully and
with a clear decision made on to what extent we choose to 'bless' this
mechanism in comparison to the distro repositories.

Essentially I'm trying to make the point that this is an extremely
sensitive issue which has the potential to cause long-term and
non-reversible changes to software distribution paradigms we've been
using for decades, so it needs to be handled carefully and with an
appreciation of all the consequences, not just with a 'hey, let's build
it, slap together some press about it and see what happens' kind of
attitude...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

On Tue, Nov 5, 2013 at 4:29 PM, Adam Williamson  wrote:
> On Tue, 2013-11-05 at 15:23 -0500, Josh Boyer wrote:
>> On Tue, Nov 5, 2013 at 2:58 PM, Adam Williamson  wrote:
>> > On Fri, 2013-11-01 at 14:22 -0400, Josh Boyer wrote:
>> >
>> >> > - What about watching films, listening to music? I think it is a basic
>> >> > requirement for students (at least for me).
>> >> >
>> >> > Maybe we should add a that a student should be able to play videos and
>> >> > listen to music. It should be easy to install required codes
>> >> > (free/nonfree/patente) if they are available in the repositories (yes, I
>> >> > mean rpmfusion)
>> >>
>> >> This would require approval beyond the WG, as it goes against Fedora's
>> >> policies.  Note, I am not saying you are incorrect, just that it's a
>> >> conversation to be had elsewhere first.
>> >
>> > Ensuring that it's possible/easy to install plugins from third party
>> > repositories when appropriate if those third party repositories are
>> > defined is not, I don't believe, against any policies, or we could not
>> > have the automatic codec installation mechanisms in Totem and Rhythmbox.
>> > (Which, as I read it, is the kind of thing this comment was about).
>>
>> The codec search only works if you have repositories configured that
>> have packages that match the Provides (as far as I understand).
>> Fedora policy says that we do not promote or install such
>> repositories.  This is the "don't talk about RPMFusion" rule.
>>
>> So sure, we can have software that will pull things in if the user has
>> done some manual intervention.  We just cant, currently, do that thing
>> for them.
>
> Right, that's exactly what I was saying. I just think this is all the
> _original poster_ was talking about, not any kind of automatic
> configuration of such repositories. (Or at least, you can read it that
> way).

OK.  I guess that's fine, but it seems like a non-goal to me.  I mean,
it already works that way.  All adding it to the PRD would do would
make an easy thing to check off the list as "met".

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

On Tue, 2013-11-05 at 15:23 -0500, Josh Boyer wrote:
> On Tue, Nov 5, 2013 at 2:58 PM, Adam Williamson  wrote:
> > On Fri, 2013-11-01 at 14:22 -0400, Josh Boyer wrote:
> >
> >> > - What about watching films, listening to music? I think it is a basic
> >> > requirement for students (at least for me).
> >> >
> >> > Maybe we should add a that a student should be able to play videos and
> >> > listen to music. It should be easy to install required codes
> >> > (free/nonfree/patente) if they are available in the repositories (yes, I
> >> > mean rpmfusion)
> >>
> >> This would require approval beyond the WG, as it goes against Fedora's
> >> policies.  Note, I am not saying you are incorrect, just that it's a
> >> conversation to be had elsewhere first.
> >
> > Ensuring that it's possible/easy to install plugins from third party
> > repositories when appropriate if those third party repositories are
> > defined is not, I don't believe, against any policies, or we could not
> > have the automatic codec installation mechanisms in Totem and Rhythmbox.
> > (Which, as I read it, is the kind of thing this comment was about).
> 
> The codec search only works if you have repositories configured that
> have packages that match the Provides (as far as I understand).
> Fedora policy says that we do not promote or install such
> repositories.  This is the "don't talk about RPMFusion" rule.
> 
> So sure, we can have software that will pull things in if the user has
> done some manual intervention.  We just cant, currently, do that thing
> for them.

Right, that's exactly what I was saying. I just think this is all the
_original poster_ was talking about, not any kind of automatic
configuration of such repositories. (Or at least, you can read it that
way).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

AppData: what if screenshots are the wrong aspect ratio?

2013-11-05 Thread Jerry James

I just took a look at making AppData xml files for the packages I
maintain.  I started with the alphabetically first one (why not?):
abe.  Here is my first attempt:



 abe.desktop
 CC0
 Abe's Amazing Adventure
 
  
   Abe's Amazing Adventure is a scrolling, platform-jumping, key-collecting,
   ancient pyramid exploring game, vaguely in the style of similar games for
   the Commodore+4.  The game is intended to show young people (I'm writing
   it for my son's birthday) all the cool games they missed.
  
 
 
  http://abe.sourceforge.net/screen0-4-1.png
  http://abe.sourceforge.net/screen2-4-2.png
 
 http://abe.sourceforge.net/
 


But those screenshots are not the right aspect ratio.  What is the
right thing to do here?  Just use this anyway and let the GUIs decide
how to resize the screenshots?  Download the screenshots and figure
out how to massage them into the right aspect ratio on my machine?  If
so, where do I store the massaged screenshots?

Also, the documentation at
http://people.freedesktop.org/~hughsient/appdata/ doesn't say what a
screenshot type is supposed to be.  I gathered that one should have
type "default" and the rest should have no type by looking at some
examples.  If that's not correct, could the documentation be updated
to explain this, please?

Thanks,
-- 
Jerry James
http://www.jamezone.org/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

On Mon, 2013-11-04 at 23:50 +0100, Michael Scherer wrote:
> Le lundi 04 novembre 2013 à 21:02 +0100, Reindl Harald a écrit :
> > 
> > Am 04.11.2013 20:56, schrieb drago01:
> > > On Mon, Nov 4, 2013 at 8:49 PM, Reindl Harald  
> > > wrote:
> > >> that's all true but you can be pretty sure if a "app-store" with
> > >> bundeled applications exists *nobody* would package and maintain
> > >> them as RPM -> everybody would point with his finger to the app
> > > 
> > > No because RPM packages apps *do* have benifits .. otherwise we
> > > wouldn't have this discussion.
> > > 
> > >> if it goes in that direction, and it starts faster than anybody likes
> > >> you do a dramatical harm to the userbase which likes the consistent
> > >> package managment and *really used* conecpt of shared libraries
> > > 
> > > Again those are NOT MUTUALLY EXCLUSIVE. You can have sandboxed *and*
> > > rpm packaged apps at the same time.
> > 
> > the most imporant word in your answer is *CAN*
> > 
> > but you will not, nobody will package whatever application
> > as RPM if he is fine with the app-store, so you *could*
> > have both but i doubt at the end of the day it will happen
> 
> If no one think that using a rpm is bringing any value, then indeed, no
> one will do the job. Now, if someone think this is better for whatever
> reasons, then this someone will do the job. 
> 
> It seems that your fear is that if people are not forced to make rpm,
> they will not see the value of doing so, and so would not do it. 
> 
> So if that's the problem, then the solution is to demonstrate the value
> of packaging and rpm rather than restricting all others alternatives. 

So to me this is the nub of the debate, and it's both fantastically
interesting and fantastically difficult to work out in advance.

In an ideal world things would work the way Michael describes, and also,
the stock market would behave precisely as neat theories based on
rational actors predict, and no-one would have any difficulty solving
the three door problem, and healthcare.gov would never have been
launched in a state in which it could not possibly work...

And in the real world, well, it's the real world. :)

So let me step into my handy Tardis and bring back a vignette from the
Real World after Fedora and other distributions bless upstream app
distribution as a preferred channel:

---

Scene: an office, much like this one.

Manager: ...so, executive summary: you're saying you'd _like_ to spend a
not insubstantial chunk of your fairly expensive time working to jump
through some hoops so our Shiny New Application can be included in these
'downstream distribution' things, but if I insist, you can whack a
button to put it in the Linux App Store and we can go to press with our
announcement tomorrow?

Well-Intentioned Techie A: (gulps)...yes.

Manager: Whack that button, techie. Whack it hard. Now get out of my
office, I have to call the PR department.

Well-Intentioned Techie A: (sighs) OK. So, when will you let me have
some time to work on having the app packaged in distributions further
down the road?

Manager: What were the concrete benefits to us again?

Well-Intentioned Techie A: Err, well, in an extremely theoretical way
that you will never understand no matter how many times I explain it to
you, it probably makes our app - and the rest of the ecosystem! - more
secure.

Manager: Less of this 'ecosystem' crap, Techie, no-one cares about that.
ZDNet is not yelling about any security issues in our product right now,
right?

WITA: Er, no.

Manager: Okay, not my problem, then. What else?

WITA: (sighs, continues with an ever-increasing sense of foreboding)
Well, it might reduce storage and memory usage on the user's system by
an amount that wouldn't really be appreciable and would be difficult for
a non-technical user to associate with our app in the first pl- you're
never going to give me time to work on this, are you?

Manager: No. No, I'm not. But here, have another bottle of rye.

WITA: (sighs, returns to office, resumes drinking)

---

Now after I've collected my Tony awards...I hope you get the point. In
theory, we'd still be able to evangelize the benefits of centralized
distribution in a world where we blessed a form of upstream
distribution. In practice, things may well be messier than that. If
distros move away from the gospel of centralized distribution to a
sufficient extent, we may wind up in a 'tragedy of the commons' where
it's just not enough in anyone's short-term direct interest to invest
the resources in supported centralized distribution, even though many
people would recognize the arguments in its favour on a long-term,
ecosystem-wide level. "We can post it on the store and it'll work on
everyone's system tomorrow" is an *extremely* powerful argument.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https

Re: Draft Product Description for Fedora Workstation

On Tue, Nov 05, 2013 at 01:06:29PM -0800, Adam Williamson wrote:
> > I really would like all my desktop applications to run in a sandbox, whether
> > they come from upstream directly or from us.
> I would like that too, to be clear. That is why I used the term
> "upstream distribution" and not the term "sandboxed apps". Sandboxing is
> a desirable technology for both upstream and centralized distribution,
> which makes its conflation with upstream distribution unfortunate in
> this debate: I think that has come about because sandboxing is arguably
> more _urgently_ desirable for upstream distribution, but what we're
> really arguing about here is the old 'upstream vs. distro-based'
> chestnut, not sandboxing.

In that case, I absolutely agree with your previous statement which has
been snipped from this subthread. :)


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora Workstation product name

On Tue, Nov 5, 2013 at 4:00 PM, Matthew Miller  wrote:
> On Tue, Nov 05, 2013 at 11:25:18AM -0500, Matthias Clasen wrote:
>> The Fedora Workstation effort (not a great name, by the way), is brand
>
> It doesn't have to end up with that name, for the record. That's just a
> working title and indicative of the conversation at Flock. Peter Jones had
> suggested "Fedora Client", and there were some others as well.

People long ago dropped desktop@ from the CC list on the thread you
took this from.  If there is a desire to debate and suggest new names
for the Workstation product, it should probably be done on desktop@
and not devel@.

Please start a new thread there.

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

2013-11-05 Thread Olav Vitters

On Tue, Nov 05, 2013 at 12:56:47PM -0800, Adam Williamson wrote:
> bad outcome as low as possible. "Let's just try it and see what
> happens!" is not a mature approach to risk management.

Ehr, instead of promoting something as supported, just start off slow.
Call if alpha, write down all the concerns, etc. Announcing this as the
new supported + preferred way is not what is intended IMO.

Your post effectively read as stop energy IMO. It is impossible to get
everything right at the first version. Just ensure everyones expectation
is correct. Call it experimental + alpha initially.

Various concerns have been raised. Just write them down, make a plan to
address them, done.

-- 
Regards,
Olav
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

On Tue, Nov 5, 2013 at 9:56 PM, Adam Williamson  wrote:
> On Mon, 2013-11-04 at 21:03 +0100, drago01 wrote:
>> On Mon, Nov 4, 2013 at 9:02 PM, Reindl Harald  wrote:
>> >
>> >
>> > Am 04.11.2013 20:56, schrieb drago01:
>> >> On Mon, Nov 4, 2013 at 8:49 PM, Reindl Harald  
>> >> wrote:
>> >>> that's all true but you can be pretty sure if a "app-store" with
>> >>> bundeled applications exists *nobody* would package and maintain
>> >>> them as RPM -> everybody would point with his finger to the app
>> >>
>> >> No because RPM packages apps *do* have benifits .. otherwise we
>> >> wouldn't have this discussion.
>> >>
>> >>> if it goes in that direction, and it starts faster than anybody likes
>> >>> you do a dramatical harm to the userbase which likes the consistent
>> >>> package managment and *really used* conecpt of shared libraries
>> >>
>> >> Again those are NOT MUTUALLY EXCLUSIVE. You can have sandboxed *and*
>> >> rpm packaged apps at the same time.
>> >
>> > the most imporant word in your answer is *CAN*
>> >
>> > but you will not, nobody will package whatever application
>> > as RPM if he is fine with the app-store, so you *could*
>> > have both but i doubt at the end of the day it will happen
>>
>> And I disagree ... but there is a way to find out ... lets try and see ;)
>
> That's rather a cavalier attitude.
>
> You seem to agree that the future Harald posits is at least a
> possibility.

No I don't. I just think that at this point the best way to prove that
to him is simply to show it how it works out in practice.

I still don't get why we have to argue that much about something like
this .. is giving upstreams a well defined way how to ship there
applications instead of letting them come up with a hack really that
bad?
Upstreams will always (and always had) seek was to do that .. simply
because there is demand. No one is forcing anyone to install such
apps.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

On Tue, 2013-11-05 at 16:04 -0500, Matthew Miller wrote:
> On Tue, Nov 05, 2013 at 12:44:21PM -0800, Adam Williamson wrote:
> > "Promote as the Proper Way To Get Apps On GNOME / Fedora Desktop" would
> > NOT be great. Having spent a lot of time thinking about both sides of
> > the debate I'm still firmly in the 'coherent distribution is the ideal
> > state' camp. Upstream distribution is probably never going to go away
> > entirely, and it'd be good to make it as painless and reliable as
> > possible _where it's really necessary to use it_. But it should never be
> > the primary/preferred method of software distribution on Fedora, in my
> > opinion. It should always be an exception.
> 
> I really would like all my desktop applications to run in a sandbox, whether
> they come from upstream directly or from us.

I would like that too, to be clear. That is why I used the term
"upstream distribution" and not the term "sandboxed apps". Sandboxing is
a desirable technology for both upstream and centralized distribution,
which makes its conflation with upstream distribution unfortunate in
this debate: I think that has come about because sandboxing is arguably
more _urgently_ desirable for upstream distribution, but what we're
really arguing about here is the old 'upstream vs. distro-based'
chestnut, not sandboxing.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

On Tue, Nov 05, 2013 at 12:44:21PM -0800, Adam Williamson wrote:
> "Promote as the Proper Way To Get Apps On GNOME / Fedora Desktop" would
> NOT be great. Having spent a lot of time thinking about both sides of
> the debate I'm still firmly in the 'coherent distribution is the ideal
> state' camp. Upstream distribution is probably never going to go away
> entirely, and it'd be good to make it as painless and reliable as
> possible _where it's really necessary to use it_. But it should never be
> the primary/preferred method of software distribution on Fedora, in my
> opinion. It should always be an exception.

I really would like all my desktop applications to run in a sandbox, whether
they come from upstream directly or from us.



-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora Workstation product name

On Tue, Nov 05, 2013 at 11:25:18AM -0500, Matthias Clasen wrote:
> The Fedora Workstation effort (not a great name, by the way), is brand

It doesn't have to end up with that name, for the record. That's just a
working title and indicative of the conversation at Flock. Peter Jones had
suggested "Fedora Client", and there were some others as well. 


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

On Mon, 2013-11-04 at 16:15 -0500, Bastien Nocera wrote:
> 
> - Original Message -
> > I don't get your example but I agree with Reindl Harald - Linux
> > Distribution is a set of software that works as one coherent
> > environment. Let it be 10, 100 or 1000 different packages but
> > they're chosen, compiled and adjusted to work together. This is the
> > strength of Linux as operating system.
> 
> I'd like to see the QA matrix on that one...

It's hideous, but I suspect the QA matrix for sandboxed apps would be
even worse. Are you going to guarantee to me that the sandboxing will be
100% perfect - that we'll *never* have the case where a 'sandboxed' app
works on Ubuntu 13.04 but not on Fedora 18? Yeah, I didn't think so...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

On Mon, 2013-11-04 at 21:03 +0100, drago01 wrote:
> On Mon, Nov 4, 2013 at 9:02 PM, Reindl Harald  wrote:
> >
> >
> > Am 04.11.2013 20:56, schrieb drago01:
> >> On Mon, Nov 4, 2013 at 8:49 PM, Reindl Harald  
> >> wrote:
> >>> that's all true but you can be pretty sure if a "app-store" with
> >>> bundeled applications exists *nobody* would package and maintain
> >>> them as RPM -> everybody would point with his finger to the app
> >>
> >> No because RPM packages apps *do* have benifits .. otherwise we
> >> wouldn't have this discussion.
> >>
> >>> if it goes in that direction, and it starts faster than anybody likes
> >>> you do a dramatical harm to the userbase which likes the consistent
> >>> package managment and *really used* conecpt of shared libraries
> >>
> >> Again those are NOT MUTUALLY EXCLUSIVE. You can have sandboxed *and*
> >> rpm packaged apps at the same time.
> >
> > the most imporant word in your answer is *CAN*
> >
> > but you will not, nobody will package whatever application
> > as RPM if he is fine with the app-store, so you *could*
> > have both but i doubt at the end of the day it will happen
> 
> And I disagree ... but there is a way to find out ... lets try and see ;)

That's rather a cavalier attitude. 

You seem to agree that the future Harald posits is at least a
possibility. If so, I think you, he and I would all agree it would be a
negative outcome in at least some respects. It is, therefore, a future
risk. It's not an easily reversible risk: we can't invent a sandboxed
app distribution mechanism, promote it as a blessed and 'supported'
method of app distribution for Fedora, and then suddenly say 'hey, wait,
that was a bad idea!' and take it away again. Or, rather, we could, but
that path would have its own negative consequences.

So: you, he and I all agree that the path your propose implies a risk.
You would also argue, I'm sure, that it may result in a benefit.

In this situation what we should do is carefully consider the relative
possibilities of the good, bad and mixed outcomes with as much precision
as we can, and try to come up with a path forward which makes the
likelihood of a good outcome as high as possible and the likelihood of a
bad outcome as low as possible. "Let's just try it and see what
happens!" is not a mature approach to risk management.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

On Mon, 2013-11-04 at 11:13 +0100, drago01 wrote:
> On Mon, Nov 4, 2013 at 11:11 AM, Frank Murphy  wrote:
> > On Mon, 4 Nov 2013 11:03:45 +0100
> > drago01  wrote:
> >
> >
> >> Apps shipping from upstream direcly does not have to be closed
> >> source. Firefox for instance could use that, or libreoffice, or
> >> eclipse. If a user needs a newer version (or nightly build) without
> >> having upstream worry about the specific distribution.
> >>
> >>
> > I haven't read every post in the thread.
> > Confused are use asking users to build nightlies
> > (or other ver) from src?
> 
> No we are just creating a way to allow those upstreams to create those
> builds for users (as Florian said without having them to update to
> rawhide or wait six months for the next release).

Haven't read the whole thread yet, but in case it hasn't been said:

"Build a way" would be great. I've said a few times that it'd be nice
for there to be a cross-distro framework for third-party app
distribution.

"Promote as the Proper Way To Get Apps On GNOME / Fedora Desktop" would
NOT be great. Having spent a lot of time thinking about both sides of
the debate I'm still firmly in the 'coherent distribution is the ideal
state' camp. Upstream distribution is probably never going to go away
entirely, and it'd be good to make it as painless and reliable as
possible _where it's really necessary to use it_. But it should never be
the primary/preferred method of software distribution on Fedora, in my
opinion. It should always be an exception.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

On Tue, Nov 5, 2013 at 9:23 PM, Josh Boyer  wrote:
> On Tue, Nov 5, 2013 at 2:58 PM, Adam Williamson  wrote:
>> On Fri, 2013-11-01 at 14:22 -0400, Josh Boyer wrote:
>>
>>> > - What about watching films, listening to music? I think it is a basic
>>> > requirement for students (at least for me).
>>> >
>>> > Maybe we should add a that a student should be able to play videos and
>>> > listen to music. It should be easy to install required codes
>>> > (free/nonfree/patente) if they are available in the repositories (yes, I
>>> > mean rpmfusion)
>>>
>>> This would require approval beyond the WG, as it goes against Fedora's
>>> policies.  Note, I am not saying you are incorrect, just that it's a
>>> conversation to be had elsewhere first.
>>
>> Ensuring that it's possible/easy to install plugins from third party
>> repositories when appropriate if those third party repositories are
>> defined is not, I don't believe, against any policies, or we could not
>> have the automatic codec installation mechanisms in Totem and Rhythmbox.
>> (Which, as I read it, is the kind of thing this comment was about).
>
> The codec search only works if you have repositories configured that
> have packages that match the Provides (as far as I understand).
> Fedora policy says that we do not promote or install such
> repositories.  This is the "don't talk about RPMFusion" rule.

And I still think this kind of "censorship" is a bit to paranoid but IANAL.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

On Tue, Nov 5, 2013 at 2:58 PM, Adam Williamson  wrote:
> On Fri, 2013-11-01 at 14:22 -0400, Josh Boyer wrote:
>
>> > - What about watching films, listening to music? I think it is a basic
>> > requirement for students (at least for me).
>> >
>> > Maybe we should add a that a student should be able to play videos and
>> > listen to music. It should be easy to install required codes
>> > (free/nonfree/patente) if they are available in the repositories (yes, I
>> > mean rpmfusion)
>>
>> This would require approval beyond the WG, as it goes against Fedora's
>> policies.  Note, I am not saying you are incorrect, just that it's a
>> conversation to be had elsewhere first.
>
> Ensuring that it's possible/easy to install plugins from third party
> repositories when appropriate if those third party repositories are
> defined is not, I don't believe, against any policies, or we could not
> have the automatic codec installation mechanisms in Totem and Rhythmbox.
> (Which, as I read it, is the kind of thing this comment was about).

The codec search only works if you have repositories configured that
have packages that match the Provides (as far as I understand).
Fedora policy says that we do not promote or install such
repositories.  This is the "don't talk about RPMFusion" rule.

So sure, we can have software that will pull things in if the user has
done some manual intervention.  We just cant, currently, do that thing
for them.

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

On Fri, 2013-11-01 at 14:22 -0400, Josh Boyer wrote:

> > - What about watching films, listening to music? I think it is a basic
> > requirement for students (at least for me).
> >
> > Maybe we should add a that a student should be able to play videos and
> > listen to music. It should be easy to install required codes
> > (free/nonfree/patente) if they are available in the repositories (yes, I
> > mean rpmfusion)
> 
> This would require approval beyond the WG, as it goes against Fedora's
> policies.  Note, I am not saying you are incorrect, just that it's a
> conversation to be had elsewhere first.

Ensuring that it's possible/easy to install plugins from third party
repositories when appropriate if those third party repositories are
defined is not, I don't believe, against any policies, or we could not
have the automatic codec installation mechanisms in Totem and Rhythmbox.
(Which, as I read it, is the kind of thing this comment was about).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Draft v2 Workstation WG Governance Charter

Hi All,

Here's the second draft of the charter.  I think I captured most of
the discussion to date, but there's always a chance I missed
something.  Please read this over and provide any feedback you have.
Please pay particular attention to the (NOTE:) items.

Thanks.

josh

== Fedora Workstation WG Governance ==

This document describes the governing structure for the Fedora
Workstation Work Group.

=== Membership ===

The Fedora Workstation Work Group has nine voting members, with one
member selected by the Fedora Engineering Steering Committee as the
liaison to FESCo.

The FESCo liaison is always a member of the decision making group for
the Work  Group.  The liaison is responsible for presenting the WG
decisions and summary of WG discussions to FESCo on a regular basis.
They will also take feedback or requirements from FESCo back to the
WG.  The liaison is not required to be a  FESCo member, but should be
able to regularly attend the FESCo meetings.

Members of the Work Group are chosen by the Work Group as seats become
 available.  In the event that a current member relinquishes their
seat, the Work Group will fill the seat by selecting a candidate and
approving by majority consensus.  Eligible candidates must be in the
FPCA+1 group.  The Work Group is highly  encouraged to seek out
candidates that have been showing persistent and high quality
contribution to the Workstation product.

(NOTE: I believe this is a decent encapsulation of the discussion
we've had thus far.  I've omitted term limits for now, but I'm open to
suggestions.  The FPCA+1 requirement seems reasonable to me as we want
to make sure they're a Fedora contributor first and foremost.
Suggestions/questions welcome.)

=== Current Members ===

* Josh Boyer (FESCo Liaison) (jwb)
* Matthias Clasen (mclasen)
* Kalev Lember (kalev)
* Ryan Lerch (ryanlerch)
* Jens Petersen (juhp)
* Christian Schaller (cschalle)
* Owen Taylor (otaylor)
* Lukáš Tinkl (ltinkl)
* Christoph Wickert (cwickert)

=== Making Decisions ===

Because Fedora is a global project, members of the working group may
be distributed across multiple timezones. It may be possible to have a
real-time IRC meetings, but  in general we will conduct business on
the mailing list.

Many of our decisions can be made through "lazy consensus";. Under
this model, an intended action is announced on the mailing list,
discussed, and in the absence of a group of dissenting contributors
within a few days, simply done.

For bigger issues, where there may be disagreement, or where there is
long-term  impact, or where an action may not easily be undone, we
will put forth a formal  proposal on the mailing list with a
"[Proposal for Vote] header in the email Subject:  field.  Working
group members can vote +1 to approve, -1 to disagree, or 0 to abstain;
five +1 votes are necessary for a measure to pass. Non-members may
comment on the item and (of course) discuss on the mailing list, but
are asked to refrain from  putting votes on official proposal threads.

In the event that a live meeting is held in IRC to discuss an issue,
proposals will be done in much the same way.  A member will put forth
an official proposal by prefixing a summary of such with "Proposal:"
and WG members will vote as above.  Results will be recorded and
posted in any meeting minutes.

(NOTE: I chose option #2 from the previous draft for now.  If you'd
like to see something different, please speak up.  I don't believe
anyone commented on this section specifically.)

=== Changing these Rules ===

This document will be approved by consensus of the initial Working
Group members and approved by FESCo. After initial ratification, any
substantive changes can be approved by majority vote and sent to FESCo
for acceptance.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

2013-11-05 Thread Ray Strode

Hi,

- Original Message -
> > We should be enabling the user to get the things
> > done he/she cares about, not forcing them to learn the things we care
> > about.
> > 
> > There should be no "You must be this tall to ride Fedora Workstation"
> > signs.
> [...snip...]
> 
> Is it the intent that the developer cases here completely subsume the
> case of a developer who is working primarily on Fedora itself
> (including the Worsktation)?  Perhaps we should call that out to
> correctly prioritize integration of the various developer tools
> currently available or planned for the Workstation.

That's a good point, too. My mail is trying to make sure we consider 
developers who don't work on Fedora, but just use Fedora for development.
Paul makes a very reasonable point that we should be clear to accomodate 
(and not alienate) ourselves (Fedora contributors) as well.

So, as a throw-away example..., It might not make sense to have fedpkg in
the default install, but having an easily obtainable Fedora SDK of sorts
that includes all the bits needed to get up and going might be a good idea.

--Ray
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Review Request: prboom-plus - Free enhanced DOOM engine

2013-11-05 Thread punto...@libero.it


Il 05/11/2013 18:56, Jaromir Capik ha scritto:

Hello everyone.

I'm searching for volunteers willing to review the prboom-plus engine:

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

Anybody want to help with that?

Thanks in advance.

Regards,
Jaromir.

--
Jaromir Capik
Red Hat Czech, s.r.o.
Software Engineer / Secondary Arch

Email: jca...@redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkynova 99/71, 612 45, Brno, Czech Republic
IC: 27690016



hi
take...
can you take https://bugzilla.redhat.com/show_bug.cgi?id=1005796 ?
if you have time 
thanks
regards
gil

<>-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

R: Re: Discontinued Packing of NetBeans IDE

2013-11-05 Thread punto...@libero.it

hi
see https://fedoraproject.org/wiki/Features/NetBeans_7.3 (should be update)
problem(s):
- latest NB releases use some libraries available in java8 e.g.
  https://github.com/furosys/nashorn
  Nashorn for Java 7 https://bitbucket.org/ramonza/nashorn-backport (used by 
NB)
  https://bugzilla.redhat.com/show_bug.cgi?id=1005932
- eclipse integration, i/we haven't no intentions to use eclipse libraries (e.
g. eclipse jgit)
  if users was use thesefeatures should/must use eclipse ide
- some libraries was updates, and others should be adapted for latest release 
7.4

for now porting of NB is stopped
regards
gil

>Messaggio originale
>Da: sochotni...@redhat.com
>Data: 05/11/2013 18.03
>A: "Development discussions related to Fedora"
>Ogg: Re: Discontinued Packing of NetBeans IDE
>
>Quoting Rahul Sundaram (2013-11-05 17:46:55)
>>  Hi
>> 
>> 
>> On Tue, Nov 5, 2013 at 11:45 AM, Manuel Faux  wrote:
>> 
>> > Is it correct that the NetBeans IDE is currently not packed for Fedora? I
>> > checked the "netbeans" package, which was last built for fc17.
>> > Is there any technical or license reason for this or is just nobody
>> > packing it right now?
>> >
>> 
>> Someone from Sun used to be the maintainer and noone is doing it right
>> now.  No technical or licensing issues if anyone is interested in packaging
>> it afaik.
>
>More specifically look at:
>
>https://lists.fedoraproject.org/pipermail/java-devel/2010-November/003980.
html
>
>Reason nobody picked it up is that is has relatively big dependency chain and
>there was nobody interested enough (from maintainer perspective). Most Java
>packages are in Fedora because they are dependencies of following packages:
>
>* Tomcat
>* Maven
>* Eclipse
>* WildFly
>* (new) Big Data SIG stuff
>* and of course a few more apps here and there
>
>-- 
>Stanislav Ochotnicky 
>Software Engineer - Developer Experience
>
>PGP: 7B087241
>Red Hat Inc.   http://cz.redhat.com
>-- 
>devel mailing list
>devel@lists.fedoraproject.org
>https://admin.fedoraproject.org/mailman/listinfo/devel
>Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

2013-11-05 Thread Paul W. Frields

On Mon, Nov 04, 2013 at 09:21:15AM -0500, Ray Strode wrote:
> I think this is a pretty good starting point for our development
> direction, and sets the stage for us making positive progress in the
> new working group model.
> 
> I do think we should keep it open to tweaks in the future as things
> play out, (at the discretion of the 9 members on the working group).
> In other words, I think it lays a solid outline for enabling us all
> to know which direction to go, but i want to make sure if it doesn't
> ever "get in the way". The working group should treat it as a living
> document that gets updated as necessary to reflect changes in the
> landscape.

Agreed, it's a good start.  One question...

> > Case 2: Independent Developer
> > Personal development system for an independent software developer doing
> > contract work or developing apps for a new opportunity.
> >
> > Desktop Apps: Up to date desktop with email client, browser, productivity
> > suite, messaging, and  complete set of desktop apps and utilities.  Desktop
> > apps should be sufficient to make  this system the developer's only 
> > computer.
> s/and  complete/and a complete/
> s/make  this/make this/
> 
> [... snip other use cases that sound good ...]
> 
> > Other users
> > While the developer workstation is the main target of this system and what 
> > we
> > try to design this for, we do of course also welcome other users to the
> > Fedora Workstation. In fact many of the changes and improvements we expect 
> > to
> > implement for developers will be equally beneficial to other user segments,
> I think this is a really important point.  Developers are users, too,
> just trying
> to get their work done.  We should make sure the OS doesn't get in the way, 
> and
> that it doesn't enforce artificial barriers to entry.  Just because a user may
> know how the sausage is made, doesn't mean we should make them stuff their own
> (so to speak).  And if a user/developer doesn't know the inner workings of
> Fedora, that's okay, too.  We should be enabling the user to get the things
> done he/she cares about, not forcing them to learn the things we care about.
> 
> There should be no "You must be this tall to ride Fedora Workstation" signs.
[...snip...]

Is it the intent that the developer cases here completely subsume the
case of a developer who is working primarily on Fedora itself
(including the Worsktation)?  Perhaps we should call that out to
correctly prioritize integration of the various developer tools
currently available or planned for the Workstation.

-- 
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/
The open source story continues to grow: http://opensource.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Call for ideas] Defining the scope of the Environments and stacks WG

2013-11-05 Thread Tadej Janež

Hi!

I would like to invite all of you who are interested in helping defining
the scope (i.e. "what we will do" document) of the Environments and
stacks WG to join the discussion [0] at our new env-and-stacks mailing
list [1]. If you have an idea/expectation/suggestion, please write it
up.

We especially encourage members of other WGs to express their
expectations with respect to our WG, so we can align them better.

Best regards,
Tadej

[0]
https://lists.fedoraproject.org/pipermail/env-and-stacks/2013-November/18.html
[1] https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Review Request: prboom-plus - Free enhanced DOOM engine

2013-11-05 Thread Jaromir Capik

Hello everyone.

I'm searching for volunteers willing to review the prboom-plus engine:

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

Anybody want to help with that?

Thanks in advance.

Regards,
Jaromir.

--
Jaromir Capik
Red Hat Czech, s.r.o.
Software Engineer / Secondary Arch

Email: jca...@redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkynova 99/71, 612 45, Brno, Czech Republic
IC: 27690016 


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[389-devel] Please review (take #2) ticket 47575: add test case for ticket47560

2013-11-05 Thread thierry bordaz

Hi All,

This review is new proposal to implement CI test cases inside 389-DS.
The layout of the tests will be:

/dirsrvtests/
tickets/
ticket_abc_test.py
ticket_xyz_test.py

...
finalizer

testsuites/
acl_test.py
replication_test.py
...

Each ticket_xyz_test.py will contain "framework" functions that will
allocate a fresh installed instance then the test functions:
"framework" functions are _ds_create_standalone, DSInstance class
and ds_instance pytest fixture.
tests functions are named 'test_ticket_xyz' with 'ds_instance'
fixture as argument.

py.test will call the test functions 'test_ticket_xyz'. Its argument
is an instance (ds_instance) of DSInstance where
ds_instance.instance is a connection to the instance.

The first instance of DSInstance (first ticket being tested), get a
newly created instance (e.g. slapd-standalone) and creates a backup
of the instance (under /tmp/slapd-standalone.bck/backup_HHMMSS.tar.gz).
Then when running others ticket test cases, the instance is
reinitialized from the backup.
So each ticket test case will have an instance almost like it was
just created.

py.test will discover all the ticket_xxx_test.py files and run them.
In order to remove the created instances, py.test is called a second
time to run finalizer.py.
So a jenkins job script, will do something like:

cd /dirsrvtests/tickets
py.test -v # that will run all the ticket_xxx_tests and create
the instance
py.test -v finalizer.py

Note: in order to check/backup/restore instance, new functions are
added in lib389 (
checkInstanceBackupFS, instanceBackupFS, instanceRestoreFS), I will
send an other review for them as it is not in 389-DS repos.

https://fedorahosted.org/389/attachment/ticket/47575/0002-Ticket-47575-CI-test-add-test-case-for-ticket47560.patch

--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Meeting minutes from today's Env-and-Stacks WG meeting (2013-11-05)

2013-11-05 Thread Marcela Maslanova

13:34  if someone's unhappy about anything, then please say so
16:13:42  otherwise next topic
16:13:45  makes sense, I agree with the no IRC.
16:14:14  we could all idle in #fedora-devel I suppose.
16:14:37  everyone is already there (I guess)
16:14:40  I think most of us already do
16:14:44 * handsome_pirate returns
16:14:59 * abadger1999 hasn't been but could start it was domnated by 
desktop flame wars for a while :-/
16:15:14  actually... let's just talk about irc channels later.
16:15:21  fine by me
16:15:26  #topic Meeting frequency and times
16:15:30  when outsiders start asking where to find us on irc.
16:15:55 * handsome_pirate isn't in #fedora-devel by default, but will be from 
now on
16:16:12  I am usually there
16:16:50  As far as meeting frequency, while we're hashing 
things out, we may want to have them fairly often
16:16:53  Weekly
16:17:10 * masta looks in and lurks
16:17:10  Tuesday is better than Monday
16:17:20  Fedora QA meeting is Mondays at this time
16:17:26  handsome_pirate: you are evil :)
16:17:32  mmaslano:  heh
16:17:45  juhp_: abadger1999: I was wondering if you wish to go to 
every second meeting
16:17:49  mmaslano:  We can set it up to alternate time each 
week so we get the most coverage
16:17:57  so you don't have to be up in strange times
16:18:06  that might be good
16:18:27  16:00 UTC on tuesdays works really nicely for me
16:19:14  +1
16:19:18  But, I can do otherwise
16:19:51  alternate times seem good and 16:00 works for me as one of 
the alternatives
16:20:00  it could be better, but okay
16:20:23  I'm fine with weekly meetings, but I would prefer less 
meetings when there are less things to discuss
16:20:32  let's do another whenisgood for odd and other for even week
16:20:34  +1
16:20:35  tjanez: I agree
16:20:42  sounds good
16:20:45  I just see that right now we likely have plenty to do
16:20:55  This can be revisited later
16:21:04  So, one time is Tues, 1600
16:21:24  So, how about another time?
16:21:27  juhp_: which time and day do you prefer
16:21:33  Ok. Tuesday, 16:00 UTC works for me for the next couple of 
months
16:21:41  it's 1:00 in the morning for you, so you can pick
16:21:44  I don't think we need another whenisgood, we just need to 
pick up the second time.
16:22:19 * abadger1999 has noticed that biweekly meetings tend to have lower 
overall attendance (maybe because people forget which week they're in?)
16:22:43  mmaslano, well roughly 12:00 from now +-4 hours would be fine
16:22:49  abadger1999: that's for smart telephones are ;-)
16:22:53  but might still be easier to use whenisgood :)
16:23:11  mmaslano: yeah.. but people book other meetings and 
events as well...
16:23:18  juhp_: also bkabrda can't in this hour, so maybe he should 
specify his preference too
16:23:24  right
16:23:46  I agree with juhp_, use whenisgood and make precedence to 
bkabrda and juhp_
16:24:14  abadger1999: do you want to setup another whenisgood 'cause 
you know how to do it properly on first time? :)
16:24:27  Why don't we just use the same one?
16:24:46  and select the best time that includes slavek?
16:24:49  http://whenisgood.net/fedenvstk/results/q3gmp7
16:25:15  abadger1999 good point :-)
16:25:25  agreed, thinking out of the box :-)
16:25:48  maybe people should adjust/amend their general availability?
16:25:55  Tuesday, wed, fri 13:00 or 14:00
16:26:00  so around 13:00 UTC might work
16:26:06  yeah
16:26:47  there seems to be no other option including bkabrda on Tue
16:27:31  and probably not better option in other days either
16:27:34 * handsome_pirate is +1 Tues
16:27:35  13:00 UTC is 5am local time for abadger1999 and it's a 
little early for me
16:27:44  Keep it somewhat simpler
16:27:45 * samkottler would like ot keep the meeting on tuesdays generally
16:27:59  samkottler:  We can both show up to the office a bit 
early :)
16:28:01  samkottler: I kinda thought that the idea was that I 
wouldn't be able to make this alternate meeting?
16:28:11  and from the looks of it drieden won't either.
16:28:25  samkottler: 
http://www.timeanddate.com/worldclock/meetingtime.html?iso=20131105&p1=1960&p2=43&p3=248
16:28:30  samkottler: it's hard :)
16:29:04  Anyway, how about ML for this one?
16:29:10  We ought to move on
16:29:12  abadger1999 13:00 is tricky for me, I'm getting my kids 
ready for school, but can be available sporadically at that time.
16:29:34  mmaslano: yeah it's difficult, we'll figure it out on the 
list :-)
16:29:38  it is 10pm here but that is okay
16:30:02  #info odd and even weeks will have different time for 
meetings because of time zones
16:30:04  drieden: I take it 14:00 Wed is even worse for you?
16:30:20  (since you have the hours after that blocked off as well)
16:30:32  abadger1999 Yes 14:00 wed is a regularly scheduled meeting
16:31:00  #agreed 16:00 UTC for week starting 19th November
16:31:36  let's sta

Re: ntp-4.2.6p5-11.fc19.src.rpm does not rpmbuild...

2013-11-05 Thread Barry Scott

On Fri 18 Oct 2013 17:59:31 Miroslav Lichvar wrote:
> On Fri, Oct 18, 2013 at 02:14:40PM +0100, Barry Scott wrote:
> > On Thu 17 Oct 2013 17:56:57 Barry Scott wrote:
> > > I need to patch ntp for my uses. But I find that the src rpm will not
> > > build
> > > on F19.
> > > 
> > > cd . && env
> > > PATH="/home/bscott/rpmbuild/BUILD/ntp-4.2.6p5/ntpd:/home/bscott/bin:/usr
> > > /loc al/bin:/bin:/usr/bin:/usr/local/sbin:/sbin:/usr/sbin" autogen -L
> > > ../include --writable -Tagman1.tpl -bntpd ntpd-opts.def
> > > ice-9/psyntax.scm:1259:12: In procedure dobody:
> 
> > > ice-9/psyntax.scm:1259:12: Syntax error:
> That looks like https://bugzilla.redhat.com/show_bug.cgi?id=958908.
> 
> It's fixed in autogen-5.18-1.fc20. The F19 ntp spec includes a
> workaround "touch ntpd/ntpd.1 util/ntp-keygen.1", which prevents
> autogen from rebuilding the man pages. If you are patching other
> autogen files in the ntp code, you'll need to update the autogen
> package or similarly touch the other man pages.

Thanks for the info.

I found the touch commands in the first F20 ntp SRPM and that got the rpmbuild 
working.

Barry

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Discontinued Packing of NetBeans IDE

2013-11-05 Thread Stanislav Ochotnicky

Quoting Rahul Sundaram (2013-11-05 17:46:55)
>  Hi
> 
> 
> On Tue, Nov 5, 2013 at 11:45 AM, Manuel Faux  wrote:
> 
> > Is it correct that the NetBeans IDE is currently not packed for Fedora? I
> > checked the "netbeans" package, which was last built for fc17.
> > Is there any technical or license reason for this or is just nobody
> > packing it right now?
> >
> 
> Someone from Sun used to be the maintainer and noone is doing it right
> now.  No technical or licensing issues if anyone is interested in packaging
> it afaik.

More specifically look at:

https://lists.fedoraproject.org/pipermail/java-devel/2010-November/003980.html

Reason nobody picked it up is that is has relatively big dependency chain and
there was nobody interested enough (from maintainer perspective). Most Java
packages are in Fedora because they are dependencies of following packages:

* Tomcat
* Maven
* Eclipse
* WildFly
* (new) Big Data SIG stuff
* and of course a few more apps here and there

-- 
Stanislav Ochotnicky 
Software Engineer - Developer Experience

PGP: 7B087241
Red Hat Inc.   http://cz.redhat.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Discontinued Packing of NetBeans IDE

2013-11-05 Thread Nathanael D. Noblet


On 11/05/2013 09:46 AM, Rahul Sundaram wrote:

Someone from Sun used to be the maintainer and noone is doing it right
now.  No technical or licensing issues if anyone is interested in
packaging it afaik.


I've been loving using netbeans however I've been using the upstream 
package.. I looked into the original package but the spec file is so 
complicated and I have no idea how java programs are packagaed so shied 
away. If someone else thinks collectively we could bring it back up to a 
recent version. I'd be delighted to co-maintain it.



--
Nathanael d. Noblet
t 403.875.4613
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Discontinued Packing of NetBeans IDE

2013-11-05 Thread Rahul Sundaram

 Hi

On Tue, Nov 5, 2013 at 11:45 AM, Manuel Faux  wrote:

> Is it correct that the NetBeans IDE is currently not packed for Fedora? I
> checked the "netbeans" package, which was last built for fc17.
> Is there any technical or license reason for this or is just nobody
> packing it right now?
>

Someone from Sun used to be the maintainer and noone is doing it right
now.  No technical or licensing issues if anyone is interested in packaging
it afaik.

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Discontinued Packing of NetBeans IDE

2013-11-05 Thread Manuel Faux

Is it correct that the NetBeans IDE is currently not packed for Fedora? I 
checked the "netbeans" package, which was last built for fc17.
Is there any technical or license reason for this or is just nobody packing it 
right now?

--ManuelFaux
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

2013-11-05 Thread Matthias Clasen

On Tue, 2013-11-05 at 12:35 +0100, Nicolas Mailhot wrote:
> Le Lun 4 novembre 2013 23:02, Nicolas Mailhot a écrit :
> 
> > The problem is not to get code in the hands of developers. You don't need
> > distros for that. The problem is to get the code to end-users and
> > developers spend more time fighting the constrains it involves than trying
> > to understand this problem-space.
> >
> > Of course the aim might not be to reach end users but to push code from
> > developpers to other developers.
> 
> And if that is the case, there is a huge disconnect between GNOME goals
> and Fedora Workstation goals. GNOME speakers repeat all year round their
> software is not aimed at "power users", but developers are the über power
> user.

Why do you think the two sets of goals have to be one and the same ?

The Fedora Workstation effort (not a great name, by the way), is brand
new, and its goals have only just been drafted. How could the goals that
GNOME has followed in the past 3 years be perfectly align with it ? And
why should they, for that matter ? This is not a GNOME project, it is
about saving Fedora.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Test-Announce] Printing Test Day today (Tuesday 2013-11-05)

2013-11-05 Thread Kamil Paral

The Printing Test Day for Fedora 20 is today.

https://fedoraproject.org/wiki/Test_Day:2013-11-05_Printing

This test day is for testing all aspects of printing, including setting
up the printer, sharing printers on the network, and printing jobs.

The changes in Fedora 20 are relatively minor: switching to CUPS 1.7 and
Ghostscript 9.10, and some improvements to cups-filters and the
"Printers" part of GNOME Settings.

Remember that CUPS unit testing is only one small part of the story:
printing is very much in need of integration testing. Try printing with
different applications, using options you don't normally use in the
print dialog. Try to see how many different ways you can break it!

If you have access to a printer and a machine running Fedora 20 (a live
CD is fine), please join in! We'll be on IRC at the usual place:

irc://irc.freenode.net/fedora-test-day

Tim.
*/
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

2013-11-05 Thread Reindl Harald

Am 05.11.2013 17:22, schrieb Miloslav Trmač:
> Look at all the software that has been written for GTK1 and obsolete
> libraries that hasn't been ported and therefore no longer runs on
> Fedora.  Wouldn't it have been nice to continue to have a practical
> option to use that software, even if it doesn't integrate that well
> and it no longer has an active maintainer?

no because exactly that is terrible from security point of view
this means unmaintained code careless in the distribution

you can be pretty sure that in the case bad tings happening later
Fedora as distribution and Linux at all will be made responsible
for such bad behavior "look they have the same troubles and no
longer more secure than OSX and Windows"



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: gtk3 broken/missing icons on kde

On Tuesday, November 5, 2013, Matthias Clasen wrote:

> On Tue, 2013-11-05 at 08:23 +0100, drago01 wrote:
> > On Tue, Nov 5, 2013 at 3:03 AM, Adam Williamson 
> > >
> wrote:
> > > On Sun, 2013-10-27 at 01:46 +0200, Kevin Kofler wrote:
> > >> Adam Williamson wrote:
> > >> > I don't think we'd really be correct in blocking the release for
> such
> > >> > issues - especially not Beta. We used to have 'polish' criteria for
> > >> > Final which at least required the icons used in the system menus -
> i.e.
> > >> > what's specified in the app's .desktop file - to be sane for all
> > >> > installed applications, but we dropped that (and other polish
> criteria)
> > >> > with the F19/F20 criteria re-write on the basis that they were
> really
> > >> > stretching a bit too far and would be unlikely to hold up to a 'last
> > >> > blocker before release' acid test. Stuff like this doesn't break
> > >> > anyone's use of the system catastrophically and can reasonably be
> fixed
> > >> > with updates.
> > >>
> > >> But it also affects the live images (making them look very
> unpolished) and
> > >> we don't respin those.
> > >
> > > That's why I said 'reasonably' not 'perfectly' :) I can see an argument
> > > for blocking Final, though in practice, I don't think our current
> > > standards are such that it really makes sense to claim our final
> > > releases are so smooth as to be worth enforcing a high standard of
> > > polish via the blocker mechanisms
> >
> > Then we should that. There is a difference between "perfect" and
> something that
> > looks obviously broken.
>
> Are we really fighting about the classification of fixed bugs here,
>

Yes ;)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

2013-11-05 Thread Miloslav Trmač

On Sat, Nov 2, 2013 at 5:20 PM, Kevin Kofler  wrote:
> I think it is a very bad idea to try to explicitly and officially support
> third-party software, especially proprietary third-party software.

The thing is, making third-party software easier to maintain and
deploy will in the vast majority of causes also make in-distribution
software easier to maintain and deploy.  And being actively hostile to
third-party software, feeling free to break APIs and ABIs because Open
Source can in theory adapt, and, in the extreme, celebrating actions
that are hostile to third-party software, often ends up to also being
hostile to in-distribution software with limited number of interested
contributors.

Look at all the software that has been written for GTK1 and obsolete
libraries that hasn't been ported and therefore no longer runs on
Fedora.  Wouldn't it have been nice to continue to have a practical
option to use that software, even if it doesn't integrate that well
and it no longer has an active maintainer?
 Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: gtk3 broken/missing icons on kde

2013-11-05 Thread Matthias Clasen

On Tue, 2013-11-05 at 08:23 +0100, drago01 wrote:
> On Tue, Nov 5, 2013 at 3:03 AM, Adam Williamson  wrote:
> > On Sun, 2013-10-27 at 01:46 +0200, Kevin Kofler wrote:
> >> Adam Williamson wrote:
> >> > I don't think we'd really be correct in blocking the release for such
> >> > issues - especially not Beta. We used to have 'polish' criteria for
> >> > Final which at least required the icons used in the system menus - i.e.
> >> > what's specified in the app's .desktop file - to be sane for all
> >> > installed applications, but we dropped that (and other polish criteria)
> >> > with the F19/F20 criteria re-write on the basis that they were really
> >> > stretching a bit too far and would be unlikely to hold up to a 'last
> >> > blocker before release' acid test. Stuff like this doesn't break
> >> > anyone's use of the system catastrophically and can reasonably be fixed
> >> > with updates.
> >>
> >> But it also affects the live images (making them look very unpolished) and
> >> we don't respin those.
> >
> > That's why I said 'reasonably' not 'perfectly' :) I can see an argument
> > for blocking Final, though in practice, I don't think our current
> > standards are such that it really makes sense to claim our final
> > releases are so smooth as to be worth enforcing a high standard of
> > polish via the blocker mechanisms
> 
> Then we should that. There is a difference between "perfect" and something 
> that
> looks obviously broken.

Are we really fighting about the classification of fixed bugs here, or
is there a new issue that I am not aware of ?

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

2013-11-05 Thread Christian Schaller

Hi Ryan,
I been discussing the possibilities of doing some surveys with Langdon White, 
so hopefully yes.
We just need to rustle up the budget first :)

Christian

- Original Message -
From: "Ryan Lerch" 
To: "Discussions about development for the Fedora desktop" 
, devel@lists.fedoraproject.org
Sent: Monday, November 4, 2013 11:14:21 AM
Subject: Re: Draft Product Description for Fedora Workstation

On 01/11/13 10:24, Christian Fredrik Kalager Schaller wrote: 

Hi everyone,
Attached is the draft PRD for the Workstation working group. The
proposal tries to be relatively high level and focus on goals and
principles, but I have included some concrete examples at times to try
to provide some clarity on how the goals and principles could play out
in practice.

I hope the community at large will take the time to read through it and
provide feedback so that when the working group meet next we can use
that feedback to start tuning in on the final form of the PRD.

Also in the name of openness, before I sent this here, I showed the PRD
draft to key stakeholders and decision makers inside Red Hat, to ensure
that we have the necessary support for these plans to get the kind of
engineering resources allocated from Red Hat we will need to pull this
off. 

Sincerely,
Christian F.K. Schaller

P.S. I am celebrating both our wedding anniversary and my wifes birthday
this weekend so I will not be able to be online a lot. That said I will
make the time to go online to check my email from time to time so that I
can respond to any questions that has come in, just don't expect
immediate answers from me this weekend :) 

Although i am not sure if the PRD is the place for it, But should we also think 
about conducting 
some user surveys to help define our target audience further? Also, some User 
testing on what 
we have already would also be useful for a baseline to check against in the 
future when we start 
implementing changes. 

cheers, 
ryanlerch 

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[perl-Test-Simple] Created tag perl-Test-Simple-1.001002-1.fc21

2013-11-05 Thread Paul Howarth

The lightweight tag 'perl-Test-Simple-1.001002-1.fc21' was created pointing to:

 dd82ca2... Update to 1.001002
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Test-Simple] Created tag perl-Test-Simple-1.001002-1.fc20

2013-11-05 Thread Paul Howarth

The lightweight tag 'perl-Test-Simple-1.001002-1.fc20' was created pointing to:

 dd82ca2... Update to 1.001002
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Test-Simple/f20] Update to 1.001002

2013-11-05 Thread Paul Howarth

Summary of changes:

  dd82ca2... Update to 1.001002 (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Module-Build] 0.4008 bump

2013-11-05 Thread Jitka Plesnikova

commit 7842d063cfab19f636149dbe69bf86ca062ce41a
Author: Jitka Plesnikova 
Date:   Tue Nov 5 16:37:13 2013 +0100

0.4008 bump

 .gitignore |1 +
 perl-Module-Build.spec |7 +--
 sources|2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 24abc28..b88c003 100644
--- a/.gitignore
+++ b/.gitignore
@@ -9,3 +9,4 @@ Module-Build-0.2808.tar.gz
 /Module-Build-0.4004.tar.gz
 /Module-Build-0.4005.tar.gz
 /Module-Build-0.4007.tar.gz
+/Module-Build-0.4008.tar.gz
diff --git a/perl-Module-Build.spec b/perl-Module-Build.spec
index 5f235c8..2830fae 100644
--- a/perl-Module-Build.spec
+++ b/perl-Module-Build.spec
@@ -1,11 +1,11 @@
 %global cpan_version_major 0.40
-%global cpan_version_minor 07
+%global cpan_version_minor 08
 %global cpan_version %{cpan_version_major}%{?cpan_version_minor}
 
 Name:   perl-Module-Build
 Epoch:  2
 Version:
%{cpan_version_major}%{?cpan_version_minor:.%cpan_version_minor}
-Release:3%{?dist}
+Release:1%{?dist}
 Summary:Build and install Perl modules
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -123,6 +123,9 @@ LANG=C TEST_SIGNATURE=1 MB_TEST_EXPERIMENTAL=1 ./Build test
 %{_mandir}/man3/*
 
 %changelog
+* Tue Nov 05 2013 Jitka Plesnikova  - 2:0.40.08-1
+- 0.4008 bump
+
 * Wed Aug 14 2013 Jitka Plesnikova  - 2:0.40.07-3
 - Perl 5.18 re-rebuild of bootstrapped packages
 
diff --git a/sources b/sources
index 957405c..e07fd09 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-d589909669f3c3e8ace554f00eb815a1  Module-Build-0.4007.tar.gz
+01675c01f6a42c528d02dc34cc5383bf  Module-Build-0.4008.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Draft Product Description for Fedora Workstation

2013-11-05 Thread Christian Schaller

The term 'Power user' is not meaningless if you use it to refer to users of
Fedora on IBM Power architecture ;)

But apart from that I do agree that the term as generally used doesn't provide 
a very clear target for development.

Christian


- Original Message -
> From: "drago01" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Tuesday, November 5, 2013 6:53:15 AM
> Subject: Re: Draft Product Description for Fedora Workstation
> 
> On Tue, Nov 5, 2013 at 12:35 PM, Nicolas Mailhot
>  wrote:
> >
> > Le Lun 4 novembre 2013 23:02, Nicolas Mailhot a écrit :
> >
> >> The problem is not to get code in the hands of developers. You don't need
> >> distros for that. The problem is to get the code to end-users and
> >> developers spend more time fighting the constrains it involves than trying
> >> to understand this problem-space.
> >>
> >> Of course the aim might not be to reach end users but to push code from
> >> developpers to other developers.
> >
> > And if that is the case, there is a huge disconnect between GNOME goals
> > and Fedora Workstation goals. GNOME speakers repeat all year round their
> > software is not aimed at "power users", but developers are the über power
> > user.
> 
> Depends on what you mean by "power user" (I hate this meaningless
> term) if it means "software developer" then
> yes. If it means "someone that spends his whole day in config dialogs" then
> no.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Workstation WG Governance Charter

On Tue, Nov 5, 2013 at 9:51 AM, Miloslav Trmač  wrote:
> On Mon, Nov 4, 2013 at 6:57 PM, Owen Taylor  wrote:
>> On Wed, 2013-10-30 at 15:22 -0400, Josh Boyer wrote:
>>> On Wed, Oct 30, 2013 at 3:16 PM, Ray Strode  wrote:
>>> > Hi,
>>> >
>>> > On Wed, Oct 30, 2013 at 9:01 AM, Josh Boyer  
>>> > wrote:
>>> >> The other positions will be filled by general election
>>> >> every two years. As a special exception, four seats will be filled in
>>> >> one year, with those positions chosen at random (unless some number of
>>> >> members decide to step down). Voting will follow the standard Fedora
>>> >> election process and be open to all contributors in the CLA+1 group.
>>> >>
>>> >> In the event that a current member relinquishes their seat, that seat
>>> >> will be filled by the first runner up in the previous election.  If
>>> >> that person is not able or willing to fill the seat, it will go to
>>> >> each successive runner up until the seat is filled.
>>> >
>>> > I think, I personally, would rather see the previous working group
>>> > decide new members of the working group.  They're the ones doing the
>>> > work, so they should get the most say in the direction the work goes.
>>> > (the whole "fedora is a meritocracy not a democracy" thing).
>>> >
>>> > Put another way: I don't think someone who works on desktop related
>>> > software should have much say in who gets to be put in the cloud
>>> > working group, or vice-versa.
>>> >
>>> > Let the people already doing the work decide the continuing direction
>>> > of the work.
>>> > If things really get off course, fesco can intervene, but I don't
>>> > think that will happen.
>>>
>>> Fair.  To be honest, the more I think about it the more I dislike the
>>> idea of doing full blown elections.  They seem overkill and cumbersome
>>> when it comes to coordinating, etc.
>>
>> I strongly support this view - the end result of having too many
>> elections is that only a tiny fraction of people have the attention to
>> understand what is going on and vote.
>
> Repeating myself from the server list:
>
> I don't think long serving terms, and especially indefinite serving
> terms, are healthy: there should be an easy way for the community to
> self-correct without requiring extraordinary effort like finding a
> thick-skinned "opposition leader" to set up a recall election or the
> like.

Isn't that something that's addressed by FESCo oversight here?

> AFAICT unlike (Czech and US at least) national governments, the Fedora
> elections have always had very low overhead and basically no campaign
> / pre-election posturing seasons disruptive to the project; there
> hasn't been much election-related burden to speak of.

It's not necessarily about burden, though I think there is some burden
here.  It's mostly about the voting body either having no idea who to
pick because they aren't participating in this area, or being entirely
indifferent and not voting for the same reasons.  Coordinating a full
election for the WG seems overkill.

>> It also seems problematical to
>> have a elected working group that falls under the supervision of FESCO
>> which is also elected. What if FESCO and the group disagree?
> This can just as well happen with a non-elected group.

Yes.  I don't think the WG can change this itself anyway.  The WGs are
under the supervision (used very loosely here) of FESCo.

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Workstation WG Governance Charter

2013-11-05 Thread Miloslav Trmač

On Mon, Nov 4, 2013 at 6:57 PM, Owen Taylor  wrote:
> On Wed, 2013-10-30 at 15:22 -0400, Josh Boyer wrote:
>> On Wed, Oct 30, 2013 at 3:16 PM, Ray Strode  wrote:
>> > Hi,
>> >
>> > On Wed, Oct 30, 2013 at 9:01 AM, Josh Boyer  
>> > wrote:
>> >> The other positions will be filled by general election
>> >> every two years. As a special exception, four seats will be filled in
>> >> one year, with those positions chosen at random (unless some number of
>> >> members decide to step down). Voting will follow the standard Fedora
>> >> election process and be open to all contributors in the CLA+1 group.
>> >>
>> >> In the event that a current member relinquishes their seat, that seat
>> >> will be filled by the first runner up in the previous election.  If
>> >> that person is not able or willing to fill the seat, it will go to
>> >> each successive runner up until the seat is filled.
>> >
>> > I think, I personally, would rather see the previous working group
>> > decide new members of the working group.  They're the ones doing the
>> > work, so they should get the most say in the direction the work goes.
>> > (the whole "fedora is a meritocracy not a democracy" thing).
>> >
>> > Put another way: I don't think someone who works on desktop related
>> > software should have much say in who gets to be put in the cloud
>> > working group, or vice-versa.
>> >
>> > Let the people already doing the work decide the continuing direction
>> > of the work.
>> > If things really get off course, fesco can intervene, but I don't
>> > think that will happen.
>>
>> Fair.  To be honest, the more I think about it the more I dislike the
>> idea of doing full blown elections.  They seem overkill and cumbersome
>> when it comes to coordinating, etc.
>
> I strongly support this view - the end result of having too many
> elections is that only a tiny fraction of people have the attention to
> understand what is going on and vote.

Repeating myself from the server list:

I don't think long serving terms, and especially indefinite serving
terms, are healthy: there should be an easy way for the community to
self-correct without requiring extraordinary effort like finding a
thick-skinned "opposition leader" to set up a recall election or the
like.

AFAICT unlike (Czech and US at least) national governments, the Fedora
elections have always had very low overhead and basically no campaign
/ pre-election posturing seasons disruptive to the project; there
hasn't been much election-related burden to speak of.

> It also seems problematical to
> have a elected working group that falls under the supervision of FESCO
> which is also elected. What if FESCO and the group disagree?
This can just as well happen with a non-elected group.
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Packaging Python 3.4.0

2013-11-05 Thread Toshio Kuratomi

On Tue, Nov 05, 2013 at 07:29:35AM -0500, Bohuslav Kabrda wrote:
> Hi all,
> I started working on updating python3 to 3.4.0. So far, this is only in
> a private branch "python3.4" in dist-git, since I'll need to get a Change
> approved for Fedora 21. I already created the Change [1], but I was told
> that it will get on FESCo schedule when Fedora 21 schedule and future is
> more clear, so for now I'll just work on Python 3.4.0.
>
Hmmm Putting on a fesco hat, I would be more than willing to approve
changes for F21 now We've already approved Python3 as Default which has
both F21 and F22 goals.

I think that the F21 Schedule and Product desciptions are somewhat
orthogonal to some features including this.  The things I'm looking at that
imply that are:

* Something that either is non-specific to one of our products
* Something that is an upgrade of packages already in Fedora

So in my view -- submit the Change! :-)

> When Python 3.4.0 reaches beta1 (which means feature freeze, which also
> means that the bytecode format should no longer change) - November 24 [2]
> - I plan to create a repo in Copr so that everyone has access to built
> RPMs, and also I want to start rebuilding as many packages as possible to
> see how they work with Python 3.4.
>
 The rebuilding make me want to get this into the main repos early.

> As for the current state of Python 3.4 in the dist-git branch:
> - It still seems a bit unclear what upstream will do with the sha3
>   implementation (although they will probably keep it), so I didn't rebase
>   the fips patch yet, there is still plenty of time for that.

I think Christian outlined what they are going to do with sha3 yesterday
(but yeah, it depends on what is happening with the sha3 standard so there's
a bit of uncertainty there still).

> - pep453 [3] (pip bootstraping) hasn't been implemented yet. The pep also
>   contains recommendation for distro packagers, so here's what we should do.
> -- Make a circular dependency between python3 and python3-pip (ugly, will
>require bootstraping with every new Python minor version).
>
Do you mean minor version as in the "4" in 3.4 or as in the micro level ("0"
in 3.4.0)?

We can get around bootstrapping at minor version revs if pip is only used at
runtime, not at buildtime.

We can still get around bootstrapping at micro version if we are careful
never to include pip's code in the package.  Only figure out where to find
pip's code.

> -- Definitely delete bundled CA certificates and use system certificates
>instead.

+1

> -- Maybe remove the bundled pip (although this goes against the pep) and
> use python3-pip. E.g. everything would work as expected, but under the
> wraps, python3-pip package would be used. So when doing security updates,
> we'd just fix python3-pip. It is however true that if Fedora's pip would
> be different from the upstream bundled one, users may experience some
> behaviour differencies. I'd like to hear your opinions on how we should
> approach this.
>
We should definitely do this.  pip itself bundles code that we've had to
unbundle locally -- maintaining that morass of software again (it's also
bundled inside of virtualenv...) is going to lead to a lot of work anytime
an update needs to happen.

However, talking with ncoghlan it may not be simple.  The case that makes
things tricky is pyvenv.  Upstream python wants to protect venv's from
changes to code on the system.  ie: if a user installs a backwards
incompatible pip on the system, that should not affect the pip inside the
existing venvs.  Equally, if there are security issues found with pip, those
changes would not be propogated to the pip inside the venvs.

ncoghlan proposed that we create wheels in the pip package (and all the
packages that pip bundles that we have to unbundle) and then when ensurepip
installs into a venv, it copies those wheels in there.

I'm wondering if we could do a little better.  Instead of keeping around two
copies of all this software on the system, if we can reconstruct a wheel zip
(or possibly just copy the files in) from the wheel metadata and files on
the system.   I know that sysadmins and developers will hotfix software on
the system for issues that they care about.  Having those changes propogate
to newly installed venvs seems like a better plan than having the venvs get
the old copies that were built at rpm build time.

-Toshio

pgpQBZ2fP8GGy.pgp
Description: PGP signature
___
python-devel mailing list
python-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: Source file audit - 2013-09-30

2013-11-05 Thread Patrick Monnerat

 
Kevin Fenzi wrote:



monnerat:BADURL:openca-ocspd-1.5.1-rc1.tar.gz:ocspd


The URL is not available anymore.
I've just packaged 1.9.0 for rawhide/f20/f19/f18. It is not the latest
version, but it's the latest that doesn't use libpki. I've submitted a
review request for this library, but nobody was interested in reviewing
(https://bugzilla.redhat.com/show_bug.cgi?id=723575). When I discovered
that this library was flawn with a lot of memory leakage bugs, I retired
the request.
Source for version 1.9.0 is still downloadable.


monnerat:BADURL:Synchro-PHPMailer-4d9434e-5.2.6.tar.gz:php-PHPMailer


Works for me.

Regards,
Patrick

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora 20-Beta RC3 AMIS

2013-11-05 Thread Dennis Gilmore

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

hi all,

Beta RC2 images have been uploaded to EC2 and are available at 

ami-afcc94c6 : us-east-1 image for i386
ami-a5cd95cc : us-east-1 image for x86_64

additionally if your looking to the AMI's they have been added to files
in the release tree
http://dl.fedoraproject.org/pub/alt/stage/20-Beta-RC3/Images/i386/Fedora-Images-i386-20-Beta-AMI
http://dl.fedoraproject.org/pub/alt/stage/20-Beta-RC3/Images/x86_64/Fedora-Images-x86_64-20-Beta-AMI

when we get to final Beta and the images are uploaded to all regions
they will all be listed and the file will be gpg signed in the final
tree

Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJSePznAAoJEH7ltONmPFDRZUMP/0OKQWw6gAUfoZF9Npxr/cUv
bpy72rO8diw6gnP75DREvNpIBv+0Ud3EjSqgz58ZLRt8EVRBufNFAVHa4yqgaPUj
IKkNcm6+INOY5xEDDblxzTduvJaeW5hv0y8cAirIgN63Yz3TEfFa1PV05bdb7Gnx
NJ0qdaSRkDnXJ6RwIe0CIH7VSlUsw2atBVBw3vZPeXZ/RJALyDDBwJXxlrvgoM5h
zuk4x8c960FHGplSd3h2bvYo9+weapcA10Jc+78j8qQoHzTLPtg6G18Yoqs/EFq8
TDR/zdogw2bFQfgsaBPEVpfAs0tnrUo0bHrp8ojQTXpKXOlZmvzVk23x903v9LsT
SsgnpvoCs4u/n0dMKzF10uw7MgpZBY9BIPTumnKg+/+iCqhcjKzJy1uOnFVeG8UT
DeyuI2NFZ18NM+iXqMPmMEWawiNys2p9JY3L5TiGEK5iJXuOaX5BXcXGhX1BOrai
t0YtlKRa3afYogMgzJmb2/ZLiV8fuvt40VbJ3Io+wJUHougMhGYMjivJd7dfmd7c
KHnlst54J00rnm9Ul47VvrYQg2HuFQEyuJA/uDy9qYMBInqGIQlfyGM7yM4lMt8V
pPZ6gMi0EbTbnRh1t0mf4J2TdzuPj7wODk1zZ1PzY54mIlCNr76bQ8a9aukz0dzJ
M6uLJmRzUTom0Az+r3Pa
=6Hha
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Test-Announce] Fedora 20 Beta Release Candidate 3 (RC3) Available Now!

2013-11-05 Thread Andre Robatino

NOTE: The 64-bit Desktop Live, and the 32- and 64-bit Security Spins are
over their respective size targets.

As per the Fedora 20 schedule [1], Fedora 20 Beta Release Candidate 3
(RC3) is now available for testing. Content information, including
changes, can be found at
https://fedorahosted.org/rel-eng/ticket/5787#comment:24 . Please see the
following pages for download links (including delta ISOs) and testing
instructions. Normally dl.fedoraproject.org should provide the fastest
download, but download-ib01.fedoraproject.org is available as a mirror
(with an approximately 1 hour lag) in case of trouble. To use it, just
replace "dl" with "download-ib01" in the download URL.

Installation:

https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test

Base:

https://fedoraproject.org/wiki/Test_Results:Current_Base_Test

Desktop:

https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test

Ideally, all Alpha and Beta priority test cases for Installation [2],
Base [3], and Desktop [4] should pass in order to meet the Beta Release
Criteria [5]. Help is available on #fedora-qa on irc.freenode.net [6],
or on the test list [7].

Create Fedora 20 Beta test compose (TC) and release candidate (RC)
https://fedorahosted.org/rel-eng/ticket/5787

Current Blocker and Freeze Exception bugs:
http://qa.fedoraproject.org/blockerbugs/current

[1] http://fedorapeople.org/groups/schedule/f-20/f-20-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Installation_validation_testing
[3] https://fedoraproject.org/wiki/QA:Base_validation_testing
[4] https://fedoraproject.org/wiki/QA:Desktop_validation_testing
[5] https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria
[6] irc://irc.freenode.net/fedora-qa
[7] https://admin.fedoraproject.org/mailman/listinfo/test



signature.asc
Description: OpenPGP digital signature
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Bug 1026716] perl-Test-Reporter-1.60 is available

2013-11-05 Thread bugzilla

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



--- Comment #1 from Petr Pisar  ---
This is a bug-fixing release suitable for all Fedoras.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=gZL7bTRoGr&a=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Test-Reporter] 1.60 bump

2013-11-05 Thread Petr Pisar

commit 00647923a7b0a583abb8f1b9513d6d8d83ffd35c
Author: Petr Písař 
Date:   Tue Nov 5 14:37:26 2013 +0100

1.60 bump

 .gitignore  |1 +
 perl-Test-Reporter.spec |   11 +++
 sources |2 +-
 3 files changed, 9 insertions(+), 5 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 720b01c..b080b3b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
 /Test-Reporter-1.58.tar.gz
 /Test-Reporter-1.59.tar.gz
+/Test-Reporter-1.60.tar.gz
diff --git a/perl-Test-Reporter.spec b/perl-Test-Reporter.spec
index ba2262e..b8d2d2f 100644
--- a/perl-Test-Reporter.spec
+++ b/perl-Test-Reporter.spec
@@ -1,6 +1,6 @@
 Name:   perl-Test-Reporter
-Version:1.59
-Release:3%{?dist}
+Version:1.60
+Release:1%{?dist}
 Summary:Sends test results to cpan-test...@perl.org
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -8,7 +8,7 @@ URL:http://search.cpan.org/dist/Test-Reporter/
 Source0:
http://www.cpan.org/authors/id/D/DA/DAGOLDEN/Test-Reporter-%{version}.tar.gz
 BuildArch:  noarch
 BuildRequires:  perl
-BuildRequires:  perl(ExtUtils::MakeMaker)
+BuildRequires:  perl(ExtUtils::MakeMaker) >= 6.17
 BuildRequires:  perl(strict)
 BuildRequires:  perl(warnings)
 # Run-time:
@@ -57,11 +57,14 @@ find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} 
\;
 make test
 
 %files
-%doc Changes CONTRIBUTING COPYING LICENSE README
+%doc Changes CONTRIBUTING LICENSE README
 %{perl_vendorlib}/*
 %{_mandir}/man3/*
 
 %changelog
+* Tue Nov 05 2013 Petr Pisar  - 1.60-1
+- 1.60 bump
+
 * Sun Aug 04 2013 Fedora Release Engineering  
- 1.59-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
 
diff --git a/sources b/sources
index 5e98247..731484d 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-7b81be1fa634a8312775e1428b0adee5  Test-Reporter-1.59.tar.gz
+e36fc3c25a71b2ceba2ae21c6a2e02fc  Test-Reporter-1.60.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

File Test-Reporter-1.60.tar.gz uploaded to lookaside cache by ppisar

2013-11-05 Thread Petr Pisar

A file has been added to the lookaside cache for perl-Test-Reporter:

e36fc3c25a71b2ceba2ae21c6a2e02fc  Test-Reporter-1.60.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1026708] perl-IPC-Cmd-0.86 is available

2013-11-05 Thread bugzilla

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-IPC-Cmd-0.86-1.fc21
 Resolution|--- |RAWHIDE
Last Closed||2013-11-05 08:36:23



-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=lQPH81rskw&a=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Draft Product Description for Fedora Workstation

2013-11-05 Thread Simo Sorce

On Mon, 2013-11-04 at 18:19 +0100, Kevin Kofler wrote:
> Chris Murphy wrote:
> > Right, because that's a model for success that shouldn't be either
> > emulated or improved upon, it's better for each little fiefdom's paradise
> > to erect walls to ensure cross influence isn't happening.
> 
> Your insulting the Free Software community as a "fiefdom" really offends me.

Well Kevin, I normally agree with a lot of what you say, but if
"fiefdom" offends you, your pretense to decide for the users *really*
offends me.

I will not cite every passage here, but you keep complaining that
allowing a different distribution model somehow implicitly will cast
doom on Free Software.

First of all that is plain nonsense, the distribution model has nothing
to do with licenses and a Free software App store is no more proprietary
than a distribution specific repository, which in our case is exactly
the default "Fedora App Store" if you want.

But what I find terrible is that you want to make technical decisions
that *limit* users freedom, and this is *inexcusable*.

One of the most important things about freedom is to let the user be
*free*. Yes, to the point he can entrap himself. Our duty as Free
Software developers is to provide Free Software alternatives, not to
make life difficult for our users to try to force them in our own world
view, that's what totalitarianism is about.

Users will choose anyway, so the only thing you attain when trying to
put bars around a user is to have the users go away. Nobody likes cages
not even if they are made of Free Software bars.

> Hugely disruptive to your freedom, indeed… What's wrong with GIMP?

Yeah and what's wrong with the *actual* Freedom to choose what to use ?

We are not talking about distributing proprietary apps in fedora or
making them better than Free Software apps, so stop being stubborn and
look at the reality of things. Users want a better experience, and
upstreams are often in a position to do so, we just need to provide them
with the tools to do it w/o compromising the platform in the process.

A system that allows a user to install sandboxed[*] applications is
better than what we have now for some cases, and I see no reason why you
should be so upset about allowing a technical solution to a problem
users have whether you like what they are going to do with it or not.

Simo.

* and *ideally* I mean SELinux sanbdboxed with specific APIs that must
be used to interact with the rest of the system, so that the application
doesn't have free reign over users files.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Old kernels from FC19

2013-11-05 Thread Łukasz Trąbiński

Thank I will try this solution and i will try catch ooops from kernel.


2013/11/5 Björn Persson 

> Łukasz Trąbiński wrote:
> > when i boot machines with many ethernet devices I got
> > random number ethX. Once eth0 is eth0, after reboot eth0 is eth1.
> > After again boot eth1 is eth1 and so on.
>
> I had a problem like that, which began when I upgraded to Fedora 17. I
> worked around it by writing these Udev rules in a file
> named /etc/udev/rules.d/01-network-interface-naming.rules:
>
> ACTION=="add", SUBSYSTEM=="net", ATTR{address}=="00:0c:46:16:d0:bc",
> NAME:="world"
> ACTION=="add", SUBSYSTEM=="net", ATTR{address}=="00:1e:8c:cf:cd:e5",
> NAME:="gigabit"
> ACTION=="add", SUBSYSTEM=="net", ATTR{address}=="00:16:6f:a9:95:34",
> NAME:="wifi"
>
> --
> Björn Persson
>
> Sent from my computer.
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Packages have "proxy" word.

2013-11-05 Thread Richard W.M. Jones

On Fri, Nov 01, 2013 at 02:54:15PM +0100, Stanislav Ochotnicky wrote:
> Quoting Zbigniew Jędrzejewski-Szmek (2013-11-01 13:52:31)
> > On Fri, Nov 01, 2013 at 12:09:03PM +, Daniel P. Berrange wrote:
> > > On Fri, Nov 01, 2013 at 02:07:22AM +0100, Zbigniew Jędrzejewski-Szmek 
> > > wrote:
> > > > On Fri, Nov 01, 2013 at 01:08:33AM +0200, مصعب الزعبي wrote:
> > > > > بسم الله الرّحمن الرّحيم
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > The result of updating Fedora by yum is fail !!
> > > > > 
> > > > > When any package have "proxy" word marked to (install or update) , 
> > > > > error message will appear with http 403 error forbidden.
> > > > > 
> > > > > In my country Syria (maybe others) all URLs have "proxy" word are 
> > > > > forbidden and couldn't open by default way.
> > > > 
> > > > I think you'll have to use a... proxy to work around this problem.
> > > > Or maybe it'll be enough to use a https connection to the mirror.
> > > 
> > > NB, US export restrictions that Fedora is subject to mean users
> > > from Syria should not be downloading Fedora at all[1], via a proxy
> > > or not.
> > Let's consider how likely this export restriction is to prevent a
> > member of the Syrian government or military from obtaining a copy of
> > Fedora? Not very likely. How likely this export restriction is to hurt
> > a random person, e.g. trying to install open source to avoid
> > restrictions imposed by their government? The first is a joke, the
> > second is high enough to keep this restriction in the same contempt
> > as the Syrian government's ban on "proxy".
> 
> You are walking on thin ice and should stop immediately

He's right though.  The law as it applies to general purpose software
is stupid, immoral and counterproductive.  But it is the law, at least
in the United States and European Union[1].

Rich.

[1] http://ec.europa.eu/trade/policy/countries-and-regions/countries/syria/

-- 
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://people.redhat.com/~rjones/virt-top
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F-20 Branched report: 20131105 changes

2013-11-05 Thread Fedora Branched Report

Compose started at Tue Nov  5 09:15:06 UTC 2013

Broken deps for armhfp
--
[blueman]
blueman-1.23-7.fc20.armv7hl requires obex-data-server >= 0:0.4.3
blueman-1.23-7.fc20.armv7hl requires gvfs-obexftp
[bwm-ng]
bwm-ng-0.6-11.1.fc20.armv7hl requires libstatgrab.so.9
[cloud-init]
cloud-init-0.7.2-7.fc20.noarch requires dmidecode
[cobbler]
cobbler-2.4.0-2.fc20.noarch requires syslinux
[condor-wallaby]
condor-wallaby-client-5.0.3-4.fc20.noarch requires python-qmf >= 
0:0.9.1073306
[fts]
fts-server-3.1.1-1.fc20.armv7hl requires libactivemq-cpp.so.14
[glpi]
glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Version
glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Stdlib
glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-ServiceManager
glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Loader
glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-I18n
glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Cache-apc
glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Cache
[gnome-do-plugins]
gnome-do-plugins-thunderbird-0.8.4-14.fc20.armv7hl requires thunderbird
[gofer]
ruby-gofer-0.75-4.fc20.noarch requires rubygem(qpid) >= 0:0.16.0
[gradle]
gradle-1.0-18.fc20.noarch requires plexus-container-default
[grass]
grass-6.4.3-2.fc20.armv7hl requires libgeos-3.3.8.so
grass-libs-6.4.3-2.fc20.armv7hl requires libgeos-3.3.8.so
[gtkd]
gtkd-geany-tags-2.0.0-29.20120815git9ae9181.fc18.noarch requires gtkd = 
0:2.0.0-29.20120815git9ae9181.fc18
[kawa]
1:kawa-1.11-5.fc19.armv7hl requires servlet25
[koji]
koji-vm-1.8.0-2.fc20.noarch requires python-virtinst
[kyua-cli]
kyua-cli-0.5-3.fc19.armv7hl requires liblutok.so.0
kyua-cli-tests-0.5-3.fc19.armv7hl requires liblutok.so.0
[monotone]
monotone-1.0-11.fc19.armv7hl requires libbotan-1.8.2.so
perl-Monotone-1.0-11.fc19.armv7hl requires perl(:MODULE_COMPAT_5.16.2)
[mozilla-firetray]
mozilla-firetray-thunderbird-0.3.6-0.5.143svn.fc18.1.armv7hl requires 
thunderbird >= 0:11
[msp430-libc]
msp430-libc-20120224-2.fc19.noarch requires msp430-gcc >= 0:4.6.3
[nifti2dicom]
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtksys.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkWidgets.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkVolumeRendering.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkViews.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkTextAnalysis.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkRendering.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkParallel.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkInfovis.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkImaging.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkIO.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkHybrid.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGraphics.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGeovis.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGenericFiltering.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkFiltering.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCommon.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCharts.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libQVTK.so.5.10
[nocpulse-common]
nocpulse-common-2.2.7-2.fc20.noarch requires perl(RHN::DBI)
[openbox]
gdm-control-3.5.2-2.fc20.armv7hl requires gnome-panel
gnome-panel-control-3.5.2-2.fc20.armv7hl requires gnome-panel
[openpts]
openpts-0.2.6-7.fc20.armv7hl requires tboot
[osm2pgsql]
osm2pgsql-0.82.0-1.fc20.armv7hl requires libgeos-3.3.8.so
[oyranos]
oyranos-libs-0.4.0-7.fc19.armv7hl requires libraw.so.5
[perl-BerkeleyDB]
perl-BerkeleyDB-0.53-1.fc20.armv7hl requires libdb = 0:5.3.21
[perl-Language-Expr]
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
[perl-MIME-Lite-HTML]
perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires 
perl(:MODULE_COMPAT_5.16.0)
[perl-Padre]
perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0)
[pure]
pure-doc-0.57-4.fc20.noarch requires pure = 0:0.57-4.fc20
[python-tag]
python-tag-2013.1-1.fc20.armv7hl requires libboost_python.so.1.53.0
[rootplot]
rootplot-2.2.1-7.fc19.noarch requires root-python
[ruby-spqr]
ruby-spqr-0.3.6-7.fc20.noarch requires ruby-qpid-qmf
[rubygem-audited-activerecord]
rubygem-audited-activerecord-3.0.0-3.fc19.noarch requires 
rubygem(activerecord) < 0:4
[rubygem-fog]
rubygem-fog-1.11.1-1.fc20.noarch requires rubygem(nokogiri) < 0:1.6
[scala]
scala-2.9.2-2.fc19

Re: Draft Product Description for Fedora Workstation

2013-11-05 Thread Frank Murphy

On Tue, 5 Nov 2013 12:35:30 +0100
"Nicolas Mailhot"  wrote:

> And if that is the case, there is a huge disconnect between GNOME
> goals and Fedora Workstation goals. GNOME speakers repeat all year
> round their software is not aimed at "power users", but developers
> are the über power user.
> 

Not all developers use Gnome,
if they did, the other DEs' would not exist (within Fedora).

-- 
Regards,
Frank 
www.frankly3d.com

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

On Tue, Nov 5, 2013 at 12:58 PM, Frank Murphy  wrote:
> On Tue, 5 Nov 2013 12:53:15 +0100
> drago01  wrote:
>
>> Depends on what you mean by "power user" (I hate this meaningless
>> term) if it means "software developer" then
>> yes. If it means "someone that spends his whole day in config
>> dialogs" then no.
>
> Maybe?
> http://www.techterms.com/definition/poweruser

This is mostly about having powerful hardware, which our users have
the freedom to buy and run fedora on.
Since we build software and not hardware it does not matter much.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

2013-11-05 Thread Frank Murphy

On Tue, 5 Nov 2013 12:53:15 +0100
drago01  wrote:

> Depends on what you mean by "power user" (I hate this meaningless
> term) if it means "software developer" then
> yes. If it means "someone that spends his whole day in config
> dialogs" then no.

Maybe?
http://www.techterms.com/definition/poweruser

-- 
Regards,
Frank 
www.frankly3d.com

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

On Tue, Nov 5, 2013 at 6:35 AM, Nicolas Mailhot
 wrote:
>
> Le Lun 4 novembre 2013 23:02, Nicolas Mailhot a écrit :
>
>> The problem is not to get code in the hands of developers. You don't need
>> distros for that. The problem is to get the code to end-users and
>> developers spend more time fighting the constrains it involves than trying
>> to understand this problem-space.
>>
>> Of course the aim might not be to reach end users but to push code from
>> developpers to other developers.
>
> And if that is the case, there is a huge disconnect between GNOME goals
> and Fedora Workstation goals. GNOME speakers repeat all year round their
> software is not aimed at "power users", but developers are the über power
> user.

Fortunately, the WG can highlight the areas in whatever software they
choose that need to be modified to accomplish the WG's goals.  And due
to the wonderfulness of open source, Fedora can make those changes.
Work with whatever upstream is in question to see if there are changes
that can be done in a manner that benefit both.  Basically,
collaboration and compromise are going to be required.

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation