Outage: Build System - 2010-07-28 07:15 UTC

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

There will be an outage starting at 2010-07-28 07:15 UTC, which will
last approximately 48 hours.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d '2010-07-28 07:15 UTC'

Reason for outage: dist-git migration and Fedora 14 branching

Affected Services:

Buildsystem - http://koji.fedoraproject.org/
CVS / Source Control

Unaffected Services: All others

Ticket Link: N/A

Contact Information: Jesse Keating  or Oxf13 on IRC

Please join #fedora-admin in irc.freenode.net or respond to this email
to track the status of this outage.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxP1rcACgkQ4v2HLvE71NVOpwCgiXd2yra19vxTqo2qK6sDIHXL
AFUAoK9/j53MDD3BWsKDhpMBL2qCMB0E
=r/Hd
-END PGP SIGNATURE-
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Test-Announce] Fedora 14 Alpha Test Compose Validation Test ( 07/29 - 08/04 )

[He Rui]

Greetings Testers,

I'm happy to announce that validation test event against F-14 Alpha Test
Compose is coming! Similar with F-13, this time we planned testing of
both Installation Process[1] and Desktop functionality[2] to ensure that
they meet the F-14 Alpha Release Criteria[3].

Welcome everyone to come and join this event. Alpha TC images will be
provided around Jul 29th[4] at:

* http://serverbeach1.fedoraproject.org/pub/alt/stage/

Test results pages have been improved, please refer to them and follow
the instructions and execute test cases inside:

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

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


After you finish any test, please post your test results in the matrices
from the above links. If you encounter a defect, feel free to discuss
with it on IRC/Test List and file it in bugzilla if it's a bug. 

Please also be informed that another announcement will be sent out once
Alpha TC1 is available, stay tuned! 


Thanks,
Hurry


[1] https://fedoraproject.org/wiki/QA:Installation_validation_testing
[2] https://fedoraproject.org/wiki/QA:Desktop_validation_testing
[3] https://fedoraproject.org/wiki/Fedora_14_Alpha_Release_Criteria
[4]
http://poelstra.fedorapeople.org/schedules/f-14/f-14-quality-tasks.html

-- 
Contacts

Hurry
FAS Name: Rhe 
Timezone: UTC+8
TEL: 86-010-62608141
IRC nick: rhe #fedora-qa #fedora-zh

___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: KDE-SIG meeting report (30/2010)

[Jaroslav Reznik]

On Tuesday, July 27, 2010 07:46:48 pm Kevin Kofler wrote:
> Rahul Sundaram
wrote:
> > DeviceKit or udisks backend?
> 
> libudev / udisks / upower
actually. The original DeviceKit is dead. The
> name for the Solid backend
stuck, it should probably be renamed.

Yes, it should be renamed - which
name??? It's not DeviceKit anymore but now is there any common name for
udisks, upower etc... Or we can call the backend uSolid? ;-)

R.

>
Kevin Kofler

-- 
Jaroslav Řezník 
Software Engineer -
Base Operating Systems Brno

Office: +420 532 294 275
Mobile: +420 602 797
774
Red Hat, Inc.   http://cz.redhat.com/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

HowTo fix multi-module maven javadoc builds

[Stanislav Ochotnicky]

Hello, good news everyone! (sort of)

We recently updated maven to version 2.2.1 in rawhide (soon to be F14
branch) and with this update certain bugs/problems creeped in. I'd say
most are fixed now but update to javadoc plugin is causing maven
projects that have multiple modules to fail with something like this:

[ERROR] BUILD ERROR
[INFO] --
[INFO] Internal error in the plugin manager executing goal
'org.apache.maven.plugins:maven-javadoc-plugin:2.7:javadoc': Unable to
load the mojo 'org.apache.maven.plugins:maven-javadoc-plugin:2.7:javadoc'
in the plugin 'org.apache.maven.plugins:maven-javadoc-plugin'. A required
class is missing: org/apache/maven/shared/invoker/MavenInvocationException
org.apache.maven.shared.invoker.MavenInvocationException


Solution to this problem is to use javadoc:aggregate goal instead of
javadoc:javadoc. This adds the benefit of having single inter-linked
javadocs for all modules available. We will try to find real reason for
this problem later, but for now this is the best solution.

So I repeat:
 * Use javadoc:aggregate to generate javadocs for multiple-module maven
   projects

Thanks for tuning in,

-- 
Stanislav Ochotnicky 
Associate Software Engineer - Base Operating Systems Brno

PGP: 71A1677C
Red Hat Inc.   http://cz.redhat.com


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Can anyone contact Balint Christian (rezso)?

[Sven Lankes]

On Wed, Jul 21, 2010 at 02:31:19PM +0200, Sven Lankes wrote:

> Following the process
> https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
> Is someone able to get in touch with Christian Balint (rezso)?
> His last koji activity was on the 18th of March 2010. I sent a personal
> email on the 9th of June to which I got no reply.
> I've opened https://bugzilla.redhat.com/show_bug.cgi?id=611487 to track
> the AWOL procedure.

The above bug is now 3+ weeks old and it seems clear that rezso is
nonresponsive.

Can we please orphan his packages?:

packages with co-maintainers:

fet
gdal
grass 
iverilog
libdap
mapnik
mapserver
openlayers

packages without any co-maintainers:

tinyows
geos
proj
libgeotiff
mapbender
ogdi

I would take over gdal and grass if nobody else steps forward to do so
(I'd rather have someone with more knowledge in the field of gis be the
maintainer).

-- 
sven === jabber/xmpp: s...@lankes.net
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 14 branching and dist-git roll out

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/23/2010 11:54 PM, Jesse Keating wrote:
> The conversion will take a couple days, which means our normal short
> outage for branching will be a bit extended.  I wish there was another
> way, but converting over 9K cvs repos into git repos does take some
> time.  I really feel that this move is worth the extended outage.

The conversion process has begun.  We have just over 10K repos to
convert, and nearly 200 are done already.  I'm employing a second host
to help conversion to cut down on the over all outage time.

I was not able to get a fedpkg (fedora-packager) build out today,
however as soon as that repo is converted and we get the koji changes in
place to build from git we will use that as a test build and get the
updated fedpkg into your hands.

I've also started on some wiki work to change some CVS pages, but much
more will come.  Any help here is appreciated.

Thanks again for your patience!

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxP9eMACgkQ4v2HLvE71NV6jQCfRCSkB2BCvGchCVL7n2izoze6
L1oAniHdh0NNUc4c58Qh2mkr1XSUq0s0
=ZnFm
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

selinux issue with wine

[Ankur Sinha]

hi,

I've recently come across an selinux issue.

Is this another selinux issue with the package? 

(I don't want to switch off selinux.)

regards,
Ankur


> 
> Summary:
> 
> SELinux has prevented wine from performing an unsafe memory operation.
> 
> Detailed Description:
> 
> SELinux denied an operation requested by wine-preloader, a program used to run
> Windows applications under Linux. This program is known to use an unsafe
> operation on system memory but so are a number of malware/exploit programs 
> which
> masquerade as wine. If you were attempting to run a Windows program your only
> choices are to allow this operation and reduce your system security against 
> such
> malware or to refrain from running Windows applications under Linux. If you 
> were
> not attempting to run a Windows application this indicates you are likely 
> being
> attacked by some for of malware or program trying to exploit your system for
> nefarious purposes. Please refer to
> http://wiki.winehq.org/PreloaderPageZeroProblem Which outlines the other
> problems wine encounters due to its unsafe use of memory and solutions to 
> those
> problems.
> 
> Allowing Access:
> 
> If you decide to continue to run the program in question you will need to 
> allow
> this operation. This can be done on the command line by executing: # setsebool
> -P mmap_low_allowed 1
> 
> Fix Command:
> 
> /usr/sbin/setsebool -P mmap_low_allowed 1
> 
> Additional Information:
> 
> Source Contextunconfined_u:unconfined_r:wine_t:s0-s0:c0.c1023
> Target Contextunconfined_u:unconfined_r:wine_t:s0-s0:c0.c1023
> Target ObjectsNone [ memprotect ]
> Sourcewine-preloader
> Source Path   /usr/bin/wine-preloader
> Port  
> Host  localhost.localdomain
> Source RPM Packages   wine-core-1.2.0-1.fc13
> Target RPM Packages   
> Policy RPMselinux-policy-3.7.19-39.fc13
> Selinux Enabled   True
> Policy Type   targeted
> Enforcing ModeEnforcing
> Plugin Name   wine
> Host Name localhost.localdomain
> Platform  Linux localhost.localdomain
>   2.6.33.6-147.fc13.x86_64 #1 SMP Tue Jul 6 
> 22:32:17
>   UTC 2010 x86_64 x86_64
> Alert Count   7
> First SeenWed 28 Jul 2010 14:52:13 IST
> Last Seen Wed 28 Jul 2010 15:05:01 IST
> Local ID  31ffc502-0121-44b8-8cf1-5e02ad32fca1
> Line Numbers  
> 
> Raw Audit Messages
> 
> node=localhost.localdomain type=AVC msg=audit(1280309701.355:60): avc:  
> denied  { mmap_zero } for  pid=11268 comm="wine-preloader" 
> scontext=unconfined_u:unconfined_r:wine_t:s0-s0:c0.c1023 
> tcontext=unconfined_u:unconfined_r:wine_t:s0-s0:c0.c1023 tclass=memprotect
> 
> node=localhost.localdomain type=SYSCALL msg=audit(1280309701.355:60): 
> arch=4003 syscall=90 success=no exit=-13 a0=ffe19130 a1=0 a2=ffe19130 
> a3=5a items=0 ppid=11109 pid=11268 auid=500 uid=500 gid=500 euid=500 suid=500 
> fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="wine-preloader" 
> exe="/usr/bin/wine-preloader" 
> subj=unconfined_u:unconfined_r:wine_t:s0-s0:c0.c1023 key=(null)
> 
> 

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

Re: [HEADS-UP] systemd is now the default init system in rawhide

[Lennart Poettering]

On Sat, 24.07.10 00:14, Casey Dahlin (cdah...@redhat.com) wrote:

> 
> On Fri, Jul 23, 2010 at 10:54:50PM -0500, Garrett Holmstrom wrote:
> > On 7/23/2010 20:26, Lennart Poettering wrote:
> > > - You can boot into either of them by setting the "init=" kernel cmdline
> > >option according to your wishes. If you pass "init=/bin/systemd" you
> > >will boot into systemd, if you pass "init=/sbin/upstart" you will boot
> > >into upstart (note the /sbin vs. /bin!)
> > 
> > Why is the systemd executable in /bin instead of /sbin?
> 
> Without looking too closely I believe systemd eventually seeks to replace
> things like gnome-session daemon. It has session management in mind as well as
> system.

Yes, this is the case. Normal users can and should start it and it might
even be invoked by scripts such as gnomerc or suchlike. On most
distributions (with the exception of Fedora) /sbin/ is not in $PATH and
hence the right place for the systemd binary is /bin/ and nothing else.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: selinux issue with wine

[Michael Schwendt]

On Wed, 28 Jul 2010 15:08:24 +0530, Ankur wrote:

> hi,
> 
> I've recently come across an selinux issue.
> 
> Is this another selinux issue with the package? 
> 
> (I don't want to switch off selinux.)

Why don't you comment on the stuff you've quoted? It has told you what
SELinux command you can run as a fix.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firefox 4 for Fedora 14?

[Brandon Lozza]

On Wed, Jul 28, 2010 at 2:57 AM, Nicu Buculei  wrote:
> On 07/28/2010 01:08 AM, Mike McGrath wrote:
>>> On 07/27/2010 10:53 PM, Rahul Sundaram wrote:

 Are we skipping Firefox 4 for Fedora 14?  Beta 2 has been released
 recently and I am wondering if we can go with it if it fits into the
 schedule.  There are dozens of new features including WebM support that
 would be nice to have.
>>
>> -1 didn't the last time we started using a pre-release from Mozilla turn
>> out pretty bad for us?
>
> That was Firefox 3.0 included as RC in Fedora 9, from an user
> perspective my memories about it are sweet... it was worse with
> Thunderbird 3, which was included in a release (F11) in Beta stage, and
> not even a late beta, it was something like Beta2, but AFAIK Firefox is
> expected to be RC around F14.
>
> And while Thunderbird 3 was included due to the slow development pace of
> the upstream (we used to have a very old Tb 2), Firefox 4 comes with at
> least a killer feature, WebM (IIRC, another killer feature is the new js
> engine)
>
> --
> nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>

Quite the contrary.

The Linux kernel is trademarked. Linus isn't a jerk and doesn't
prevent distros from patching it.

Mozilla's trademark requirements violate Freedom #2
The freedom to study how the program works, and change it to make it
do what you wish (freedom 1). Access to the source code is a
precondition for this.

We're NOT allowed to make changes (patches) without their permission.
This is defacto non-free. I understand we work with upstream but that
shouldn't prevent us from maintaining it.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firefox 4 for Fedora 14?

[Rahul Sundaram]

 On 07/28/2010 04:15 PM, Brandon Lozza wrote:
>
> We're NOT allowed to make changes (patches) without their permission.
> This is defacto non-free. I understand we work with upstream but that
> shouldn't prevent us from maintaining it.

We are maintaining it just fine.  Licensing is offtopic for this thread
and I recommend you talk to FSF and understand the view points on the
issue of trademark guidelines.

Rahul

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

Re: Firefox 4 for Fedora 14?

[Brandon Lozza]

On Wed, Jul 28, 2010 at 6:49 AM, Rahul Sundaram  wrote:
>  On 07/28/2010 04:15 PM, Brandon Lozza wrote:
>>
>> We're NOT allowed to make changes (patches) without their permission.
>> This is defacto non-free. I understand we work with upstream but that
>> shouldn't prevent us from maintaining it.
>
> We are maintaining it just fine.  Licensing is offtopic for this thread
> and I recommend you talk to FSF and understand the view points on the
> issue of trademark guidelines.
>
> Rahul
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>

The FSF drafted up the four freedoms and it's not offtopic, we're
discussing Firefox4 and the fact that we won't be able to make changes
to it to fix it without their permission.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firefox 4 for Fedora 14?

[Rahul Sundaram]

 On 07/28/2010 04:22 PM, Brandon Lozza wrote
> The FSF drafted up the four freedoms and it's not offtopic, we're
> discussing Firefox4 and the fact that we won't be able to make changes
> to it to fix it without their permission.

There is no specific non-upstream change that Firefox maintainers in
Fedora want to do and hence it is irrelevant to this thread which is
merely about integration of Firefox in Fedora 14 which requires no
patches. 

Rahul

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

Re: Firefox 4 for Fedora 14?

[drago01]

On Wed, Jul 28, 2010 at 12:52 PM, Brandon Lozza  wrote:

>
> The FSF drafted up the four freedoms and it's not offtopic, we're
> discussing Firefox4 and the fact that we won't be able to make changes
> to it to fix it without their permission.

You know that Fedora isn't any different or even worse right?
So complaining on how others protect their trademark while we do
essentially the same is kind of BS.

And btw. the four freedoms defined by the FSF do not require you to be
able to use a trademark without permission.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firefox 4 for Fedora 14?

[Haïkel Guémar]

Le 28/07/2010 12:45, Brandon Lozza a écrit :
> 
> Mozilla's trademark requirements violate Freedom #2
> The freedom to study how the program works, and change it to make it
> do what you wish (freedom 1). Access to the source code is a
> precondition for this.
> 
> We're NOT allowed to make changes (patches) without their permission.
> This is defacto non-free. I understand we work with upstream but that
> shouldn't prevent us from maintaining it.

That's just the same with most distro trademarks (fedora, debian, etc ...)

Mozilla does not forbid you to study/modify/distribute their work but as
fedora to distribute a modified version under their trademark.
That's why we have generic-* packages in our repositories.

Best regards,
H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: selinux issue with wine

[Ankur Sinha]

On Wed, 2010-07-28 at 12:38 +0200, Michael Schwendt wrote:
> On Wed, 28 Jul 2010 15:08:24 +0530, Ankur wrote:
> 
> > hi,
> > 
> > I've recently come across an selinux issue.
> > 
> > Is this another selinux issue with the package? 
> > 
> > (I don't want to switch off selinux.)
> 
> Why don't you comment on the stuff you've quoted? It has told you what
> SELinux command you can run as a fix.

hey,

I know nothing about selinux. I have no clue what the command would do.
We generally report selinux denials as bugs, and wanted to confirm if
this is another one that is to be reported.

Sorry if it cause noise on the list. 

regards,
Ankur

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

Re: selinux issue with wine

[Michael Schwendt]

On Wed, 28 Jul 2010 16:50:49 +0530, Ankur wrote:

> We generally report selinux denials as bugs, and wanted to confirm if
> this is another one that is to be reported.

Well, if there were a policy for this already, SELinux would not
have complained about it.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: selinux issue with wine

[Frank Murphy]

On 28/07/10 12:20, Ankur Sinha wrote:

> I know nothing about selinux. I have no clue what the command would do.
> We generally report selinux denials as bugs, and wanted to confirm if
> this is another one that is to be reported.
>
> Sorry if it cause noise on the list.
>

Hi Ankur,


*Normally* it is best if concerned about something to post to the 
selinx-list:  https://admin.fedoraproject.org/mailman/listinfo/selinux

I would also check bugzilla.redhat.com to see if there is an existing
similar wine bug. This will save the selinux maintainers looking for 
duplicates.

*But in this case don't*, as the alert does not say report it.
Instead it tells you using this program can be a risk (dangerous?)
But if you really need this program:
su
/usr/sbin/setsebool -P mmap_low_allowed 1

Then is should work without alert.

-- 
Regards,

Frank Murphy
UTF_8 Encoded
Friend of Fedora
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firefox 4 for Fedora 14?

[Florent Le Coz]

  On 28/07/2010 00:24, Brandon Lozza wrote:
> F11 or F12 had a beta version of firefox
>
> spot's chromium builds do support webm, it works great :)
>
>
It's still not included in fedora's repositories, so it doesn't change 
anything.
Firefox 4 in F14 is, in my opinion, a MUST HAVE for a distribution 
"leading the way".

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

Re: Firefox 4 for Fedora 14?

[Brandon Lozza]

On Wed, Jul 28, 2010 at 6:55 AM, Rahul Sundaram  wrote:
>  On 07/28/2010 04:22 PM, Brandon Lozza wrote
>> The FSF drafted up the four freedoms and it's not offtopic, we're
>> discussing Firefox4 and the fact that we won't be able to make changes
>> to it to fix it without their permission.
>
> There is no specific non-upstream change that Firefox maintainers in
> Fedora want to do and hence it is irrelevant to this thread which is
> merely about integration of Firefox in Fedora 14 which requires no
> patches.

Wrong, users of the KDE spin would LOVE to have OpenSUSE's patches to
integrate it _better_ with KDE.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firefox 4 for Fedora 14?

[Rahul Sundaram]

 On 07/28/2010 05:47 PM, Brandon Lozza wrote:
> On Wed, Jul 28, 2010 at 6:55 AM, Rahul Sundaram  wrote:
>>  On 07/28/2010 04:22 PM, Brandon Lozza wrote
>>> The FSF drafted up the four freedoms and it's not offtopic, we're
>>> discussing Firefox4 and the fact that we won't be able to make changes
>>> to it to fix it without their permission.
>> There is no specific non-upstream change that Firefox maintainers in
>> Fedora want to do and hence it is irrelevant to this thread which is
>> merely about integration of Firefox in Fedora 14 which requires no
>> patches.
> Wrong, users of the KDE spin would LOVE to have OpenSUSE's patches to
> integrate it _better_ with KDE.

What does that have to do with this thread?  As long as the patches are
not upstream,  Firefox in Fedora won't have it.  Period. 

Rahul

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

Re: Firefox 4 for Fedora 14?

[Brandon Lozza]

On Wed, Jul 28, 2010 at 8:27 AM, Rahul Sundaram  wrote:
>  On 07/28/2010 05:47 PM, Brandon Lozza wrote:
>> On Wed, Jul 28, 2010 at 6:55 AM, Rahul Sundaram  wrote:
>>>  On 07/28/2010 04:22 PM, Brandon Lozza wrote
 The FSF drafted up the four freedoms and it's not offtopic, we're
 discussing Firefox4 and the fact that we won't be able to make changes
 to it to fix it without their permission.
>>> There is no specific non-upstream change that Firefox maintainers in
>>> Fedora want to do and hence it is irrelevant to this thread which is
>>> merely about integration of Firefox in Fedora 14 which requires no
>>> patches.
>> Wrong, users of the KDE spin would LOVE to have OpenSUSE's patches to
>> integrate it _better_ with KDE.
>
> What does that have to do with this thread?  As long as the patches are
> not upstream,  Firefox in Fedora won't have it.  Period.
>
> Rahul
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>

It does have to do with the thread; stop saying it doesn't.

The point is, if we rely on upstream to fix the software then we
SHOULD NOT ship BETA. There are technical (security, stability)
reasons for this.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firefox 4 for Fedora 14?

[Mike McGrath]

On Wed, 28 Jul 2010, Florent Le Coz wrote:

>   On 28/07/2010 00:24, Brandon Lozza wrote:
> > F11 or F12 had a beta version of firefox
> >
> > spot's chromium builds do support webm, it works great :)
> >
> >
> It's still not included in fedora's repositories, so it doesn't change
> anything.
> Firefox 4 in F14 is, in my opinion, a MUST HAVE for a distribution
> "leading the way".
>

In my opinion including software that even upstream says is not ready is
for a distribution that's "lost their way".  We can still be a leading
distribution and not include pre-release software.  Especially pre-release
software that's not only in our critical path, but also something that
almost all of us use every day.  Maybe as firefox4 available in
updates-testing, but certainly not a core default package.

I think what people are missing is that even though our release is
scheduled for late October.  The feature freeze was _yesterday_.  meaning
that firefox would need to have been ready for use yesterday.  Not in
October when it might maybe be ready.

There's a difference between making people use new software and making
them use half-baked software.  Lets not be the half-baked distro.

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

Re: Firefox 4 for Fedora 14?

[Frank Murphy]

On 28/07/10 13:52, Mike McGrath wrote:

  Maybe as firefox4 available in
> updates-testing, but certainly not a core default package.

+1

-- 
Regards,

Frank Murphy
UTF_8 Encoded
Friend of Fedora
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firefox 4 for Fedora 14?

[Brandon Lozza]

On Wed, Jul 28, 2010 at 8:57 AM, Frank Murphy  wrote:
> On 28/07/10 13:52, Mike McGrath wrote:
> 
>  Maybe as firefox4 available in
>> updates-testing, but certainly not a core default package.
>
> +1
>
> --
> Regards,
>
> Frank Murphy
> UTF_8 Encoded
> Friend of Fedora
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>

+1

It should be in updates-testing
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firefox 4 for Fedora 14?

[Florent Le Coz]

  On 28/07/2010 14:52, Mike McGrath wrote:
> In my opinion including software that even upstream says is not ready is
> for a distribution that's "lost their way".  We can still be a leading
> distribution and not include pre-release software.  Especially pre-release
> software that's not only in our critical path, but also something that
> almost all of us use every day.
I agree, but doesn't that mean that Firefox 4.0 won't be available in 
F14 at all and will only be in F15?
I think it would be a huge drawback for Fedora 14.

 Florent

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

Broken dependencies: perl-Pugs-Compiler-Rule

[buildsys]

perl-Pugs-Compiler-Rule has broken dependencies in the rawhide tree:
On x86_64:
perl-Pugs-Compiler-Rule-0.37-4.fc13.noarch requires 
perl(:MODULE_COMPAT_5.10.1)
On i386:
perl-Pugs-Compiler-Rule-0.37-4.fc13.noarch requires 
perl(:MODULE_COMPAT_5.10.1)
Please resolve this as soon as possible.


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

Broken dependencies: perl-Config-Model

[buildsys]

perl-Config-Model has broken dependencies in the rawhide tree:
On x86_64:
perl-Config-Model-1.205-2.fc14.noarch requires perl(YAML::Any) >= 
0:0.303
On i386:
perl-Config-Model-1.205-2.fc14.noarch requires perl(YAML::Any) >= 
0:0.303
Please resolve this as soon as possible.


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

Broken dependencies: perl-Data-Alias

[buildsys]

perl-Data-Alias has broken dependencies in the rawhide tree:
On x86_64:
perl-Data-Alias-1.07-6.fc13.x86_64 requires perl(:MODULE_COMPAT_5.10.1)
On i386:
perl-Data-Alias-1.07-6.fc13.i686 requires perl(:MODULE_COMPAT_5.10.1)
Please resolve this as soon as possible.


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

Re: Firefox 4 for Fedora 14?

[Chen Lei]

2010/7/28 Frank Murphy :
> On 28/07/10 13:52, Mike McGrath wrote:
> 
>  Maybe as firefox4 available in
>> updates-testing, but certainly not a core default package.
>
> +1
>
> --
> Regards,

This is extremely complicated which means we can't push any xulrunner
related packages to stable for a long time even for a security issue.

Regard,
Chen Lei
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firefox 4 for Fedora 14?

[Orcan Ogetbil]

On Wed, Jul 28, 2010 at 9:28 AM, Chen Lei wrote:
> 2010/7/28 Frank Murphy :
>> On 28/07/10 13:52, Mike McGrath wrote:
>> 
>>  Maybe as firefox4 available in
>>> updates-testing, but certainly not a core default package.
>>
>> +1
>>
>> --
>> Regards,
>
> This is extremely complicated which means we can't push any xulrunner
> related packages to stable for a long time even for a security issue.
>

...and we come back to my suggestion of enabling having multiple
versions of the same package in updates-testing.

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

Re: Firefox 4 for Fedora 14?

[Michel Alexandre Salim]

On Wed, 28 Jul 2010 17:57:39 +0530, Rahul Sundaram wrote:

> On 07/28/2010 05:47 PM, Brandon Lozza wrote:
>> On Wed, Jul 28, 2010 at 6:55 AM, Rahul Sundaram 
>> wrote:
>>>  On 07/28/2010 04:22 PM, Brandon Lozza wrote
 The FSF drafted up the four freedoms and it's not offtopic, we're
 discussing Firefox4 and the fact that we won't be able to make
 changes to it to fix it without their permission.
>>> There is no specific non-upstream change that Firefox maintainers in
>>> Fedora want to do and hence it is irrelevant to this thread which is
>>> merely about integration of Firefox in Fedora 14 which requires no
>>> patches.
>> Wrong, users of the KDE spin would LOVE to have OpenSUSE's patches to
>> integrate it _better_ with KDE.
> 
> What does that have to do with this thread?  As long as the patches are
> not upstream,  Firefox in Fedora won't have it.  Period.
> 
Is Red Hat Legal just more careful than Novell's legal department? 
Otherwise, how is it that they ship Firefox with custom patches (and call 
it Firefox) and we don't..

Regards,

-- 
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/

Email:  sali...@fedoraproject.org  | GPG key ID: 78884778
Jabber: hir...@jabber.ccc.de   | IRC: hir...@irc.freenode.net

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

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

Re: Firefox 4 for Fedora 14?

[Rahul Sundaram]

 On 07/28/2010 07:23 PM, Michel Alexandre Salim wrote:
> Is Red Hat Legal just more careful than Novell's legal department? 
> Otherwise, how is it that they ship Firefox with custom patches (and call 
> it Firefox) and we don't..

Firefox can be shipped with custom patches and the trademark intact as
long as Mozilla agrees to it. Alternatively, you can implement
additional functionality via a add-on and include that by default. 

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

Re: Firefox 4 for Fedora 14?

[Andreas Tunek]

2010/7/28 Rahul Sundaram :
> On 07/28/2010 03:33 AM, Brandon Lozza wrote:
>> Doesn't our version already support WebM?
>>
>
> Nope.  We have updated Gstreamer and WebKit-Gtk in Fedora 13 and 12 for
> WebM support bringing it to Epiphany and Midori users and I assume
> Spot's Chromium repo users also have support for it but Firefox 4 will
> be the first stable version with WebM support built-in.
>

Epiphany is basically uselessin F13, see Bug 603358.

/Andreas

> Rahul
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Gnome 3 delayed

[Michał Piotrowski]

Hi,

It seems that Gnome 3 will be released in march 2011. How will this
affect Fedora 14? Gnome 3 was an important feature of F14.

http://lwn.net/Articles/397482/

Regards,
Michal
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firefox 4 for Fedora 14?

[Rahul Sundaram]

 On 07/28/2010 07:50 PM, Andreas Tunek wrote:
>
> Epiphany is basically uselessin F13, see Bug 603358.

Using it here just fine without that issue.

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

Re: Gnome 3 delayed

[James Laska]

On Wed, 2010-07-28 at 16:27 +0200, Michał Piotrowski wrote:
> Hi,
> 
> It seems that Gnome 3 will be released in march 2011. How will this
> affect Fedora 14? Gnome 3 was an important feature of F14.
> 
> http://lwn.net/Articles/397482/

I believe it will continued to be offered as an experimental option.
From http://fedoraproject.org/wiki/Features/Gnome3#Contingency_Plan ...

"If gnome-shell is not complete or stable enough, keep it experimental
and stay with 'classical GNOME' as the default. Users will still be able
to try the shell manually, just like in F12 and F13. "

Thanks,
James




signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firefox 4 for Fedora 14?

[Martin Sourada]

On Wed, 2010-07-28 at 09:57 +0300, Nicu Buculei wrote: 
> On 07/28/2010 01:08 AM, Mike McGrath wrote:
> >> On 07/27/2010 10:53 PM, Rahul Sundaram wrote:
> >>>
> >>> Are we skipping Firefox 4 for Fedora 14?  Beta 2 has been released
> >>> recently and I am wondering if we can go with it if it fits into the
> >>> schedule.  There are dozens of new features including WebM support that
> >>> would be nice to have.
> >
> > -1 didn't the last time we started using a pre-release from Mozilla turn
> > out pretty bad for us?
> 
> That was Firefox 3.0 included as RC in Fedora 9, from an user 
> perspective my memories about it are sweet... it was worse with 
> Thunderbird 3, which was included in a release (F11) in Beta stage, and 
> not even a late beta, it was something like Beta2, but AFAIK Firefox is 
> expected to be RC around F14.
> 
> And while Thunderbird 3 was included due to the slow development pace of 
> the upstream (we used to have a very old Tb 2), Firefox 4 comes with at 
> least a killer feature, WebM (IIRC, another killer feature is the new js 
> engine)
...which is already present in all currently maintained fedora releases
via webkitgtk (midori, epiphany, kazehakase, ...). Now, that is a *real
killer feature*... I'm not sure about the js engine but something tells
me it's still slower than webkit's or chromium's or opera's...

Sorry, I'm -1 for FF4 in F14. It's second beta now and scheduled release
is around F14 release, which is too late (not counting in account that
they'll most likely slip with their release...).

Martin


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firefox 4 for Fedora 14?

[Brandon Lozza]

On Wed, Jul 28, 2010 at 10:40 AM, Martin Sourada
 wrote:
> On Wed, 2010-07-28 at 09:57 +0300, Nicu Buculei wrote:
>> On 07/28/2010 01:08 AM, Mike McGrath wrote:
>> >> On 07/27/2010 10:53 PM, Rahul Sundaram wrote:
>> >>>
>> >>> Are we skipping Firefox 4 for Fedora 14?  Beta 2 has been released
>> >>> recently and I am wondering if we can go with it if it fits into the
>> >>> schedule.  There are dozens of new features including WebM support that
>> >>> would be nice to have.
>> >
>> > -1 didn't the last time we started using a pre-release from Mozilla turn
>> > out pretty bad for us?
>>
>> That was Firefox 3.0 included as RC in Fedora 9, from an user
>> perspective my memories about it are sweet... it was worse with
>> Thunderbird 3, which was included in a release (F11) in Beta stage, and
>> not even a late beta, it was something like Beta2, but AFAIK Firefox is
>> expected to be RC around F14.
>>
>> And while Thunderbird 3 was included due to the slow development pace of
>> the upstream (we used to have a very old Tb 2), Firefox 4 comes with at
>> least a killer feature, WebM (IIRC, another killer feature is the new js
>> engine)
> ...which is already present in all currently maintained fedora releases
> via webkitgtk (midori, epiphany, kazehakase, ...). Now, that is a *real
> killer feature*... I'm not sure about the js engine but something tells
> me it's still slower than webkit's or chromium's or opera's...
>
> Sorry, I'm -1 for FF4 in F14. It's second beta now and scheduled release
> is around F14 release, which is too late (not counting in account that
> they'll most likely slip with their release...).
>
> Martin
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>

There is also plugin compatibility . Newer != better
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [HEADS-UP] systemd is now the default init system in rawhide

[Ray Strode]

Hi

On Wed, Jul 28, 2010 at 6:26 AM, Lennart Poettering
 wrote:
> On Sat, 24.07.10 00:14, Casey Dahlin (cdah...@redhat.com) wrote:
>
>>
>> On Fri, Jul 23, 2010 at 10:54:50PM -0500, Garrett Holmstrom wrote:
>> > On 7/23/2010 20:26, Lennart Poettering wrote:
>> > > - You can boot into either of them by setting the "init=" kernel cmdline
>> > >    option according to your wishes. If you pass "init=/bin/systemd" you
>> > >    will boot into systemd, if you pass "init=/sbin/upstart" you will boot
>> > >    into upstart (note the /sbin vs. /bin!)
>> >
>> > Why is the systemd executable in /bin instead of /sbin?
>>
>> Without looking too closely I believe systemd eventually seeks to replace
>> things like gnome-session daemon. It has session management in mind as well 
>> as
>> system.
>
> Yes, this is the case. Normal users can and should start it and it might
> even be invoked by scripts such as gnomerc or suchlike. On most
> distributions (with the exception of Fedora) /sbin/ is not in $PATH and
> hence the right place for the systemd binary is /bin/ and nothing else.

Could put systemd in /sbin and have a symlink to it called

 /bin/sessiond

That would also allow the daemon to know which "mode" it's running in.
 Still, probably not worth it.

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

Re: Fedora 14 branching and dist-git roll out

[pbrobin...@gmail.com]

On Wed, Jul 28, 2010 at 10:18 AM, Jesse Keating  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 07/23/2010 11:54 PM, Jesse Keating wrote:
>> The conversion will take a couple days, which means our normal short
>> outage for branching will be a bit extended.  I wish there was another
>> way, but converting over 9K cvs repos into git repos does take some
>> time.  I really feel that this move is worth the extended outage.
>
> The conversion process has begun.  We have just over 10K repos to
> convert, and nearly 200 are done already.  I'm employing a second host
> to help conversion to cut down on the over all outage time.
>
> I was not able to get a fedpkg (fedora-packager) build out today,
> however as soon as that repo is converted and we get the koji changes in
> place to build from git we will use that as a test build and get the
> updated fedpkg into your hands.
>
> I've also started on some wiki work to change some CVS pages, but much
> more will come.  Any help here is appreciated.

So once the package is converted is the git repo read/write so we can
begin updates or is it all down until the conversion is complete?

Also is there a wiki page outlining the rough conversion from old to
new commands and other such policy/procedure changes?

Cheers,
Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firefox 4 for Fedora 14?

[Paul W. Frields]

On Wed, Jul 28, 2010 at 03:04:46PM +0200, Florent Le Coz wrote:
>   On 28/07/2010 14:52, Mike McGrath wrote:
> > In my opinion including software that even upstream says is not ready is
> > for a distribution that's "lost their way".  We can still be a leading
> > distribution and not include pre-release software.  Especially pre-release
> > software that's not only in our critical path, but also something that
> > almost all of us use every day.
> I agree, but doesn't that mean that Firefox 4.0 won't be available in 
> F14 at all and will only be in F15?
> I think it would be a huge drawback for Fedora 14.

It would be huge if there people who can't live without it didn't have
any other way of getting it than having it pre-packaged.  I think
Firefox 4 looks to be fantastic, but the truth is that people only
have to wait a few months for a release with it pre-packaged, if
they're not able to add it on their own.

-- 
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/
  Where open source multiplies: http://opensource.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Python 2.7 status: python2.7 is in dist-f14

[Bill Nottingham]

David Malcolm (dmalc...@redhat.com) said: 
> A further 26 builds in dist-f14-py27-rebuild had newer builds in
> rawhide, so we'll need to rebuild these; some are important e.g. yum and
> anaconda (see [1] again).

Oof. In the future, can we make sure we just don't move these builds
that override newer builds?

I was doing rebuilds against the new boost, and the fact that the older
one was tagged over means that 5-10 of them now need rebuilt again,
as the buildroot went backwards.

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

Re: Python 2.7 status: python2.7 is in dist-f14

[David Malcolm]

On Wed, 2010-07-28 at 11:55 -0400, Bill Nottingham wrote:
> David Malcolm (dmalc...@redhat.com) said: 
> > A further 26 builds in dist-f14-py27-rebuild had newer builds in
> > rawhide, so we'll need to rebuild these; some are important e.g. yum and
> > anaconda (see [1] again).
> 
> Oof. In the future, can we make sure we just don't move these builds
> that override newer builds?

Looks like a bug in the script that I used; it was meant to not move
them, but in fact it did.

> I was doing rebuilds against the new boost, and the fact that the older
> one was tagged over means that 5-10 of them now need rebuilt again,
> as the buildroot went backwards.

Looking at boost, the log [1] contains:
"Newer build found for boost."
so it wasn't meant to have been moved.

However, looking at boost builds [2], I see:
boost-1.41.0-13.fc14 built into dist-f14-py27-rebuild _did_ get moved
into dist-f14.

Sorry about this.

It looks like oget has since built boost-1.44.0-0.3.fc14 into dist-f14
against python2.7, so presumably further builds in dist-f14 will pick up
the correct version of boost.


Looking at the script [3], it looks like the indentation of the call to
kojisession.tagBuildBypass(target, build) is wrong; it should be guarded
by the "if not newer" conditional.  Patch attached.


Grepping the log indicates that the list of 26 packages for which a
newer build was replaced with an older build is:
Django-south
PyXML
akonadi
anaconda
boost
fonttools
gdb
gwibber
hplip
kdepimlibs
libgsf
libselinux
livecd-tools
mapserver
pacemaker
policycoreutils
python-pyblock
python-toscawidgets
setroubleshoot
source-highlight
tryton
vips
virtaal
xapian-bindings
yum
zinnia

All of these would have needed a rebuild anyway, and some already have
been rebuilt.

Dave

[1]
http://dmalcolm.fedorapeople.org/python-packaging/mass-tag-from-dist-f14-py27-rebuild-into-dist-f14.txt


[2] http://koji.fedoraproject.org/koji/packageinfo?packageID=1074
[3]
http://git.fedorahosted.org/git/?p=releng;a=blob;f=scripts/mass-tag.py;h=c6225af73f3055fbfea6f1d11841ad446d4a8bbc;hb=HEAD

diff --git a/scripts/mass-tag.py b/scripts/mass-tag.py
index c6225af..fe7d0f7 100755
--- a/scripts/mass-tag.py
+++ b/scripts/mass-tag.py
@@ -100,7 +100,7 @@ for build in builds:
 if not newer:
 print 'Tagging %s into %s' % (build['nvr'], target)
 taglist.append(build['nvr'])
-#kojisession.tagBuildBypass(target, build)
+#kojisession.tagBuildBypass(target, build)
 
 print 'Tagging %s builds.' % len(taglist)
 #results = kojisession.multiCall()
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: f14 boost-1.44.0 upgrade: notice of intent

[Adam Williamson]

On Tue, 2010-07-27 at 13:47 -0700, Benjamin Kosnik wrote:
> > Do you have a list of packages which will need to be rebuilt?  This is
> > the last day before we branch, and with the dist-git outage there will
> > be a short time to fix things before the Alpha freeze.  Is anything in
> > the critpath dependent upon boost, or in the primary spins?
> 
> here's the old list:
> openvrml pingus hugin conexus player mapnik aqsis qpidc deluge
> rcsslogplayer Miro asc glob2 vegastrike gnash chess pyexiv2 k3d kdeedu
> python-tag linkage barry rcssserver QuantLib wesnoth mkvtoolnix
> rb_libtorrent bmpx xmms2 wp_tray fuse-encfs referencer source-highlight
> HippoDraw rcsserver3d 
> 
> This is from:
> http://fedoraproject.org/wiki/Features/F13Boost141

Add gnote to that list. That one needs to get rebuilt ASAP, as it's in
the default live spin.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

Re: Fedora 14 branching and dist-git roll out

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/28/2010 08:15 AM, pbrobin...@gmail.com wrote:
> So once the package is converted is the git repo read/write so we can
> begin updates or is it all down until the conversion is complete?

Kinda, but not for production use.  Once they are all converted I have
to move them into place and setup the git hooks.  I'm not doing that as
they are converted, but once the whole mess is done.

> 
> Also is there a wiki page outlining the rough conversion from old to
> new commands and other such policy/procedure changes?

I'll be working on that (with help please!) today.  But rougly if you
did "make " before, you'd do "fedpkg " now.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxQXeYACgkQ4v2HLvE71NXfkgCgvvigBsin477BHe6hFByPzBMA
/M0An2B9siKoTVAH1AiKBU8kUfkn9q/G
=G41h
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firefox 4 for Fedora 14?

[Adam Williamson]

On Tue, 2010-07-27 at 19:16 -0500, Mike McGrath wrote:

> > We was delayed in F-12 (two weeks) and in F-13 (two weeks), probably
> > we'll have a final version for Firefox 4 before or a bit after we
> > release F-14. Another thing, we can test a lot and assist in upstream
> > during our testing phase.
> > It's +1 for me.
> >
> 
> If Fedora didn't have stability issues I'd be all for it, but we do.  And
> part of it is because we shoot from the hip with stuff like this.  If
> Mozilla doesn't think it's ready yet, I don't know why we would think it
> is.

I don't see why we can't just ship with 3.x and ship 4.0 as an update
when it comes out (assuming it doesn't suck). Yes, Board stable updates
vision and blah blah, but Firefox is something that people *will* go out
and download the latest version of if you don't provide it for them. So
I'd probably be happiest going that way.

(Having said that, I'm running 4.0b1 from upstream on one of my systems
and it works absolutely fine...)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

Re: Python 2.7 status: python2.7 is in dist-f14

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/28/2010 09:25 AM, David Malcolm wrote:
> Looks like a bug in the script that I used; it was meant to not move
> them, but in fact it did.

D'oh.  Due to an earlier bug in this script (which David successfully
fixed) I didn't notice this later bug, which David is also fixing.  My
fault.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxQX0sACgkQ4v2HLvE71NWMgwCgq7WEht2FEnj4ZYxujoT6MqIJ
1xEAnjr6GMjsdATz3PUwWBUbtXwS83yQ
=4SGI
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firefox 4 for Fedora 14?

[Adam Williamson]

On Wed, 2010-07-28 at 07:52 -0500, Mike McGrath wrote:

> I think what people are missing is that even though our release is
> scheduled for late October.  The feature freeze was _yesterday_.  meaning
> that firefox would need to have been ready for use yesterday.  Not in
> October when it might maybe be ready.

Nope. That's only for things that are declared as features. If you don't
declare your version update to be a feature, you can happily do it right
up to the release freeze.

(This is one thing I find absurd about the feature process, but don't
get me started.)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

Re: Firefox 4 for Fedora 14?

[Adam Williamson]

On Wed, 2010-07-28 at 09:41 -0400, Orcan Ogetbil wrote:
> On Wed, Jul 28, 2010 at 9:28 AM, Chen Lei wrote:
> > 2010/7/28 Frank Murphy :
> >> On 28/07/10 13:52, Mike McGrath wrote:
> >> 
> >>  Maybe as firefox4 available in
> >>> updates-testing, but certainly not a core default package.
> >>
> >> +1
> >>
> >> --
> >> Regards,
> >
> > This is extremely complicated which means we can't push any xulrunner
> > related packages to stable for a long time even for a security issue.
> >
> 
> ...and we come back to my suggestion of enabling having multiple
> versions of the same package in updates-testing.

...or we come back to how updates-testing is not a backports repo, and
if we want to have a backports repo, we should make a backports repo. =)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

Re: Firefox 4 for Fedora 14?

[Adam Williamson]

On Wed, 2010-07-28 at 11:37 -0400, Paul W. Frields wrote:
> On Wed, Jul 28, 2010 at 03:04:46PM +0200, Florent Le Coz wrote:
> >   On 28/07/2010 14:52, Mike McGrath wrote:
> > > In my opinion including software that even upstream says is not ready is
> > > for a distribution that's "lost their way".  We can still be a leading
> > > distribution and not include pre-release software.  Especially pre-release
> > > software that's not only in our critical path, but also something that
> > > almost all of us use every day.
> > I agree, but doesn't that mean that Firefox 4.0 won't be available in 
> > F14 at all and will only be in F15?
> > I think it would be a huge drawback for Fedora 14.
> 
> It would be huge if there people who can't live without it didn't have
> any other way of getting it than having it pre-packaged.  I think
> Firefox 4 looks to be fantastic, but the truth is that people only
> have to wait a few months for a release with it pre-packaged, if
> they're not able to add it on their own.

I'd rather we provide them a package than have people going out and
installing software from third-party sources (yes, mozilla.org is hardly
Evil, but it sets a bad precedent). I really don't see much of a reason
we can't ship it as a post-release update. We'd probably want to do that
in the end anyway, because Mozilla tends to stop security supporting old
branches anyway; it's certainly plausible that they stop supporting 3.x
during F14's support lifetime.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

Re: Firefox 4 repo

[Kai Engert]

  On 18.07.2010 16:06, Mike Chambers wrote:
> Anyone doing any builds of this during development and supplying a repo
> to download and install that way instead of source builds?  Or is it too
> buggy to do at the moment?

Remi does:

http://rpms.famillecollet.com/fedora/13/remi/i386/repoview/firefox4.html

http://blog.famillecollet.com/pages/Config-en

Kai

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

Re: Python 2.7 status: python2.7 is in dist-f14

[Adam Williamson]

On Wed, 2010-07-28 at 11:55 -0400, Bill Nottingham wrote:
> David Malcolm (dmalc...@redhat.com) said: 
> > A further 26 builds in dist-f14-py27-rebuild had newer builds in
> > rawhide, so we'll need to rebuild these; some are important e.g. yum and
> > anaconda (see [1] again).
> 
> Oof. In the future, can we make sure we just don't move these builds
> that override newer builds?
> 
> I was doing rebuilds against the new boost, and the fact that the older
> one was tagged over means that 5-10 of them now need rebuilt again,
> as the buildroot went backwards.

Still, if they were in the py27 tag they *must* need to be rebuilt again
anyway, because the later builds in Rawhide would have been against
Python 2.6 and hence would be broken anyway. So in practice it doesn't
make a huge different, AFAICT.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

Re: Firefox 4 for Fedora 14?

[Kai Engert]

  The work done by Remi, providing a parallel install Firefox 4 for 
Fedora 13, could be reused to provide the same parallel install in 
Fedora 14.

http://rpms.famillecollet.com/fedora/13/remi/i386/repoview/firefox4.html

http://blog.famillecollet.com/pages/Config-en


kai

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

Re: Firefox 4 for Fedora 14?

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/28/2010 09:59 AM, Adam Williamson wrote:
> Nope. That's only for things that are declared as features. If you don't
> declare your version update to be a feature, you can happily do it right
> up to the release freeze.
> 

I'd like to apply it to all packages, but I tend to get severe push back
whenever I suggest that.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxQZhkACgkQ4v2HLvE71NWaqgCfaUhloxcOP16OEMtmi3IpQLl8
ZqcAnRdP3q/DUQW0N/deazJw4JjyKjl1
=3cND
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firefox 4 for Fedora 14?

[Kevin Fenzi]

Again, I never know where to reply in these long threads. ;) 

Personally, I would suggest we let people who are involved with
upstream and follow development and handle bugs for firefox decide
this. 

We could call them our "firefox package maintainers". ;) 

So, this thread serves as a way to let them know some people are
interested in 4.0 and would love to see it, but some think it shouldn't
be at the cost of too much loss of stability. 

So, is there any further information we can gain/provide from continuing
this thread?

kevin


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Seeking to merge python 2.7 into rawhide

[Mark Knoop]

At 19:00 on 26 Jul 2010, Jeff Spaleta wrote:
> On Mon, Jul 26, 2010 at 6:38 PM, Adam Williamson
>  wrote:
> > revelation (okay, okay, i'm sneaking this one in because *i* depend
> > on it :>)
> 
> I depend on it to and it needs a complete overhaul and an upstream
> reboot.  Want to help me start an effort to reboot the upstream? It
> really needs to be retooled..especially porting it to gvfs from
> gnomevfs.

Note that there are a few forks of revelation on bitbucket, so it looks
like some of this work is under way.

http://bitbucket.org/erikg/revelation/descendants

-- 
Mark Knoop
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firefox 4 for Fedora 14?

[Peter Jones]

On 07/28/2010 01:10 PM, Adam Williamson wrote:
> On Wed, 2010-07-28 at 11:37 -0400, Paul W. Frields wrote:
>> On Wed, Jul 28, 2010 at 03:04:46PM +0200, Florent Le Coz wrote:
>>>   On 28/07/2010 14:52, Mike McGrath wrote:
 In my opinion including software that even upstream says is not ready is
 for a distribution that's "lost their way".  We can still be a leading
 distribution and not include pre-release software.  Especially pre-release
 software that's not only in our critical path, but also something that
 almost all of us use every day.
>>> I agree, but doesn't that mean that Firefox 4.0 won't be available in 
>>> F14 at all and will only be in F15?
>>> I think it would be a huge drawback for Fedora 14.
>>
>> It would be huge if there people who can't live without it didn't have
>> any other way of getting it than having it pre-packaged.  I think
>> Firefox 4 looks to be fantastic, but the truth is that people only
>> have to wait a few months for a release with it pre-packaged, if
>> they're not able to add it on their own.
> 
> I'd rather we provide them a package than have people going out and
> installing software from third-party sources (yes, mozilla.org is hardly
> Evil, but it sets a bad precedent). I really don't see much of a reason
> we can't ship it as a post-release update. We'd probably want to do that
> in the end anyway, because Mozilla tends to stop security supporting old
> branches anyway; it's certainly plausible that they stop supporting 3.x
> during F14's support lifetime.

Just because it isn't in the F14 repo doesn't mean it won't be available to
people who really want a packaged version earlier - look at spot's chromium
packages, for example.  And I really expect the F14-F15 time frame to be a very
similar situation with Firefox - just because it's released doesn't mean there
isn't some time to wait before it's really shippable.  6 months won't be the
end of the world, especially if it's added to an add-on repo someplace so
people can get it if they really want something other than ff3.

-- 
Peter

Old MacDonald had an agricultural real-estate tax abatement.

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

Re: Firefox 4 for Fedora 14?

[Mike McGrath]

On Wed, 28 Jul 2010, Peter Jones wrote:

> On 07/28/2010 01:10 PM, Adam Williamson wrote:
> > On Wed, 2010-07-28 at 11:37 -0400, Paul W. Frields wrote:
> >> On Wed, Jul 28, 2010 at 03:04:46PM +0200, Florent Le Coz wrote:
> >>>   On 28/07/2010 14:52, Mike McGrath wrote:
>  In my opinion including software that even upstream says is not ready is
>  for a distribution that's "lost their way".  We can still be a leading
>  distribution and not include pre-release software.  Especially 
>  pre-release
>  software that's not only in our critical path, but also something that
>  almost all of us use every day.
> >>> I agree, but doesn't that mean that Firefox 4.0 won't be available in
> >>> F14 at all and will only be in F15?
> >>> I think it would be a huge drawback for Fedora 14.
> >>
> >> It would be huge if there people who can't live without it didn't have
> >> any other way of getting it than having it pre-packaged.  I think
> >> Firefox 4 looks to be fantastic, but the truth is that people only
> >> have to wait a few months for a release with it pre-packaged, if
> >> they're not able to add it on their own.
> >
> > I'd rather we provide them a package than have people going out and
> > installing software from third-party sources (yes, mozilla.org is hardly
> > Evil, but it sets a bad precedent). I really don't see much of a reason
> > we can't ship it as a post-release update. We'd probably want to do that
> > in the end anyway, because Mozilla tends to stop security supporting old
> > branches anyway; it's certainly plausible that they stop supporting 3.x
> > during F14's support lifetime.
>
> Just because it isn't in the F14 repo doesn't mean it won't be available to
> people who really want a packaged version earlier - look at spot's chromium
> packages, for example.  And I really expect the F14-F15 time frame to be a 
> very
> similar situation with Firefox - just because it's released doesn't mean there
> isn't some time to wait before it's really shippable.  6 months won't be the
> end of the world, especially if it's added to an add-on repo someplace so
> people can get it if they really want something other than ff3.
>

Perhaps it's time to figure out how to make things like Tom's chromium
more official.  Find actual hosting/mirroring for that stuff, make a clear
path to get people to it but also letting them know "hey, your milage may
vary".

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

Re: Firefox 4 for Fedora 14?

[Peter Jones]

On 07/28/2010 02:25 PM, Mike McGrath wrote:
> On Wed, 28 Jul 2010, Peter Jones wrote:
> 
>> On 07/28/2010 01:10 PM, Adam Williamson wrote:
>>> On Wed, 2010-07-28 at 11:37 -0400, Paul W. Frields wrote:
 On Wed, Jul 28, 2010 at 03:04:46PM +0200, Florent Le Coz wrote:
>   On 28/07/2010 14:52, Mike McGrath wrote:
>> In my opinion including software that even upstream says is not ready is
>> for a distribution that's "lost their way".  We can still be a leading
>> distribution and not include pre-release software.  Especially 
>> pre-release
>> software that's not only in our critical path, but also something that
>> almost all of us use every day.
> I agree, but doesn't that mean that Firefox 4.0 won't be available in
> F14 at all and will only be in F15?
> I think it would be a huge drawback for Fedora 14.

 It would be huge if there people who can't live without it didn't have
 any other way of getting it than having it pre-packaged.  I think
 Firefox 4 looks to be fantastic, but the truth is that people only
 have to wait a few months for a release with it pre-packaged, if
 they're not able to add it on their own.
>>>
>>> I'd rather we provide them a package than have people going out and
>>> installing software from third-party sources (yes, mozilla.org is hardly
>>> Evil, but it sets a bad precedent). I really don't see much of a reason
>>> we can't ship it as a post-release update. We'd probably want to do that
>>> in the end anyway, because Mozilla tends to stop security supporting old
>>> branches anyway; it's certainly plausible that they stop supporting 3.x
>>> during F14's support lifetime.
>>
>> Just because it isn't in the F14 repo doesn't mean it won't be available to
>> people who really want a packaged version earlier - look at spot's chromium
>> packages, for example.  And I really expect the F14-F15 time frame to be a 
>> very
>> similar situation with Firefox - just because it's released doesn't mean 
>> there
>> isn't some time to wait before it's really shippable.  6 months won't be the
>> end of the world, especially if it's added to an add-on repo someplace so
>> people can get it if they really want something other than ff3.
>>
> 
> Perhaps it's time to figure out how to make things like Tom's chromium
> more official.  Find actual hosting/mirroring for that stuff, make a clear
> path to get people to it but also letting them know "hey, your milage may
> vary".

I would really like to see kopers happen, yes.  That'd be great.

-- 
Peter

I number the Linux folks among my personal heroes.
-- Donald Knuth

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

Re: Firefox 4 for Fedora 14?

[Mike McGrath]

On Wed, 28 Jul 2010, Peter Jones wrote:

> On 07/28/2010 02:25 PM, Mike McGrath wrote:
> > On Wed, 28 Jul 2010, Peter Jones wrote:
> >
> >> On 07/28/2010 01:10 PM, Adam Williamson wrote:
> >>> On Wed, 2010-07-28 at 11:37 -0400, Paul W. Frields wrote:
>  On Wed, Jul 28, 2010 at 03:04:46PM +0200, Florent Le Coz wrote:
> >   On 28/07/2010 14:52, Mike McGrath wrote:
> >> In my opinion including software that even upstream says is not ready 
> >> is
> >> for a distribution that's "lost their way".  We can still be a leading
> >> distribution and not include pre-release software.  Especially 
> >> pre-release
> >> software that's not only in our critical path, but also something that
> >> almost all of us use every day.
> > I agree, but doesn't that mean that Firefox 4.0 won't be available in
> > F14 at all and will only be in F15?
> > I think it would be a huge drawback for Fedora 14.
> 
>  It would be huge if there people who can't live without it didn't have
>  any other way of getting it than having it pre-packaged.  I think
>  Firefox 4 looks to be fantastic, but the truth is that people only
>  have to wait a few months for a release with it pre-packaged, if
>  they're not able to add it on their own.
> >>>
> >>> I'd rather we provide them a package than have people going out and
> >>> installing software from third-party sources (yes, mozilla.org is hardly
> >>> Evil, but it sets a bad precedent). I really don't see much of a reason
> >>> we can't ship it as a post-release update. We'd probably want to do that
> >>> in the end anyway, because Mozilla tends to stop security supporting old
> >>> branches anyway; it's certainly plausible that they stop supporting 3.x
> >>> during F14's support lifetime.
> >>
> >> Just because it isn't in the F14 repo doesn't mean it won't be available to
> >> people who really want a packaged version earlier - look at spot's chromium
> >> packages, for example.  And I really expect the F14-F15 time frame to be a 
> >> very
> >> similar situation with Firefox - just because it's released doesn't mean 
> >> there
> >> isn't some time to wait before it's really shippable.  6 months won't be 
> >> the
> >> end of the world, especially if it's added to an add-on repo someplace so
> >> people can get it if they really want something other than ff3.
> >>
> >
> > Perhaps it's time to figure out how to make things like Tom's chromium
> > more official.  Find actual hosting/mirroring for that stuff, make a clear
> > path to get people to it but also letting them know "hey, your milage may
> > vary".
>
> I would really like to see kopers happen, yes.  That'd be great.
>

Maybe I'm mistaken, I thought kopers was just for building.  Does it
encompass hosting, distribution and such?

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

Re: Firefox 4 for Fedora 14?

[drago01]

On Wed, Jul 28, 2010 at 8:42 PM, Mike McGrath  wrote:
> On Wed, 28 Jul 2010, Peter Jones wrote:
>
>> On 07/28/2010 02:25 PM, Mike McGrath wrote:
>> > On Wed, 28 Jul 2010, Peter Jones wrote:
>> >
>> >> On 07/28/2010 01:10 PM, Adam Williamson wrote:
>> >>> On Wed, 2010-07-28 at 11:37 -0400, Paul W. Frields wrote:
>>  On Wed, Jul 28, 2010 at 03:04:46PM +0200, Florent Le Coz wrote:
>> >   On 28/07/2010 14:52, Mike McGrath wrote:
>> >> In my opinion including software that even upstream says is not ready 
>> >> is
>> >> for a distribution that's "lost their way".  We can still be a leading
>> >> distribution and not include pre-release software.  Especially 
>> >> pre-release
>> >> software that's not only in our critical path, but also something that
>> >> almost all of us use every day.
>> > I agree, but doesn't that mean that Firefox 4.0 won't be available in
>> > F14 at all and will only be in F15?
>> > I think it would be a huge drawback for Fedora 14.
>> 
>>  It would be huge if there people who can't live without it didn't have
>>  any other way of getting it than having it pre-packaged.  I think
>>  Firefox 4 looks to be fantastic, but the truth is that people only
>>  have to wait a few months for a release with it pre-packaged, if
>>  they're not able to add it on their own.
>> >>>
>> >>> I'd rather we provide them a package than have people going out and
>> >>> installing software from third-party sources (yes, mozilla.org is hardly
>> >>> Evil, but it sets a bad precedent). I really don't see much of a reason
>> >>> we can't ship it as a post-release update. We'd probably want to do that
>> >>> in the end anyway, because Mozilla tends to stop security supporting old
>> >>> branches anyway; it's certainly plausible that they stop supporting 3.x
>> >>> during F14's support lifetime.
>> >>
>> >> Just because it isn't in the F14 repo doesn't mean it won't be available 
>> >> to
>> >> people who really want a packaged version earlier - look at spot's 
>> >> chromium
>> >> packages, for example.  And I really expect the F14-F15 time frame to be 
>> >> a very
>> >> similar situation with Firefox - just because it's released doesn't mean 
>> >> there
>> >> isn't some time to wait before it's really shippable.  6 months won't be 
>> >> the
>> >> end of the world, especially if it's added to an add-on repo someplace so
>> >> people can get it if they really want something other than ff3.
>> >>
>> >
>> > Perhaps it's time to figure out how to make things like Tom's chromium
>> > more official.  Find actual hosting/mirroring for that stuff, make a clear
>> > path to get people to it but also letting them know "hey, your milage may
>> > vary".
>>
>> I would really like to see kopers happen, yes.  That'd be great.
>>
>
> Maybe I'm mistaken, I thought kopers was just for building.  Does it
> encompass hosting, distribution and such?

IIRC yes, it just needs to happen  someday ;)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firefox 4 for Fedora 14?

[Mike McGrath]

On Wed, 28 Jul 2010, drago01 wrote:

> On Wed, Jul 28, 2010 at 8:42 PM, Mike McGrath  wrote:
> > On Wed, 28 Jul 2010, Peter Jones wrote:
> >
> >> On 07/28/2010 02:25 PM, Mike McGrath wrote:
> >> > On Wed, 28 Jul 2010, Peter Jones wrote:
> >> >
> >> >> On 07/28/2010 01:10 PM, Adam Williamson wrote:
> >> >>> On Wed, 2010-07-28 at 11:37 -0400, Paul W. Frields wrote:
> >>  On Wed, Jul 28, 2010 at 03:04:46PM +0200, Florent Le Coz wrote:
> >> >   On 28/07/2010 14:52, Mike McGrath wrote:
> >> >> In my opinion including software that even upstream says is not 
> >> >> ready is
> >> >> for a distribution that's "lost their way".  We can still be a 
> >> >> leading
> >> >> distribution and not include pre-release software.  Especially 
> >> >> pre-release
> >> >> software that's not only in our critical path, but also something 
> >> >> that
> >> >> almost all of us use every day.
> >> > I agree, but doesn't that mean that Firefox 4.0 won't be available in
> >> > F14 at all and will only be in F15?
> >> > I think it would be a huge drawback for Fedora 14.
> >> 
> >>  It would be huge if there people who can't live without it didn't have
> >>  any other way of getting it than having it pre-packaged.  I think
> >>  Firefox 4 looks to be fantastic, but the truth is that people only
> >>  have to wait a few months for a release with it pre-packaged, if
> >>  they're not able to add it on their own.
> >> >>>
> >> >>> I'd rather we provide them a package than have people going out and
> >> >>> installing software from third-party sources (yes, mozilla.org is 
> >> >>> hardly
> >> >>> Evil, but it sets a bad precedent). I really don't see much of a reason
> >> >>> we can't ship it as a post-release update. We'd probably want to do 
> >> >>> that
> >> >>> in the end anyway, because Mozilla tends to stop security supporting 
> >> >>> old
> >> >>> branches anyway; it's certainly plausible that they stop supporting 3.x
> >> >>> during F14's support lifetime.
> >> >>
> >> >> Just because it isn't in the F14 repo doesn't mean it won't be 
> >> >> available to
> >> >> people who really want a packaged version earlier - look at spot's 
> >> >> chromium
> >> >> packages, for example.  And I really expect the F14-F15 time frame to 
> >> >> be a very
> >> >> similar situation with Firefox - just because it's released doesn't 
> >> >> mean there
> >> >> isn't some time to wait before it's really shippable.  6 months won't 
> >> >> be the
> >> >> end of the world, especially if it's added to an add-on repo someplace 
> >> >> so
> >> >> people can get it if they really want something other than ff3.
> >> >>
> >> >
> >> > Perhaps it's time to figure out how to make things like Tom's chromium
> >> > more official.  Find actual hosting/mirroring for that stuff, make a 
> >> > clear
> >> > path to get people to it but also letting them know "hey, your milage may
> >> > vary".
> >>
> >> I would really like to see kopers happen, yes.  That'd be great.
> >>
> >
> > Maybe I'm mistaken, I thought kopers was just for building.  Does it
> > encompass hosting, distribution and such?
>
> IIRC yes, it just needs to happen  someday ;)
>

Maybe baby steps?  Small incremental changes.  Sure some features will be
missing that kopers will provide.  But perhaps we could just create a
Fedora-13-devel tag in koji, push it to it's own repo or to individual
fedora-13-spot / fedora-13-mmcgrath repos.  One that doesn't migrate to
updates-testing or updates.  It just sits there.

We're going to need something like this when kopers comes out anyway
right?  I figure smaller steps towards that goal is better then one big
one.

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

Re: Firefox 4 for Fedora 14?

[drago01]

On Wed, Jul 28, 2010 at 9:12 PM, Mike McGrath  wrote:
> On Wed, 28 Jul 2010, drago01 wrote:
>
>> On Wed, Jul 28, 2010 at 8:42 PM, Mike McGrath  wrote:
>> > On Wed, 28 Jul 2010, Peter Jones wrote:
>> >
>> >> On 07/28/2010 02:25 PM, Mike McGrath wrote:
>> >> > On Wed, 28 Jul 2010, Peter Jones wrote:
>> >> >
>> >> >> On 07/28/2010 01:10 PM, Adam Williamson wrote:
>> >> >>> On Wed, 2010-07-28 at 11:37 -0400, Paul W. Frields wrote:
>> >>  On Wed, Jul 28, 2010 at 03:04:46PM +0200, Florent Le Coz wrote:
>> >> >   On 28/07/2010 14:52, Mike McGrath wrote:
>> >> >> In my opinion including software that even upstream says is not 
>> >> >> ready is
>> >> >> for a distribution that's "lost their way".  We can still be a 
>> >> >> leading
>> >> >> distribution and not include pre-release software.  Especially 
>> >> >> pre-release
>> >> >> software that's not only in our critical path, but also something 
>> >> >> that
>> >> >> almost all of us use every day.
>> >> > I agree, but doesn't that mean that Firefox 4.0 won't be available 
>> >> > in
>> >> > F14 at all and will only be in F15?
>> >> > I think it would be a huge drawback for Fedora 14.
>> >> 
>> >>  It would be huge if there people who can't live without it didn't 
>> >>  have
>> >>  any other way of getting it than having it pre-packaged.  I think
>> >>  Firefox 4 looks to be fantastic, but the truth is that people only
>> >>  have to wait a few months for a release with it pre-packaged, if
>> >>  they're not able to add it on their own.
>> >> >>>
>> >> >>> I'd rather we provide them a package than have people going out and
>> >> >>> installing software from third-party sources (yes, mozilla.org is 
>> >> >>> hardly
>> >> >>> Evil, but it sets a bad precedent). I really don't see much of a 
>> >> >>> reason
>> >> >>> we can't ship it as a post-release update. We'd probably want to do 
>> >> >>> that
>> >> >>> in the end anyway, because Mozilla tends to stop security supporting 
>> >> >>> old
>> >> >>> branches anyway; it's certainly plausible that they stop supporting 
>> >> >>> 3.x
>> >> >>> during F14's support lifetime.
>> >> >>
>> >> >> Just because it isn't in the F14 repo doesn't mean it won't be 
>> >> >> available to
>> >> >> people who really want a packaged version earlier - look at spot's 
>> >> >> chromium
>> >> >> packages, for example.  And I really expect the F14-F15 time frame to 
>> >> >> be a very
>> >> >> similar situation with Firefox - just because it's released doesn't 
>> >> >> mean there
>> >> >> isn't some time to wait before it's really shippable.  6 months won't 
>> >> >> be the
>> >> >> end of the world, especially if it's added to an add-on repo someplace 
>> >> >> so
>> >> >> people can get it if they really want something other than ff3.
>> >> >>
>> >> >
>> >> > Perhaps it's time to figure out how to make things like Tom's chromium
>> >> > more official.  Find actual hosting/mirroring for that stuff, make a 
>> >> > clear
>> >> > path to get people to it but also letting them know "hey, your milage 
>> >> > may
>> >> > vary".
>> >>
>> >> I would really like to see kopers happen, yes.  That'd be great.
>> >>
>> >
>> > Maybe I'm mistaken, I thought kopers was just for building.  Does it
>> > encompass hosting, distribution and such?
>>
>> IIRC yes, it just needs to happen  someday ;)
>>
>
> Maybe baby steps?  Small incremental changes.  Sure some features will be
> missing that kopers will provide.  But perhaps we could just create a
> Fedora-13-devel tag in koji, push it to it's own repo or to individual
> fedora-13-spot / fedora-13-mmcgrath repos.  One that doesn't migrate to
> updates-testing or updates.  It just sits there.
>
> We're going to need something like this when kopers comes out anyway
> right?  I figure smaller steps towards that goal is better then one big
> one.

No disagreement here ... in fact this is a not really a "baby step"
but "have something usable and start from there" which makes a lot of
sense.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Test-Announce] Testing Fedora? Please enable SELinux if you can

[Adam Williamson]

I've been asked by FESCo to post this public service announcement :)

We'd just like to remind those who test Fedora, in whatever
way...running a stable release with updates-testing, running Rawhide,
being a proven tester (especially)...that it's best if you test with
SELinux enabled and enforcing. This is the default configuration of
Fedora, so we need testers to be running with this configuration so we
don't miss problems that show up when SELinux is running.

For proven testers, I actually added a section about this to the
instructions recently -
https://fedoraproject.org/wiki/Proven_tester#Testing_process .

We recognize there may be situations when SELinux causes problems and
you need to make it permissive or turn it off temporarily, but please
try and keep it turned on if you possibly can, and if you're in a
situation where you need to disable it, please let the developers know
by filing a bug, so they can fix it and you can turn it back on. Thanks
a lot!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

coprs and personal repos: [Was: Re: Firefox 4 for Fedora 14?]

[seth vidal]

On Wed, 2010-07-28 at 14:12 -0500, Mike McGrath wrote:

> Maybe baby steps?  Small incremental changes.  Sure some features will be
> missing that kopers will provide.  But perhaps we could just create a
> Fedora-13-devel tag in koji, push it to it's own repo or to individual
> fedora-13-spot / fedora-13-mmcgrath repos.  One that doesn't migrate to
> updates-testing or updates.  It just sits there.


> 
> We're going to need something like this when kopers comes out anyway
> right?  I figure smaller steps towards that goal is better then one big
> one.

Toshio and I have talked about the targets of coprs and what the
problems are we're trying to solve. Here are the problems:

1. I want to build these pkgs which have small patches to what's in
fedora but I don't have the archs to build them on
   :solved by scratch builds in koji

2. I want to build these pkgs which have patches/changes to what's in
fedora but I don't have the machines to build them on
   :solved by scratch builds in koji

3. I want to build these pkgs which have patches/changes to what's in
fedora but I don't have a place to host them
   :provided, but not explicitly encouraged or endorsed by
fedorapeople.org

4. I want to build these pkgs and they have new deps on pkgs which are
not in fedora and I need to chain-build them from arbitrary
   :not provided by anything currently since you cannot build pkgs in
koji with arbitrary deps from arbitrary repos.


Item 4 is the main point that has been the big ticket item that things
like Canonical's PPAs have hit.

Since the other 3 had some relatively-possible solution Toshio and I
started down the path of solving #4 since that was the only explicitly
unsolved problem.

Now - I think it would be perfectly reasonable for us to come up with a
better/more official solution for #3. It's pretty simple to implement.
We could setup a:
http://repos.fedoraproject.org/$username/reponame/

it would be as simple as a subdir/path on the current fedorapeople (but
using the repos hostname so we could move it later if needs demanded it)

so - in theory we could have repos like:

http://repos.fp.o/skvidal/func-future/
or
http://repos.fp.o/func-group/func-future/

and extend out from there.

then when item #4 is fully solved we could move this hierarchy to be
used by coprs.

It's a good place to start.

-sv


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

Re: Python 2.7 status: python2.7 is in dist-f14

[Bill Nottingham]

Adam Williamson (awill...@redhat.com) said: 
> Still, if they were in the py27 tag they *must* need to be rebuilt again
> anyway, because the later builds in Rawhide would have been against
> Python 2.6 and hence would be broken anyway. So in practice it doesn't
> make a huge different, AFAICT.

Boost had python bindings. Most things that use boost don't use that,
so it's more of a net win to do the boost rebuilds against the right major
version of boost in conjunction with rebuilding boost for its python
bindings, rather than building against the old version of boost with working
python bindings.

Bill

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

Re: coprs and personal repos: [Was: Re: Firefox 4 for Fedora 14?]

[drago01]

On Wed, Jul 28, 2010 at 9:37 PM, seth vidal  wrote:
> On Wed, 2010-07-28 at 14:12 -0500, Mike McGrath wrote:
>
>> Maybe baby steps?  Small incremental changes.  Sure some features will be
>> missing that kopers will provide.  But perhaps we could just create a
>> Fedora-13-devel tag in koji, push it to it's own repo or to individual
>> fedora-13-spot / fedora-13-mmcgrath repos.  One that doesn't migrate to
>> updates-testing or updates.  It just sits there.
>
>
>>
>> We're going to need something like this when kopers comes out anyway
>> right?  I figure smaller steps towards that goal is better then one big
>> one.
>
> Toshio and I have talked about the targets of coprs and what the
> problems are we're trying to solve. Here are the problems:
>
> 1. I want to build these pkgs which have small patches to what's in
> fedora but I don't have the archs to build them on
>   :solved by scratch builds in koji
>
> 2. I want to build these pkgs which have patches/changes to what's in
> fedora but I don't have the machines to build them on
>   :solved by scratch builds in koji
>
> 3. I want to build these pkgs which have patches/changes to what's in
> fedora but I don't have a place to host them
>   :provided, but not explicitly encouraged or endorsed by
> fedorapeople.org
>
> 4. I want to build these pkgs and they have new deps on pkgs which are
> not in fedora and I need to chain-build them from arbitrary
>   :not provided by anything currently since you cannot build pkgs in
> koji with arbitrary deps from arbitrary repos.

5. Some easy way to enable/disable such repos other than messing with
config files?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: coprs and personal repos: [Was: Re: Firefox 4 for Fedora 14?]

[seth vidal]

On Wed, 2010-07-28 at 21:49 +0200, drago01 wrote:
> On Wed, Jul 28, 2010 at 9:37 PM, seth vidal  wrote:
> > On Wed, 2010-07-28 at 14:12 -0500, Mike McGrath wrote:
> >
> >> Maybe baby steps?  Small incremental changes.  Sure some features will be
> >> missing that kopers will provide.  But perhaps we could just create a
> >> Fedora-13-devel tag in koji, push it to it's own repo or to individual
> >> fedora-13-spot / fedora-13-mmcgrath repos.  One that doesn't migrate to
> >> updates-testing or updates.  It just sits there.
> >
> >
> >>
> >> We're going to need something like this when kopers comes out anyway
> >> right?  I figure smaller steps towards that goal is better then one big
> >> one.
> >
> > Toshio and I have talked about the targets of coprs and what the
> > problems are we're trying to solve. Here are the problems:
> >
> > 1. I want to build these pkgs which have small patches to what's in
> > fedora but I don't have the archs to build them on
> >   :solved by scratch builds in koji
> >
> > 2. I want to build these pkgs which have patches/changes to what's in
> > fedora but I don't have the machines to build them on
> >   :solved by scratch builds in koji
> >
> > 3. I want to build these pkgs which have patches/changes to what's in
> > fedora but I don't have a place to host them
> >   :provided, but not explicitly encouraged or endorsed by
> > fedorapeople.org
> >
> > 4. I want to build these pkgs and they have new deps on pkgs which are
> > not in fedora and I need to chain-build them from arbitrary
> >   :not provided by anything currently since you cannot build pkgs in
> > koji with arbitrary deps from arbitrary repos.
> 
> 5. Some easy way to enable/disable such repos other than messing with
> config files?

yum-config-manager --enable repo1 repo2 repo3

-sv


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

Re: coprs and personal repos: [Was: Re: Firefox 4 for Fedora 14?]

[Bill Nottingham]

drago01 (drag...@gmail.com) said: 
> 5. Some easy way to enable/disable such repos other than messing with
> config files?

yum-plugin-tmprepo? (This may not fit your definition of 'easy'.)

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

Re: coprs and personal repos: [Was: Re: Firefox 4 for Fedora 14?]

[Frank Murphy]

On 28/07/10 20:49, drago01 wrote:

>
> 5. Some easy way to enable/disable such repos other than messing with
> config files?

gnome-packagekit-extra
tick what you need.

-- 
Regards,

Frank Murphy
UTF_8 Encoded
Friend of Fedora
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Crash on Subcommander 2.0.0 Beta 5

[Jochen Schmitt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hallo,

unfortunately, an user has reported an crash on subcommander 2.0.0 Beta 5
in the following bug report:

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

Because, I have no idea, what was going wrong, I would post this
message to the list in the hope that anyone can give me a hint
to fix this issue.

Best Regards:

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

iJwEAQECAAYFAkxQjXkACgkQZLAIBz9lVu/s0QP/aergLcxv3WGMwd8r2COQu1vT
v+Tkc5EAV64045XsqdlC0KAfzJZKaK1sVla3wphDlSsraI5Ey2CSxU0jyUX80aSB
6DBt9iLgt06ao6aVMCmfB4tNWbN5am07zGLDwesW7Cs03B2ILL9aCdW1kTpQYVZd
+JMhTALd2zJzSvBQDUc=
=/U9a
-END PGP SIGNATURE-

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

Re: coprs and personal repos: [Was: Re: Firefox 4 for Fedora 14?]

[Dan Williams]

On Wed, 2010-07-28 at 15:37 -0400, seth vidal wrote:
> On Wed, 2010-07-28 at 14:12 -0500, Mike McGrath wrote:
> 
> > Maybe baby steps?  Small incremental changes.  Sure some features will be
> > missing that kopers will provide.  But perhaps we could just create a
> > Fedora-13-devel tag in koji, push it to it's own repo or to individual
> > fedora-13-spot / fedora-13-mmcgrath repos.  One that doesn't migrate to
> > updates-testing or updates.  It just sits there.
> 
> 
> > 
> > We're going to need something like this when kopers comes out anyway
> > right?  I figure smaller steps towards that goal is better then one big
> > one.
> 
> Toshio and I have talked about the targets of coprs and what the
> problems are we're trying to solve. Here are the problems:
> 
> 1. I want to build these pkgs which have small patches to what's in
> fedora but I don't have the archs to build them on
>:solved by scratch builds in koji
> 
> 2. I want to build these pkgs which have patches/changes to what's in
> fedora but I don't have the machines to build them on
>:solved by scratch builds in koji
> 
> 3. I want to build these pkgs which have patches/changes to what's in
> fedora but I don't have a place to host them
>:provided, but not explicitly encouraged or endorsed by
> fedorapeople.org
> 
> 4. I want to build these pkgs and they have new deps on pkgs which are
> not in fedora and I need to chain-build them from arbitrary
>:not provided by anything currently since you cannot build pkgs in
> koji with arbitrary deps from arbitrary repos.
> 
> 
> Item 4 is the main point that has been the big ticket item that things
> like Canonical's PPAs have hit.

They also hit the Staples Easy Button about 1000 times.  If there's a
case to be made that this should be easy to do, then we should add
tolling to common/Makefile to:

1) make an srpm
2) build it as a scratch build in koji
3) automatically download the built packages
4) scp them to your fedorapeople account
5) run createrepo remotely on the fp account
6) generate a yum .repo file for the repo and print out a link to it or
something

ie, enable doing this with *one* command in the dist-cvs/git checkout,
like 'make ppa' or 'fedpkg ppa' that will do all these steps for you.

Dan

> Since the other 3 had some relatively-possible solution Toshio and I
> started down the path of solving #4 since that was the only explicitly
> unsolved problem.
> 
> Now - I think it would be perfectly reasonable for us to come up with a
> better/more official solution for #3. It's pretty simple to implement.
> We could setup a:
> http://repos.fedoraproject.org/$username/reponame/
> 
> it would be as simple as a subdir/path on the current fedorapeople (but
> using the repos hostname so we could move it later if needs demanded it)
> 
> so - in theory we could have repos like:
> 
> http://repos.fp.o/skvidal/func-future/
> or
> http://repos.fp.o/func-group/func-future/
> 
> and extend out from there.
> 
> then when item #4 is fully solved we could move this hierarchy to be
> used by coprs.
> 
> It's a good place to start.
> 
> -sv
> 
> 


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

Re: coprs and personal repos: [Was: Re: Firefox 4 for Fedora 14?]

[drago01]

On Wed, Jul 28, 2010 at 9:51 PM, seth vidal  wrote:
> On Wed, 2010-07-28 at 21:49 +0200, drago01 wrote:
>> On Wed, Jul 28, 2010 at 9:37 PM, seth vidal  
>> wrote:
>> > On Wed, 2010-07-28 at 14:12 -0500, Mike McGrath wrote:
>> >
>> >> Maybe baby steps?  Small incremental changes.  Sure some features will be
>> >> missing that kopers will provide.  But perhaps we could just create a
>> >> Fedora-13-devel tag in koji, push it to it's own repo or to individual
>> >> fedora-13-spot / fedora-13-mmcgrath repos.  One that doesn't migrate to
>> >> updates-testing or updates.  It just sits there.
>> >
>> >
>> >>
>> >> We're going to need something like this when kopers comes out anyway
>> >> right?  I figure smaller steps towards that goal is better then one big
>> >> one.
>> >
>> > Toshio and I have talked about the targets of coprs and what the
>> > problems are we're trying to solve. Here are the problems:
>> >
>> > 1. I want to build these pkgs which have small patches to what's in
>> > fedora but I don't have the archs to build them on
>> >   :solved by scratch builds in koji
>> >
>> > 2. I want to build these pkgs which have patches/changes to what's in
>> > fedora but I don't have the machines to build them on
>> >   :solved by scratch builds in koji
>> >
>> > 3. I want to build these pkgs which have patches/changes to what's in
>> > fedora but I don't have a place to host them
>> >   :provided, but not explicitly encouraged or endorsed by
>> > fedorapeople.org
>> >
>> > 4. I want to build these pkgs and they have new deps on pkgs which are
>> > not in fedora and I need to chain-build them from arbitrary
>> >   :not provided by anything currently since you cannot build pkgs in
>> > koji with arbitrary deps from arbitrary repos.
>>
>> 5. Some easy way to enable/disable such repos other than messing with
>> config files?
>
> yum-config-manager --enable repo1 repo2 repo3

My wording might not have been the best with enable I actually meant install.

something like
copers --enable foo
copers --disable foo

which would download and set up the repo.

(Shouldn't be really hard to do though)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: coprs and personal repos: [Was: Re: Firefox 4 for Fedora 14?]

[seth vidal]

On Wed, 2010-07-28 at 15:10 -0700, Dan Williams wrote:
> > Item 4 is the main point that has been the big ticket item that things
> > like Canonical's PPAs have hit.
> 
> They also hit the Staples Easy Button about 1000 times.  If there's a
> case to be made that this should be easy to do, then we should add
> tolling to common/Makefile to:
> 
> 1) make an srpm
check

> 2) build it as a scratch build in koji
check

> 3) automatically download the built packages
check

3.5) Sign the pkgs with your (or someone's) gpg key
   not-so-check

> 4) scp them to your fedorapeople account

   unchecked

> 5) run createrepo remotely on the fp account

   createrepo is not fp, on purpose, this could be changed - but it's
better to run it locally, if only b/c of whatever arbitrary arguments
you may want to add to it - not to mention the memory constraints.

> 6) generate a yum .repo file for the repo and print out a link to it or
> something

   sure. - though we'd be better off generating an rpm which contains
the .repo file - so people could 'install' the repositories in the
strictest sense.

-sv



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

F14 Wallpapers Package -- Need a Review

[Martin Sourada]

Hi all,

As some of you might know, we (the Fedora Design Team) would like to
have first wallpapers available in Alpha release. So I've prepared a
package with them (pretty much reusing spec file from previous releases)
which is now awaiting a review:
https://bugzilla.redhat.com/show_bug.cgi?id=618852

If anyone would be so kind to quickly review the package it would be
more than welcome (we'd like to make it in *before* alpha freeze).

I'm willing to do a swap review in return :)

Thanks,
Martin


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firefox 4 for Fedora 14?

[ニール・ゴンパ]

On Wed, Jul 28, 2010 at 2:16 PM, drago01  wrote:

>
> No disagreement here ... in fact this is a not really a "baby step"
> but "have something usable and start from there" which makes a lot of
> sense.
>
>
As much as I want Chromium to be in Fedora, I don't want it in the
repository if it is going to have crippled HTML5 support. It will make
Fedora look even worse than it already does for multimedia support. As for
Firefox 4, I'd rather have a beta included in Fedora than an older version.
However, Firefox 4 is tracked for an October 15 release. As far as I'm
aware, Fedora 14 is still tracked for an October 26. Even if Fedora 14's
release schedule doesn't slip (and we know it will, there's not been a
release in a long time that Fedora hasn't slipped), the final version of
Firefox 4 should be ready in time for final release of Fedora 14.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [HEADS-UP] systemd is now the default init system in rawhide

[darrell pfeifer]

On Sat, Jul 24, 2010 at 23:34, Kevin Fenzi  wrote:

> >>
>
> First it seems that my boot would fail. It was unable to find or run a
> 'default.target' and would hang. Unfortunately it advises you to check
> the logs, but since syslog isn't up yet and you can't do anything to
> look at dmesg thats not very helpfull. ;(
>
> If there is no /etc/systemd/system/default.target could we fall back to
> a single user target?
>
> Also, in my switchover, I got no getty's setup by default. Happily I
> was able to figure out how to add them here by looking at the FAQ (once
> I found it. ;)
>
> What symbolic link did you set to get a graphical target?

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

Re: Firefox 4 for Fedora 14?

[Tom "spot" Callaway]

On 07/28/2010 04:47 PM, Conan Kudo (ニール・ゴンパ) wrote:
> On Wed, Jul 28, 2010 at 2:16 PM, drago01  > wrote:
> 
> 
> No disagreement here ... in fact this is a not really a "baby step"
> but "have something usable and start from there" which makes a lot of
> sense.
> 
> 
> As much as I want Chromium to be in Fedora, I don't want it in the
> repository if it is going to have crippled HTML5 support. 

To be fair, Chromium uses ffmpeg for its HTML5. If you have ffmpeg
installed (with my Chromium builds), then you get HTML5 support. If you
don't, well, you don't. Chromium isn't "crippled". Fedora just can't
include ffmpeg for obvious reasons, and Chromium has chosen not to use
the native libv8 code.

~spot
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [HEADS-UP] systemd is now the default init system in rawhide

[Kevin Fenzi]

On Wed, 28 Jul 2010 13:55:23 -0700
darrell pfeifer  wrote:

> On Sat, Jul 24, 2010 at 23:34, Kevin Fenzi  wrote:
> 
> > >>
> >
> > First it seems that my boot would fail. It was unable to find or
> > run a 'default.target' and would hang. Unfortunately it advises you
> > to check the logs, but since syslog isn't up yet and you can't do
> > anything to look at dmesg thats not very helpfull. ;(
> >
> > If there is no /etc/systemd/system/default.target could we fall
> > back to a single user target?
> >
> > Also, in my switchover, I got no getty's setup by default. Happily I
> > was able to figure out how to add them here by looking at the FAQ
> > (once I found it. ;)
> >
> What symbolic link did you set to get a graphical target?

ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target

kevin



signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Crash on Subcommander 2.0.0 Beta 5

[Julian Aloofi]

Am Mittwoch, den 28.07.2010, 22:05 +0200 schrieb Jochen Schmitt:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hallo,
> 
> unfortunately, an user has reported an crash on subcommander 2.0.0 Beta 5
> in the following bug report:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=619182
> 
> Because, I have no idea, what was going wrong, I would post this
> message to the list in the hope that anyone can give me a hint
> to fix this issue.
> 
> Best Regards:
> 
> Jochen Schmitt

I see you already forwarded it to the upstream bugtracker. Just add a
link to the upstream bug, and that's enough if you're not capable of
fixing it. :)

Regards,
Julian


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firefox 4 for Fedora 14?

[Martin Sourada]

On Wed, 2010-07-28 at 16:58 -0400, Tom "spot" Callaway wrote: 
> On 07/28/2010 04:47 PM, Conan Kudo (ニール・ゴンパ) wrote:
> > On Wed, Jul 28, 2010 at 2:16 PM, drago01  > > wrote:
> > 
> > 
> > No disagreement here ... in fact this is a not really a "baby step"
> > but "have something usable and start from there" which makes a lot of
> > sense.
> > 
> > 
> > As much as I want Chromium to be in Fedora, I don't want it in the
> > repository if it is going to have crippled HTML5 support. 
> 
> To be fair, Chromium uses ffmpeg for its HTML5. If you have ffmpeg
> installed (with my Chromium builds), then you get HTML5 support. If you
> don't, well, you don't. Chromium isn't "crippled". Fedora just can't
> include ffmpeg for obvious reasons, and Chromium has chosen not to use
> the native libv8 code.
> 
Speaking of which, is there any chance to split ffmpeg into free (which
could be included in fedora) and nonfree part? IIRC we've done something
like that with xine-lib-extras and gst-plugins-bad in the past...

Martin


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firefox 4 for Fedora 14?

[Adam Williamson]

On Wed, 2010-07-28 at 23:28 +0200, Martin Sourada wrote:

> Speaking of which, is there any chance to split ffmpeg into free (which
> could be included in fedora) and nonfree part? IIRC we've done something
> like that with xine-lib-extras and gst-plugins-bad in the past...

ffmpeg, unfortunately, isn't set up to be modularised like this; you
can't build an ffmpeg-free with the free codecs and an ffmpeg-patented
with the patented ones and have them co-exist nicely. So an ffmpeg build
with almost all the codecs ripped out in the Fedora repos would
'compete' with the full build in That Other Repo, not complement it, and
the way the two repos are set up, it would be tricky to have a
handicapped build in the Fedora repo and a full build in That Other One
and have it easy for people to pick the one from That Other Repo (since
Other Repo packages use the same disttag as Fedora ones).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

Re: Firefox 4 for Fedora 14?

[ニール・ゴンパ]

On Wed, Jul 28, 2010 at 4:38 PM, Adam Williamson wrote:

> On Wed, 2010-07-28 at 23:28 +0200, Martin Sourada wrote:
>
> > Speaking of which, is there any chance to split ffmpeg into free (which
> > could be included in fedora) and nonfree part? IIRC we've done something
> > like that with xine-lib-extras and gst-plugins-bad in the past...
>
> ffmpeg, unfortunately, isn't set up to be modularised like this; you
> can't build an ffmpeg-free with the free codecs and an ffmpeg-patented
> with the patented ones and have them co-exist nicely. So an ffmpeg build
> with almost all the codecs ripped out in the Fedora repos would
> 'compete' with the full build in That Other Repo, not complement it, and
> the way the two repos are set up, it would be tricky to have a
> handicapped build in the Fedora repo and a full build in That Other One
> and have it easy for people to pick the one from That Other Repo (since
> Other Repo packages use the same disttag as Fedora ones).
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
> http://www.happyassassin.net
>
>
That is assuming that "the other repo" uses the same name as Fedora's.
Fedora could call it ffmpeg-free, and "the other repo" could call it
ffmpeg-nonfree, and have the nonfree one obsolete the free one. Simple fix,
I think.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firefox 4 for Fedora 14?

[Orcan Ogetbil]

On Wed, Jul 28, 2010 at 4:58 PM, Tom "spot" Callaway wrote:
> Fedora just can't
> include ffmpeg for obvious reasons,

How many more years are we talking about for ffmpeg?

Speaking of which, when can we include a mp3 decoder library in
Fedora? I heard that all mp3 decoding patents will expire in 2012.
There are a few encoding patents that will expire in 2015-16.

Are we going to wait until all mp3 encoders become patent-free to
include decoders in Fedora? (Same question applies to video codecs.)

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

Re: Firefox 4 for Fedora 14?

[Bill Nottingham]

Orcan Ogetbil (oget.fed...@gmail.com) said: 
> On Wed, Jul 28, 2010 at 4:58 PM, Tom "spot" Callaway wrote:
> > Fedora just can't
> > include ffmpeg for obvious reasons,
> 
> How many more years are we talking about for ffmpeg?

Given that ffmpeg continues to add new codecs (AFAIK), approximately
MAXINT?

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

Re: Firefox 4 for Fedora 14?

[Bruno Wolff III]

On Wed, Jul 28, 2010 at 17:00:01 -0500,
  "Conan Kudo (ニール・ゴンパ)"  wrote:
> On Wed, Jul 28, 2010 at 4:38 PM, Adam Williamson wrote:
> 
> That is assuming that "the other repo" uses the same name as Fedora's.
> Fedora could call it ffmpeg-free, and "the other repo" could call it
> ffmpeg-nonfree, and have the nonfree one obsolete the free one. Simple fix,
> I think.

"conflicts" would probably be more appropriate than "obsoletes".
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Gnome 3 delayed

[Chris Jones]

On Thu, Jul 29, 2010 at 12:36 AM, James Laska  wrote:
>
> On Wed, 2010-07-28 at 16:27 +0200, Michał Piotrowski wrote:
> > Hi,
> >
> > It seems that Gnome 3 will be released in march 2011. How will this
> > affect Fedora 14? Gnome 3 was an important feature of F14.
> >
> > http://lwn.net/Articles/397482/
>
> I believe it will continued to be offered as an experimental option.
> From http://fedoraproject.org/wiki/Features/Gnome3#Contingency_Plan ...
>
> "If gnome-shell is not complete or stable enough, keep it experimental
> and stay with 'classical GNOME' as the default. Users will still be able
> to try the shell manually, just like in F12 and F13. "
>
> Thanks,
> James
>

I'm not going to pretend that I'm not pleased about the delay. I plan
to keep using G2 for as long as I possible can, long after the Gnome 3
release.

Regards


--
http://home.comcen.com.au/foxmulder881/signature/details.html
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Gnome 3 delayed

[Michał Piotrowski]

2010/7/28 James Laska :
> On Wed, 2010-07-28 at 16:27 +0200, Michał Piotrowski wrote:
>> Hi,
>>
>> It seems that Gnome 3 will be released in march 2011. How will this
>> affect Fedora 14? Gnome 3 was an important feature of F14.
>>
>> http://lwn.net/Articles/397482/
>
> I believe it will continued to be offered as an experimental option.
> From http://fedoraproject.org/wiki/Features/Gnome3#Contingency_Plan ...
>
> "If gnome-shell is not complete or stable enough, keep it experimental
> and stay with 'classical GNOME' as the default. Users will still be able
> to try the shell manually, just like in F12 and F13. "
>

Good to know that there is a contingency plan.

Regards,
Michal
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Gnome 3 delayed

[Michał Piotrowski]

2010/7/29 Chris Jones :
> On Thu, Jul 29, 2010 at 12:36 AM, James Laska  wrote:
>>
>> On Wed, 2010-07-28 at 16:27 +0200, Michał Piotrowski wrote:
>> > Hi,
>> >
>> > It seems that Gnome 3 will be released in march 2011. How will this
>> > affect Fedora 14? Gnome 3 was an important feature of F14.
>> >
>> > http://lwn.net/Articles/397482/
>>
>> I believe it will continued to be offered as an experimental option.
>> From http://fedoraproject.org/wiki/Features/Gnome3#Contingency_Plan ...
>>
>> "If gnome-shell is not complete or stable enough, keep it experimental
>> and stay with 'classical GNOME' as the default. Users will still be able
>> to try the shell manually, just like in F12 and F13. "
>>
>> Thanks,
>> James
>>
>
> I'm not going to pretend that I'm not pleased about the delay. I plan
> to keep using G2 for as long as I possible can, long after the Gnome 3
> release.

Is it possible to disable gnome-shell in the gnome 3? Or because it is
not the case you want to continue to use gname 2?

Regards,
Michal

BTW. I know how difficult this transition can be - I still do not like
kde 4 when I liked a kde 3...
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Fedora 14 Milestone Reached: Feature Freeze-2010-07-27

[John Poelstra]

Yesterday, July 27, 2010, we reached Feature Freeze for Fedora 14

As previously noted, at Feature Freeze it is expected that all features 
are *significantly* "feature complete" and ready for testing: 
https://fedoraproject.org/wiki/Feature_Freeze_Policy.

A review of the status section on the following feature pages shows that 
the following feature pages have not had a recent update OR the feature 
does not appear to be "feature complete" based on the information 
provided.

https://fedoraproject.org/wiki/Features/CryptographyInKernel
https://fedoraproject.org/wiki/Features/MultipathInstall (last updated 
in February)
https://fedoraproject.org/wiki/Features/D_Programming
https://fedoraproject.org/wiki/Features/MeeGo_1.0 (is this really 
feature complete if packages still need to be reviewed?)
https://fedoraproject.org/wiki/Features/Erlang_R14
https://fedoraproject.org/wiki/Features/Gnome3 (listed at 55% done)
https://fedoraproject.org/wiki/Features/Spice
https://fedoraproject.org/wiki/Features/Go_Programming
https://fedoraproject.org/wiki/Features/EC2
https://fedoraproject.org/wiki/Features/systemd

Feature owners, please update your feature page as soon as possible so 
that we have the most current information possible going into our first 
test release.  Feature pages which are not updated or show the feature 
as significantly complete or testable by 2010-08-02 will be sent to 
FESCo for reconsideration.

Thank you,
John

p.s. all feature owners have been bcc'd on this email


___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 14 Milestone Reached: Feature Freeze-2010-07-27

[John Poelstra]

Jonathan MERCIER said the following on 07/28/2010 06:37 PM Pacific Time:
> For D Programming Feature:
> ldc is in stable repo
> tango is in review https://bugzilla.redhat.com/show_bug.cgi?id=608069 by
> Chen Lei.
>
> For guideline i do a draft and ticket is open for review:
> https://fedorahosted.org/fpc/ticket/7#comment:2
>
> Extra Feature:
> I work for add an environnemnt for D programmer:
> - i package derelict for create D application using OpenGl
> * https://bugzilla.redhat.com/show_bug.cgi?id=618668
> * if someone want take this review feel free
> - I try to patch DWT2 is SWT port to D, but developper will be away for
> a few weeks, so i think this package will come for september (i hope
> before)
> - after DWT i will package poseidon an IDE using DWT
>
> For me  D Programming Feature is done i waiting review for guideline and
> tango. Some extra Feature will come later.
>
> best regards

If the packages aren't reviewed and in rawhide by now this feature will 
need to wait until Fedora 15.

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

Re: [HEADS-UP] systemd is now the default init system in rawhide

[darrell pfeifer]

I installed the latest systemd and added the appropriate symbolic link to
graphical startup.

My system hangs when almost complete at the plymouth throbber. In text mode
it gets to the end of starting services and hangs. gdm never starts.

In /var/log/messages, these seem to be the suspicious lines

Jul 28 14:21:26 darrell init[1]: Job
dev-mapper-vg_darrell\x1dlv_root.device/start timed out.
Jul 28 14:21:26 darrell kernel: init[1]: Job
dev-mapper-vg_darrell\x1dlv_root.device/start timed out.
Jul 28 14:21:35 darrell init[1]: Job
dev-disk-by\x1duuid-f060d5d3\x1ddef6\x1d4247\x1d9162\x1da810e55ca01c.device/s
tart timed out.
Jul 28 14:21:35 darrell kernel: init[1]: Job
dev-disk-by\x1duuid-f060d5d3\x1ddef6\x1d4247\x1d9162\x1da810e55ca01c.
device/start timed out.

df shows the volume as

/dev/mapper/vg_darrell-lv_root

Any suggestions?

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

Re: Firefox 4 for Fedora 14?

[Chen Lei]

2010/7/29 Conan Kudo (ニール・ゴンパ) :
> On Wed, Jul 28, 2010 at 4:38 PM, Adam Williamson 
> wrote:
>>
>> On Wed, 2010-07-28 at 23:28 +0200, Martin Sourada wrote:
>>
>> > Speaking of which, is there any chance to split ffmpeg into free (which
>> > could be included in fedora) and nonfree part? IIRC we've done something
>> > like that with xine-lib-extras and gst-plugins-bad in the past...
>>
>> ffmpeg, unfortunately, isn't set up to be modularised like this; you
>> can't build an ffmpeg-free with the free codecs and an ffmpeg-patented
>> with the patented ones and have them co-exist nicely. So an ffmpeg build
>> with almost all the codecs ripped out in the Fedora repos would
>> 'compete' with the full build in That Other Repo, not complement it, and
>> the way the two repos are set up, it would be tricky to have a
>> handicapped build in the Fedora repo and a full build in That Other One
>> and have it easy for people to pick the one from That Other Repo (since
>> Other Repo packages use the same disttag as Fedora ones).
>> --
>> Adam Williamson
>> Fedora QA Community Monkey
>> IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
>> http://www.happyassassin.net
>>
>
> That is assuming that "the other repo" uses the same name as Fedora's.
> Fedora could call it ffmpeg-free, and "the other repo" could call it
> ffmpeg-nonfree, and have the nonfree one obsolete the free one. Simple fix,
> I think.
> --

The issue is who can split the patent free codecs from ffmepg?
Obviously, ffmpeg upstream don't like this idea, maintaining a fedora
specfic ffmepg isn't a easy job.


Regards,
Chen Lei
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [HEADS-UP] systemd is now the default init system in rawhide

[goineasy9]

Add init=/sbin/upstart to the end of the kernel line and it will boot up using 
upstart.  Last lines in my boot read failing to load default.service and then 
failing to start default.service.





-Original Message-
From: darrell pfeifer 
To: Development discussions related to Fedora 
Sent: Wed, Jul 28, 2010 5:59 pm
Subject: Re: [HEADS-UP] systemd is now the default init system in rawhide


I installed the latest systemd and added the appropriate symbolic link to 
graphical startup.


My system hangs when almost complete at the plymouth throbber. In text mode it 
gets to the end of starting services and hangs. gdm never starts.


In /var/log/messages, these seem to be the suspicious lines



Jul 28 14:21:26 darrell init[1]: Job 
dev-mapper-vg_darrell\x1dlv_root.device/start timed out.
Jul 28 14:21:26 darrell kernel: init[1]: Job 
dev-mapper-vg_darrell\x1dlv_root.device/start timed out.
Jul 28 14:21:35 darrell init[1]: Job 
dev-disk-by\x1duuid-f060d5d3\x1ddef6\x1d4247\x1d9162\x1da810e55ca01c.device/s
tart timed out.
Jul 28 14:21:35 darrell kernel: init[1]: Job 
dev-disk-by\x1duuid-f060d5d3\x1ddef6\x1d4247\x1d9162\x1da810e55ca01c.
device/start timed out.



df shows the volume as


/dev/mapper/vg_darrell-lv_root


Any suggestions?


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

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

Fedora 14 Alpha Blocker Meeting #3 Friday @ 16:00 UTC

[John Poelstra]

Open Fedora 14 Alpha Blocker Bugs = 6
Days until Release Candidate Compose = 8

Here's the run down on the current open Fedora 14 Alpha Blocker bugs

615443 :: NEW :: livecd-tools :: David Huff :: booting live images from 
nightly fails (can't mount root filesystem) :: 
https://bugzilla.redhat.com/show_bug.cgi?id=615443
--This bug was reported on July 16, 2010, coming up on two weeks ago. 
Still no comments from the maintainer.


597858 :: NEW :: firefox :: Gecko Maintainer :: "SELinux is preventing 
firefox from making its memory writable and executable." crashes rawhide 
firefox start :: https://bugzilla.redhat.com/show_bug.cgi?id=597858
--It's unclear if this should remain a blocker bug.  FESCo discussed it 
briefly at their meeting on Tuesday and most people seemed ambivalent 
about the issue.  Need a clear position statement from the maintainer or 
FESCo.


617166 :: NEW :: rpm :: Panu Matilainen :: find-debuginfo.sh change for 
gdb index :: https://bugzilla.redhat.com/show_bug.cgi?id=617166
--It's unclear if this bug should be considered a blocker for releasing. 
  It allegedly blocks the completion of a feature.  We do not have 
current release criteria that addresses that scenario.


619238 :: NEW :: distribution :: Bill Nottingham :: can't login to 
normal rawhide install :: https://bugzilla.redhat.com/show_bug.cgi?id=619238
--Reported yesterday.  Need input from maintainer.


618504 :: NEW :: xmlrpc-c :: Enrico Scholz :: Can not submit abrt bugs 
:: https://bugzilla.redhat.com/show_bug.cgi?id=618504
--Discussion in the comments if this is a blocker bug or not. Would be 
good to get some feedback from the maintainer and QA before Friday's 
blocker review meeting.


617115 :: ON_QA :: livecd-tools :: David Huff :: rawhide live spins 
showing black screen instead of syslinux boot menu :: 
https://bugzilla.redhat.com/show_bug.cgi?id=617115
--A fix has been submitted and testing is in process
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [HEADS-UP] systemd is now the default init system in rawhide

[darrell pfeifer]

On Wed, Jul 28, 2010 at 19:33,  wrote:

> Add init=/sbin/upstart to the end of the kernel line and it will boot up
> using upstart.  Last lines in my boot read failing to load default.service
> and then failing to start default.service.
>
> Check one of the recent previous messages.

ln -sf /lib/systemd/system/graphical.target
/etc/systemd/system/default.target

Will solve that problem and get you a bit further along the way.

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

Re: [HEADS-UP] systemd is now the default init system in rawhide

[goineasy9]

I found a fix on bugzilla:
rpm -e --nodeps systemd-units
yum install systemd-units
Which created the symlinks and default.service which seemed to be missing, and 
allowed the boot to finish, but I may have been to quick to use it.  One CPU 
core is at maximum and Chrome won't open, so I'm temporarily back to upstart 
till I get time to look at it further.


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


-Original Message-
From: darrell pfeifer 
To: Development discussions related to Fedora 
Sent: Wed, Jul 28, 2010 6:46 pm
Subject: Re: [HEADS-UP] systemd is now the default init system in rawhide





On Wed, Jul 28, 2010 at 19:33,   wrote:

Add init=/sbin/upstart to the end of the kernel line and it will boot up using 
upstart.  Last lines in my boot read failing to load default.service and then 
failing to start default.service.


Check one of the recent previous messages.


ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target


Will solve that problem and get you a bit further along the way.


darrell 

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

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

Re: [HEADS-UP] systemd is now the default init system in rawhide

[darrell pfeifer]

On Wed, Jul 28, 2010 at 21:20,  wrote:

> I found a fix on bugzilla:
> rpm -e --nodeps systemd-units
> yum install systemd-units
> Which created the symlinks and default.service which seemed to be missing,
> and allowed the boot to finish, but I may have been to quick to use it.  One
> CPU core is at maximum and Chrome won't open, so I'm temporarily back to
> upstart till I get time to look at it further.
>
>  https://bugzilla.redhat.com/show_bug.cgi?id=618315
>
>
> Thanks for the info and the bugzilla.

Reinstalling systemd-units got me a mostly working system.

I also had the same problem with one core using 100% CPU, in my case for
Xorg.

Added my comments to the bug.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 14 Alpha Blocker Meeting #3 Friday @ 16:00 UTC

[Matt McCutchen]

On Wed, 2010-07-28 at 19:33 -0700, John Poelstra wrote:
> 597858 :: NEW :: firefox :: Gecko Maintainer :: "SELinux is preventing 
> firefox from making its memory writable and executable." crashes rawhide 
> firefox start :: https://bugzilla.redhat.com/show_bug.cgi?id=597858
> --It's unclear if this should remain a blocker bug.

https://fedoraproject.org/wiki/Fedora_14_Alpha_Release_Criteria#Alpha_Release_Requirements

14. It must be possible to run the default web browser and a terminal
application from the default desktop environment. The web browser must
be able to download files, load extensions, and log into FAS

-- 
Matt

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